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
Adding accommodation metrics by deal id with the model `int_core__monthly_accommodation_history_by_deal`.
With this PR, we have the full set of batch 1 metrics by deal id completed, although separated in different tables. Aggregation will come in a separated PR.
Similarly as the previous PR, this one it's a mix between the logic of `int_core__mtd_accommodation_metrics` and the logic existing for the `int_core__monthly_X_history_by_deal` . It also adds the tests in schema.
Related work items: #17689
Adding the 6 Guest Journey metrics by deal id by creating the model `int_core__monthly_guest_journey_history_by_deal`
The structure for the deal id detail follows yesterday's approach on bookings, namely `int_core__monthly_booking_history_by_deal`, but considering the metric computation of the guest journey, namely `int_core__mtd_guest_journey_metrics`.
It also adds the dbt tests ensuring that date and id_deal are not null and that the combination of both is unique.
Related work items: #17689
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
The bank transactions table coming from Xero has positive amounts for all transactions by default.
Nevertheless, some transactions are receiving and some are sending.
This PR implements sign for transactions amounts throughout the DWH so that aggregations work properly.
I've also left the transaction sign column in some spots since it might be useful for some aggregation wizardry (ie cancel out receiving transactions in resolutions so that counts are more accurate).
Related work items: #17551
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
A very denormalized table that brings Bank Transactions Line Items, Bank Transactions and Contacts into a single table.
Building this because we need to show some data in a PBI report that needs data from all three tables and can't be joined in PBI.
Related work items: #17551
Fixing accommodation host by using accommodation to user, after discussion with Ben R.
This improves data quality, even though there's some duplicates removal.
I checked and it effectively removes accommodations that mostly were considered as 'Never Booked', thus not a massive impact is expected for the business kpis. But in any case, let's do things properly :)
Related work items: #17538
