This PR closes the first draft of the first batch of business kpis. Host logic has changed to be applied at deal id level.
It's mostly an adapted copy-paste from the accommodation counterpart, specifically:
- `int_core__mtd_deal_lifecycle`: computes the historic deal lifecycle. One line for each deal and MTD date. **Important**: _Not all hosts have a deal set. This will need a data quality report for business teams to fix_
- `int_core__mtd_deal_metrics`: computes the aggregation at MTD date level of the metrics per lifecycle state and activity state
Additionally, this PR changes:
- `int_core__mtd_aggregated_metrics`: it includes the new 3 deal metrics and changes the source of the already existing 3 deal metrics from `mtd_booking_metrics` to the new `mtd_deal_metrics`
- `int_core__mtd_booking_metrics`: removes all code needed to compute the remaining deal metrics, speeding it up considerably.
After this PR, the mtd models run (locally) at the following speed:
- `int_core__mtd_accommodation_lifecycle`: 47 sec
- `int_core__mtd_deal_lifecycle`: 3 sec
- `int_core__mtd_accommodation_metrics`: 5 sec
- `int_core__mtd_deal_metrics`: < 1 sec
- `int_core__mtd_booking_metrics`: 8 sec (quite a reduction)
- `int_core__mtd_guest_journey_metrics`: 5 sec
- `int_core__mtd_aggregated_metrics` and `core__mtd_aggregated_metrics`: < 1 sec
Related work items: #17312
This PR will compute the listing metrics in an aggregated manner to be displayed in the Main KPIs dashboard, specifically:
- New Listings
- First Time Booked Listings
- Churning Listings
- It also adapts the computation for the already existing metrics of Listings Booked in X months
At code level, it contains the following:
- Adds `int_core__mtd_accommodation_metrics`, which computes the aggregation of the lifecycle of listings at date level (unique), being date the corresponding date from `int_dates_mtd`
- Changes `int_core__mtd_aggregated_metrics` to take the accommodation metrics from the new model. Those 3 already existing (Listings booked in X month) now read from the new model as well.
- Changes `int_core__mtd_booking_metrics` to remove unused computation, making it lighter. Specifically, it removes 1) listing related metrics, since now we have a dedicated model and 2) number of guests booked, since it's not used at all.
The resulting values in local are consistent with what is already reported in the staging report.
Related work items: #17312
Adding int_core__accommodation
Includes both:
- Main information of the accommodation, mostly coming from stg_core__accommodation and int_core__country.
- Listing lifecycle computation, based on the created bookings from stg_core__bookings. It's just the current state, no history.
Some considerations:
- I opted to use stg_core__bookings and not int_core__bookings. Main reason is in case at some point we want to add listing-based information to the booking table, it would avoid cyclic references.
- I opted to keep all the logic of 1) accommodation info and 2) lifecycle in the same model. This could be easily split into: lifecycle first that reads uniquely from staging and then the int_core__accommodation that could read from the staging version to retrieve accommodation attributes + the lifecycle one. Up to you
I'd suggest to review first the documentation in schema since it explains the logic applied.
Notion page linked to this task: https://www.notion.so/knowyourguest-superhog/Listing-lifecycle-4dc0311b21ca44f8859969e419872ebd
Related work items: #17312
- Main purpose is to bring the Bank Transactions table from sync to stg.
- Along the way:
- I created a couple of new generic tests.
- I reviewed docs and tests for a couple of other Xero models that were not in the best shape.
Related work items: #17551
There's a couple of broken tests for Stripe data in production for some `accepted_values` one, but it's just because our test is too strict and doesn't really account for all values.
This PR fixes plus drops a small comment on the funky sources table which won't hurt for future modelers.
Adding Country to intermediate, both model + documentation.
At this stage, the model is set as a view but we can discuss what is the best approach
Related work items: #17312
Adding cancelled bookings metric based on the feedback of the tech team. Mainly, the date of a cancelled booking can be considered as the `updated_date_utc` for those bookings with status cancelled, as it's a terminal state and no additional steps should follow.
I also took the opportunity to update:
- The order on the `int_core__mtd_aggregated_metrics`, so it matches the one in the Notion page for the 1st batch, freeing already the space for the order_by numbers for missing metrics
- Make acronyms of alias in the `main_kpi` subquery in `int_core__mtd_booking_metrics` slightly more clear
- Remove empty line at the end of the file in `int_core__mtd_booking_metrics`
Keep in mind that the cancelled bookings metric will be directly available in the dashboard once this PR is approved and DWH re-runs.
Related work items: #17310
