How Dashboard Dates and Date Ranges Work

This page covers the dates behind the dashboard. For how to build your dashboard and what each tile counts, see Understanding Your TicketingHub Dashboard Tiles. Nothing here changes your reports or your orders — it only affects which figures a dashboard tile adds up.

Choosing What a Date Means

Every tile counts things that happened on a date, and there are two dates to choose between:

Date booked on counts on the day the sale, payment or refund was recorded.
Date booked for counts on the day the experience takes place.

A tour booked in March for a trip in July counts in March on Date booked on, and in July on Date booked for. Use Date booked on to see how trading went, and Date booked for to see how busy you will be. These are the same two dates your reports already offer, named the same way.

The two will rarely match over the same range, and neither is more correct than the other. Check which one is selected before comparing figures or explaining a difference to someone.

Which Time Zone Each Date Uses

A sale is recorded in your account’s time zone, because when you took the money is a fact about your business.

A visit is recorded in the product’s own time zone, because when an experience happens belongs to the place it happens in.

This only makes a difference if you sell products in more than one time zone. If all of your products run where your account is based, the two are the same and you can ignore this.

If you do sell across time zones, an example: you are based in London and sell a New York tour that runs at 9pm on 5 May. On Date booked for it counts on 5 May — the day it happens in New York — rather than being pushed into 6 May because London had already moved on. Your local figures stay on your local days, and each product’s visits stay on its own.

Why a Date Range Can Widen

To stay fast over long histories, the dashboard keeps recent activity day by day, and older activity grouped into whole weeks and then whole months. Nothing is lost, but older periods are held less finely.

If the range you pick starts or ends part way through one of those grouped periods, the dashboard widens it to the whole period and shows you what it used: the dates in the picker change, and the grouping changes with them.

For example, asking for 14–31 May in a period that is kept by month will show you 1–31 May, grouped by month.

That is deliberate. A figure held for a whole month cannot be split into part of a month, so the alternatives would be to leave that month out or to show part of it as though it were all of it — either of which would give you a total that is simply wrong. Widening the range keeps the number honest and tells you what it covers.

Recent ranges are unaffected, so day-to-day use never runs into this.

A very long range is grouped more coarsely for a different reason: so a chart stays readable. More than about a year is shown by week rather than by day, and more than about seven years by month, and the picker shows the grouping it used. A range reaches back no further than 1 January 2011, where All time starts, and no more than ten years ahead.

Counting Bookings That Hold Several Ticket Types

Most bookings hold more than one kind of ticket — two adults and a child is one booking, not three. So when you ask a booking question about a ticket type, the dashboard answers it about whole bookings.

Filter a Bookings tile to Adult and you get the number of bookings that included at least one adult ticket. Filter it to Child and you get the number that included at least one child ticket. A family booking is in both answers, because it genuinely is both.

That means the ticket types will not add up to the total, and they are not meant to. A week with 100 bookings might show 95 including adults and 60 including children. Nothing is being double counted; you are asking three different questions and getting three correct answers.

Money and people behave differently, and the difference is worth holding on to. Those are divisible: filter Sales or People to Adult and you get the adult share of each booking, and the shares do add back up to the total. A booking cannot be divided that way, which is exactly why its count does not.

None of this applies to filters a booking has only one of. Filter by product, channel or reseller and every figure adds up as you would expect, bookings included.

Some figures cannot be filtered by some things at all. A payment is taken against an order rather than against a product, so there is no way to say which product it belongs to. Filter by product and the Payments, Refunds and Commission tiles say Not available with this filter rather than showing a figure that would only ever read zero. The same happens the other way round: filter by payment type and the tiles for sales and bookings say it instead. Remove the filter and the figures come back.

When You Change a Sale’s Details Later

The dashboard records each sale with the details it had when it was made: the product, ticket type, channel, reseller, user, coupon and so on. Changing one of those details afterwards does not move the sales already recorded.

For example, if you move an order to a different reseller, the original sale stays with the first reseller, and the new reseller’s figures only include what is recorded from then on. Anything recorded after the change, such as a later refund on the same order, goes under the new reseller. The same applies if you apply a coupon to a booking after it was made, move a sale to a different user, or change the type of a ticket.

Your dashboard shows what happened at the time, rather than rewriting the past each time something is edited. The order itself always shows its current details.

Drilling Down to the Transactions

Every tile showing a figure offers Drill down in its menu, which lists the individual transactions behind that tile’s figure. It carries across everything the tile was using: the figure it was showing, the same date basis, the same date range, and every filter you had applied. The list you land on is exactly the transactions behind the number you clicked.

That last point is worth taking literally. Drill down from Sales and you get the transactions that changed your sales — nothing else. A payment against one of those bookings is not in the list, because taking the money does not change what was sold; drill down from Payments to see it there instead.

The list breaks each transaction down into the parts it is made of, one row each, so a booking of two adult tickets and a guidebook is three rows. Each row names what it is against — the ticket, the extra, the merchandise or the tax — along with its ticket type, so you can see what a figure is made of without opening the order.

Alongside that, a row carries the order and booking references it belongs to, the product and ticket category it was sold under, where the sale came from, and for a payment the kind of payment it was. Between them that is usually enough to settle a query without leaving the page, and the order reference links through to the order when it is not.

Only the parts the tile counted are listed, and the Amount column shows each part’s own value. For sales, payments and most other tiles the column adds up to the tile. Tiles that measure something taken away — cancellations, refunds, expired value, commission and allocated cost — show that amount as a positive figure, while the list shows each transaction the way round it reads in your accounts, so there the column adds up to the tile with a minus sign in front. That matters most when you have filtered to something a booking only partly consists of: filter to one ticket type and you get the rows for that ticket type alone, which is exactly what the tile is counting.

Quantity, People and Amount all read the same way round, so you can scan across a row without checking which column you are in, and everything reads from your side of the counter. A sale is positive in all three, and a cancelled booking of five adult tickets reads −5, −5 and a negative amount. The same holds for money: a payment you took is positive and a refund you gave back is negative.

Every row carries both of its dates, whichever one the tile was counting on. The Date booked on and Date booked for columns are the same two dates the picker offers, so a row reads the same way whichever you arrived on, and both show the time as well as the day.

The basis still decides which rows are in the list, so switching it changes the transactions you see rather than the meaning of a column. And if the range was widened to whole weeks or months, the list covers the widened range too.

Click any column heading to sort by it, and click again to reverse it. Export as CSV takes every transaction your filters select rather than the page in front of you, so it is prepared in the background and offered to you when it is ready.

If you have moved, added or removed tiles without saving them to a view, drilling down asks you to confirm before it leaves the dashboard, because the arrangement would be lost. Save the view first if you want to keep it.

Quick Checks

When two totals disagree, check the date basis first and the date range second. Most differences are one of those two.
If the dates or the grouping changed after you chose them, you have asked for a period that is kept less finely. The figures are right for the range now shown.
If your visit figures look a day out from what you expect, check whether that product runs in a different time zone from your account.
If a tile’s figure and the transactions behind it seem to disagree, check the range shown in the picker. A widened range covers more days than you asked for, and the list covers the same days as the tile.
If a transaction list looks like it is on the wrong dates, check which of the two date columns you are reading. Both are always shown, and only one of them matches the basis the tile was counting on.
If a reseller, user or coupon’s figures look different from what the orders show today, check whether those orders were changed after the sale. A sale stays under the details it was made with.
If booking numbers for each ticket type add up to more than the total, that is correct. A booking holding several ticket types is counted once under each of them. Sales and people divide between ticket types; bookings do not.