# Description
Same PR as before, just adds a new commit that fixes my silly issue in prod. I owe some drinks :D
# 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: #19570
# Description
_Describe your motivation and changes here._
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
# Description
Automates the new dash query through DWH. It's a first step towards enabling a very simple PBI reporting on new dash performance. Data is aggregated at user level with the main performance indicators that we're currently reporting. I added a few more informative fields from user side.
Changes:
* in intermediate, creation of `int_core__new_dash_user_overview`. It mainly uses the models in previous PRs to avoid crazy computations, since most of the logic has already been implemented. The only thing is that it's "hardcoded" (with variable) the categorisation of what is NOT a paid service.
* in reporting, creation of `core__new_dash_user_overview`. It just exposes the info from intermediate to reporting.
* added schema entries for intermediate/core and reporting/core, it's the same description for both cases.
# 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.
Reverts !2657
Related work items: #19570
# Description
Automates the new dash query through DWH. It's a first step towards enabling a very simple PBI reporting on new dash performance. Data is aggregated at user level with the main performance indicators that we're currently reporting. I added a few more informative fields from user side.
Changes:
* in intermediate, creation of `int_core__new_dash_user_overview`. It mainly uses the models in previous PRs to avoid crazy computations, since most of the logic has already been implemented. The only thing is that it's "hardcoded" (with variable) the categorisation of what is NOT a paid service.
* in reporting, creation of `core__new_dash_user_overview`. It just exposes the info from intermediate to reporting.
* added schema entries for intermediate/core and reporting/core, it's the same description for both cases.
# 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: #19570
Changing naming to follow convention.
This PR has the following changes:
- the model `int_core__mtd_aggregated_metrics` has been moved to cross and changed the name to `int_mtd_aggregated_metrics`
- the model `int_core__monthly_aggregated_metrics_history_by_deal` has been moved to cross and changed the name to `int_monthly_aggregated_metrics_history_by_deal`
- the reporting models `core__mtd_aggregated_metrics` and `core__monthly_aggregated_metrics_history_by_deal` now source the `int_mtd_aggregated_metrics` and `int_monthly_aggregated_metrics_history_by_deal` to avoid breaking the production dashboard
- the reporting models have been duplicated from core into general with the correct names, i.e., `mtd_aggregated_metrics` and `monthly_aggregated_metrics_history_by_deal`
- Documentation has been moved in intermediate and replicated in reporting, adding comments on the currently in use models that are going to die soon.
This will allow for a transition of the PBI dashboard from one source to another. Exposures file still not touched since technically the report is still sourcing the 'legacy' models. Documentation of the refactor here: https://www.notion.so/knowyourguest-superhog/Refactoring-Business-KPIs-5deb6aadddb34884ae90339402ac16e3
Related work items: #18202
New model for guests satisfaction report, I included columns to check what is the guest paying for that might be helpful for analysis as well
Related work items: #16947
This PR creates 2 new models:
- `int_core__monthly_aggregated_metrics_history_by_deal`, which just gathers the information of the previously created models that compute the kpis by deal id.
- `core__monthly_aggregated_metrics_history_by_deal`, effectively a copy from intermediate to reporting
It also includes documentation of these 2 models, differences between these and the `mtd_aggregated_metrics` equivalents and references it to exposures. I took the opportunity to update the documentation of the `core__mtd_aggregated_metrics` now that it's a bit more mature.
This should be the last PR for the first draft of 'by deal' metrics.
Related work items: #17689
This PR aims to provide a first draft for business KPIs, at this stage **quite minimal**.
It mostly contains a MTD and Monthly display approach. No dimensions are created.
The models created are:
- **int_dates_mtd**: mainly it reads from int_dates to retrieve those days needed for a MTD/monthly display
- **int_core__mtd_booking_metrics**: it contains the booking metrics, ending in a format of date|value|value last year|increment
--> here we could add, in the future, additional metrics from other sources (ex: guest journey, etc)
- **int_core__mtd_aggregated_metrics**: it transforms the data coming from the different mtd intermediate sources to be easily displayed in the dashboard. This is a good candidate for macros :)
- **core__mtd_aggregated_metrics**: copy-paste of the its int_core version, including a bit of model documentation
The dashboard is functional but in another PR. I can show you how it looks like at the moment you are going to check the PR
Related work items: #17214
