Reporting, often also referred to as Analytics, in the Suite is different from the more common WYSIWYG query preparation tools.
- those tools create a single query to the database that is immediately executed and its results returned to the screen.
- the Suite reports are custom programs created by a SQL programmer to a specified business need, contain a process of many SQL queries, filtering and logic which is executed upon request and results written to a persistent database table for future retrieval and display.
So, let’s just talk a bit about this different kind of reporting.
Selections You Make and Selections Made for You
You make selections by clicking on the values offered in the page selectors that the report offers. These choices provide a gross filter to the data that is included in the report, and allow you to point the report where you want to focus. To the extent that you are offered a selection against a data dimension the data is reduced, or further defined, by your selection. BUT, until you know the business specification of the report, its raison d’être, you aren’t sure what that selection will accomplish.
Let’s say you are presented with a “Location” selector which shows you the store hierarchies available to you. You choose one of them, drill down two levels to the “Division A” aggregate node and select that. So, your selection creates a report instance that acts upon the choice of “Division A”. But, what does that mean?
Depending upon what the report programmer was told to do your selection will lead to other decisions made for you. Your selection could..
- limit the page data in the report such that the metric values displayed are the aggregate of all data coming from the just the stores in that node. Or,
- limit the store hierarchy to that node and all its descendants so the report can drill-down from that node down to the store level. Or,
- limit the store hierarchy to
- that node, and
- all its descendants. So you can see the constituents of its data. And,
- all its siblings. So you can see where it fits in performance to its peers. And,
- all its ancestors. So you can get some idea of how that node participates in the performance of the total company. Or,
- Something different
Other Selections Made for You
Availability of Selectors
Sometimes the specification will allow full access to dimension views and sometimes not. Example
- a report is designed as a drill-down into the store dimension. In that case the Location selection process that normally allows selection by Hierarchy or by Attribute would be limited to just location by Hierarchy (which supports drill-down).
Filters on Dimension Values
- When an implementation is focused on understanding household shopping for the purposes of communicating to those identified households it is common to exclude transactions made without a card swipe (card_id=0). This reduces the data in the report so that a “total” in that report will not foot with a total from an accounting report.
- When a segmentation is focused on identifying shoppers by a certain (set of) behavior(s) it is common to exclude households or cards that display behavior contrary to the purpose of the segmentation. Behaviors like
- haven’t shopped in the last 6 weeks
- have shopped less than 3 times in the last month
- have more than 20 transactions per week
- shop in only one category, or purchase less that 5 different items
Whenever these filters are applied it reduces the data in the report, and any report that uses the result of the segmentation.
Why must I “run” a Report
Since the report data you see is the result of a programmed script having been run
- using your instance selections
- using the data in a database
we require a distinct event to occur to tell us “Yes, I’ve made all my selections and am ready to run the report.” This just means you need to click on the run icon , but until then we haven’t done anything.
When you click on that button the system puts the report script and your choices into an execution queue and depending upon the
- load on the database system
- the number of reports being run ahead of yours
- the size of the database engine you are using
- the size of the data identified by your selections
the report will complete either sooner or later. Some reports run in under a minute others could take hours. The reports in the Suite don’t shy away from the difficult issues! If you have an analysis that is that difficult, we can still handle it.
To make your life a little easier
- you don’t need to sit and wait for the report to complete. You may navigate away from that screen and do other work while the report is running. When complete a little message box pops up to tell you its done.
- if you ask for a report that has already been run the answers have been stored in a database table so you don’t need to re-run the report, it will just immediately display once your selector specification is complete.
- reports that are based on a relative time selection, like “complete” month, will be automatically re-run when the time granularity progresses (the month closes) so when you revisit the report the new data is already there.
Making a Shopper Group in a Report
A shopper count in a cell in a report is a truly wonderful thing. All the logic and filtering and selection that went into the report are at work, and that could be quite a lot. We were thinking that just reading that number, although valuable on its own, was missing something. Users were asking how they could save that count as a list of shoppers that made up that count, and then use that list in either another analyses, or to direct messages/offers to those shoppers.
We heard you, and voilà, all you need to do is click on the cell(s) of interest and you can name and save that number as a list of shoppers. That list is then available under that saved name for use as
- a report filter
- a preferred shopper list to “target” messages/offers in the weekly individual circular process.
Kinda ties it all together, don’t ya think?