# Description
This PR does the following:
* Moves `core/int_core__booking_summary` to `cross/int_core__booking_summary`
* Renames the model `cross/int_core__booking_summary` to `cross/int_booking_summary`
* Same for schema entry. In the new schema, I just added in the description how to retrieve exclusively New Dash Bookings for usability purposes.
Then, it adapts any dependency on `int_core__booking_summary` to `int_booking_summary`
No additional changes - inclusion of Resolution Incidents data will come later in a different PR.
# 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: #30676
# Description
First version of Stay Disrupt conversion funnel. It's a simple monthly compute of:
Active accounts -> Accounts that offered SD in GJ started in month -> Accounts that have had payments paid of SD in month
Total Guest Journeys Started -> GJ that offered SD in month-> Payments paid of SD in month
Some details:
* It also includes CIH, and data starts on 1st Jan 2025. This is to create report. This needs to be changed once the report is created.
* Note that Accounts that offered SD in GJ started in month and GJ that offered SD in month is equal to 0 as no data flows through the new flow. The rest has data.
* I consider all users, not only New Dash, knowing that I don't know if someone knows which users will have a certain Guest Product enabled.
Model is "agnostic" to the GP if we want, though the name still aims to be only for SD.
# 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. **View to start with**
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #30277
# Description
Drop Monthly Growth Score By Deal legacy models in Intermediate and Reporting.
This includes schema entries.
These models were already identified as to be deprecated on the 23rd May 2025, so, today.
# Checklist
- [X] Project compiles, no additional warning is raised.
Related work items: #29826
# Description
Reporting version of New Dash Onboarding
It also adds a missing description of a field.
It also adapts the logic for Hubspot Onboarding Owner, after a discussion with Alex. It still does not cover 100% of the cases but he's investigating the rest.
# 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.
- [ ] 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.
Related work items: #30249
# Description
Improvements on onboarding data:
* Hubspot services that clients expressed their interest in are now sorted alphabetically. This is needed for:
* A new boolean to compare current active services applied in listings vs. services that captured the interest of the client on onboarding. This can help identify clients that we might need to follow up to ensure all programs are created and applied.
# 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.
- [ ] 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.
Related work items: #30249
# Description
Adds new model in intermediate for new dash deal onboarding.
Adds additional fields in new dash tables for services completion at program level.
# 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.
- [ ] 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.
Related work items: #30249
# Description
Remove old models:
- `monthly_aggregated_metrics_history_by_deal`
- `int_monthly_aggregated_metrics_history_by_deal`
# 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.
Remove old models
Related work items: #29672
# Description
Updates deprecation dates to 23rd May.
Updates exposure with new Account Growth report
# Checklist
- [X] Project compiles
Related work items: #29374
# Description
Creates an intermediate model to compute the impact in revenue (total or rrpr) due to the growth.
This model also categorises the impact, and provides additional attributes for reporting purposes.
This model aims to substitute, in time, the current existing version of `int_monthly_growth_score_by_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: #29374
# Description
I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming.
Changes:
* Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items".
* Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items".
* Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items".
* Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it.
# 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: #29374
# Description
Switches Created Bookings to Billable Bookings in the scope of Projected Bookings. I opted for hard switching (thus removing Projected Created Bookings) altogether to avoid having unused models in production.
This aims to set the ground to include, in the future, APIs Billable Bookings.
Impact in KPIs:
* `int_kpis__agg_daily_created_bookings` now is `int_kpis__agg_daily_billable_bookings`. Aside from the name change, it's reduced to 4 metrics to just one. Schema changes also apply.
Impact in Projected KPIs:
* `int_kpis_projected__agg_daily_created_bookings` now is `int_kpis_projected__agg_daily_billable_bookings`. Fields are also renamed accordingly.
* `int_kpis_projected__agg_monthly_created_bookings` now is `int_kpis_projected__agg_monthly_billable_bookings`. Fields are also renamed accordingly.
* Schema file is also updated accordingly.
Impact on new model for Growth Score:
* `int_created_bookings_growth_score_by_deal` now is `int_billable_bookings_growth_score_by_deal`. Fields are also renamed accordingly.
* Schema is also updated accordingly.
Note that since the end model `int_billable_bookings_growth_score_by_deal` is not used at the moment in reporting, there's no user-facing impact. Also, the rest of modified models are not used for other purposes.
# 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: #29374
# Description
Creates a first unified version of API verifications. This is a very simple model as it aims to capture the minimal essence of Verifications in a unified view. Any very-in-depth-API-specific detail is not available here.
Additionally, I propagated the Check-in date in the Athena model.
This is needed for API Bookings KPIs future models.
# 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. **Currently as a view, despite it's 70k records. If this grows we could consider other materialisations**
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #29374
# Description
After checking the current growth score model... I think I will decommission it for something simpler.
This PR introduces a new growth score purely based on Created Bookings, thus it won't work for API deals. For API deals I will do a similar Total Revenue comparison separately.
This uses the projected bookings at the end of the month, thus this is updated in a daily basis and it's timely.
# 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: #29374
# Description
Technically, a payout can be submitted while not in a finished incident state. Likely next step from res perspective is just to close the ticket.
This PR just adds two new fields for completion and consistency, and fixes the completion test so it makes sense.
# 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.
- [ ] 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
Adds monetary value in terms of payouts for further understanding of the potential impact on improving the flagging.
# 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: #29284
# Description
Creates 2 new models in the scope of flagging: how good are we at identifying "at risk" bookings vs. 1) the number of claims generated and 2) the number of submitted payouts?
This only applies for Protected Bookings in New Dash that have been completed (14 days after the check-out) with potential resolutions appearing in Resolutions Center.
The first table `int_flagging_booking_categorisation` contains all the heavy logic to categorise the bookings.
The second view `int_flagging_performance_analysis` computes standard binary classification scores, for the 2 possible ways of tracking.
Tables are already in prod to help you understand while reviewing. You'll see that the figures are still quite low, specially due to small amount of claims/submitted payouts. This makes the true positives being just... 1.
There's heavy test and documentation coverage to ensure there's no mistakes on the computation.
# 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. **Materialising as table the first model despite being just 1 record since otherwise tests takes ages**
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #29284
# Description
Adds more robust testing for Total Revenue and Revenue Retained Post-Resolutions in:
* int_mtd_vs_previous_year_metrics
* int_ytd_mtd_main_metrics_overview
# 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.
- [ ] 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.
More robust testing on key metrics
Related work items: #29227
# Description
As raised by Kayla, Retained metrics are not computed correctly in AM Account Margin report, see screenshot:
Issue lies in the fact that Guest Payments contains more dimensions than the rest of the models. This is generating duplicates in the combination_of_sources CTE, but these are effectively hidden because of the sum() applied of the metrics.
In the case of a Deal having in the same day Guest Payments with different dimensions from those selected, AND on the same day having a value on Invoiced Revenue or Host Resolutions, then the Invoiced Revenue or Host Resolutions would be duplicated.
This PR aims to fix this issue, and also adds a few tests on the base model for AM Account Margin to ensure this is kind of error raises an alert.
I'll be debugging other affected models and increase the robustness test-wise; as well as gathering the full impact.
# 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.
- [ ] 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.
Related work items: #29227
# Description
Small changes to exclude "irrelevant" data. All data is relevant I guess but this is less.
* Exclude churned accounts after 3 months.
* Exclude any data after 24 months.
# 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.
- [ ] 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.
Related work items: #28998
# Description
Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc.
In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control.
# 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. **Worth discussing the possibilities to include indexes in the future**
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #28998
# Description
To be able to compute By Deal KPIs similarly as we do for Main KPIs we need to propagate the "By Deal" dimension first in intermediate. This does not impact reporting since there's a macro that already cuts the dimensions to be displayed, but I modified the name so it's clearer.
Changes:
* In `int_mtd_vs_previous_year_metrics`, I added a new `dimension_list`. This is applied to all initial CTEs that filter by dimension. Note that I added here the `by_deal` dimension.
* Modified the name of `get_kpi_dimensions_for_production` to `get_main_kpis_dimensions_for_production`. Now it's more explicit that this is the configuration for Main KPIs reporting. This affects both `business_kpis_configuration` and it's usage in `mtd_aggregated_metrics`.
* Modified the tests in `int_mtd_vs_previous_year_metrics` and `int_mtd_aggregated_metrics` to include the new dimension `by_deal`.
* It seems by adding this now autoformatting works again on this model! I'll tag all cases that are just because of autoformatting.
MD5 trick has been applied in `reporting.mtd_aggregated_metrics`.
# 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: #28998
# Description
Removes old onboarding mrr models, that are no longer used.
dbt compiles correctly and no deprecated warning is showing anymore.
This finishes the refactor
Related work items: #28949
# Description
Tags as deprecated the following models:
* `int_monthly_onboarding_mrr_per_deal`
* `int_mtd_agg_onboarding_mrr_revenue`
Project compiles.
Related work items: #28949
# Description
Removes the models:
* int_monthly_12m_window_contribution_by_deal
* int_monthly_churn_metrics
as well as their entries in the schema files.
Project compiles and KPIs run works.
This closes stage 3 of the refactor.
# 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.
Remove previous Churn models
Related work items: #28948
# Description
Churn models being tagged as deprecated for next week, for information.
# 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.
Deprecation of Churn Models
Related work items: #28948
# Description
I noticed this morning that after the name changes some exclusions have been messed up.
I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic.
I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month.
# 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.
- [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved**
- [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: #28560
# Description
Changes:
* Creates Booking Fees in YTD/MTD
* Creates Booking Fees per Billable Booking in YTD/MTD. This is exposed forward.
* Removes code for Onboarding MRR in YTD/MTD.
Additional fixes:
* Small mistake - Revenue Churn is now considered as NEGATIVE
# 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: #28560
# Description
Propagates Client Type to KPIs by Deal and AM models. This is just a distinction between Platform and APIs.
# 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: #28181
# Description
Adds number format for display purposes
# 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.
Adds number format
Related work items: #27609
# Description
Changes:
* Adds Onboarding MRR
* Refactors exclusion code for ongoing month / invoicing cycle
* Adds sign format on relative differences
# 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: #27609, #27805
# 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.
Revert "Adds Onboarding MRR"
Reverted commit `dab210c6`.
# 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.
Revert "Refactor display exclusion for clarity purposes"
Reverted commit `fdec616f`.
# 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.
Revert "Relative increments with sign"
Reverted commit `f5718ded`.
# Description
Changes:
* Adds Revenue Churn Rate in YTD/MTD Overview. This has several implications, I finally understood how to properly compute a YTD.
The problem is that Revenue Churn Rate is a % of the Total "Churned" Revenue in a 12 m period vs. the Total Revenue in the same 12 m period. This is a bit tricky because it's not really additive, because of the Churn definition. Total Churned Revenue is the Revenue that the churned deals in a month generated on that past 12 months prior to churning.
So - in order to aggregate it properly, we need to do the sum of the Total Churned Revenue and retrieve the Total Revenue on these 12 months, and THEN compute the Churn rate.
This PR mainly retrieves the necessary input from the Churn models and then follows a similar computation as for the rest of YTD/MTD converted metrics.
I'll handle Onboarding MRR in a separated PR as this one is quite dense already.
# 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: #27609, #27805
# Description
Changes:
* Adds template for targets -> These need to be revised
* Adds comparison of values vs. targets
* Allows for multi-year last date computation (allowing multiple years to be selected, not just the last one)
# 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: #27609, #27805
# Description
First version of the model int_ytd_mtd_aggregated_main_metrics_overview
It aggregates data at the level of:
* Date
* Dimension
* Dimension Value
* Metric Name (or Id Metric)
This computes differences and relative differences in:
* current MTD vs previous month EOM
* current MTD vs previous year MTD
* current year YTD vs previous year YTD
This is applied to 13 metrics, namely:
* Total Revenue
* Revenue Retained Post-Resolutions
* Guest Revenue
* Invoiced Operator Revenue
* Invoiced APIs Revenue
* Billable Bookings
* Live Deals
* New Deals
* Churning Deals
* Damage Waiver Payout Rate
* Host Resolutions Payout Rate
* Invoiced Operator Revenue per Billable Booking
* Waiver Revenue per Billable Booking
This still does not handle:
* Comparison vs. targets (to be done later, need input)
* Missing metrics on Onboarding MRR / Revenue Churn (to be done later)
* Invoicing dependant data exclusion (to be done in reporting)
# 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. **At the moment I keep everything as views and seems ok. We'll see if this needs to be materialised as tables later on**
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #27609
