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

510 lines
21 KiB
MySQL
Raw Normal View History

/*
This model pivots the data of the different mtd metrics models to get
previous year for each line & computing relative increment. --
*/
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
{{ config(materialized="table", unique_key=["date", "dimension", "dimension_value"]) }}
with
created_bookings as (
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_mtd_created_bookings") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
union all
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_monthly_created_bookings") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
),
check_out_bookings as (
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_mtd_check_out_bookings") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
union all
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_monthly_check_out_bookings") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
),
cancelled_bookings as (
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_mtd_cancelled_bookings") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
union all
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_monthly_cancelled_bookings") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
),
billable_bookings as (
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_mtd_billable_bookings") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
union all
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_monthly_billable_bookings") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
),
created_guest_journeys as (
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_mtd_created_guest_journeys") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
union all
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_monthly_created_guest_journeys") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
),
started_guest_journeys as (
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_mtd_started_guest_journeys") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
union all
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_monthly_started_guest_journeys") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
),
completed_guest_journeys as (
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_mtd_completed_guest_journeys") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
union all
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_monthly_completed_guest_journeys") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
),
guest_journeys_with_payment as (
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_mtd_guest_journeys_with_payment") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
union all
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_monthly_guest_journeys_with_payment") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
),
listings as (
select *
from {{ ref("int_kpis__agg_daily_listings") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
and (is_month_to_date = true or is_end_of_month = true)
),
deals as (
select *
from {{ ref("int_kpis__agg_daily_deals") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
and (is_month_to_date = true or is_end_of_month = true)
),
guest_payments as (
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_mtd_guest_payments") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
union all
select *
2024-11-05 12:17:26 +01:00
from {{ ref("int_kpis__agg_monthly_guest_payments") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
),
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
invoiced_revenue as (
select *
from {{ ref("int_kpis__agg_mtd_invoiced_revenue") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
union all
select *
from {{ ref("int_kpis__agg_monthly_invoiced_revenue") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
),
host_resolutions as (
select *
from {{ ref("int_kpis__agg_mtd_host_resolutions") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
union all
select *
from {{ ref("int_kpis__agg_monthly_host_resolutions") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
),
int_monthly_churn_metrics as (select * from {{ ref("int_monthly_churn_metrics") }}),
int_kpis__agg_dates_main_kpis as (
select *
from {{ ref("int_kpis__agg_dates_main_kpis") }}
where
dimension in ('global', 'by_number_of_listings', 'by_billing_country')
and dimension_value <> 'UNSET'
),
plain_kpi_combination as (
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
select
d.year,
d.month,
d.day,
d.is_end_of_month,
d.is_current_month,
d.is_end_of_month_or_yesterday,
d.first_day_month,
d.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
d.dimension,
d.dimension_value,
-- BOOKINGS --
created_bookings.created_bookings,
check_out_bookings.check_out_bookings,
cancelled_bookings.cancelled_bookings,
billable_bookings.billable_bookings,
-- GUEST JOURNEYS --
created_guest_journeys.created_guest_journeys,
started_guest_journeys.started_guest_journeys,
completed_guest_journeys.completed_guest_journeys,
guest_journeys_with_payment.guest_journeys_with_payment
as paid_guest_journeys,
cast(started_guest_journeys.started_guest_journeys as decimal)
/ created_guest_journeys.created_guest_journeys as start_rate_guest_journey,
cast(completed_guest_journeys.completed_guest_journeys as decimal)
/ started_guest_journeys.started_guest_journeys
as completion_rate_guest_journey,
1
- cast(completed_guest_journeys.completed_guest_journeys as decimal)
/ started_guest_journeys.started_guest_journeys
as incompletion_rate_guest_journey,
cast(guest_journeys_with_payment.guest_journeys_with_payment as decimal)
/ completed_guest_journeys.completed_guest_journeys
as payment_rate_guest_journey,
-- DEALS --
deals.new_deals,
deals.never_booked_deals,
deals.first_time_booked_deals,
deals.active_deals,
deals.churning_deals,
deals.inactive_deals,
deals.reactivated_deals,
deals.deals_booked_in_month,
deals.deals_booked_in_6_months,
deals.deals_booked_in_12_months,
-- LISTINGS (ACCOMMODATIONS) --
listings.new_listings,
listings.never_booked_listings,
listings.first_time_booked_listings,
listings.active_listings,
listings.churning_listings,
listings.inactive_listings,
listings.reactivated_listings,
listings.listings_booked_in_month,
listings.listings_booked_in_6_months,
listings.listings_booked_in_12_months,
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
-- HOST (OPERATOR) REVENUE --
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
invoiced_revenue.xero_booking_net_fees_in_gbp,
invoiced_revenue.xero_listing_net_fees_in_gbp,
invoiced_revenue.xero_verification_net_fees_in_gbp,
invoiced_revenue.xero_operator_net_fees_in_gbp,
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
-- APIs REVENUE --
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
invoiced_revenue.xero_apis_net_fees_in_gbp,
invoiced_revenue.xero_e_deposit_net_fees_in_gbp,
invoiced_revenue.xero_guesty_net_fees_in_gbp,
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
-- HOST RESOLUTIONS --
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
host_resolutions.xero_host_resolution_amount_paid_in_gbp,
host_resolutions.xero_host_resolution_payment_count,
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
-- GUEST REVENUE AND PAYMENTS --
guest_payments.deposit_fees_in_gbp,
guest_payments.waiver_payments_in_gbp,
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
invoiced_revenue.xero_waiver_paid_back_to_host_in_gbp,
nullif(
coalesce(guest_payments.waiver_payments_in_gbp, 0)
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
+ coalesce(invoiced_revenue.xero_waiver_paid_back_to_host_in_gbp, 0),
0
) as waiver_net_fees_in_gbp,
guest_payments.checkin_cover_fees_in_gbp,
guest_payments.total_guest_payments_in_gbp,
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
-- TOTAL REVENUE --
nullif(
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
+ coalesce(invoiced_revenue.xero_operator_net_fees_in_gbp, 0)
+ coalesce(invoiced_revenue.xero_apis_net_fees_in_gbp, 0),
0
) as total_revenue_in_gbp,
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
-- GUEST REVENUE AND PAYMENTS WEIGHTED METRICS --
guest_payments.total_guest_payments_in_gbp / nullif(
completed_guest_journeys.completed_guest_journeys, 0
) as guest_payments_per_completed_guest_journey,
guest_payments.total_guest_payments_in_gbp / nullif(
guest_journeys_with_payment.guest_journeys_with_payment, 0
) as guest_payments_per_paid_guest_journey,
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
-- TOTAL REVENUE WEIGHTED METRICS --
(
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
+ coalesce(invoiced_revenue.xero_operator_net_fees_in_gbp, 0)
+ coalesce(invoiced_revenue.xero_apis_net_fees_in_gbp, 0)
) / nullif(
created_bookings.created_bookings, 0
) as total_revenue_per_created_booking,
(
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
+ coalesce(invoiced_revenue.xero_operator_net_fees_in_gbp, 0)
+ coalesce(invoiced_revenue.xero_apis_net_fees_in_gbp, 0)
) / nullif(
created_guest_journeys.created_guest_journeys, 0
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
) as total_revenue_per_created_guest_journey,
(
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
+ coalesce(invoiced_revenue.xero_operator_net_fees_in_gbp, 0)
+ coalesce(invoiced_revenue.xero_apis_net_fees_in_gbp, 0)
) / nullif(
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
deals.deals_booked_in_month, 0
) as total_revenue_per_deals_booked_in_month,
(
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
+ coalesce(invoiced_revenue.xero_operator_net_fees_in_gbp, 0)
+ coalesce(invoiced_revenue.xero_apis_net_fees_in_gbp, 0)
) / nullif(
listings.listings_booked_in_month, 0
) as total_revenue_per_listings_booked_in_month,
-- CHURN --
churn.total_revenue_churn_average_contribution,
churn.created_bookings_churn_average_contribution,
churn.listings_booked_in_month_churn_average_contribution
from int_kpis__agg_dates_main_kpis d
left join
created_bookings
on d.date = created_bookings.end_date
and d.dimension = created_bookings.dimension
and d.dimension_value = created_bookings.dimension_value
left join
check_out_bookings
on d.date = check_out_bookings.end_date
and d.dimension = check_out_bookings.dimension
and d.dimension_value = check_out_bookings.dimension_value
left join
cancelled_bookings
on d.date = cancelled_bookings.end_date
and d.dimension = cancelled_bookings.dimension
and d.dimension_value = cancelled_bookings.dimension_value
left join
billable_bookings
on d.date = billable_bookings.end_date
and d.dimension = billable_bookings.dimension
and d.dimension_value = billable_bookings.dimension_value
left join
created_guest_journeys
on d.date = created_guest_journeys.end_date
and d.dimension = created_guest_journeys.dimension
and d.dimension_value = created_guest_journeys.dimension_value
left join
started_guest_journeys
on d.date = started_guest_journeys.end_date
and d.dimension = started_guest_journeys.dimension
and d.dimension_value = started_guest_journeys.dimension_value
left join
completed_guest_journeys
on d.date = completed_guest_journeys.end_date
and d.dimension = completed_guest_journeys.dimension
and d.dimension_value = completed_guest_journeys.dimension_value
left join
guest_journeys_with_payment
on d.date = guest_journeys_with_payment.end_date
and d.dimension = guest_journeys_with_payment.dimension
and d.dimension_value = guest_journeys_with_payment.dimension_value
left join
listings
on d.date = listings.date
and d.dimension = listings.dimension
and d.dimension_value = listings.dimension_value
left join
deals
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
on d.date = deals.date
and d.dimension = deals.dimension
and d.dimension_value = deals.dimension_value
left join
guest_payments
on d.date = guest_payments.end_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
and d.dimension = guest_payments.dimension
and d.dimension_value = guest_payments.dimension_value
left join
Merged PR 3443: Switch of Xero metrics New KPIs flow - Invoiced Revenue and Host Resolutions # Description Switches Xero metrics to the new KPIs flow. This uses the 2 new entities around Invoiced Revenue and Host Resolutions. The metrics affected will change computation source in PBI as well (for MTD per category and Monthly by deal views). This directly affects the following metrics: * Invoiced Operator Revenue * Invoiced Booking Fees Revenue * Invoiced Listing Fees Revenue * Invoiced Verification Fees Revenue * Invoiced APIs Revenue * Invoiced Athena Revenue * Invoiced E-Deposit Revenue * Damage Host-Waiver Payments * Host Resolutions Amount Paid * Host Resolutions Payment Count Additionally, the following metrics will be indirectly affected since depend partially on Xero: * Total Revenue * 4x Total Revenue per (Booking Created, Guest Journey Created, Deals Booked in Month, Listings Booked in Month) * Waiver Retained # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. **Same as last time - the way models are called could be improved, but let's switch everything first and then discuss. There's chances these cross models will die anyway** - [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: #23759
2024-11-07 07:48:38 +00:00
invoiced_revenue
on d.date = invoiced_revenue.end_date
and d.dimension = invoiced_revenue.dimension
and d.dimension_value = invoiced_revenue.dimension_value
left join
host_resolutions
on d.date = host_resolutions.end_date
and d.dimension = host_resolutions.dimension
and d.dimension_value = host_resolutions.dimension_value
left join
int_monthly_churn_metrics churn
on d.date = churn.date
and d.dimension = churn.dimension
and d.dimension_value = churn.dimension_value
)
select
current.year,
current.month,
current.day,
current.is_end_of_month,
current.is_current_month,
current.is_end_of_month_or_yesterday,
current.first_day_month,
current.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
current.dimension,
current.dimension_value,
previous_year.date as previous_year_date,
-- BOOKINGS --
{{ calculate_safe_relative_increment("created_bookings") }},
{{ calculate_safe_relative_increment("check_out_bookings") }},
{{ calculate_safe_relative_increment("cancelled_bookings") }},
{{ calculate_safe_relative_increment("billable_bookings") }},
-- GUEST JOURNEYS --
{{ calculate_safe_relative_increment("created_guest_journeys") }},
{{ calculate_safe_relative_increment("started_guest_journeys") }},
{{ calculate_safe_relative_increment("completed_guest_journeys") }},
{{ calculate_safe_relative_increment("paid_guest_journeys") }},
{{ calculate_safe_relative_increment("start_rate_guest_journey") }},
{{ calculate_safe_relative_increment("completion_rate_guest_journey") }},
{{ calculate_safe_relative_increment("incompletion_rate_guest_journey") }},
{{ calculate_safe_relative_increment("payment_rate_guest_journey") }},
-- DEALS --
{{ calculate_safe_relative_increment("new_deals") }},
{{ calculate_safe_relative_increment("never_booked_deals") }},
{{ calculate_safe_relative_increment("first_time_booked_deals") }},
{{ calculate_safe_relative_increment("active_deals") }},
{{ calculate_safe_relative_increment("churning_deals") }},
{{ calculate_safe_relative_increment("inactive_deals") }},
{{ calculate_safe_relative_increment("reactivated_deals") }},
{{ calculate_safe_relative_increment("deals_booked_in_month") }},
{{ calculate_safe_relative_increment("deals_booked_in_6_months") }},
{{ calculate_safe_relative_increment("deals_booked_in_12_months") }},
-- LISTINGS --
{{ calculate_safe_relative_increment("new_listings") }},
{{ calculate_safe_relative_increment("never_booked_listings") }},
{{ calculate_safe_relative_increment("first_time_booked_listings") }},
{{ calculate_safe_relative_increment("active_listings") }},
{{ calculate_safe_relative_increment("churning_listings") }},
{{ calculate_safe_relative_increment("inactive_listings") }},
{{ calculate_safe_relative_increment("reactivated_listings") }},
{{ calculate_safe_relative_increment("listings_booked_in_month") }},
{{ calculate_safe_relative_increment("listings_booked_in_6_months") }},
{{ calculate_safe_relative_increment("listings_booked_in_12_months") }},
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
-- HOST (OPERATOR) REVENUE --
{{ calculate_safe_relative_increment("xero_booking_net_fees_in_gbp") }},
{{ calculate_safe_relative_increment("xero_listing_net_fees_in_gbp") }},
{{ calculate_safe_relative_increment("xero_verification_net_fees_in_gbp") }},
{{ calculate_safe_relative_increment("xero_operator_net_fees_in_gbp") }},
-- APIs REVENUE --
{{ calculate_safe_relative_increment("xero_apis_net_fees_in_gbp") }},
{{ calculate_safe_relative_increment("xero_e_deposit_net_fees_in_gbp") }},
{{ calculate_safe_relative_increment("xero_guesty_net_fees_in_gbp") }},
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
-- HOST RESOLUTIONS --
{{ calculate_safe_relative_increment("xero_host_resolution_amount_paid_in_gbp") }},
{{ calculate_safe_relative_increment("xero_host_resolution_payment_count") }},
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
-- GUEST REVENUE --
{{ calculate_safe_relative_increment("deposit_fees_in_gbp") }},
{{ calculate_safe_relative_increment("waiver_payments_in_gbp") }},
{{ calculate_safe_relative_increment("xero_waiver_paid_back_to_host_in_gbp") }},
{{ calculate_safe_relative_increment("waiver_net_fees_in_gbp") }},
{{ calculate_safe_relative_increment("checkin_cover_fees_in_gbp") }},
{{ calculate_safe_relative_increment("total_guest_payments_in_gbp") }},
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
-- TOTAL REVENUE --
{{ calculate_safe_relative_increment("total_revenue_in_gbp") }},
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
-- GUEST REVENUE WEIGHTED METRICS --
{{
calculate_safe_relative_increment(
"guest_payments_per_completed_guest_journey"
)
}},
{{ calculate_safe_relative_increment("guest_payments_per_paid_guest_journey") }},
Merged PR 2292: Propagate invoicing metrics for KPIs This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet. This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal): - Invoiced Operator Revenue - Host Resolution Count of Payments - Host Resolution Amount Paid With these 3 new metrics, we're able to combine them with the existing ones to compute: - Total Revenue - Total Revenue per Booking Created - Total Revenue per Guest Journey Created - Total Revenue per Deal Booked in Month - Total Revenue per Listings Booked in Month You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward. Main changes: - `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics - `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side. Additional changes: - In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp` - I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning: 1 - explicit alias naming (from `gj` to `guest_journeys`) 2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type 3 - Re-apply autoformatting Related work items: #18108, #18109, #18110
2024-07-15 07:33:55 +00:00
-- TOTAL REVENUE WEIGHTED METRICS --
{{ calculate_safe_relative_increment("total_revenue_per_created_booking") }},
{{ calculate_safe_relative_increment("total_revenue_per_created_guest_journey") }},
{{ calculate_safe_relative_increment("total_revenue_per_deals_booked_in_month") }},
{{
calculate_safe_relative_increment(
"total_revenue_per_listings_booked_in_month"
)
}},
-- CHURN --
{{ calculate_safe_relative_increment("total_revenue_churn_average_contribution") }},
{{
calculate_safe_relative_increment(
"created_bookings_churn_average_contribution"
)
}},
{{
calculate_safe_relative_increment(
"listings_booked_in_month_churn_average_contribution"
)
}}
from plain_kpi_combination current
left join
plain_kpi_combination previous_year
on current.dimension = previous_year.dimension
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
and current.dimension_value = previous_year.dimension_value
and current.month = previous_year.month
and current.year = previous_year.year + 1
where
(
current.is_end_of_month = true
or (current.is_current_month = true and current.day = previous_year.day)
)