Refactor mtd joins to improve performance, as stated in the ticket:
We noticed that some of the new models for MTD purposes (KPIs reporting) take quite a bit of time to run some simple joins.
The main reason is that there's a double join that can be simplified. The current state is:
```
from int_dates_mtd d
inner join
sometable t
on extract(year from t.table_date) = d.year
and extract(month from t.table_date) = d.month
and extract(day from t.table_date) <= d.day
```
and it can be changed to:
```
from int_dates_mtd d
inner join
sometable t
on date_trunc('month', t.table_date)::date = d.first_day_month
and extract(day from t.table_date) <= d.day
```
which is way faster, and keeps the same computation
Related work items: #18330
This PR aims to expose the new metrics to the business KPIs report.
The new metrics exposed are, for the global and the by deal view:
- Guest Revenue
- Guest Revenue per Guest Journey Completed
- Guest Revenue per Guest Journey with Payment
- Guest Payments
- Guest Payments per Guest Journey Completed
- Guest Payments per Guest Journey with Payment
- Guest Journey with Payment
- Guest Journey Payment Rate
Changes:
- Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view.
- Silly change that I miss some GJ payment metric for the view by deal id.
- Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files
- Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display.
- **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when.
This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis!
Related work items: #18107
This PR aims to propagate the computation of guest revenue model into the aggregated models.
Changes:
- I changed the logic on `int_mtd_guest_revenue_metrics` since it was still using the old computation of the relative increment within the same model. Basically, I removed it (last part of the query). The rest of changes in this model are just formatting.
- I also applied the formatting in the int_mtd_vs_previous_year_metrics, mainly changing the macro calls from **'**xyz**'** to **"**xyz**"**.
What's new:
- `int_mtd_guest_revenue_metrics` into `int_mtd_vs_previous_year_metrics`, by adding `total_guest_revenue_in_gbp` and `total_guest_payments_in_gbp`. Additionally, with the new logic, for the first time we're able to compute **weighted metrics** coming from different sources. Specifically, it computes the weighted measures per guest journey completed and guest journey with payment.
- Similar behavior on the 'by deal', adding `int_monthly_guest_revenue_history_by_deal` into `int_monthly_aggregated_metrics` and similar computation
This model does not affect the exposing logic still, meaning these metrics won't be exposed in the report. This will come in a separated PR.
Related work items: #18107
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
Following yesterday's refactor of booking metrics, this PR provides a refactor of already exposed metrics: listings, deals and guest journeys.
-> Data is consistent with values already exposed.
Changes:
- for `int_core__mtd_listing_metrics`, `int_core__mtd_deal_metrics` and `int_core__mtd_guest_journey_metrics`:
1. remove the computation of the previous year metric value and the relative increment (last part of the query)
2. re-apply the formatting
- for `int_mtd_vs_previous_year_metrics`:
1. Reference listings, deals and GJ models
2. Include the metrics for these types in the `plain_kpi_combination` CTE
3. Add the computation of previous year and relative increment using the macro
- for `int_core__mtd_aggregated_metrics`
1. Remove and "hardcode" sources since all metrics now depend exclusively of `int_mtd_vs_previous_year_metrics`
This PR does not alter the exposed metrics in the production report. It does not aim to change the name of the reporting/intermediate models that expose the information, it will be done in a separated PR.
Documentation: https://www.notion.so/knowyourguest-superhog/Refactoring-Business-KPIs-5deb6aadddb34884ae90339402ac16e3
Related work items: #18202
First step on refactor of kpis:
- Remove relative incremental vs. previous year computation from the source model (`mtd_booking_metrics`, in this case)
- Aggregate the source mtd global metrics models into a single model: `int_mtd_vs_previous_year_metrics` (to enable multi-source weighted metric computation) and compute previous year value and relative increment. Now this logic is encapsulated into a macro `calculate_safe_relative_increment`, easing readability and providing a bit more robustness.
- End-to-end continuity to not break the existing dashboard display in `int_core__mtd_aggregated_metrics`
This is a substep of the global change. All info can be found in the documentation [here](https://www.notion.so/knowyourguest-superhog/Refactoring-Business-KPIs-5deb6aadddb34884ae90339402ac16e3)
Related work items: #18202
IMPORTANT: this PR was merged and reverted. The division by 0 error has been fixed in the last commit
Adds the following metrics:
- Guest Revenue
by both visions (global and by deal id)
It creates 2 new models:
- int_mtd_guest_revenue_metrics
- int_monthly_guest_revenue_history_by_deal
the approaches are similar in the sense that we retrieve the information from the int_core__verification_payments and a filter by a PAID status. I checked and the aggregated volumes of the figures correspond to the decimal as what is reported to the guest_payments dashboard (aggregating the information from the currency tab)
Same as last PR, this one does not exposes the data since a refactor of how the code is structured will follow shortly.
Related work items: #18107
Adds the following metrics:
- Guest Revenue
by both visions (global and by deal id)
It creates 2 new models:
- int_core__mtd_guest_revenue_metrics
- int_core__monthly_guest_revenue_history_by_deal
the approaches are similar in the sense that we retrieve the information from the int_core__verification_payments and a filter by a PAID status. I checked and the aggregated volumes of the figures correspond to the decimal as what is reported to the guest_payments dashboard (aggregating the information from the currency tab)
Same as last PR, this one does not exposes the data since a refactor of how the code is structured will follow shortly.
Reverts !2199
Related work items: #18107
Adds the following metrics:
- Guest Revenue
by both visions (global and by deal id)
It creates 2 new models:
- int_core__mtd_guest_revenue_metrics
- int_core__monthly_guest_revenue_history_by_deal
the approaches are similar in the sense that we retrieve the information from the int_core__verification_payments and a filter by a PAID status. I checked and the aggregated volumes of the figures correspond to the decimal as what is reported to the guest_payments dashboard (aggregating the information from the currency tab)
Same as last PR, this one does not exposes the data since a refactor of how the code is structured will follow shortly.
Related work items: #18107
This is a first approach to compute some easy metrics for the "deal" based business kpis. At this stage, it contains the information of bookings (created, checkout, cancelled) per deal and month, including both historic months as well as the current one. This do not contain MTD computation because it's overkill to do a MTD at deal level (+ we have 1k deals, so scalability can become a problem in the future)
Models:
- **int_dates_by_deal**: simple model that reads from **int_dates** and just joins it with **unified_users** to retrieve the deals. It will be used as the 'source of truth' for which deals should be considered in a given month, basically, since the first host associated to a deal is created (not necessarily booked)
- **int_core__monthly_booking_history_by_deal**: it contains the history of bookings per deal id in a monthly basis. It should be easy enough to integrate here, in the future and if needed, B2B macro segmentation.
In terms of performance, comparing the model **int_core__monthly_booking_history_by_deal** and **int_core__mtd_booking_metrics** you'll see that I removed the joined with the **int_dates_xxx** in the CTEs. This is because I want to avoid a double join of date & deal that I tried and I stopped after 5 min running. Since this computation is in a monthly basis - no MTD - it's easy enough to just apply the **int_dates_by_deal** on the last part of the query. With this approach, it runs in 7 seconds.
Related work items: #17689
As today it's 1st of July, the logic of selecting all days of the current month for MTD purposes on the business KPIs is ko, since we select up to yesterday.
This PR allows to consider the last day of the previous month as 'current month' only for the first day of the following month, thus ensuring that the most up-to-date data is always displayed in the MTD tab.
Related work items: #17745
