| Page Properties | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Project Team
Digital Loyalty | |
|---|---|
Engineering |
🌎 Project Overview
The aim of this project is to develop a dashboard that illustrates the high-level performance of Tim Horton’s digital/loyalty program. Currently, executive leadership across Tim Horton’s seeks insights on digital health metrics at a higher frequency than the Digital & Loyalty Analytics team currently provides to them. Furthermore, the existing process to provide these metrics ad hoc requires significant manual intervention by the analytics team. Thus, the dashboard should display key metrics that the digital team already tracks, in one location. The end-users of the dashboard are anticipated to be high-level executives, who will monitor essential business metrics to effectively guide business activities, as well as members of the Digital Loyalty Analytics team and will be displayed on the Digital & Loyalty screens (therefore dashboard layout, perspective & dashboard should align to screen dimensions). However, based on the rate of uptake, users across the broader organization may utilize the dashboard on an ad hoc basis.
...
The following outlines details of each of the requested dashboard views (of which there are four c.6 in total), and should inform the development of the underlying data models to power the use case. Note that the analysis should be limited to TH Canada and Canadian Loyalty Guests.
...
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 users' selected reporting ranges, as defined by [Start Date] and [End Date]. Each callout metric will also be accompanied by the previous year’s metric for the same time period to provide a benchmark for progress (as shown by the “PY” figures beneath each metric). For example, where a user inputs Start and End Dates of 20-Jan-2020 & 29-Feb-2020, the PY values should display the values for the periods 1-year earlier, i.e. 20-Jan-2019 & 28-Feb-2019 (take note of leap years).
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 the dashboard user’s selected time period. This metric is used as a baseline to see loyalty sales penetration against system-wide sales, and is a function of the following two metrics (KDS and SWS).
...
Known Diners: cumulative count of Known Diners (guests that have registered through the Tim Hortons app) that have made a purchase within the dashboard user’s selected time period; expressed as a nominal amount. Average Known Diner These guests are typically identified where registered_account_id begins with “us-east”.
Average Known Diner Cheque: average sales of an individual transaction across all known diners for the dashboard user’s selected time period; expressed as a dollar amount.
...
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. Each line represents a different year’s KDS over the user’s selected reporting range. Within this chart, users should have the option to drill up or down on the reporting cadence (e.g., daily, weekly [fiscal], monthly, quarterly, annually). For example, if the user inputted the time range as [Start Date] 2023/01/01 to [End Date] 2023/10/01 and drilled down the reporting cadence to “weekly”, the chart would show weekly KDS penetration overtime for January to October, in 2021, 2022, and 2023.
...
Non-returning: customers who did not make a purchase during the specified cadence during the user’s selected reporting year but did make a purchase in the same cadence of the previous year; expressed as a negative nominal amount (negative bar).
Comping
Non-comping
Non-returning
Purchasing Gusts | Previous Year | Current Year |
|---|---|---|
Comping | Yes | Yes |
Non-Comping | No |
Yes | ||
Non-Returning | Yes | No |
Yes
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 time period within the selected 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.
...
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 show users the respective sales of each digital ordering or payment method, represented as a percentage of system-wide sales, during the user’s selected reporting range, as defined by [Start Date] and [End Date].
...
This will include
...
:
Kiosk sales as % of SWS, where
kiosk sales is the sum of sales where service_mode_cd in ('KIOSK', ‘KIOSK TAKEOUT’, ‘KIOSK EATIN’)
Mobile Order & Payment (MO&P) sales as % of SWS, where
MO&P sales is the sum of sales whereservice_mode_cd in ('MOBILE ORDER DRIVE THRU', 'MOBILE ORDER EAT IN', 'MOBILE ORDER TAKE OUT')
Delivery sales (3P and white label) sales as % of SWS, where
delivery sales is the sum of sales whereservice_mode_cd in ('DELIVERY', ‘WHITE LABEL DELIVERY’, ‘THIRD PARTY DELIVERY’)
Catering sales as % of SWS, where
catering sales is the sum of sales wherediningtype = ‘CT’ (from PRODRT.CURATED_TRANS_EVENTS_NEW)
Scan & Pay sales
...
as % of SWS, where
Scan & Pay sales is the sum of sales where SCANANDPAY = ‘TRUE’ (from PRODRT.CURATED_TRANS_EVENTS_NEW)
Total digital ordering sales (sum of all digital channels)
...
as a % of SWS, where
total digital ordering sales is the sum of sales from all the above service modes
In-Restaurant and Drive Thru sales (sum of all non-digital sales) as a % of SWS, where
In-restaurant and Drive Thru sales is the sum of all sales
...
where service_mode_cd in ('TAKEOUT', ‘DRIVETHRU’, ‘EATIN’)
The percentages for each of these would just be computed as the total sales for that service mode
...
within the [Start Date] and [End Date], divided by the total system-wide sales within the [Start Date] and [End Date].
There should also be callouts for Scan & Pay Loyalty Penetration (sum of Scan & Pay sales as a percentage of all loyalty sales)
...
, where Scan & Pay
...
Time Series 1 of 3: Digital Ordering Sales Over Time
...
sales is the same as the previously-used definition above, and loyalty sales is the sum of all sales where LEFT(LOYALTY_CUSTOMER_ID,3) = '046'.
Time Series 1 of 3: Digital Ordering Channel Sales (% of SWS) Over Time
The first time series in this view, Digital Ordering Channel Sales (% of SWS) Over Time, is intended to illustrate the sales per restaurant per day penetration of systemwide sales for each digital ordering channel over the user’s selected time range, . This data will be represented as a stacked bar chart, where each portion of the stacked bar corresponds to the average sales per restaurant per day of sales as a % of systemwide sales for each digital ordering channel. The sum of all the sales per restaurant per day sales as a % of systemwide sales of each digital ordering channel should amount to the total digital sales per restaurant per daysales as a % of systemwide sales, which is represented by the value of the entire bar. Digital sales as a percentage of system-wide sales is represented as a line (above the bars, on a separate y-axis) also spans the duration of the user’s selected reporting range.
Similar to the other charts, users will have the option to drill up or down on the reporting cadence (e.g., daily, weekly, monthly, quarterly, annually). As well, the chart will feature the average sales per restaurant per day for the user’s entire selected time period in comparison to the average for the same time period in the previous year; average CY YTD data will also be featured in a bar at the end, as pictured in the sample view.
Time Series 2 of 3: Ordering Channel Cheque Comparison Over Time
The second time series, Service Mode Cheque Comparison Over Time, is intended to compare the average cheque amount across all digital ordering channels over time using a clustered bar chart. Similar to the other charts, users will have the option to drill up or down on the reporting cadence (e.g., daily, weekly, monthly, quarterly, annually). The x-axis will display the days/weeks/months of the user’s selected reporting range, depending on which reporting cadence that the user drills down to. Average cheque for each ordering channel will be represented by a bar in the cluster. This chart will also feature a multi-select option, allowing the user to select the specific ordering channels they want to view (from Drive-Thru. Restaurant POS, In-restaurant, MO&P, Kiosks, Delivery, Catering, ODMB)
...
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 YTDto 1-Oct-2022 to Current Date, unless specifically noted otherwise.
...
The second time series, Scan & Pay Impact on Guest Cheque and Frequency, is intended to demonstrate how using Scan & Pay influences guest cheque and frequency over time. This will feature three superimposed line charts, with each line representing cheque lift, frequency lift, and spend lift that occurs 3 days, 7 days, 14 days, and 21 days after the guest first uses Scan & Pay.
Time Series 3 of 4: Scan & Pay Turn Offs
...
The fourth time series, Scan & Pay First Time Purchasers, is intended to show the evolution of Scan & Pay adoption over time; that is, whether more people are using Scan & Pay for the first time, overtime. Similar to the previous chart, users should have the option to drill up or down on the reporting cadence (e.g., daily, weekly [fiscal], monthly, quarterly, annually). This chart will also feature bars representing the nominal number of Scan & Pay first time purchasers for each cadence that the user drills down to (eg: each month, if they choose “monthly”) across the user’s selected reporting range. 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”, the bars will show the nominal number of guests who are using Scan & Pay to make a purchase for the first time ever in each month, from January to October 2023.month, from January to October 2023.
View #6: Digital Metrics
To follow
View #7: Loyalty Metrics
https://rbictg.atlassian.net/wiki/x/aYBmCQE
Technical Specification
To meet the objective of the initiative, Data Engineering will support with the following:
Translate requirements into a plan with engineering activities to meet due date.
Guest cohort is limited to digital loyalty guests with purchases in Canada, and should exclude charity related purchases.
Engage with project team to clarify any assumptions or initiative objectives, as well as to provide the project team with regular & ongoing updates on progress.
Complete the data governance requirements for the project.
Conduct the appropriate quality assurance (“QA”) activities to ensure metrics are accurate.
Provide support and ongoing maintenance of the data models and dashboarddashboards.
⚠️ Risks
Project timeline overrun: as a high-priority project, with executive-level interest, adherence to the overall project timeline is the most significant risk of the project.High computational load: multiple data models will need to be built to develop each metric for the dashboard. These data models can become large and difficult for the chosen visualization tool to read. Additionally, this may result in a high computational requirement, which will need to be mitigated for.
Inaccurate data: as the dashboard is anticipated to influence TH Digital & Loyalty decision-making, the accuracy of the data is paramount.