| Page Properties | Jira Initiative | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Page Properties | ||||||||||||||||
|
...
The following outlines details of each of the requested the dashboard views (of which there are four in total), and should inform the development of the underlying data models to power the use case.
...
2. [End Date] A feature to allow the user to select an end date of the analysis, expressed in the format yyyy/mm/dd. This will represent the end date of the date range being examined by the user.
This date range - along with all others across the dashboard views - should always default to YTD, unless specifically noted otherwise.
Callout Metrics: this first dashboard view should present users with a series of callout metrics that summarize the performance (& health ?) of Tim Hortons Digital & Loyalty during the user’s users' selected reporting rangeranges, as defined by [Start Date] and [End Date]:
Known Diner Sales Penetration: cumulative Known Diner Sales (all sales that are made by guests that have registered through the Tim Hortons app), expressed as a percentage of cumulative system-wide sales for ($) for the dashboard user’s selected time period. This metric is used as a baseline to see loyalty sales penetration to our against system-wide sales, and is a function of the following two metrics (KDS and SWS).
Known Diner Sales: (KDS) cumulative Known Diner Sales (all sales that are made by guests that have registered through the Tim Hortons app) for the dashboard user’s selected time period; expressed as a nominal dollar amount ($).
System-wide Sales (SWS): all sales across the Tim Hortons system for the dashboard user’s selected time period; expressed as a nominal dollar amount.
...
In addition to callout metrics, this view should also feature an option for users to to filter for one specific metric and display it across each province in a map visualization. For example, if the user selects Known Diner Sales, the map should populate each province with a percentage representing the proportion of Known Diner Sales that each province accounts for (e.g., Ontario accounts for 32.3% of Canada’s KDS). This is done by taking the selected metric’s value for each province and dividing it by the value for Canada (e.g., Ontario KDS / Canada KDS).
...
The first time-series chart, KDS Penetration Over Time, is intended to illustrate, using superimposed line charts, the evolution of KDS penetration throughout the dashboard user’s selected time period, compared to past years over the same time period.
...
Similar to the previous chart, users should have the option to drill up or down on the reporting cadence (e.g., daily, weekly, monthly, quarterly). Total guests, comprising all three types of guests, for each cadence will form one bar in the bar chart. For example, if the user inputted their time range as [Start Date] 2023/01/01 to [End Date] 2023/10/01 and drilled down the reporting cadence to “monthly”, comping guests in January 2023 would be the number of guests who made a purchase both in January 2022 and January 2023; non-comping guests would be the number of guests who did not make a purchase in January 2022 but did make one in January 2023; non-returning guests would be the number of guests who made a purchase in January 2022 but did not make one in January 2023. The count of comping and non-comping guests would accumulate to form the positive portion of the bar for January, while non-returning guests would be represented as the negative portion of the January bar. This would be repeated to create a bar for each month from January to October 2023. Similar to the previous chart, this chart will also feature the average of comping, non-comping, and non-returning guests for January to October 2023 in comparison to the average of comping, non-comping, and non-returning guests for the same time period in the previous year.
...
This will include kiosk sales, Mobile Order & Payment (MO&P) sales, delivery sales, catering sales, Outdoor Digital Menu Board (ODMB) sales, Scan & Pay sales(?), total digital sales (sum of all digital channels), as well as restaurant POS and Drive Thru sales (sum of all non-digital sales). The percentages for each of these would just be computed as the total sales for that service mode/payment method within the [Start Date] and [End Date], divided by the total system-wide sales within the [Start Date] and [End Date].
...
Note, Sales per Restaurant per Day: cumulative sales made by the specified digital ordering channel within the specified reporting cadence (e.g., for each month, if specified cadence is monthly), divided by number of restaurants that actively operate the digital ordering channel, per day.
The first time series in this view, Digital Ordering Sales Over Time, is intended to illustrate the sales per restaurant per day for each digital ordering channel over the user’s selected time range, as a stacked bar chart, where each portion of the stacked bar corresponds to the sales of each digital ordering channel.
Time Series 2 of 3: Service Mode Ordering Channel Cheque Comparison Over Time
...
Time Series 3 of 3: Loyalty Penetration by Service Mode Ordering Channel Over Time
View #4: Offers & Points
As depicted in the illustrative sample view above, this dashboard view should include:
...
Note, Loyalty Penetration: count of transactions made by a guest with a loyalty account, as a percentage of the count of total transactions.
The third time series, Loyalty Penetration by Service Mode Over Time, is intended to illustrate the evolution of loyalty penetration in each digital ordering channel over the course of the user’s selected time range. For example, loyalty penetration within delivery would be represented as the count of transactions made through the delivery channel by a guest with a loyalty account, as a percentage of the count of total transactions made through the delivery channel. Loyalty penetration will be represented as a series of superimposed line charts, with each line corresponding to a different channel
View #4: Offers & Points
...
As depicted in the illustrative sample view above, this dashboard view should include:
User Inputs: Dashboard users will be able to input their desired reporting range by selecting the following:
1. [Start Date] A feature to allow the user to select a start date of the analysis, expressed in the format yyyy/mm/dd. This will represent the start date of the date range being examined by the user.
2. [End Date] A feature to allow the user to select an end date of the analysis, expressed in the format yyyy/mm/dd. This will represent the end date of the date range being examined by the user.
Callout Metrics: this first dashboard view should show users series of callout metrics that summarize the performance of the Tim Hortons offers and rewards program during the user’s selected reporting range, as defined by [Start Date] and [End Date]. :
Unique Guests who Received Offers: count of registered loyalty guests who received at least one offer within the user’s selected reporting range
Unique Purchasing Guests: count of registered loyalty guests who made at least one purchase within the user’s selected reporting range
Unique Guests who Activated Offers:: count of registered loyalty guests who activated at least one offer within the user’s selected reporting range
Unique Offer-Using Guests: count of registered loyalty guests who redeemed at least one offer on a purchase within the selected reporting range
Purchasing Guest Offer Penetration: count of offer-using guests as a percentage of the total count of purchasing guests
Time Series 1 of 3: Top 10 Offers (by Sends/Activation Rate/Redemption Rate)
In this dashboard view, the first time series, Top 10 Offers (by Sends/Activation Rate/Redemption Rate), is intended to illustrate
Time Series 2 of 3: Points Issued per Known Diner $ Over Time
In this dashboard view
Time Series 3 of 3: Guest x Offer Interaction Over Time
KPIs:
RRAMI: Restaurants Reporting Any Menu Item
Just show number (no chart)
...
Discounting views
Points Issued per KDS $ spent
Net discounting
Data Engineering will
Translate requirements into a plan with engineering activities to meet due date.
Complete the data governance requirements for the project (such as availing metadata such as a data dictionary for users)
Provide support and ongoing maintenance of the data in Databricks to ensure the data continues to meet the requirements defined herein.
Risks
Project timeline overrun.