Hi everyone!
I'm working on pulling HH data by FY/Season (ours is the same) for a board report looking at increase/decrease of HHs and attrition rates.
In T-Stats I simply used:
Filter/Slicer: Ticket Order Date = FY
Categories: Price Type Category (This gives me specific amounts for Comps, Discount, Standard, and Subscription). Currently just looking at any ticketed household.
Measures: Constituents (since we're looking for households)
I've exported the results to a list, created an output set with Ticket History Order Date Between 9/1/2016 - 8/31/2017 (our Fiscal year) - because I want to see the order dates to confirm Tessitura is providing the correct data.
What I received back was interesting, there are over 1300 records with no order date listed. I went through and spot checked a slew of records. They all have orders during the month of August 2016 ( this is the month prior to my requested output of 9/1/2016 as well as the month prior to our FY start date of 9/1/2016.) and there are no commonalities between them. Some are paid, some comp, others are tickets that were refunded or exchanged, etc.
Two questions:
Has anyone ever experienced this? Do you have any idea why this would occur? It doesn't make sense to me that Tessitura would provide an output that doesn't truly qualify for the request?
Is there a better or more accurate to get this information? I would prefer to exclude comps and subscriptions. I'm frequently baffled by results when attempting this as well given a constituent record can have in a single FY/Season, comps, subs and standard/single tickets. Extractions aren't great because exclusion segments are all or nothing. I thought T-Stats may be the solution, however, if I exclude the "comps" category, is T-Stats also all or nothing? Sadly, I'm not a big fan of lists because I find the output can be unreliable.
I'd love to hear what others use and to find an answer for the mystery of listing a household with no order date. I've scoured the network but I'm not finding exactly what I'm looking for.
Thank you!
Michelle, your organization is a sublicensee in a consortium, correct? If so there a few things that jump out at me based on your description of events.
The first is you mentioned your FY and season are the same, but your criteria is based on order date. While it's certainly reasonable to want to report based on order date, generally I'd expect some performances may go on sale in advance, and thus orders in a particular FY do not necessarily align with performance in that FY. If you truly do want to review by season, then I'd recommend swapping out your order date filter for a season filter instead. If your goal here really is more about when the orders came in, rather than what the orders came in for, then this may not need to change, but I thought it was worth mentioning.
Second, unless you have customized T-Stats to do otherwise, the "Fiscal" dates in T-Stats are all based on the FYs defined in TR_BATCH_PERIOD in Tessitura. At the moment, there is no standard out of the box way in Tessitura to define different fiscal years for different organizations in a consortium. If your September to August fiscal year differs from the fiscal years defined in TR_BATCH_PERIOD, and your T-Stats filter were literally just Order Date > Fiscal > Fiscal Year, then your T-Stats report may not have been limiting to the time period you intended. You could swap the Fiscal Year filter in T-Stats for using the Calendar Year Hierarchy and then selecting the desired dates to be sure.
Another thing to keep in mind is when you save a list from T-Stats, it's a static list with no criteria. So when you overlay an output set on top of it, what you're getting is whatever you requested in that output set about those particular constituents. But there's no connection to the original reason why they ended up in the list.So for example, they could have had orders on one set of dates (putting them in the T-Stats report) and also orders on various other dates, which would potentially show in the output set. Both things can be true, but they're separate and showing up for different reasons. Also if you ever import external sales directly into Ticket History (similar to how conversion data is handled), those orders won't natively be in T-Stats, but if you're using Ticket History criteria in your output set, you'd potentially see those orders there. So using an output set to try to validate a T-Stats report is not a guaranteed apples to apples comparison.
For the orders you were looking at with no order date listed in the output set, I'm wondering if these were unfulfilled rollover orders? T-Stats by default doesn't include unfullfilled rollovers (ie completely unpaid rollovers) but it does have an optional setting to include them. I'm not sure if your environment currently has those in T-Stats, or if they'd be loaded into your Ticket History, but that's another thing to consider. If you're looking at increase or decreases in households with tickets over time, I'd probably recommend excluding unfulfilled rollovers from your report.
If your real goal here is to look at how many single-ticket households you had a given year vs the next (or the last) I do think you could accomplish that using T-Stats. Since you're dealing in aggregates, it's probably easier to look at it that way than using output sets anyway.
For your question about Comps, in T-Stats, if you exclude the comp price type category, then your report will not include any tickets booked with a price type that has that category. However, that doesn't necessary exclude all $0 tickets, as it's possible to have a free ticket associated with a different category. So that is something to be mindful of. If a given constituent has both comp and non-comp tickets, excluding the comp tickets from the report will not entirely remove that constituent from the report. That constituent will still be present due to their other tickets.
If you wanted to look at just the total number of constituents with non-comp, non-subscription tickets season over season, I recommend the following recipe:
New Report in the Tickets cube
Add to Filter/Slicer: Ticketing Price Types - Price Type Category, untick Comp, Subscription
Add to Categories: Ticketing Season - Season (or Ticketing Season - Season Fiscal Year, either are good options here), select desired seasons/FYs
Add to Series: Measures - Num Constituents
If your goal is something more like finding out how many NEW constituents you have in certain years, you'd probably want to do some overlaying with lists. The lists could have been created from T-Stats, or list manager or extractions depending on how fancy you want to get with your criteria. Essentially you'd use an approach similar to this: https://community.tessituranetwork.com/topical_groups/tstats/b/tstats-blog/posts/how-many-of-these-are-those
If part of what you're trying to do is more complex, such as...if a person had subscription tickets in a given year, even if they also have single tickets, don't include them in the count of "single ticket constituents" for that year, you can do that too.
I know that probably doesn't answer your question about what you were seeing with your output set, but I hope it does help with the analysis you're trying to do in T-Stats.
Hi Amanda,
Yes, we're part of a larger consortium. This is fantastic information and makes perfect sense. I had no idea the FY table was limited. I switched to the recipe provided before reading and found the results to be more accurate. I suspect I'm overthinking this, though I'm trying to understand the how T-Stats, Output Sets and Lists "think."
If there is documentation that explains the intricacies of T-Stats rather than the broader "how to" that would be helpful to me.
We do not currently use the rollover feature for subscriptions. My thought was, pull the broader data from T-Stats into a list and further refine those constituents to find "of these" HHs who is in/not in or has/does not have a purchase via a particular Price Type, MOS, etc. My understanding is that is part of the function of lists/output sets.
I ended up pulling all constituents by season who had a ticket purchase on file and used the compare tables function in Excel. This is something I should easily be able to do with a list and output set yet ended up with far less HHs than those I came up with doing the comparisons outside of Tessitura.
Finally, our data is not as "clean" as it should/could be as. There were sadly too many "cooks" making decisions about season setup and there is a lack of consistency from year to year. I find this to be very problematic and have learned that you really have to spend time mapping out your season set up in order to ensure great data pulls later!
Thank you again for your valuable insight and assistance!
Michelle
Hi Michelle,
The T-Stats User Guide (this is the latest: www.tessituranetwork.com/.../TStats-v5-User-Guide) has a glossary section at the end which explains where everything comes from in Tessitura (as well as notes about which items are configurable). That may be of interest. That said, the FY configuration issue we were discussing earlier is not specific to T-Stats. That is moreso general Tessitura functionality, which is reflected in T-Stats. Many orgs do customize around that particular issue though.