Point In Time Reporting

Former Member
Former Member $organization

Hello everyone!

We have recently stumbled upon an 'inconsistency' in Analytics as it relates to sales reporting and how we match that to our financial reporting. 

As we try to dig in to something like "weekly" or "daily" sales we have come across totals that vary based on the day we pull them. For example:

  • A dashboard that is refreshed on Sunday evening states that we have $100 in total sales (with no date filter).
  • I go back in the following day (after a refresh), add ORDER DATE as a filter and see that total sales for that point in time are now $90, although overall sales have gone up.

This has made it difficult to assure Board & VP's (with confidence) that our numbers are accurate. My questions are two-fold:

  • Has anyone else noticed this?
  • How have you handled managing / explaining this upwards?

I think part of our issue is that the Tessitura database is a very fluid thing - especially as it relates to the order-date. Changes / adjustments made to orders (exchanges, returns, etc) will change how past days get reported on. Order Date isn't like a batch report date (or transaction date), which have a definitive end. 

Thanks in advance for any & all feedback!

Parents
  • Former Member
    Former Member $organization

    Thanks Heath!

    Overall - yes. We're trying to manage the understanding of "order date" vs "transaction date" for both ourselves and the executives here. We don't need to know about every little discrepancy, but seeing them has caused confusion among everyone here. Right now, we have our feet in two different reporting structures: a static excel report and Analytics. The excel report mostly provides us context for YOY sales and pacing. We just converted over to Tessitura, so our ticketing history is a work-in-progress.

    We're mostly trying to manage expectations of "accuracy" as it relates to Analytics (and sales reporting in general). Between myself and our Database Manager, I'd like to think we're mostly building them correctly - but it's been difficult trying to explain these discrepancies (re: structure) upward.

    I guess what I'm saying is (and looking for reassurance on): is our hypothesis that using 'Order Date' as a way to reference point-in-time sales a losing battle until shows / performances / seasons are fully closed? Secondarily - should best practice indicate that our daily / weekly / monthly reporting stay in one area (analytics) as opposed to trying to manage a static file as well? Knowing that changes in accounts can impact how order-date reports, this to me seems likely.

    Ed

Reply
  • Former Member
    Former Member $organization

    Thanks Heath!

    Overall - yes. We're trying to manage the understanding of "order date" vs "transaction date" for both ourselves and the executives here. We don't need to know about every little discrepancy, but seeing them has caused confusion among everyone here. Right now, we have our feet in two different reporting structures: a static excel report and Analytics. The excel report mostly provides us context for YOY sales and pacing. We just converted over to Tessitura, so our ticketing history is a work-in-progress.

    We're mostly trying to manage expectations of "accuracy" as it relates to Analytics (and sales reporting in general). Between myself and our Database Manager, I'd like to think we're mostly building them correctly - but it's been difficult trying to explain these discrepancies (re: structure) upward.

    I guess what I'm saying is (and looking for reassurance on): is our hypothesis that using 'Order Date' as a way to reference point-in-time sales a losing battle until shows / performances / seasons are fully closed? Secondarily - should best practice indicate that our daily / weekly / monthly reporting stay in one area (analytics) as opposed to trying to manage a static file as well? Knowing that changes in accounts can impact how order-date reports, this to me seems likely.

    Ed

Children
No Data