# Description
Brings 3 new properties from HubSpot - Deals:
* Dashboard Type: Old Dash, New Dash or null
* Pricing Structure: this contains several possibilities, such as new pricing v1, v2, old pricing (legacy), api pricing, etc.
* Partnership Services: what services the client has according to Hubspot. Not the best in terms of quality but better than nothing specially in Old Dash. I also handled a small processing since services were differently separated.
This is propagated to intermediate in `int_hubspot__deal`. This is needed to automate the pricing differences for clients in old dash to be moved to new dash.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented. **Mostly on intermediate, did not bother to update staging besides the new fields.**
- [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: #28627
# Description
Only affects Churn Rate targets: Adds 1 extra decimal. Fixes issue on YTD not computed properly.
# 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.
Fix YTD on Revenue Churn Rate. Increase precision with 1 decimal
Related work items: #28560
# Description
Modifies our CI pipeline so that:
- It produces a master-version `manifest.json`.
- It only compiles models that have been modified when compared to the master version.
Related work items: #28629
# Description
Ensures Resolutions Payouts (in amount paid) is 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.
- [ ] 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.
Same freshness in MTD and YTD/target for Resolutions Payouts
Related work items: #28560
# 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
There's misalignment in the different areas in the business, but even within our own report...
**I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side.
Changes:
* Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary.
* Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost.
* Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD.
Additional Changes:
* Tests are also aligned with new names.
* Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird.
# 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: #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
Main Changes:
* Computes the total booking fees in `int_kpis__metric_daily_invoiced_revenue`
* Propagates within KPIs, including schema and tests
* Propagates within cross in both "by deal" and "by dimension/global"
* Propagates to main kpis tests
Small fix:
* In `int_mtd_vs_previous_year_metrics`, manual formatting because sqlfmt is broken on this model...
# 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
Main changes:
* Modifies target seeds to include FY2025 and FY2026. This includes now absolute values for equivalent rate metrics. This also includes Booking Fees per Billable Booking, despite this metric is still not computed. This will be done in a separated PR.
* Removes Onboarding MRR as this requirement is no longer needed, and there has not been any target computed for this metric. This is modified to include Revenue Churn as an absolute figure.
Small note. Targets for FY 2025 rely on the actuals from Finance. Up to January 2025 included, these should match with our YTD values, but it's not the case due to small differences in Billable Bookings / Deals; as well as accrued revenue. Accrued revenue is very troublesome specially on Guesty side, since this affects Total Revenue, and this affects also Resolutions Payout Rate, and so on...
# 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
Filtered test accounts according to `Account_type` in Cosmos
Unfortunately this doesn't actually filter all test accounts, there are some that are correctly classified and I will have to ask specifically to either remove or classify correctly
# 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.
Filtered test accounts
Related work items: #28239
