Commit graph

3 commits

Author SHA1 Message Date
Oriol Roqué Paniagua
72c966631e Merged PR 2824: Propagates Billing Country and Deal Name into int_dates_by_deal
# Description

Changes:
* Adding `main_deal_name` and `main_billing_country_iso_3_per_deal` in `int_dates_by_deal` model.
* Documents the 2 new fields. Also, ensures `main_deal_name` is not null
* Removes `id_deal not null` condition since it's enforced on the inner join with `int_core__deal`

# 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: #18911, #19083
2024-09-12 10:27:56 +00:00
Oriol Roqué Paniagua
94bdc53adf Merged PR 2498: Materialise int_dates_mtd and int_dates_by_deal as table to improve performance
# Description

Materialise int_dates_mtd and int_dates_by_deal as tables. This should improve the run speed as seen in local by quite a bit, and hopefully provide a better starting point for adding new dimensionality on business kpis.

I also documented these 2 models, that were missing :)

# 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: #19514
2024-08-06 15:03:32 +00:00
Oriol Roqué Paniagua
010135fb63 Merged PR 2164: Adding booking metrics by deal id for business kpis
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
2024-07-01 16:00:14 +00:00