STBs Attended 3+ Productions in last 5 Years

Hi Michelle,

Set a filter on Season Current Fiscal Year Offset using a Value type filter of between -5 and 0 (or Season Fiscal Year and select the past 5).

Set another filter on either Price Type Category, selecting only the Single Ticket categories, or a filter on Package Season set to include only "(none)".

In a Pivot Table, add Constituent details on Rows (ID, Display Name...). In the Values panel, add a Unique Count of Production (or Production Season). Then hover over that Value and click the funnel icon to filter the results, selecting a Value type filter of >= 3.

Cheers,
Chris

Admittedly I have not spent much time in analytics because I have been focused on building our data integrity in the application, but aren't ticket sales in Analytics based on data from T_TICKET_HISTORY?

If T_TICKET_HISTORY is the source of ticket sales then the sales reflected in analytics will not be correct if an organization does things like credit admission tickets to the cost of a memberships by processing the tickets as returns given that returned tickets get removed from T_TICKET_HISTORY whenever TP_UPDATE_TICKET_HISTORY is run for the season.

The other issue with sales in analytics is that it uses the Order date as the sales date which is not necessarily the date the ticket was actually sold. Under normal operations our business model has scenarios where we have running order or orders that get created days sometimes months prior to when the sale is actually recorded.

For example if we started a running order in on January 1st for a trade customer for the month of January all sales for that customer in that order would have a sale date of 1/1 even if the tickets were actually sold multiple days throughout the month.

This also means in the sales number being reported in Analytics for a given day can change depending on if someone adds or removes tickets to an order with an historical sales date.

Lastly Order date is not a static value in that people can go in and change the date at any point in time resulting in completely different sales numbers for the affected dates when they do. While the field can be locked down, it still represents an opportunity for inconsistent sales data.

Hi Ronald,

Analytics optionally can include converted ticket history from a legacy system, but doesn't by default. Analytics always includes live orders.

In addition to order date, you can reference the CREATE DATE on the sub lineitems in an order. This is the date a ticket was added to an order.

I hope that helps,
Chris

Good to know.

We don't use create date from T_SUB_LINEITEM because that is not necessarily reflective of the sale date given that for a wide variety of reasons a ticket line can be added to an order long before it is registered as a sale and in certain ticket states it can be removed from an order without an offsetting transaction resulting in inconsistent reporting for a given date range.

We use the following logic to determine the sale date as this will always reflect the same numbers for a given date range and time.

Select sl.Sli_No, Printed_Date  as SaleDate, Order_no
, sl.Perf_no, price_type , due_amt as Price, sl.seat_no , sl.sli_status
, zone_no ,t.printed_loc , 1 as Qty, t.printed_by  from TX_SLI_TICKET as T
inner join T_SUB_LINEITEM as SL on t.sli_no = sl.sli_no where reprint_no = 0

Thank you Ronald,

That sheds a lot of light on your practices. It may not help you, but for clarity on the thread, removed SLI are removed from Analytics as well.

Is the printed date in you case also the date of attendance or the event (performance) date?

Thank you Ronald,

That sheds a lot of light on your practices. It may not help you, but for clarity on the thread, removed SLI are removed from Analytics as well.

Is the printed date in you case also the date of attendance or the event (performance) date?

Until the changes we put in place for Covid performance date was an irrelevant date for us for GA tickets given that our tickets were good for a year.

That the line gets removed from Analytics is what I was referring to as part of the data consistency problem. If on February 1st I run a sales report for the month January or view a dashboard it should reflect the same exact numbers when viewing that date range 6 months later. Given that in February or March someone can go in and remove SLI records for lines that have not been ticketed it means the report I run on 2/1 may not show the same totals when I run it again on 9/1 for the exact same date range.

It might not be that big a deal if it was just a handful of tickets, but for us it could be a big enough number to move performance against budget and breakage numbers by several percentage points as we have orders of a hundred tickets or more where the order clean up process for canceled groups could result in the removal of thousands of tickets.

While some of that could be managed through process and permissions those solutions are not perfect. For that reason we divide tickets sales into the following buckets:

Unissued – Sales tickets on orders that have either not been paid for yet or printed. This number is not constant as the tickets can be removed with no financial transition

 Issued – Any ticket that has been assigned a ticket number. This can only happen when a ticket is fully paid or a 0 dollar ticket. The record cannot be deleted

 Exchanged – Any ticket that was returned and exchanged for a different performance

 Upgraded – Any ticket returned and applied to a membership

 Returned – Any ticket that was returned but not exchanged or upgraded

 Net – Issued - (Exchanged + Upgraded + Returned)

Returns are broken down into 3 categories so that when looking at the net sales people have some understanding of what actually went into the net sales number.

Here is an example of of sales from 7/1 as to why we can't use the canned reporting in the application or Analytics for our sales reporting:

As you can see the majority of sales from that day are no longer reflected in Analytics because the tickets have been returned. That they have been returned doesn't change the fact that on 7/1 we sold over 12,187 tickets with only 86 tickets returned that day.

The Ticket by sales period report is wrong because it factors in tickets that have not been fully paid. This is an example of the kind of order that results in an inaccurate sales total:

The report shows 2 tickets sold for 125 dollars, but that is not correct. The price of each ticket is 49.95. In short the deposit is showing up as sales and is skewing the per ticket price average.