# Description
Applies the new dedicated source of truth of "is this account fake" based on Claims. This removes the previous logic.
In terms of differences, not much because:
1. New logic applied in the backend is pretty much the same as we had with a few improvements
2. This exclusion is only applied for New Dash. I checked the number of test accounts in New Dash and these are 2, the same ones in the new logic and for the old (currently in production). So no real impact.
Impact will come at the moment to start handling exclusions for KPIs, but this will done later on dedicated PRs to assess impacts 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.
- [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: #27319
# Description
This PR adds a new version to `int_core__check_in_cover_users`. The new version respectes the public interface of V1, but changes the strategy to determine which users get included in the list. Instead of relying on their account configuration (v1), v2 simply looks at whether they had any VR created offering CIH in the past 30 days.
This approach changes the semantic of the model, but we deem the new one reasonable.
The motivation behind this change is to ensure this models (1) keeps working after the activation of the Guest Products FF and (2) stays simple. Trying to follow a strategy where we look at both old and new configs was deemed very complex and didn't add much value.
# 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: #30165
# Description
Adds a field that helps categorize whether we owe money to an account or they owe money to Truvi.
Outstanding Resolutions or Outstanding Invoices
The idea is to include this field as a filter in the Invoicing & Crediting report to help Finance and Resolutions in the payment and approval process.
# 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.
Outstanding Payments
Related work items: #30204
# Description
This PR moves the categorisation of Bookings with Incidents from the flagging specific model to Booking Summary, effectively keeping this at Booking ID level.
This also handles the direct dependency with the flagging categorisation model.
I also improved the documentation and test coverage on the Booking Summary as it's becoming more and more central to many areas.
# 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
This PR prepares the existing `int_core__vr_check_in_cover` model for the activation of the Guest Products feature flag.
It creates a second logic path which identifies VRs that have CIH in them ~~through product bundles~~ through looking at `stg_core__verification_request_to_guest_product `, and unions it with the old stuff.
The new CTE only gets called after the FF gets activated. This is defined in a var that we will need to adjust depending on when do we really activate the FF.
Note that these items are still pending:
- update the var to the right value once Lawrence pulls the trigger.
- clarify what the hell happens with CIH being "pushed" or not to ALL old dash hosts. This PR currently assumes this will NOT happen. If it will happen, we will need to change things.
# 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: #30165
# 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
Creates a new metric: Confident Stay Revenue.
This includes:
* Setting the computation in `int_mtd_vs_previous_year_metrics`
* Configuring the metric behavior in `int_mtd_aggregated_metrics`. It follows the same as CIH.
* Adding the metric in the completion test. I didn't add it in the outlier test in purpose as any new value would trigger the outlier since there's no history to compare against.
Few notes:
* I confirm it displays no value, as the product has not been launched.
* Note that the inclusion of Confident Stay in Guest Revenue was already handled in the previous PR.
Next steps to complete the ticket:
* Add in the Data Glossary of Main KPIs the definition of Confident Stay Revenue
* Add in the Data Glossary of Account Performance the definition of Confident Stay Revenue
# 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.
- [N/A] I have checked for DRY opportunities with other models and docs.
- [N/A] 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: #30278
# Description
Propagates Stay Disrupt Guest Product in KPIs flow, within Guest Payments. This is done by:
* Adding a new measure on `stay_disrupt_fees_in_gbp` in the daily model `int_kpis__metric_daily_guest_payments`
* Adding stay_disrupt_fees_in_gbp in the `total_guest_payments_in_gbp` measure in the daily model `int_kpis__metric_daily_guest_payments`
Afterwards this gets propagated downstream. No changes in the `total_guest_payments_in_gbp` measure in following models. However, a new measure for `stay_disrupt_fees_in_gbp` is created in the 4 Guest Payments related models of:
* `int_kpis__metric_monthly_guest_payments`
* `int_kpis__agg_monthly_guest_payments`
* `int_kpis__metric_mtd_guest_payments`
* `int_kpis__agg_mtd_guest_payments`
Note that this also affects the schema entry of KPIs for both description and completion tests, in the case of aggregation models.
Considering the almost non-existent usage of Guest KPIs report, I will not bother propagating Confident Stay in Product Guest KPIs, nor the report itself:
However, total Guest Revenue would include Confident Stay in Guest KPIs as well.
Next steps, in a separated PR:
* Propagation of new measure `stay_disrupt_fees_in_gbp` so it's available in Main 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.
- [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: #30278
# 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
Brings additional info from Hubspot Deals regarding onboarding process
# 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
Removes 2 fields that no longer exist in the backend. Needed to do since I need to bring another table to sync_core.
No PBI dependencies found.
Fields are:
* flag_as_problem in SH User
* autonavigate in VerificationSet
# Checklist
- [X] The edited models and dependants run properly with production data.
- [ ] 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
- [X] Check if a full-refresh is required after this PR is merged.
Related work items: #30229
# Description
Integrates Guest Product Payments coming from the new flow of Guest Products.
This also removes few fields that will not be used or that do not make sense for GP specifically.
# 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: #30110
# Description
Guest Journey Payments to reporting. This aims to substitute core__verification_payments_v2, which is in use in the report of Guest Payments within Business Overview.
In order to avoid re-doing PBI work, I already set id_guest_product_payment as text for future usage. Similarly, superhog fees are called truvi fees.
# 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: #30024
# Description
Switches all models that still use int_core__verification_payments, except for the equivalent in reporting that needs a parallel GJ Payments to do a proper refactor.
# 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: #30024
# Description
Switches the 3 KPIs models that used int_core__verification_payments_v2 to now use int_core__guest_journey_payments.
Audit successful.
# 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: #30024
# Description
Creates a first version of Guest Journey Payments. This model intends to replace int_core__verification_payments, and equivalent audit succeeds.
Additional changes:
* Removed decimal conversion in source models. In the GJ Payment model I avoid doing any currency conversion (thus one less join); however we need to have all decimals to exactly replicate the same computation. Peanuts, but still.
* Tagged as deprecated: int_core__verification_payments
* Added additional fields for reference in terms of IDs and specifically a handy is_status_paid for future joins.
* Added more robust test coverage and enhanced descriptions of fields.
# 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: #30024
# Description
New model for Verification Product Payments (Waiver, Deposit, Fee + not assigned set as Unknown).
This includes:
* Similar upper case and coalesce for payment status and verification product name
* Rename of paway_minimum_commission_local_curr as it was not clear (this needs to be handled separately)
* Waiver payaway stuff
* No tax handling
Audit passed with following considerations:
```
-- THIS GOES INTO AN AUDIT FILE
{% set old_query %}
select
*
from dwh_hybrid.intermediate.int_core__verification_product_payments
{% endset %}
{% set new_query %}
select
id_verification_to_payment,
id_payment,
is_refundable,
created_at_utc,
updated_at_utc,
payment_due_at_utc,
payment_due_date_utc,
payment_paid_at_utc,
payment_paid_date_utc,
payment_reference,
refund_due_at_utc,
refund_due_date_utc,
payment_refunded_at_utc,
payment_refunded_date_utc,
refund_payment_reference,
id_user_host,
id_guest_user as id_user_guest,
id_verification,
id_verification_request,
coalesce(
upper(verification_payment_type), 'UNKNOWN'
) as verification_product_name,
currency,
total_amount_in_txn_currency,
total_amount_in_gbp,
is_host_taking_waiver_risk,
payaway_percentage,
payaway_minimum_commission_local_curr as payaway_minimum_commission_in_txn_currency,
amount_due_to_host_in_txn_currency,
amount_due_to_host_in_gbp,
superhog_fee_in_txn_currency,
superhog_fee_in_gbp,
coalesce(upper(payment_status),'UNKNOWN') as payment_status,
notes
from dwh_hybrid.intermediate.int_core__verification_payments_v2
where (verification_payment_type != 'CheckInCover' or verification_payment_type is null)
{% endset %}
{{
audit_helper.compare_and_classify_query_results(
old_query,
new_query,
primary_key_columns=["id_verification_to_payment"],
columns=[
"id_verification_to_payment",
"id_payment",
"is_refundable",
"created_at_utc",
"updated_at_utc",
"payment_due_at_utc",
"payment_due_date_utc",
"payment_paid_at_utc",
"payment_paid_date_utc",
"payment_reference",
"refund_due_at_utc",
"refund_due_date_utc",
"payment_refunded_at_utc",
"payment_refunded_date_utc",
"refund_payment_reference",
"id_user_host",
"id_user_guest",
"id_verification",
"id_verification_request",
"verification_product_name",
"currency",
"total_amount_in_txn_currency",
"total_amount_in_gbp",
"is_host_taking_waiver_risk",
"payaway_percentage",
"payaway_minimum_commission_in_txn_currency",
"amount_due_to_host_in_txn_currency",
"amount_due_to_host_in_gbp",
"superhog_fee_in_txn_currency",
...
# Description
First model for Guest Product Payments. It only contains CIH from Verification Payments (so, the "old" CIH).
Some notes:
* It does not handle taxes computation.
* It converts guest product name to upper case, as the guest product tables are in upper case. I also apply it for payment status, as well as an UNKNOWN status for whenever it's null - we'd need to consider this for the rest of the refactor.
* Computation is placed within a CTE. This is intended since at some point this will include also Guest Product Payments that come from Guest Product related tables.
* Enhanced documentation with respect to Verification Payments V2.
Audit performed:
```
-- THIS GOES INTO AN AUDIT FILE
{% set old_query %}
select
*
from dwh_hybrid.intermediate.int_core__guest_product_payments
{% endset %}
{% set new_query %}
select
id_verification_to_payment,
id_payment,
is_refundable,
created_at_utc,
updated_at_utc,
payment_due_at_utc,
payment_due_date_utc,
payment_paid_at_utc,
payment_paid_date_utc,
payment_reference,
refund_due_at_utc,
refund_due_date_utc,
payment_refunded_at_utc,
payment_refunded_date_utc,
refund_payment_reference,
id_user_host,
id_guest_user as id_user_guest,
id_verification,
id_verification_request,
upper(verification_payment_type) as guest_product_name,
currency,
total_amount_in_txn_currency,
total_amount_in_gbp,
coalesce(upper(payment_status),'UNKNOWN') as payment_status,
notes
from dwh_hybrid.intermediate.int_core__verification_payments_v2
where verification_payment_type = 'CheckInCover'
{% endset %}
{{
audit_helper.compare_and_classify_query_results(
old_query,
new_query,
primary_key_columns=["id_verification_to_payment"],
columns=[
"id_verification_to_payment",
"id_payment",
"is_refundable",
"created_at_utc",
"updated_at_utc",
"payment_due_at_utc",
"payment_due_date_utc",
"payment_paid_at_utc",
"payment_paid_date_utc",
"payment_reference",
"refund_due_at_utc",
"refund_due_date_utc",
"payment_refunded_at_utc",
"payment_refunded_date_utc",
"refund_payment_reference",
"id_user_host",
"id_user_guest",
"id_verification",
"id_verification_request",
"guest_product_name",
"currency",
"total_amount_in_txn_currency",
"total_amount_in_gbp",
"payment_status",
"notes",
],
sample_limit=10000000,
)
}}
```
# 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 ...
# Description
Fixes the Account Growth issue on the rank/share on revenue metrics.
Issue was that the share needs to be shifted one month for account computation; meaning that the impact score of April relies on the share from March (as there's no April revenue data).
The shift also affected the rank as it's based on the share.
Solution is:
* Re-bring actual revenue share and attribute it to the correct month
* Apply a coalesce giving priority to the revenue share/rank from the correct month. If no data is available (ongoing month), show share/rank of previous month. This is intended to help quantify account importance in the ongoing month - as it's actually the case in the report
Tested locally + run in prod to check the report performance. Small note, this makes revenue share not adding up anymore to 100% as accounts that go live in the same month are excluded. This is exactly the same as for Billable Items.
# 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: #30013
# 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
