9ca9c827fe
# Description Computes projected Bookings to the end of the current month per dimension and dimension value KPIs changes: * Adds a int_kpis__agg_daily_created_bookings model. This is a standard KPIs model that computes created bookings at a daily level per dimension and dimension value. Projected KPIs (NEW): * Adds a new folder named projected within KPIs. This includes a simple Readme. * Adds a default dimension dates model that ranges from the past 3 complete months to the end of the current month, that is in the future. * Adds 2 projected models for created bookings: The daily one, that handles the logic of the projection (same month + last 7 days) and the monthly one, that retrieves the end of month projected value as well as some indicators of how good or bad this was for previous months. How good is the projection at 11th of March (so 10 days in the month)? `select * from intermediate.int_kpis_projected__agg_monthly_created_bookings order by actual_created_bookings desc`  # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28251
1.4 KiB
Projected KPIs Readme
(!) If you are reading this, be warned that any model within this folder contains ESTIMATES in the form of projections.
Purpose
The \kpis\projected folder is dedicated to projected KPIs modelisation, which include mostly any relevant dimension and measure and time aggregation needed for transforming data into business estimates.
These are likely depending on the actual KPIs.
Convention
- Any model within the folder
intermediate\kpis\projectedneeds to follow this convention:int_kpis_projected__{structure_type}_{time_dimension}_{relevant_entity_name}.
For the structure type, time dimension and relevant entity name, please refer to the documentation within KPIs - it remains the same.
Contributing guidelines
Always KISS - Keep It Simple Stupid: An easier model is better for debugging. If we're in need to do advanced predictions, then likely we'll need to do Machine Learning rather than just business rules.
Always report the error: There's multiple ways to check how good or bad is an estimate, but at least provide a simple measure for each estimate. Make sure that this estimate is based on a recent period from which we are able to retrieve the actual data (the source of truth). Make sure that this estimate can be computed in the past without any data leakage - otherwise Uri will be very, very mad.
Have fun!