# Description
Removes old computation of KPIs of Bookings, Guest Journeys and Guest Payments, after yesterday's switch to new computation.
It cleans 1) models 2) schema entries and 3) temporary tests.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [NA] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them. **(Except for the duplicated Booking to Product Bundle)**
- [X] I have checked for DRY opportunities with other models and docs.
- [NA] 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 KPIs computation for Bookings, Guest Journeys and Guest Payments
Related work items: #23576
# Description
Added CSAT score metrics, both average score as count of score to correctly aggregate for agg 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.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
CSAT score
Related work items: #23372
# Description
Adds 2 new metrics:
- xero_host_resolution_amount_paid_in_gbp
- xero_host_resolution_payment_count
Effectively it will split the "real" invoicing sources of revenue from "host resolution payments". This was already reading from 2 different Xero models (bank transactions vs. sales).
We have as usual:
- 1 Daily metric model
- 2 MTD/Monthly metric model
- 2 MTD/Monthly agg model (I already changed the name to agg instead of aggregated)
- 1 test to compare the values match the current setup
# 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.
- [NA] 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: #23565
# Description
Exposes New KPIs of Bookings, Guest Journeys and Guest Payments in the 2 main flows: Monthly+MTD per Global, By Billing Country and By # of Listings Segmentation & Monthly By Deal
I did some checks on Global and By Billing Country and looks good.
I checked some examples for Monthly By Deal and looks good.
# 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.
- [NO] I have checked for DRY opportunities with other models and docs. **Likely there's ways to create default configs for KPIs saying "hey, this is Main KPIs for a specific view so use this models and these filters". But at this stage since it's a transitional stage I don't want do overthink. Let's tackle this later on if that's ok for you. It means we will live with some repeated expressions**
- [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: #23455
# Description
Here are all models for guest journey metrics attributed to check-in date with their monthly and MTD aggregation.
I did a little modification on the assert_dimension_completeness test so it can have a list of metrics to check instead of having to put it separately for each one, let me know what you think @<Oriol Roqué Paniagua> and I can update it for all other models that are using that test and update as well al names from aggregated to agg (Or should I just do it in a separate PR??)
I also checked the total values vs your models and the results make sense, there is some difference which is to be expected but nothing crazy.
# 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: #23387
# Description
Created new models for the new Guest KPIs
These are for created, started and completed guest journeys and the highest granularity.
These includes date (day), id_deal, has_payment, has_check_in (government id), accommodation segmentation and billing country
# 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: #23387
# Description
Adding new claim NewDashVersion as an indicator for User Host
# 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: #23457
# Description
Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic.
If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc)
If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash.
The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work.
# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY**
- [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.
Changes claims and logic to consider user is in new dash. Downstream propagation included
Related work items: #23457
# Description
Adds Check-Out, Cancelled and Billable Bookings in the new KPI flow.
For each of these metrics, it includes:
* Daily model
* Monthly/MTD without dimension aggregates
* Monthly/MTD with dimension aggregates
* Schema entries for the abovementioned 5 models
* Temporary test to compare the different metrics against current production KPIs
I also implemented a quick performance fix that removes the dependency of Billable Bookings from Booking Charge Events, since Bookings table already contains the needed information.
# 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.
- [NA] 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: #23454
# Description
Adds Guest Payments metrics, namely:
* deposit_fees_in_gbp
* waiver_payments_in_gbp
* checkin_cover_fees_in_gbp
* total_guest_payments_in_gbp
It includes:
* Daily model
* Monthly/MTD without dimension aggregates
* Monthly/MTD with dimension aggregates
* Schema entries for the abovementioned 5 models
* Temporary test to compare the different metrics against current production KPIs
# 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.
- [NA] 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: #23453
# Description
Adds GJ with Payment. It includes:
* Daily model
* Monthly/MTD without dimension aggregates
* Monthly/MTD with dimension aggregates
* Schema entries for the abovementioned 5 models
* Temporary test to compare against current production KPIs
# 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.
- [NA] 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: #23453
# Description
Fixes dbt test - I forgot to exclude dates when these are null.
# 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.
- [NA] I have checked for DRY opportunities with other models and docs.
- [NA] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Fixes null on dates
Related work items: #23453
# Description
Adds GJ Created, Started and Completed.
Each model has:
* A Daily model
* A Monthly/MTD without dimension aggregate
* A Monthly/MTD with dimension aggregate
* A comparison vs. the current flow of KPIs in the form of a test
It's quite similar as for Created Bookings. The main difference is that 1) reads from Verification Requests table and 2) I don't compute a New Dash dimension. This helps actually validating the logic of the dimension configuration macro, which works good.
I confirm that the 3 tests of comparison vs. current data work well in my local - i.e. identical content for Global, Billing Country for these 3 metrics since 2022.
This does not include:
* Guest Journeys with Payment. I'll do this in a separated PR
* Guest Payments/Revenue. I'll do this in a separated 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.
- [NA] I have checked for DRY opportunities with other models and docs. **Briefly discussed with Pablo, we'll leave it like this for the time being**
- [X] I've picked the right materialization for the affected models. **Runs quite fast**
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Related work items: #23453
# Description
This PR originally started with the intent of modifying the applicable logic for waivers where the host takes the risk (in order to follow the [current state of this specification](https://www.notion.so/knowyourguest-superhog/Guest-Services-Taxes-How-to-calculate-a5ab4c049d61427fafab669dbbffb3a2?pvs=4)).
The verification payments model was quite convoluted already: adding this logic was turning it into an unmanageable ball of hair. So I broke the rules and refactored in the same PR. The end result is that:
- The model implementation has changed quite a bit.
- Behavior for everything but host-takes-risk waivers should remain unchanged.
- Behaviour for host-takes-risk waivers should have changed.
# 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: #20043
# Description
Creates skeleton for new KPIs data flow for created_bookings metric. Details are accessible [here](https://www.notion.so/knowyourguest-superhog/KPIs-Refactor-Let-s-go-daily-2024-10-23-1280446ff9c980dc87a3dc7453e95f06?pvs=4#12a0446ff9c98085bf4dfc77f6fc22f7)
In essence:
* Models are created in intermediate in a kpis folder.
* Models have a daily segmentation. This includes `created_bookings` models, but also the daily lifecycle per listing and the segmentation. It also adds a `dimension_dates` model specific for KPIs. These have all the dimensions already in place and handle all the crazy logic.
* Other time aggregation models simply read from existing daily models which are much easier (`int_kpis__metric_mtd_created_bookings` and `int_kpis__metric_monthly_created_bookings`).
* Dimensionality aggregation can be easily added within a given timeframe (daily, mtd, monthly). For instance, I do it for mtd in the `int_kpis__aggregated_mtd_created_bookings` and for monthly in `int_kpis__aggregated_monthly_created_bookings`
* Macro configuration for dimensions: Allows to set any specific dimension for `aggregated` models. By default, the subset of global, by billing country, by number of listings and by deal apply - since these are needed for Main KPIs. I added an example with Dash Source, that currently does not exist and it's currently configured as only appearing for created bookings.
* Testing `aggregated` models completeness. A new macro called `assert_dimension_completeness` is available that ensures additive metrics are consistent vs. the global result, configurable at schema level.
* Testing refactor impact. I'm aware that changing the lifecycle model to daily impacts the volumes for listing segments. For the rest, I added a `tmp` test that checks that the dimension and dimension value per date exactly match comparing new vs. old computation.
Latest edits:
* Changed naming convention
* Split of MTD and Monthly. Now these are 2 different entities, as stated in `int_kpis__dimension_dates`.
* Added start_date and end_date for models that contemplate a range (mtd, monthly).
* Added a small readme entry in the kpis folders. Mostly it states nomenclature and some first conventions.
Dbt docs:

# 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. **Likely we'll be able to add macros for mtd and dim_agg models. We will see later on.**
- [ ] I've picked the right materialization for the affected models. **Models run ok except for the daily lifecycle of listings, which lasts several minutes in the first run. Model curr...
# Description
Sets up warning for KPIs models that will be deprecated, which are:
* 13 in core
* 2 in xero
* 5 in cross
I will keep alive the cross models that handle the final aggregations for Main KPIs for the time being, as well as the newly created Churn model that has a dependency on the monthly by deal to be filled into the mtd flow. I think handling exposure logic for Main KPIs could be a separated migration.
In other words, this is already quite a bit to migrate.
# Checklist
**I just checked that dbt compiles correctly**
- [NA] The edited models and dependants run properly with production data.
- [NA] The edited models are sufficiently documented.
- [NA] The edited models contain PK tests, and I've ran and passed them.
- [NA] I have checked for DRY opportunities with other models and docs.
- [NA] 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: #23268
# Description
Simplifies the code for the models:
* int_monthly_12m_window_contribution_by_deal
* int_monthly_churn_metrics
By just removing the additive contribution approach. This also reduces the schema file information of these 2 models. I also adapted the description to clarify the state of the models.
No rush to merge this.
# 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: #22691
# Description
Updates exposure entry for the previous top losers. Now it will become account managers overview. Link is also up to date
# Checklist
- [NA] The edited models and dependants run properly with production data.
- [NA] The edited models are sufficiently documented.
- [NA] The edited models contain PK tests, and I've ran and passed them.
- [NA] I have checked for DRY opportunities with other models and docs.
- [NA] 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: #23170
# Description
Re-aligned namings with Matt and Alex. This PR just changes the top losers, losers, winners and top winners to major decline, decline, gain and major gain respectively
# 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.
- [NA] I have checked for DRY opportunities with other models and docs.
- [NA] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Rename of categories for top losers/winners
Related work items: #23170
# Description
Exposes Churn Rates into Main KPIs, specifically Revenue Churn Rate, Bookings Churn Rate and Listings Churn Rate. This is based on the average approach.
Additionally, it adds these 3 metrics in the kpis_additive_metrics_per_dimension_are_consistent test.
Additionally, it removes from int_mtd_vs_previous_year_metrics the computation of the additive Churn Rates. The removal of further unused code will be handled in a separated 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.
- [NA] I have checked for DRY opportunities with other models and docs.
- [NA] 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: #22691
# Description
Changes:
* Explicit selection of fields in the last part of the query, rather than select *.
* Adding a few more Hubspot attributes, namely: AM, Hubspot Stage, Live Date and Cancellation Date. The main idea is to enrich the reporting with these.
* Adding the listings over 12 months. Here it's a bit more tricky than for Revenue or Bookings, since to me the main indicator is the amount of listings that are being booked in a month, over a period of 12 months (rather than unique count of listings that have been booked in the past 12 months). However, doing a sum of the listings booked in month will be very tricky for AMs and other users. I opted for averaging, and can be considered as, in average, a certain account has X amount of listings with bookings created, and this average considers the past 12 months. So I'd say it's a good estimate of the "real" size of a client in terms of potential for Superhog.
# 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.
- [NA] I have checked for DRY opportunities with other models and docs.
- [NA] 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: #22883
# Description
Decoms verification payments v1 version, and keeps v2 alive. The PBI of Guest Payments (Biz Overview) was already switched to V2 but the exposures was not reflecting it, so I changed this. Then I dropped all v1 models for verification payments and their entries in schema.
# Checklist
- [X] The edited models and dependants run properly with production data. I did run the upstream dependencies on V2 and I don't see orphans in my dbt docs. However I did not fully run end-to-end all models up to PBI reports since there's other sources involved (Xero, etc).
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [NA] I have checked for DRY opportunities with other models and docs.
- [NA] 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: #22611