data-dwh-dbt-project/models/intermediate/cross/int_mtd_aggregated_metrics.sql

667 lines
27 KiB
MySQL
Raw Normal View History

{% set metrics = [
{
"order_by": 1,
"metric": "Created Bookings (Excl. Cancelled)",
"value": "not_cancelled_created_bookings",
"previous_year_value": "previous_year_not_cancelled_created_bookings",
"relative_increment": "relative_increment_not_cancelled_created_bookings",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 2,
"metric": "Cancelled Created Bookings",
"value": "cancelled_created_bookings",
"previous_year_value": "previous_year_cancelled_created_bookings",
"relative_increment": "relative_increment_cancelled_created_bookings",
"number_format": "integer",
"increment_sign_format": "negative",
},
{
"order_by": 3,
"metric": "Total Created Bookings",
"value": "created_bookings",
"previous_year_value": "previous_year_created_bookings",
"relative_increment": "relative_increment_created_bookings",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 4,
"metric": "Check Out Bookings (Excl. Cancelled)",
"value": "not_cancelled_check_out_bookings",
"previous_year_value": "previous_year_not_cancelled_check_out_bookings",
"relative_increment": "relative_increment_not_cancelled_check_out_bookings",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 5,
"metric": "Cancelled Check Out Bookings",
"value": "cancelled_check_out_bookings",
"previous_year_value": "previous_year_cancelled_check_out_bookings",
"relative_increment": "relative_increment_cancelled_check_out_bookings",
"number_format": "integer",
"increment_sign_format": "negative",
},
{
"order_by": 6,
"metric": "Total Check Out Bookings",
"value": "check_out_bookings",
"previous_year_value": "previous_year_check_out_bookings",
"relative_increment": "relative_increment_check_out_bookings",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 8,
"metric": "Billable Check Out Bookings",
"value": "billable_check_out_bookings",
"previous_year_value": "previous_year_billable_check_out_bookings",
"relative_increment": "relative_increment_billable_check_out_bookings",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 9,
"metric": "Est. Billable Bookings",
"value": "billable_bookings",
"previous_year_value": "previous_year_billable_bookings",
"relative_increment": "relative_increment_billable_bookings",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 10,
"metric": "Guest Journey Created",
"value": "created_guest_journeys",
"previous_year_value": "previous_year_created_guest_journeys",
"relative_increment": "relative_increment_created_guest_journeys",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 11,
"metric": "Guest Journey Started",
"value": "started_guest_journeys",
"previous_year_value": "previous_year_started_guest_journeys",
"relative_increment": "relative_increment_started_guest_journeys",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 12,
"metric": "Guest Journey Completed",
"value": "completed_guest_journeys",
"previous_year_value": "previous_year_completed_guest_journeys",
"relative_increment": "relative_increment_completed_guest_journeys",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 13,
"metric": "Guest Journey with Payment",
"value": "paid_guest_journeys",
"previous_year_value": "previous_year_paid_guest_journeys",
"relative_increment": "relative_increment_paid_guest_journeys",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 20,
"metric": "Live Deals",
"value": "live_deals",
"previous_year_value": "previous_year_live_deals",
"relative_increment": "relative_increment_live_deals",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 21,
"metric": "New Deals",
"value": "new_deals",
"previous_year_value": "previous_year_new_deals",
"relative_increment": "relative_increment_new_deals",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 22,
"metric": "Deals Booked in Month",
"value": "deals_booked_in_month",
"previous_year_value": "previous_year_deals_booked_in_month",
"relative_increment": "relative_increment_deals_booked_in_month",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 23,
"metric": "Deals Booked in 6 Months",
"value": "deals_booked_in_6_months",
"previous_year_value": "previous_year_deals_booked_in_6_months",
"relative_increment": "relative_increment_deals_booked_in_6_months",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 24,
"metric": "Deals Booked in 12 Months",
"value": "deals_booked_in_12_months",
"previous_year_value": "previous_year_deals_booked_in_12_months",
"relative_increment": "relative_increment_deals_booked_in_12_months",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 25,
"metric": "Churning Deals",
"value": "churning_deals",
"previous_year_value": "previous_year_churning_deals",
"relative_increment": "relative_increment_churning_deals",
"number_format": "integer",
"increment_sign_format": "negative",
},
{
"order_by": 30,
"metric": "New Listings",
"value": "new_listings",
"previous_year_value": "previous_year_new_listings",
"relative_increment": "relative_increment_new_listings",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 31,
"metric": "First Time Booked Listings",
"value": "first_time_booked_listings",
"previous_year_value": "previous_year_first_time_booked_listings",
"relative_increment": "relative_increment_first_time_booked_listings",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 32,
"metric": "Listings Booked in Month",
"value": "listings_booked_in_month",
"previous_year_value": "previous_year_listings_booked_in_month",
"relative_increment": "relative_increment_listings_booked_in_month",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 33,
"metric": "Listings Booked in 6 Months",
"value": "listings_booked_in_6_months",
"previous_year_value": "previous_year_listings_booked_in_6_months",
"relative_increment": "relative_increment_listings_booked_in_6_months",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 34,
"metric": "Listings Booked in 12 Months",
"value": "listings_booked_in_12_months",
"previous_year_value": "previous_year_listings_booked_in_12_months",
"relative_increment": "relative_increment_listings_booked_in_12_months",
"number_format": "integer",
"increment_sign_format": "positive",
},
{
"order_by": 35,
"metric": "Churning Listings",
"value": "churning_listings",
"previous_year_value": "previous_year_churning_listings",
"relative_increment": "relative_increment_churning_listings",
"number_format": "integer",
"increment_sign_format": "negative",
},
{
"order_by": 40,
"metric": "Host Resolutions Payment Count",
"value": "xero_host_resolution_payment_count",
"previous_year_value": "previous_year_xero_host_resolution_payment_count",
"relative_increment": "relative_increment_xero_host_resolution_payment_count",
"number_format": "integer",
"increment_sign_format": "negative",
},
{
"order_by": 100,
2025-01-23 17:14:36 +01:00
"metric": "Revenue Retained Rate",
"value": "revenue_retained_ratio",
"previous_year_value": "previous_year_revenue_retained_ratio",
"relative_increment": "relative_increment_revenue_retained_ratio",
"number_format": "percentage",
"increment_sign_format": "positive",
},
{
"order_by": 101,
"metric": "Revenue Retained Post-Resolutions Rate",
"value": "revenue_retained_post_resolutions_ratio",
"previous_year_value": "previous_year_revenue_retained_post_resolutions_ratio",
"relative_increment": "relative_increment_revenue_retained_post_resolutions_ratio",
"number_format": "percentage",
"increment_sign_format": "positive",
},
{
"order_by": 102,
2025-01-24 08:30:05 +01:00
"metric": "Host Resolutions Payment Rate",
"value": "host_resolution_payment_per_created_booking_ratio",
"previous_year_value": "previous_year_host_resolution_payment_per_created_booking_ratio",
"relative_increment": "relative_increment_host_resolution_payment_per_created_booking_ratio",
2025-01-23 17:14:36 +01:00
"number_format": "percentage",
"increment_sign_format": "negative",
},
{
"order_by": 110,
"metric": "Created Booking Cancellation Rate",
"value": "cancelled_created_bookings_rate",
"previous_year_value": "previous_year_cancelled_created_bookings_rate",
"relative_increment": "relative_increment_cancelled_created_bookings_rate",
"number_format": "percentage",
"increment_sign_format": "negative",
},
{
"order_by": 111,
"metric": "Check Out Booking Cancellation Rate",
"value": "cancelled_check_out_bookings_rate",
"previous_year_value": "previous_year_cancelled_check_out_bookings_rate",
"relative_increment": "relative_increment_cancelled_check_out_bookings_rate",
"number_format": "percentage",
"increment_sign_format": "negative",
},
{
"order_by": 120,
"metric": "Guest Journey Start Rate",
"value": "start_rate_guest_journey",
"previous_year_value": "previous_year_start_rate_guest_journey",
"relative_increment": "relative_increment_start_rate_guest_journey",
"number_format": "percentage",
"increment_sign_format": "positive",
},
{
"order_by": 121,
"metric": "Guest Journey Completion Rate",
"value": "completion_rate_guest_journey",
"previous_year_value": "previous_year_completion_rate_guest_journey",
"relative_increment": "relative_increment_completion_rate_guest_journey",
"number_format": "percentage",
"increment_sign_format": "positive",
},
{
"order_by": 122,
"metric": "Guest Journey Incompletion Rate",
"value": "incompletion_rate_guest_journey",
"previous_year_value": "previous_year_incompletion_rate_guest_journey",
"relative_increment": "relative_increment_incompletion_rate_guest_journey",
"number_format": "percentage",
"increment_sign_format": "negative",
},
{
"order_by": 123,
"metric": "Guest Journey Payment Rate",
"value": "payment_rate_guest_journey",
"previous_year_value": "previous_year_payment_rate_guest_journey",
"relative_increment": "relative_increment_payment_rate_guest_journey",
"number_format": "percentage",
"increment_sign_format": "positive",
},
{
"order_by": 130,
"metric": "Revenue Churn Rate",
"value": "total_revenue_churn_average_contribution",
"previous_year_value": "previous_year_total_revenue_churn_average_contribution",
"relative_increment": "relative_increment_total_revenue_churn_average_contribution",
"number_format": "percentage",
"increment_sign_format": "negative",
},
{
"order_by": 131,
"metric": "Bookings Churn Rate",
"value": "created_bookings_churn_average_contribution",
"previous_year_value": "previous_year_created_bookings_churn_average_contribution",
"relative_increment": "relative_increment_created_bookings_churn_average_contribution",
"number_format": "percentage",
"increment_sign_format": "negative",
},
{
"order_by": 132,
"metric": "Listings Churn Rate",
"value": "listings_booked_in_month_churn_average_contribution",
"previous_year_value": "previous_year_listings_booked_in_month_churn_average_contribution",
"relative_increment": "relative_increment_listings_booked_in_month_churn_average_contribution",
"number_format": "percentage",
"increment_sign_format": "negative",
},
{
"order_by": 200,
"metric": "Total Revenue",
"value": "total_revenue_in_gbp",
"previous_year_value": "previous_year_total_revenue_in_gbp",
"relative_increment": "relative_increment_total_revenue_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 201,
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
"metric": "Revenue Retained",
"value": "revenue_retained_in_gbp",
"previous_year_value": "previous_year_revenue_retained_in_gbp",
"relative_increment": "relative_increment_revenue_retained_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 202,
"metric": "Revenue Retained Post-Resolutions",
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
"value": "revenue_retained_post_resolutions_in_gbp",
"previous_year_value": "previous_year_revenue_retained_post_resolutions_in_gbp",
"relative_increment": "relative_increment_revenue_retained_post_resolutions_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 203,
"metric": "Expected Onboarding MRR per New Deal",
"value": "expected_mrr_per_deal",
"previous_year_value": "previous_year_expected_mrr_per_deal",
"relative_increment": "relative_increment_expected_mrr_per_deal",
2025-01-27 18:26:19 +01:00
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 204,
"metric": "Expected Onboarding MRR",
"value": "expected_mrr",
"previous_year_value": "previous_year_expected_mrr",
"relative_increment": "relative_increment_expected_mrr",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
{
"order_by": 211,
"metric": "Total Revenue per Booking Created",
"value": "total_revenue_per_created_booking",
"previous_year_value": "previous_year_total_revenue_per_created_booking",
"relative_increment": "relative_increment_total_revenue_per_created_booking",
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
"increment_sign_format": "positive",
},
{
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
"order_by": 212,
"metric": "Total Revenue per Guest Journey Created",
"value": "total_revenue_per_created_guest_journey",
"previous_year_value": "previous_year_total_revenue_per_created_guest_journey",
"relative_increment": "relative_increment_total_revenue_per_created_guest_journey",
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
"increment_sign_format": "positive",
},
{
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
"order_by": 213,
"metric": "Total Revenue per Deals Booked in Month",
"value": "total_revenue_per_deals_booked_in_month",
"previous_year_value": "previous_year_total_revenue_per_deals_booked_in_month",
"relative_increment": "relative_increment_total_revenue_per_deals_booked_in_month",
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
"increment_sign_format": "positive",
},
{
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
"order_by": 214,
"metric": "Total Revenue per Listings Booked in Month",
"value": "total_revenue_per_listings_booked_in_month",
"previous_year_value": "previous_year_total_revenue_per_listings_booked_in_month",
"relative_increment": "relative_increment_total_revenue_per_listings_booked_in_month",
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 220,
"metric": "Invoiced Operator Revenue",
"value": "xero_operator_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_operator_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_operator_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 225,
Merged PR 4727: Bookings fees are now Old Dashboard Booking Fees in Main KPIs # Description Booking fees is widely used with different meanings, for old dash, for new dash, for both, etc. This is painful. First step to align on a proper naming is ensure that what we report in Main KPIs is clearly stated, which in this case, Booking Fees are now called Old Dashboard Booking Fees. Changes: * Modify `stg_seed__accounting_aggregations` seed to rename Booking Fees to Old Dashboard Booking Fees. This is for us to clarify. This is only applied for KPIs compute. I also added an empty space that I mistakenly forgot in the past for `financial_l3_aggregation`. * Modify KPIs source, i.e., `int_kpis__metric_daily_invoiced_revenue`. Here I forcefully modify the name of the field to `xero_old_dashboard_booking_net_fees_in_gbp`. * Propagate changes of downstream usages of `xero_booking_net_fees_in_gbp` to `xero_old_dashboard_booking_net_fees_in_gbp`. This affects all models, including the reporting model. On this one we still have both names to avoid breaking it. I will need to modify the data glossary in PBI anyway so I'll do this change as well. * Modify displayed metric name from Booking Fees Revenue to Old Dashboard Booking Fees Revenue. * Modify schema so it reflects the proper names, descriptions, and tests. * Ensure outlier and completion tests still work after this change. I confirm the field `xero_booking_net_fees_in_gbp` does not exist anymore in the rest of DWH after these changes, except for the abovementioned comment on the reporting line. # 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
2025-03-18 14:55:32 +00:00
"metric": "Invoiced Old Dashboard Booking Fees Revenue",
"value": "xero_old_dashboard_booking_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_old_dashboard_booking_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_old_dashboard_booking_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 226,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Invoiced Listing Fees Revenue",
"value": "xero_listing_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_listing_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_listing_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 227,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Invoiced Verification Fees Revenue",
"value": "xero_verification_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_verification_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_verification_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 231,
"metric": "Invoiced Screening Plus Revenue",
"value": "xero_screening_plus_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_screening_plus_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_screening_plus_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 232,
"metric": "Invoiced ID Verification Revenue",
"value": "xero_id_verification_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_id_verification_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_id_verification_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 233,
"metric": "Invoiced Sex Offenders Check Revenue",
"value": "xero_sex_offenders_check_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_sex_offenders_check_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_sex_offenders_check_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 234,
"metric": "Invoiced Waiver Pro Revenue",
"value": "xero_waiver_pro_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_waiver_pro_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_waiver_pro_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 235,
"metric": "Invoiced Basic Protection Revenue",
"value": "xero_basic_protection_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_basic_protection_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_basic_protection_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 236,
"metric": "Invoiced Protection Plus Revenue",
"value": "xero_protection_plus_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_protection_plus_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_protection_plus_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 237,
"metric": "Invoiced Protection Pro Revenue",
"value": "xero_protection_pro_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_protection_pro_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_protection_pro_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 240,
"metric": "Invoiced APIs Revenue",
"value": "xero_apis_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_apis_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_apis_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 245,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Invoiced Athena Revenue",
"value": "xero_guesty_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_guesty_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_guesty_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 246,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Invoiced E-Deposit Revenue",
"value": "xero_e_deposit_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_e_deposit_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_e_deposit_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 250,
"metric": "Guest Revenue",
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"value": "total_guest_payments_in_gbp",
"previous_year_value": "previous_year_total_guest_payments_in_gbp",
"relative_increment": "relative_increment_total_guest_payments_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 251,
"metric": "Guest Revenue per Guest Journey Completed",
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"value": "guest_payments_per_completed_guest_journey",
"previous_year_value": "previous_year_guest_payments_per_completed_guest_journey",
"relative_increment": "relative_increment_guest_payments_per_completed_guest_journey",
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 252,
"metric": "Guest Revenue per Guest Journey with Payment",
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"value": "guest_payments_per_paid_guest_journey",
"previous_year_value": "previous_year_guest_payments_per_paid_guest_journey",
"relative_increment": "relative_increment_guest_payments_per_paid_guest_journey",
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 260,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Deposit Fees Revenue",
"value": "deposit_fees_in_gbp",
"previous_year_value": "previous_year_deposit_fees_in_gbp",
"relative_increment": "relative_increment_deposit_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 262,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Waiver Revenue",
"value": "waiver_payments_in_gbp",
"previous_year_value": "previous_year_waiver_payments_in_gbp",
"relative_increment": "relative_increment_waiver_payments_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 263,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Damage Host-Waiver Payments",
"value": "xero_waiver_paid_back_to_host_in_gbp",
"previous_year_value": "previous_year_xero_waiver_paid_back_to_host_in_gbp",
"relative_increment": "relative_increment_xero_waiver_paid_back_to_host_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "negative",
},
{
"order_by": 264,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Waiver Retained",
"value": "waiver_net_fees_in_gbp",
"previous_year_value": "previous_year_waiver_net_fees_in_gbp",
"relative_increment": "relative_increment_waiver_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 265,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # 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. - [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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Check-In Hero Revenue",
"value": "checkin_cover_fees_in_gbp",
"previous_year_value": "previous_year_checkin_cover_fees_in_gbp",
"relative_increment": "relative_increment_checkin_cover_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
},
{
"order_by": 270,
"metric": "Host Resolutions Amount Paid",
"value": "xero_host_resolution_amount_paid_in_gbp",
"previous_year_value": "previous_year_xero_host_resolution_amount_paid_in_gbp",
"relative_increment": "relative_increment_xero_host_resolution_amount_paid_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "negative",
},
2025-01-23 17:14:36 +01:00
{
"order_by": 271,
2025-01-24 08:30:05 +01:00
"metric": "Host Resolutions Amount Paid per Booking Created",
"value": "host_resolution_amount_paid_per_created_booking",
"previous_year_value": "previous_year_host_resolution_amount_paid_per_created_booking",
"relative_increment": "relative_increment_host_resolution_amount_paid_per_created_booking",
2025-01-23 17:14:36 +01:00
"number_format": "currency_gbp",
"increment_sign_format": "negative",
},
] %}
with
int_mtd_vs_previous_year_metrics as (
select * from {{ ref("int_mtd_vs_previous_year_metrics") }}
)
{% for metric in metrics %}
select
year,
month,
day,
is_end_of_month,
is_current_month,
is_end_of_month_or_yesterday,
first_day_month,
date,
Merged PR 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # 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: #19325
2024-08-20 15:42:27 +00:00
dimension,
dimension_value,
previous_year_date,
{{ metric.order_by }} as order_by,
-- quotation marks added because text format
'{{ metric.number_format }}' as number_format,
'{{ metric.metric }}' as metric,
{{ metric.value }} as value,
{{ metric.previous_year_value }} as previous_year_value,
{{ metric.relative_increment }} as relative_increment,
case
when '{{ metric.increment_sign_format }}' = 'negative'
then {{ metric.relative_increment }} * -1
else {{ metric.relative_increment }}
end as relative_increment_with_sign_format
from int_mtd_vs_previous_year_metrics
{% if not loop.last %}
union all
{% endif %}
{% endfor %}