2024-07-08 15:58:36 +00:00
|
|
|
/*
|
|
|
|
|
This model pivots the data of the different mtd metrics models to get
|
|
|
|
|
previous year for each line & computing relative increment. --
|
|
|
|
|
*/
|
2024-08-20 15:42:27 +00:00
|
|
|
{{ config(materialized="table", unique_key=["date", "dimension", "dimension_value"]) }}
|
2024-07-08 15:58:36 +00:00
|
|
|
with
|
2024-11-04 14:52:38 +00:00
|
|
|
created_bookings as (
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_mtd_created_bookings") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
|
|
|
|
union all
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_monthly_created_bookings") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
2024-09-16 13:02:42 +02:00
|
|
|
),
|
2024-11-04 14:52:38 +00:00
|
|
|
check_out_bookings as (
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_mtd_check_out_bookings") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
|
|
|
|
union all
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_monthly_check_out_bookings") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
2024-09-16 13:02:42 +02:00
|
|
|
),
|
2024-11-04 14:52:38 +00:00
|
|
|
billable_bookings as (
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_mtd_billable_bookings") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
|
|
|
|
union all
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_monthly_billable_bookings") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
2024-07-08 15:58:36 +00:00
|
|
|
),
|
2024-11-04 14:52:38 +00:00
|
|
|
created_guest_journeys as (
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_mtd_created_guest_journeys") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
|
|
|
|
union all
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_monthly_created_guest_journeys") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
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") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
|
|
|
|
union all
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_monthly_started_guest_journeys") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
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") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
|
|
|
|
union all
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_monthly_completed_guest_journeys") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
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") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
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") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
2024-07-09 13:00:43 +00:00
|
|
|
),
|
2024-11-08 11:11:04 +00:00
|
|
|
listings as (
|
|
|
|
|
select *
|
|
|
|
|
from {{ ref("int_kpis__agg_daily_listings") }}
|
|
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-08 11:11:04 +00:00
|
|
|
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
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-08 11:11:04 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
|
|
|
|
and (is_month_to_date = true or is_end_of_month = true)
|
2024-07-09 13:00:43 +00:00
|
|
|
),
|
2024-11-04 14:52:38 +00:00
|
|
|
guest_payments as (
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_mtd_guest_payments") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
|
|
|
|
union all
|
|
|
|
|
select *
|
2024-11-05 12:17:26 +01:00
|
|
|
from {{ ref("int_kpis__agg_monthly_guest_payments") }}
|
2024-11-04 14:52:38 +00:00
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-04 14:52:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
2024-07-10 08:52:19 +00:00
|
|
|
),
|
2024-11-07 07:48:38 +00:00
|
|
|
invoiced_revenue as (
|
|
|
|
|
select *
|
|
|
|
|
from {{ ref("int_kpis__agg_mtd_invoiced_revenue") }}
|
|
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-07 07:48:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
|
|
|
|
union all
|
|
|
|
|
select *
|
|
|
|
|
from {{ ref("int_kpis__agg_monthly_invoiced_revenue") }}
|
|
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-07 07:48:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
|
|
|
|
),
|
|
|
|
|
host_resolutions as (
|
|
|
|
|
select *
|
|
|
|
|
from {{ ref("int_kpis__agg_mtd_host_resolutions") }}
|
|
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-07 07:48:38 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
|
|
|
|
union all
|
|
|
|
|
select *
|
|
|
|
|
from {{ ref("int_kpis__agg_monthly_host_resolutions") }}
|
|
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-07 07:48:38 +00:00
|
|
|
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
|
|
|
),
|
2024-10-15 10:46:56 +00:00
|
|
|
int_monthly_churn_metrics as (select * from {{ ref("int_monthly_churn_metrics") }}),
|
2024-11-11 15:57:37 +00:00
|
|
|
int_kpis__agg_dates_main_kpis as (
|
|
|
|
|
select *
|
|
|
|
|
from {{ ref("int_kpis__agg_dates_main_kpis") }}
|
|
|
|
|
where
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
dimension in ('global', 'by_number_of_listings', 'by_billing_country', 'by_business_scope')
|
2024-11-11 15:57:37 +00:00
|
|
|
and dimension_value <> 'UNSET'
|
2024-09-16 13:02:42 +02:00
|
|
|
),
|
2025-01-29 10:05:41 +01:00
|
|
|
int_monthly_onboarding_mrr_per_deal as (
|
|
|
|
|
select * from {{ ref("int_monthly_onboarding_mrr_per_deal") }}
|
|
|
|
|
),
|
|
|
|
|
int_mtd_agg_onboarding_mrr_revenue as (
|
|
|
|
|
select * from {{ ref("int_mtd_agg_onboarding_mrr_revenue") }}
|
2025-01-16 14:19:49 +01:00
|
|
|
),
|
2024-07-08 15:58:36 +00:00
|
|
|
|
|
|
|
|
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
|
|
|
|
2024-07-08 15:58:36 +00:00
|
|
|
select
|
|
|
|
|
d.year,
|
|
|
|
|
d.month,
|
|
|
|
|
d.day,
|
|
|
|
|
d.is_end_of_month,
|
|
|
|
|
d.is_current_month,
|
2024-12-09 16:13:52 +00:00
|
|
|
d.is_end_of_month_or_yesterday,
|
2024-07-16 09:14:38 +00:00
|
|
|
d.first_day_month,
|
2024-07-08 15:58:36 +00:00
|
|
|
d.date,
|
2024-08-20 15:42:27 +00:00
|
|
|
d.dimension,
|
|
|
|
|
d.dimension_value,
|
2024-07-09 13:00:43 +00:00
|
|
|
|
2025-02-06 15:12:35 +00:00
|
|
|
-- CREATED BOOKINGS --
|
2024-09-16 13:02:42 +02:00
|
|
|
created_bookings.created_bookings,
|
2025-02-06 15:12:35 +00:00
|
|
|
created_bookings.cancelled_created_bookings,
|
|
|
|
|
created_bookings.not_cancelled_created_bookings,
|
|
|
|
|
created_bookings.cancelled_created_bookings_rate,
|
|
|
|
|
|
|
|
|
|
-- CHECK OUT BOOKINGS --
|
2024-09-16 13:02:42 +02:00
|
|
|
check_out_bookings.check_out_bookings,
|
2025-02-06 15:12:35 +00:00
|
|
|
check_out_bookings.cancelled_check_out_bookings,
|
|
|
|
|
check_out_bookings.not_cancelled_check_out_bookings,
|
2025-02-17 15:59:21 +00:00
|
|
|
check_out_bookings.billable_check_out_bookings,
|
2025-02-06 15:12:35 +00:00
|
|
|
check_out_bookings.cancelled_check_out_bookings_rate,
|
|
|
|
|
|
|
|
|
|
-- OTHER BOOKINGS --
|
2024-09-16 13:02:42 +02:00
|
|
|
billable_bookings.billable_bookings,
|
2024-07-09 13:00:43 +00:00
|
|
|
|
|
|
|
|
-- GUEST JOURNEYS --
|
2024-11-04 14:52:38 +00:00
|
|
|
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,
|
2024-07-09 13:00:43 +00:00
|
|
|
|
|
|
|
|
-- DEALS --
|
|
|
|
|
deals.new_deals,
|
|
|
|
|
deals.never_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,
|
2025-02-17 07:48:11 +00:00
|
|
|
deals.live_deals,
|
2024-07-09 13:00:43 +00:00
|
|
|
|
|
|
|
|
-- LISTINGS (ACCOMMODATIONS) --
|
2024-11-08 11:11:04 +00:00
|
|
|
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,
|
2024-07-10 08:52:19 +00:00
|
|
|
|
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 --
|
2025-01-20 16:23:20 +00:00
|
|
|
-- OLD DASH --
|
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
|
|
|
invoiced_revenue.xero_old_dashboard_booking_net_fees_in_gbp,
|
2024-11-07 07:48:38 +00:00
|
|
|
invoiced_revenue.xero_listing_net_fees_in_gbp,
|
|
|
|
|
invoiced_revenue.xero_verification_net_fees_in_gbp,
|
2025-01-20 16:23:20 +00:00
|
|
|
-- NEW DASH --
|
|
|
|
|
invoiced_revenue.xero_basic_protection_net_fees_in_gbp,
|
|
|
|
|
invoiced_revenue.xero_waiver_pro_net_fees_in_gbp,
|
|
|
|
|
invoiced_revenue.xero_id_verification_net_fees_in_gbp,
|
|
|
|
|
invoiced_revenue.xero_protection_plus_net_fees_in_gbp,
|
|
|
|
|
invoiced_revenue.xero_screening_plus_net_fees_in_gbp,
|
|
|
|
|
invoiced_revenue.xero_sex_offenders_check_net_fees_in_gbp,
|
|
|
|
|
invoiced_revenue.xero_protection_pro_net_fees_in_gbp,
|
|
|
|
|
-- GLOBAL --
|
2025-03-20 13:45:44 +00:00
|
|
|
invoiced_revenue.xero_booking_net_fees_in_gbp,
|
2024-11-07 07:48:38 +00:00
|
|
|
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
|
|
|
|
2024-07-19 07:30:42 +00:00
|
|
|
-- APIs REVENUE --
|
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,
|
2024-07-19 07:30:42 +00:00
|
|
|
|
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 --
|
2024-11-07 07:48:38 +00:00
|
|
|
host_resolutions.xero_host_resolution_amount_paid_in_gbp,
|
|
|
|
|
host_resolutions.xero_host_resolution_payment_count,
|
2025-01-23 17:14:36 +01:00
|
|
|
cast(host_resolutions.xero_host_resolution_amount_paid_in_gbp as decimal)
|
|
|
|
|
/ created_bookings.created_bookings
|
2025-01-24 08:30:05 +01:00
|
|
|
as host_resolution_amount_paid_per_created_booking,
|
2025-01-24 14:17:29 +01:00
|
|
|
{{
|
|
|
|
|
return_capped_value(
|
2025-03-20 13:45:44 +00:00
|
|
|
"cast(host_resolutions.xero_host_resolution_payment_count as decimal)
|
|
|
|
|
/ created_bookings.created_bookings",
|
2025-01-24 14:17:29 +01:00
|
|
|
-1,
|
2025-02-06 15:12:35 +00:00
|
|
|
1,
|
2025-01-24 14:17:29 +01:00
|
|
|
)
|
|
|
|
|
}}
|
2025-01-24 08:30:05 +01:00
|
|
|
as host_resolution_payment_per_created_booking_ratio,
|
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
|
|
|
|
2024-07-10 08:52:19 +00:00
|
|
|
-- GUEST REVENUE AND PAYMENTS --
|
2024-07-29 09:10:58 +00:00
|
|
|
guest_payments.deposit_fees_in_gbp,
|
|
|
|
|
guest_payments.waiver_payments_in_gbp,
|
2024-11-07 07:48:38 +00:00
|
|
|
invoiced_revenue.xero_waiver_paid_back_to_host_in_gbp,
|
2024-07-29 13:16:19 +00:00
|
|
|
nullif(
|
|
|
|
|
coalesce(guest_payments.waiver_payments_in_gbp, 0)
|
2024-11-07 07:48:38 +00:00
|
|
|
+ coalesce(invoiced_revenue.xero_waiver_paid_back_to_host_in_gbp, 0),
|
2024-07-29 13:16:19 +00:00
|
|
|
0
|
|
|
|
|
) as waiver_net_fees_in_gbp,
|
2024-07-29 09:10:58 +00:00
|
|
|
guest_payments.checkin_cover_fees_in_gbp,
|
|
|
|
|
guest_payments.total_guest_payments_in_gbp,
|
2024-07-10 08:52:19 +00:00
|
|
|
|
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 --
|
2024-07-19 09:14:30 +00:00
|
|
|
nullif(
|
2024-07-29 15:15:09 +00:00
|
|
|
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
|
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),
|
2024-07-19 09:14:30 +00:00
|
|
|
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 --
|
2024-07-29 09:10:58 +00:00
|
|
|
guest_payments.total_guest_payments_in_gbp / nullif(
|
2024-11-04 14:52:38 +00:00
|
|
|
completed_guest_journeys.completed_guest_journeys, 0
|
2024-07-10 08:52:19 +00:00
|
|
|
) as guest_payments_per_completed_guest_journey,
|
2024-07-29 09:10:58 +00:00
|
|
|
guest_payments.total_guest_payments_in_gbp / nullif(
|
2024-11-04 14:52:38 +00:00
|
|
|
guest_journeys_with_payment.guest_journeys_with_payment, 0
|
2024-07-10 08:52:19 +00:00
|
|
|
) 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 --
|
2024-07-19 07:30:42 +00:00
|
|
|
(
|
2024-07-29 15:15:09 +00:00
|
|
|
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
|
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)
|
2024-09-16 13:02:42 +02:00
|
|
|
) / nullif(
|
|
|
|
|
created_bookings.created_bookings, 0
|
|
|
|
|
) as total_revenue_per_created_booking,
|
2024-07-19 07:30:42 +00:00
|
|
|
(
|
2024-07-29 15:15:09 +00:00
|
|
|
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
|
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)
|
2024-07-19 07:30:42 +00:00
|
|
|
) / nullif(
|
2024-11-04 14:52:38 +00:00
|
|
|
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,
|
2024-07-19 07:30:42 +00:00
|
|
|
(
|
2024-07-29 15:15:09 +00:00
|
|
|
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
|
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)
|
2024-07-19 07:30:42 +00:00
|
|
|
) / 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,
|
2024-07-19 07:30:42 +00:00
|
|
|
(
|
2024-07-29 15:15:09 +00:00
|
|
|
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
|
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)
|
2024-07-19 07:30:42 +00:00
|
|
|
) / nullif(
|
2024-11-08 11:11:04 +00:00
|
|
|
listings.listings_booked_in_month, 0
|
2024-10-15 10:46:56 +00:00
|
|
|
) as total_revenue_per_listings_booked_in_month,
|
|
|
|
|
|
|
|
|
|
-- CHURN --
|
2025-02-25 09:41:28 +00:00
|
|
|
churn.total_revenue_churn_preceding_12_months,
|
|
|
|
|
churn.total_revenue_global_preceding_12_months,
|
2024-10-15 10:46:56 +00:00
|
|
|
churn.total_revenue_churn_average_contribution,
|
|
|
|
|
churn.created_bookings_churn_average_contribution,
|
2024-12-31 12:10:12 +00:00
|
|
|
churn.listings_booked_in_month_churn_average_contribution,
|
|
|
|
|
|
|
|
|
|
-- INCOME RETAINED --
|
|
|
|
|
nullif(
|
|
|
|
|
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_operator_net_fees_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_apis_net_fees_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_waiver_paid_back_to_host_in_gbp, 0),
|
|
|
|
|
0
|
|
|
|
|
) as revenue_retained_in_gbp,
|
2025-01-24 14:17:29 +01:00
|
|
|
{{
|
|
|
|
|
return_capped_value(
|
2025-03-20 13:45:44 +00:00
|
|
|
"nullif(
|
|
|
|
|
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_operator_net_fees_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_apis_net_fees_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_waiver_paid_back_to_host_in_gbp, 0)
|
|
|
|
|
,0)
|
|
|
|
|
/ nullif(
|
|
|
|
|
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_operator_net_fees_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_apis_net_fees_in_gbp, 0)
|
|
|
|
|
,0)",
|
2025-01-24 14:17:29 +01:00
|
|
|
-1,
|
2025-02-06 15:12:35 +00:00
|
|
|
1,
|
2025-01-29 10:05:41 +01:00
|
|
|
)
|
2025-02-06 15:12:35 +00:00
|
|
|
}}
|
|
|
|
|
as revenue_retained_ratio,
|
2025-01-24 14:47:41 +01:00
|
|
|
|
|
|
|
|
-- INCOME RETAINED POST RESOLUTIONS--
|
|
|
|
|
nullif(
|
|
|
|
|
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_operator_net_fees_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_apis_net_fees_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_waiver_paid_back_to_host_in_gbp, 0)
|
|
|
|
|
+ coalesce(host_resolutions.xero_host_resolution_amount_paid_in_gbp, 0),
|
|
|
|
|
0
|
|
|
|
|
) as revenue_retained_post_resolutions_in_gbp,
|
2025-01-24 14:17:29 +01:00
|
|
|
{{
|
|
|
|
|
return_capped_value(
|
2025-03-20 13:45:44 +00:00
|
|
|
"nullif(
|
|
|
|
|
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_operator_net_fees_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_apis_net_fees_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_waiver_paid_back_to_host_in_gbp, 0)
|
|
|
|
|
+ coalesce(host_resolutions.xero_host_resolution_amount_paid_in_gbp, 0)
|
|
|
|
|
,0)
|
|
|
|
|
/ nullif(
|
|
|
|
|
coalesce(guest_payments.total_guest_payments_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_operator_net_fees_in_gbp, 0)
|
|
|
|
|
+ coalesce(invoiced_revenue.xero_apis_net_fees_in_gbp, 0),
|
|
|
|
|
0)",
|
2025-01-24 14:17:29 +01:00
|
|
|
-1,
|
2025-02-06 15:12:35 +00:00
|
|
|
1,
|
2025-01-24 14:17:29 +01:00
|
|
|
)
|
2025-02-06 15:12:35 +00:00
|
|
|
}}
|
|
|
|
|
as revenue_retained_post_resolutions_ratio,
|
2024-12-31 12:10:12 +00:00
|
|
|
|
2025-01-16 14:45:26 +01:00
|
|
|
-- ONBOARDING MRR METRIC --
|
2025-01-28 12:26:53 +01:00
|
|
|
onboarding_mrr.expected_mrr_per_deal,
|
2025-01-29 10:05:41 +01:00
|
|
|
onboarding_mrr_revenue.expected_mrr
|
2024-07-09 13:00:43 +00:00
|
|
|
|
2024-11-11 15:57:37 +00:00
|
|
|
from int_kpis__agg_dates_main_kpis d
|
2024-09-16 13:02:42 +02:00
|
|
|
left join
|
2024-11-04 14:52:38 +00:00
|
|
|
created_bookings
|
|
|
|
|
on d.date = created_bookings.end_date
|
2024-09-16 13:02:42 +02:00
|
|
|
and d.dimension = created_bookings.dimension
|
|
|
|
|
and d.dimension_value = created_bookings.dimension_value
|
|
|
|
|
left join
|
2024-11-04 14:52:38 +00:00
|
|
|
check_out_bookings
|
|
|
|
|
on d.date = check_out_bookings.end_date
|
2024-09-16 13:02:42 +02:00
|
|
|
and d.dimension = check_out_bookings.dimension
|
|
|
|
|
and d.dimension_value = check_out_bookings.dimension_value
|
|
|
|
|
left join
|
2024-11-04 14:52:38 +00:00
|
|
|
billable_bookings
|
|
|
|
|
on d.date = billable_bookings.end_date
|
2024-09-16 13:02:42 +02:00
|
|
|
and d.dimension = billable_bookings.dimension
|
|
|
|
|
and d.dimension_value = billable_bookings.dimension_value
|
2024-07-19 07:30:42 +00:00
|
|
|
left join
|
2024-11-04 14:52:38 +00:00
|
|
|
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
|
2024-07-19 07:30:42 +00:00
|
|
|
left join
|
2024-11-08 11:11:04 +00:00
|
|
|
listings
|
|
|
|
|
on d.date = listings.date
|
|
|
|
|
and d.dimension = listings.dimension
|
|
|
|
|
and d.dimension_value = listings.dimension_value
|
2024-09-16 13:02:42 +02:00
|
|
|
left join
|
2024-11-08 11:11:04 +00:00
|
|
|
deals
|
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
|
2024-07-19 07:30:42 +00:00
|
|
|
left join
|
2024-11-04 14:52:38 +00:00
|
|
|
guest_payments
|
|
|
|
|
on d.date = guest_payments.end_date
|
2024-08-20 15:42:27 +00:00
|
|
|
and d.dimension = guest_payments.dimension
|
|
|
|
|
and d.dimension_value = guest_payments.dimension_value
|
2024-09-16 13:02:42 +02:00
|
|
|
left join
|
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
|
2024-10-15 10:46:56 +00:00
|
|
|
left join
|
|
|
|
|
int_monthly_churn_metrics churn
|
|
|
|
|
on d.date = churn.date
|
|
|
|
|
and d.dimension = churn.dimension
|
|
|
|
|
and d.dimension_value = churn.dimension_value
|
2025-01-16 14:45:26 +01:00
|
|
|
left join
|
2025-01-29 10:05:41 +01:00
|
|
|
int_monthly_onboarding_mrr_per_deal onboarding_mrr
|
2025-01-16 14:45:26 +01:00
|
|
|
on d.date = onboarding_mrr.date
|
|
|
|
|
and d.dimension = onboarding_mrr.dimension
|
|
|
|
|
and d.dimension_value = onboarding_mrr.dimension_value
|
2025-01-29 10:05:41 +01:00
|
|
|
left join
|
|
|
|
|
int_mtd_agg_onboarding_mrr_revenue onboarding_mrr_revenue
|
|
|
|
|
on d.date = onboarding_mrr_revenue.date
|
|
|
|
|
and d.dimension = onboarding_mrr_revenue.dimension
|
|
|
|
|
and d.dimension_value = onboarding_mrr_revenue.dimension_value
|
2024-07-08 15:58:36 +00:00
|
|
|
)
|
2025-01-27 18:26:19 +01:00
|
|
|
|
2024-07-08 15:58:36 +00:00
|
|
|
select
|
|
|
|
|
current.year,
|
|
|
|
|
current.month,
|
|
|
|
|
current.day,
|
|
|
|
|
current.is_end_of_month,
|
|
|
|
|
current.is_current_month,
|
2024-12-09 16:13:52 +00:00
|
|
|
current.is_end_of_month_or_yesterday,
|
2024-07-16 09:14:38 +00:00
|
|
|
current.first_day_month,
|
2024-07-08 15:58:36 +00:00
|
|
|
current.date,
|
2024-08-20 15:42:27 +00:00
|
|
|
current.dimension,
|
|
|
|
|
current.dimension_value,
|
2024-07-08 15:58:36 +00:00
|
|
|
previous_year.date as previous_year_date,
|
|
|
|
|
|
2025-02-06 15:12:35 +00:00
|
|
|
-- CREATED BOOKINGS --
|
2024-07-10 08:52:19 +00:00
|
|
|
{{ calculate_safe_relative_increment("created_bookings") }},
|
2025-02-06 15:12:35 +00:00
|
|
|
{{ calculate_safe_relative_increment("cancelled_created_bookings") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("not_cancelled_created_bookings") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("cancelled_created_bookings_rate") }},
|
|
|
|
|
|
|
|
|
|
-- CHECK OUT BOOKINGS --
|
2024-07-10 08:52:19 +00:00
|
|
|
{{ calculate_safe_relative_increment("check_out_bookings") }},
|
2025-02-06 15:12:35 +00:00
|
|
|
{{ calculate_safe_relative_increment("cancelled_check_out_bookings") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("not_cancelled_check_out_bookings") }},
|
2025-02-17 15:59:21 +00:00
|
|
|
{{ calculate_safe_relative_increment("billable_check_out_bookings") }},
|
2025-02-06 15:12:35 +00:00
|
|
|
{{ calculate_safe_relative_increment("cancelled_check_out_bookings_rate") }},
|
|
|
|
|
|
|
|
|
|
-- OTHER BOOKINGS --
|
2024-07-15 12:32:18 +00:00
|
|
|
{{ calculate_safe_relative_increment("billable_bookings") }},
|
2024-07-09 13:00:43 +00:00
|
|
|
|
|
|
|
|
-- GUEST JOURNEYS --
|
2024-07-10 08:52:19 +00:00
|
|
|
{{ 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") }},
|
2024-07-09 13:00:43 +00:00
|
|
|
|
|
|
|
|
-- DEALS --
|
2024-07-10 08:52:19 +00:00
|
|
|
{{ calculate_safe_relative_increment("new_deals") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("never_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") }},
|
2025-02-17 07:48:11 +00:00
|
|
|
{{ calculate_safe_relative_increment("live_deals") }},
|
2024-07-09 13:00:43 +00:00
|
|
|
|
|
|
|
|
-- LISTINGS --
|
2024-07-10 08:52:19 +00:00
|
|
|
{{ 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 --
|
2025-01-20 16:23:20 +00:00
|
|
|
-- OLD DASH --
|
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
|
|
|
{{ calculate_safe_relative_increment("xero_old_dashboard_booking_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
|
|
|
{{ calculate_safe_relative_increment("xero_listing_net_fees_in_gbp") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("xero_verification_net_fees_in_gbp") }},
|
2025-01-20 16:23:20 +00:00
|
|
|
-- NEW DASH --
|
|
|
|
|
{{ calculate_safe_relative_increment("xero_basic_protection_net_fees_in_gbp") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("xero_waiver_pro_net_fees_in_gbp") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("xero_id_verification_net_fees_in_gbp") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("xero_protection_plus_net_fees_in_gbp") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("xero_screening_plus_net_fees_in_gbp") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("xero_sex_offenders_check_net_fees_in_gbp") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("xero_protection_pro_net_fees_in_gbp") }},
|
|
|
|
|
-- GLOBAL --
|
2025-03-20 13:45:44 +00:00
|
|
|
{{ calculate_safe_relative_increment("xero_booking_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
|
|
|
{{ calculate_safe_relative_increment("xero_operator_net_fees_in_gbp") }},
|
|
|
|
|
|
2024-07-19 07:30:42 +00:00
|
|
|
-- 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") }},
|
2025-01-23 17:14:36 +01:00
|
|
|
{{
|
|
|
|
|
calculate_safe_relative_increment(
|
2025-01-24 08:30:05 +01:00
|
|
|
"host_resolution_amount_paid_per_created_booking"
|
|
|
|
|
)
|
|
|
|
|
}},
|
|
|
|
|
{{
|
|
|
|
|
calculate_safe_relative_increment(
|
|
|
|
|
"host_resolution_payment_per_created_booking_ratio"
|
2025-01-23 17:14:36 +01:00
|
|
|
)
|
|
|
|
|
}},
|
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
|
|
|
|
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 --
|
2024-07-23 13:50:03 +00:00
|
|
|
{{ calculate_safe_relative_increment("deposit_fees_in_gbp") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("waiver_payments_in_gbp") }},
|
2024-07-29 13:16:19 +00:00
|
|
|
{{ calculate_safe_relative_increment("xero_waiver_paid_back_to_host_in_gbp") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("waiver_net_fees_in_gbp") }},
|
2024-07-23 13:50:03 +00:00
|
|
|
{{ calculate_safe_relative_increment("checkin_cover_fees_in_gbp") }},
|
2024-07-10 08:52:19 +00:00
|
|
|
{{ 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 --
|
2024-07-19 07:30:42 +00:00
|
|
|
{{
|
|
|
|
|
calculate_safe_relative_increment(
|
|
|
|
|
"guest_payments_per_completed_guest_journey"
|
|
|
|
|
)
|
|
|
|
|
}},
|
2024-07-10 08:52:19 +00:00
|
|
|
{{ 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 --
|
2024-07-19 07:30:42 +00:00
|
|
|
{{ 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"
|
|
|
|
|
)
|
2024-10-15 10:46:56 +00:00
|
|
|
}},
|
|
|
|
|
|
|
|
|
|
-- CHURN --
|
2025-02-25 09:41:28 +00:00
|
|
|
{{ calculate_safe_relative_increment("total_revenue_churn_preceding_12_months") }},
|
|
|
|
|
{{ calculate_safe_relative_increment("total_revenue_global_preceding_12_months") }},
|
2024-10-15 10:46:56 +00:00
|
|
|
{{ 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"
|
|
|
|
|
)
|
2024-12-31 12:10:12 +00:00
|
|
|
}},
|
|
|
|
|
|
|
|
|
|
-- INCOME RETAINED --
|
|
|
|
|
{{ calculate_safe_relative_increment("revenue_retained_in_gbp") }},
|
2025-01-23 17:14:36 +01:00
|
|
|
{{ calculate_safe_relative_increment("revenue_retained_ratio") }},
|
2024-12-31 12:10:12 +00:00
|
|
|
|
|
|
|
|
-- INCOME RETAINED POST RESOLUTIONS--
|
2025-01-16 15:32:32 +01:00
|
|
|
{{ calculate_safe_relative_increment("revenue_retained_post_resolutions_in_gbp") }},
|
2025-01-23 17:14:36 +01:00
|
|
|
{{ calculate_safe_relative_increment("revenue_retained_post_resolutions_ratio") }},
|
2024-07-08 15:58:36 +00:00
|
|
|
|
2025-01-16 14:45:26 +01:00
|
|
|
-- ONBOARDING MRR METRIC --
|
2025-01-28 12:26:53 +01:00
|
|
|
{{ calculate_safe_relative_increment("expected_mrr_per_deal") }},
|
2025-01-16 14:45:26 +01:00
|
|
|
{{ calculate_safe_relative_increment("expected_mrr") }}
|
|
|
|
|
|
2025-01-28 12:26:53 +01:00
|
|
|
from plain_kpi_combination current
|
2024-07-10 08:52:19 +00:00
|
|
|
left join
|
2025-01-28 12:26:53 +01:00
|
|
|
plain_kpi_combination previous_year
|
2024-09-16 13:02:42 +02:00
|
|
|
on current.dimension = previous_year.dimension
|
2024-08-20 15:42:27 +00:00
|
|
|
and current.dimension_value = previous_year.dimension_value
|
|
|
|
|
and current.month = previous_year.month
|
2024-07-08 15:58:36 +00:00
|
|
|
and current.year = previous_year.year + 1
|
|
|
|
|
where
|
|
|
|
|
(
|
2024-11-11 15:57:37 +00:00
|
|
|
current.is_end_of_month = true
|
Merged PR 4411: Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
# Description
Changes:
* Adapt business_kpis_configuration to include By Business Scope as production dimension.
* Sets in int_mtd_metrics_vs_previous_year the selection of business scope dimension for all KPIs models. This does not affect cross kpis models (churn/mrr). I might need to check later how to adapt Churn to include this dimension, but it's not considered as for this PR. Lastly, Billable Bookings excludes New Dash.
* Adapts condition in int_mtd_metrics_vs_previous_year so MTD values would appear independently of these appearing in the previous year. This is, the model was considering that to show current month MTD values, the dimension needed to exist the year prior. This does not happen with New Dash and I assume we never noticed because in any case, most of our dimensions have quite a long history.
* Adapts int_kpis__agg_dates_main_kpis to include the business scope dimension. By the way it's actually handled, it kind of assumes that a Deal can only be in New or Old Dash (this is correct), but while on New Dash, this deal won't have data for Old Dash (this might not be 100% correct). In any case, the global figure should be ok, and only on the deal + business scope dimensionality this could cause some potential problems. However, this is not being reported anyway at the moment.
* Adapts int_kpis__agg_dates_main_kpis to have a proper variable value for the dimensions, and this is further included in business_kpis_configuration as any other model.
Small changes:
* Adapts Churn metrics to read from dimension_deals rather than core__deals. This should be more accurate anyway.
# Checklist
- [ ] The edited models and dependants run properly with production data.
- [ ] The edited models are sufficiently documented.
- [ ] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs.
- [ ] I've picked the right materialization for the affected models.
# Other
- [ ] Check if a full-refresh is required after this PR is merged.
Propagates New Dash/Old Dash/APIs split in KPIs as per Business Scope
Related work items: #27356
2025-02-14 14:12:39 +00:00
|
|
|
or (current.is_current_month = true and (current.day = previous_year.day or previous_year.day is null))
|
2024-07-08 15:58:36 +00:00
|
|
|
)
|