Comparing ticket buyers and tickets for two or more events

Nicola Cann,

I'm not in a place where I run this as a test.  But, I'm going to try to provide a hint quickly.

If you are trying to do this in Tessitura Lists.

For both try two ticket history lines.  Home Has Performance A, and the Second Line Has Performance B

For only one of the Two performances and list that Has Performance A and Does not Have Performance B

See if this helps out.  Give it a test, please let us know how you are getting on.

Hi, Thanks for your response! I should have specified - I'd like to be able to set this up as a widget/as part of a tessitura analytics dashboard - I have a dashboard set up where I'm tracking a number of other metrics for these series and I'd like it to all be visible in the same place.

I've done a list for now, but this also doesn't give me ticket counts to each of the categories which I'd also like to see.

Thanks for the suggestion!

Nicola Cann,

So, cool...  You have a list.  You can use that list as a filter in Tessitura Analytics. (That list number will show up for the first time the day after you create the list in Tessitura. It takes a nightly refresh for this list to appear in Tessitura Analytics)

However, you need to take a few steps to make sure that the list is refreshed prior to the daily refresh of the Tessitura Analytics data.  First the list needs to be marked as a dynamic list.  There is a "standard report" that can be scheduled with the report scheduler to do a daily re-fresh of the members of the list so as new folks by both shows the list gets updated.  I don't remember the exact name of the report/utility but it something like Update the list report, or something like that.  Or the List Members report.. The key idea is you have to run a report that forces a refresh of a list.  And then Tessitura Analytics comes along and grabs that updated list of members of the list, that you can then use in your Tessitura Analytics Dashboard.

There may be some more clever ways in Tessitura Analytics to do the filtering you want.  However, I don't know this off the top of my head.  You might reach out the topical groups here on TessituraNetwork.com called either analytic Coffee or Tamato (Tessirura Analytics for Marketing and Ticket Operations) one of the folks in those groups may have some off-the-top-of-the-head ideas to help further.

That's my $0.02 for the evening.

Some great Analytics advice from Tom!

One further thing I'd add (which caught me out the first time when using Lists in Analytics!)... In your Lists filter, use the "Text" filter type, with the condition operator as "Containing", then put the List ID with a comma on either side. Otherwise you get some crazy results. 

e.g. (hopefully screenshot will show below)

, Great Point!!!

Hi Nicola,

This was a really fun use case, so I wanted to dig into a bit and prove it out. Thanks for engaging! Maybe grab a beverage...

As an alternative to the great List recommendation, this can also be approached in a few ways entirely within Tessitura Analytics. I recommend working through this in another dashboard first... We'll need to use a bucketing formula (more about that in this webinar) similar to the one in the pre-built Tessitura Dashboards > Seats and Tickets > Jump to Dashboards > _Single_Tickets called Number of Performances by Customer. I'd recommend something grouped by production season, where the first production season to open is at the left and the last one at the right. Then stacked values within each production season for the count of constituents for whom the given production season is their first from those in the widget, and broken by how many of the production seasons in the widget they purchased in total.

You can break this down in a number of ways, and I'm going to start with the Production Season sort value I'm using (it's mostly not visible in the widget, and is subtle in the legend at the bottom, named as just a period ".". 

MIN( DDIFF ( [Days in Production Season Opening Date] , NOW([Days in Production Season Opening Date]) ) )

Within each production season on the widget, this is the minimum number of days between the Production Season Opening Date and NOW(). Formatted this way (rather than between NOW and the Opening Date) returns a negative number for past production seasons, and positive for future, where the first Production Season Opening Date will have a lower, number and the most recent Production Season. This allows us to sort the value ascending. Flipping it around to "between NOW and Opening" requires a descending sort, which feels less intuitive to me.

With that value in place, we can leverage it further to determine the count of constituents for whom that value is their MIN of that value from across all their production seasons in the widget. Within a production season, for a constituent, if this value is their min production season sort value from across the whole widget (all production seasons), then "this production season" is the first from among those in the widget to which they held tickets. So for each constituent, if...

MIN( DDIFF ( [Days in Production Season Opening Date] , NOW([Days in Production Season Opening Date]) ) )
 = ( MIN( DDIFF ( [Days in Production Season Opening Date] , NOW([Days in Production Season Opening Date]) ) ) , ALL( [Production Season] ) )

...then this production season is their first. (Read more about the ALL() function here.) The first MIN value is limited to pull the sort value for the production season we're within at any given place on the axis. The second gets the MIN value for that constituent across all the production seasons they've purchased. In order to turn that into a Value for a widget, we need to group that evaluation by constituent. We need Analytics to make that comparison within each constituent in the production season individually, and not just across all constituents at once, and then count only the constituents for whom that conditional statement is true. (More about Multi-Pass Aggregation here.)

SUM ( [Constituent ID] ,
 IF (
 MIN( DDIFF ( [Days in Production Season Opening Date] , NOW([Days in Production Season Opening Date]) ) )
 = ( MIN( DDIFF ( [Days in Production Season Opening Date] , NOW([Days in Production Season Opening Date]) ) ) , ALL( [Production Season] ) )
 , 1 , 0 
 )
)

At this point we've got a count of constituents within each bar for whom "this" production season was their first from among those within the widget. To then break that count by those constituents' count of productions purchased, we add another condition to the formula above, such as:

SUM ( [Constituent ID] ,
 IF (
 MIN( DDIFF ( [Days in Production Season Opening Date] , NOW([Days in Production Season Opening Date]) ) )
 = ( MIN( DDIFF ( [Days in Production Season Opening Date] , NOW([Days in Production Season Opening Date]) ) ) , ALL( [Production Season] ) )
 AND ( [# of unique Production Season] , ALL( [Production Season] ) ) = 5
 , 1 , 0 
 )
)

This is now the count of constituents within each bar for whom "this" production season was their first from among those within the widget, AND they purchased exactly 5 distinct production seasons from among those anywhere in the widget. Rename this value to something like "5 Show Buyers" and click OK. Then duplicate the Value from its Options menu. Edit the duplicate. Change 5 to 4 and rename it "4 Show Buyers." Etc. Then set the Column Type to be Stacked.

The widget is looking really good at this point, but is missing a sense of the total count of constituents within each production season. So we could add a value to the stack of constituents for whom this production season was NOT their first from among those in the widget. This is really just flipping around the conditional check of whether this IS their first production season, to instead check whether their MIN for this production season is greater than their MIN from among ALL production seasons they purchased within the widget. (Note the greater than ">" instead of "=".)

SUM ( [Constituent ID] ,
 IF (
 MIN( DDIFF ( [Days in Production Season Opening Date] , NOW([Days in Production Season Opening Date]) ) )
 > ( MIN( DDIFF ( [Days in Production Season Opening Date] , NOW([Days in Production Season Opening Date]) ) ) , ALL( [Production Season] ) )
 , 1 , 0 
 )
)

This makes the overall height of each column representative of the full count of constituents in each production season, The last optional bit I'd add is a line chart of a simple Total Constituent Count ( [# unique Constituent ID] ), behind the columns, so that when moussing over the top of the column, that total total count is available in the tool-tip that appears.

I'll should call out that the dashboard filters are set to a dependent pair hierarchy of Season > Production, and NOT Season > Production Season. Widget filters override  Dashboard filters, and Formula filters override both Widget and Dashboard filters. Were the Dashboard filter set with Production Season, then the Formula filter for ALL([Production Season]) would have broken out to all Production Season in the selected Season, regardless of any subset that may be selected in the dependent Dashboard filter for Production Season. So, to filter out Guys & Dolls and Honeymooners, leaving only the latter 3 production seasons in the widget, the whole "is this production season a constituent's first production season" would still included those 2 excluded production seasons in it's calculation. The ALL([Production Season]) in the formula would override the Exclude Guys & Dolls and Honeymooners filter on the Dashboard level. By using Production instead, the Dashboard filter is not overridden by the ALL() function, and the widget maintains its flexibility to respect the selection in the Dashboard filters and calculate within that scope. E.g. note there are no 5 event buyers in this screenshot:

With Production Season on the Dashboard filters, Mary Poppins ends up having a Prior Event Buyers value on top, and doesn't count these constituents as "this is their first Event" constituents:

ProductionFrequency.dash

Best,
Chris

Thanks for the thorough description and shared .dash, Chris! However, to me, this is backward. It shows that our very first exhibit had lots of repeat guests. It also shows that the current exhibit has seen half of the people being first-timers and half have been to one exhibit before. Let me know what I need to edit to correct this. Thank you!7652.ProductionFrequency.dash

Hi Tony,

This widget doesn't reflect the order of purchase. It's about segmenting each show by the constituents' total show count within each show, from the selected show filter. If I purchased every show in the widget, and there are 5 shows, then I'm represented in the "Constituents w/5 Shows" value of every show, regardless of whether it's my first show, last show, or something in between.

Hope that helps,
Chris

I see what you're saying, Chris. However, what I am seeing still doesn't make sense. Again, for our current show, it says that half have been to one show and have are first-timers. This is not the case. Many of the repeat guests that have seen this show have seen more than one. 

We might need to move this one to a support ticket to have as close a look as we might need, but I have one thought first... the widget is only designed for displaying 5 or fewer shows. It feels not likely, but is it possible that the attendees for your current show are made up of only first timers, one-show constituents, and constituents with > 5 shows? No one that has been to 2-4 shows. If you change the "5 Event Buyer" formula to >= 5, do additional constituents appear?

Hi Chris- I changed the formula per your suggestion and it did not make a difference. I already submitted this as a ticket on 12/16 and after a few weeks, was told it would need to be some sort of customization, which seemed odd to me. It's ticket 399183.  

Hi Tony,

I'm confused by "half have been to one show and have are first-timers." In this widget, those should be the same thing. The 1 Event Buyers on a given show haven't attended anything prior to that show. 

Rereading my post above, for any "N Event Buyers" value, that value only renders a constituent on the production that is their first in time from all the productions in the widget. For all subsequent productions to which that constituent held tickets, that constituent is in the Prior Event Buyers bucket.

Is it possible in your case it's the Prior Event Buyers that look like the half that have been to one show? If so, that's the bucket that segments constituents for whom this was not their first show, but doesn't segment how many shows prior to that they purchased.

Chris

Chris! It is all clear now! Thanks for this explanation! So in the end, what I would like to get at is what you describe in that last sentence. For the current show, how many shows has each guest been to? Is this something we can parse out with an adjustment to the formula? Thank you again!

Absolutely Tony.

Using the Prior Event Buyer as a model, add to it the production count criteria from the N Event Buyer values:

AND ( [# of unique Production Season] , ALL( [Production Season] ) ) = N

Only do this for 2 and up so since 1 Event Buyers in a given production are already covered. Probably also warrants renaming and recoloring the values...