I'm figuring out how to use Bucketed Values within Tessitura. In one of our dashboards, I'm looking at day-of sales and pre-sales for General Admission sales (pulling in three production seasons).
For day-of sales, I used one method initially, a simple one:
Values = [Attended Count], and a Widget Filter of [Order Days Prior to Performance] = 0.
+ =
The second way, more complex, is to use bucketing:
=
My understanding is the both methods are asking the same question, but one is 2 higher than the other. Why would that be?
When I use the same two methods for pre-sales ( [Order Days Prior to Performance] < 0 ), the numbers agree.
When I use those same two methods for pre/day-of sales in a different dashboard (our Timed Admissions only), both agree.
I've narrowed it down to one particular Production Season, but why would this be the case? Why would one method give a different number for one production season, but not the others?
Hey Nathanael,Now I don't have an answer, but I do have some thoughts that may help you identity the difference. When you run the attendance by performance report, what is the result? Which does it match to? Are you able to identify the what the two different tickets are? Perhaps you can add ticket price type quantities to help locate the difference. Maybe tickets were scanned out and then back in? Or maybe reprinted/reissued and then scanned back in?Hopefully someone has a more solid answer for you. Good luck!
An ABP gives me slightly different numbers, ones that don't match up- two Production Seasons yields different results from ABP to Analytics- only one is consistent between.
One Prod Season is off by 97, one is off by 4. Not sure how to proceed with that!
Hi Nathanael,
ABP is limited to SLI Statuses of Seated, Paid and Ticketed, Paid, in case that could play into your discrepancy. However, there's a couple of elusive defects on the list...
DEV-3795 Pivot Table export to Excel with Sub/Grand Totals do not add up correctlyDEV-4237 When changing widget type from Pivot to Indicator the grand total changes to an incorrect number
DEV-3795 in summary, the numbers in the rows of a Pivot table are correct, but the grand total isn't the sum of those rows - and I'm not talking about a distinct count where something or someone could be counted once in one row and once in another, and then only once in the grand total. The work around is to set the Pivot value to subtotal by "Sum" instead of "Auto". However, an Indicator widget, as in DEV-4237, doesn't have that option, doesn't have access to the Pivot row groupings to produce an explicit sum of those rows, and yields the equivalent of the Pivot's "Auto" grand total number.
I believe that there are two defects playing into this and may be the actual root cause:
DEV-3497 N-Scan, Duplicate rows appear in Attendance Data for scanned dataDEV-5842 Unanswered Post Code Survey Responses produce Dummy Post Code Constituents in Analytics
However it's the second one, which will be resolved in the August service pack, that is playing the biggest role in what you're experiencing. At the widget or dashboard level, if you filter out Constituent ID >= 0, it may even out between the two widgets. If you'd like to explore this further, let's get a support ticket for you and we'll dig in to confirm.
Best,Chris
Chris Wallingford Product Owner Tessitura Network office: +1 888.643.5778 x553 chris.wallingford@tessituranetwork.com
When I filter as you mentioned (Consituent ID >= 0), the numbers are still off by 2. Truth be told, I'm not thrown off by this much, it seems an oddity at most, but I was wondering if my filtering/bucketing was off.
As it stands, if the number stands at 2, I'll ignore it, and wait for the August Service Pack.
Thank you! I appreciate the investigation.
Hi, Chris. Stumbled across this post from 3 years ago that seems to describe what's going on with a current dashboard of mine. I can't find DEV-3795 in the known defects list or in any Release Notes (I may not be looking correctly). Has this issue been resolved? I can apply your fix for my pivot tables, but can't seem to for the graphs. And, I'm afraid that since I don't know my data well enough that I'll miss this in other widgets and report out incorrectly.
Thanks!
Hi Keri,
This is fixed in 16.0.0+. Because the defect was a Sisense defect, we needed to get up to a later version of their platform. We have begun work to bring v15.something up to this later Sisense version as well, but don't have release target for that yet.
Thanks for the info, Chris. I'll poke through my other dashboards and apply this fix.