# Description
New KPIs model for Daily New Dash Users Services Offered
It shows which users have which services active daily per there product bundles.
There might be some services that are active in more than 1 bundle so I added the Bundle Id to the unique keys set
# 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.
Improved New Dash Services usage
Related work items: #28640
# 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
