# 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
# 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
Changes:
* 4 new models in the scope of KPIs for Billable Verifications from APIs. I believe it's more correct to say these are Billable Verifications than Billable Bookings since there's some cases in which a Booking can be duplicated and it's billed multiple times. These include:
* A daily metric model - extremely simple. You will notice there's no Billing Country not Listing Segmentation. This is because for ALL API cases this is UNSET, thus, I just remove it.
* An equivalent monthly metric model.
* Two aggregated models per dimension, dimension value: on a daily and a monthly basis.
Important change: the macro that handles the aggregations sets by default Billing Country and Listing Segmentation. I modified a bit the flow so the only required dimension is Global, and these are skipped for APIs models.
This is needed for the changes intended on the Growth score. In there, I'll combine both Platform Billable Bookings with API Billable Verifications.
Notice there's no MTD models. These could be added for sure; but since I'm not creating any metric in Main KPIs or similar, I opted to skip it for now. It can be done later 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: #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
Removes UNKNOWN in Service Business Type linked to 'BASIC DAMAGE DEPOSIT OR BASIC WAIVER'.
# 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.
Set option with basic waiver as deposit management
Related work items: #29649
# 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
Small refactor on Growth Score model. It just handles the dimension deals attributes at the end instead of having these in each CTE.
I also forced a partition ordered by deal AFTER the current ordering. This is a side effect because SQL randomly choses a value if the value being used to order was exactly the same (ex: revenue = 0). This was causing issues when auditing the 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.
- [ ] 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: #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
Added new invoices metrics for CIH and S&P API for KPI and Accounting 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.
- [ ] 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.
New API invoices
Related work items: #29276
# 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
