2024-08-19 09:57:28 +00:00
|
|
|
/*
|
|
|
|
|
Macro: get_kpi_dimensions_for_production
|
|
|
|
|
|
2024-11-11 15:57:37 +00:00
|
|
|
Provides the list of Dimensions that will be available in production for the Main KPIs.
|
|
|
|
|
It provides a proper display name for reporting purposes.
|
2024-08-19 09:57:28 +00:00
|
|
|
|
|
|
|
|
*/
|
|
|
|
|
{% macro get_kpi_dimensions_for_production() %}
|
2024-08-21 14:42:05 +00:00
|
|
|
{% set dimensions = [
|
2024-08-22 06:49:15 +00:00
|
|
|
{"dimension": "'global'", "dimension_display": "'Global'"},
|
Merged PR 3329: First version of KPIs refactored - created bookings
# Description
Creates skeleton for new KPIs data flow for created_bookings metric. Details are accessible [here](https://www.notion.so/knowyourguest-superhog/KPIs-Refactor-Let-s-go-daily-2024-10-23-1280446ff9c980dc87a3dc7453e95f06?pvs=4#12a0446ff9c98085bf4dfc77f6fc22f7)
In essence:
* Models are created in intermediate in a kpis folder.
* Models have a daily segmentation. This includes `created_bookings` models, but also the daily lifecycle per listing and the segmentation. It also adds a `dimension_dates` model specific for KPIs. These have all the dimensions already in place and handle all the crazy logic.
* Other time aggregation models simply read from existing daily models which are much easier (`int_kpis__metric_mtd_created_bookings` and `int_kpis__metric_monthly_created_bookings`).
* Dimensionality aggregation can be easily added within a given timeframe (daily, mtd, monthly). For instance, I do it for mtd in the `int_kpis__aggregated_mtd_created_bookings` and for monthly in `int_kpis__aggregated_monthly_created_bookings`
* Macro configuration for dimensions: Allows to set any specific dimension for `aggregated` models. By default, the subset of global, by billing country, by number of listings and by deal apply - since these are needed for Main KPIs. I added an example with Dash Source, that currently does not exist and it's currently configured as only appearing for created bookings.
* Testing `aggregated` models completeness. A new macro called `assert_dimension_completeness` is available that ensures additive metrics are consistent vs. the global result, configurable at schema level.
* Testing refactor impact. I'm aware that changing the lifecycle model to daily impacts the volumes for listing segments. For the rest, I added a `tmp` test that checks that the dimension and dimension value per date exactly match comparing new vs. old computation.
Latest edits:
* Changed naming convention
* Split of MTD and Monthly. Now these are 2 different entities, as stated in `int_kpis__dimension_dates`.
* Added start_date and end_date for models that contemplate a range (mtd, monthly).
* Added a small readme entry in the kpis folders. Mostly it states nomenclature and some first conventions.
Dbt docs:

# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs. **Likely we'll be able to add macros for mtd and dim_agg models. We will see later on.**
- [ ] I've picked the right materialization for the affected models. **Models run ok except for the daily lifecycle of listings, which lasts several minutes in the first run. Model curr...
2024-10-30 08:55:19 +00:00
|
|
|
{
|
|
|
|
|
"dimension": "'by_number_of_listings'",
|
2025-01-16 14:21:00 +01:00
|
|
|
"dimension_display": "'By # of Listings'",
|
Merged PR 3329: First version of KPIs refactored - created bookings
# Description
Creates skeleton for new KPIs data flow for created_bookings metric. Details are accessible [here](https://www.notion.so/knowyourguest-superhog/KPIs-Refactor-Let-s-go-daily-2024-10-23-1280446ff9c980dc87a3dc7453e95f06?pvs=4#12a0446ff9c98085bf4dfc77f6fc22f7)
In essence:
* Models are created in intermediate in a kpis folder.
* Models have a daily segmentation. This includes `created_bookings` models, but also the daily lifecycle per listing and the segmentation. It also adds a `dimension_dates` model specific for KPIs. These have all the dimensions already in place and handle all the crazy logic.
* Other time aggregation models simply read from existing daily models which are much easier (`int_kpis__metric_mtd_created_bookings` and `int_kpis__metric_monthly_created_bookings`).
* Dimensionality aggregation can be easily added within a given timeframe (daily, mtd, monthly). For instance, I do it for mtd in the `int_kpis__aggregated_mtd_created_bookings` and for monthly in `int_kpis__aggregated_monthly_created_bookings`
* Macro configuration for dimensions: Allows to set any specific dimension for `aggregated` models. By default, the subset of global, by billing country, by number of listings and by deal apply - since these are needed for Main KPIs. I added an example with Dash Source, that currently does not exist and it's currently configured as only appearing for created bookings.
* Testing `aggregated` models completeness. A new macro called `assert_dimension_completeness` is available that ensures additive metrics are consistent vs. the global result, configurable at schema level.
* Testing refactor impact. I'm aware that changing the lifecycle model to daily impacts the volumes for listing segments. For the rest, I added a `tmp` test that checks that the dimension and dimension value per date exactly match comparing new vs. old computation.
Latest edits:
* Changed naming convention
* Split of MTD and Monthly. Now these are 2 different entities, as stated in `int_kpis__dimension_dates`.
* Added start_date and end_date for models that contemplate a range (mtd, monthly).
* Added a small readme entry in the kpis folders. Mostly it states nomenclature and some first conventions.
Dbt docs:

# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs. **Likely we'll be able to add macros for mtd and dim_agg models. We will see later on.**
- [ ] I've picked the right materialization for the affected models. **Models run ok except for the daily lifecycle of listings, which lasts several minutes in the first run. Model curr...
2024-10-30 08:55:19 +00:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
"dimension": "'by_billing_country'",
|
|
|
|
|
"dimension_display": "'By Billing Country'",
|
|
|
|
|
},
|
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": "'by_business_scope'",
|
|
|
|
|
"dimension_display": "'By Business Scope'",
|
|
|
|
|
},
|
2024-08-21 14:42:05 +00:00
|
|
|
] %}
|
2024-08-19 09:57:28 +00:00
|
|
|
{{ return(dimensions) }}
|
Merged PR 3329: First version of KPIs refactored - created bookings
# Description
Creates skeleton for new KPIs data flow for created_bookings metric. Details are accessible [here](https://www.notion.so/knowyourguest-superhog/KPIs-Refactor-Let-s-go-daily-2024-10-23-1280446ff9c980dc87a3dc7453e95f06?pvs=4#12a0446ff9c98085bf4dfc77f6fc22f7)
In essence:
* Models are created in intermediate in a kpis folder.
* Models have a daily segmentation. This includes `created_bookings` models, but also the daily lifecycle per listing and the segmentation. It also adds a `dimension_dates` model specific for KPIs. These have all the dimensions already in place and handle all the crazy logic.
* Other time aggregation models simply read from existing daily models which are much easier (`int_kpis__metric_mtd_created_bookings` and `int_kpis__metric_monthly_created_bookings`).
* Dimensionality aggregation can be easily added within a given timeframe (daily, mtd, monthly). For instance, I do it for mtd in the `int_kpis__aggregated_mtd_created_bookings` and for monthly in `int_kpis__aggregated_monthly_created_bookings`
* Macro configuration for dimensions: Allows to set any specific dimension for `aggregated` models. By default, the subset of global, by billing country, by number of listings and by deal apply - since these are needed for Main KPIs. I added an example with Dash Source, that currently does not exist and it's currently configured as only appearing for created bookings.
* Testing `aggregated` models completeness. A new macro called `assert_dimension_completeness` is available that ensures additive metrics are consistent vs. the global result, configurable at schema level.
* Testing refactor impact. I'm aware that changing the lifecycle model to daily impacts the volumes for listing segments. For the rest, I added a `tmp` test that checks that the dimension and dimension value per date exactly match comparing new vs. old computation.
Latest edits:
* Changed naming convention
* Split of MTD and Monthly. Now these are 2 different entities, as stated in `int_kpis__dimension_dates`.
* Added start_date and end_date for models that contemplate a range (mtd, monthly).
* Added a small readme entry in the kpis folders. Mostly it states nomenclature and some first conventions.
Dbt docs:

# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs. **Likely we'll be able to add macros for mtd and dim_agg models. We will see later on.**
- [ ] I've picked the right materialization for the affected models. **Models run ok except for the daily lifecycle of listings, which lasts several minutes in the first run. Model curr...
2024-10-30 08:55:19 +00:00
|
|
|
{% endmacro %}
|
|
|
|
|
|
2024-11-20 11:01:22 +00:00
|
|
|
{% macro capitalise_and_remove_underscores(field_name) %}
|
|
|
|
|
initcap(regexp_replace({{ field_name }}, '_', ' ', 'g'))
|
|
|
|
|
{% endmacro %}
|
|
|
|
|
|
Merged PR 3329: First version of KPIs refactored - created bookings
# Description
Creates skeleton for new KPIs data flow for created_bookings metric. Details are accessible [here](https://www.notion.so/knowyourguest-superhog/KPIs-Refactor-Let-s-go-daily-2024-10-23-1280446ff9c980dc87a3dc7453e95f06?pvs=4#12a0446ff9c98085bf4dfc77f6fc22f7)
In essence:
* Models are created in intermediate in a kpis folder.
* Models have a daily segmentation. This includes `created_bookings` models, but also the daily lifecycle per listing and the segmentation. It also adds a `dimension_dates` model specific for KPIs. These have all the dimensions already in place and handle all the crazy logic.
* Other time aggregation models simply read from existing daily models which are much easier (`int_kpis__metric_mtd_created_bookings` and `int_kpis__metric_monthly_created_bookings`).
* Dimensionality aggregation can be easily added within a given timeframe (daily, mtd, monthly). For instance, I do it for mtd in the `int_kpis__aggregated_mtd_created_bookings` and for monthly in `int_kpis__aggregated_monthly_created_bookings`
* Macro configuration for dimensions: Allows to set any specific dimension for `aggregated` models. By default, the subset of global, by billing country, by number of listings and by deal apply - since these are needed for Main KPIs. I added an example with Dash Source, that currently does not exist and it's currently configured as only appearing for created bookings.
* Testing `aggregated` models completeness. A new macro called `assert_dimension_completeness` is available that ensures additive metrics are consistent vs. the global result, configurable at schema level.
* Testing refactor impact. I'm aware that changing the lifecycle model to daily impacts the volumes for listing segments. For the rest, I added a `tmp` test that checks that the dimension and dimension value per date exactly match comparing new vs. old computation.
Latest edits:
* Changed naming convention
* Split of MTD and Monthly. Now these are 2 different entities, as stated in `int_kpis__dimension_dates`.
* Added start_date and end_date for models that contemplate a range (mtd, monthly).
* Added a small readme entry in the kpis folders. Mostly it states nomenclature and some first conventions.
Dbt docs:

# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs. **Likely we'll be able to add macros for mtd and dim_agg models. We will see later on.**
- [ ] I've picked the right materialization for the affected models. **Models run ok except for the daily lifecycle of listings, which lasts several minutes in the first run. Model curr...
2024-10-30 08:55:19 +00:00
|
|
|
/*
|
|
|
|
|
The following lines specify for each dimension the field to be used in a
|
|
|
|
|
standalone macro.
|
|
|
|
|
Please note that strings should be encoded with " ' your_value_here ' ",
|
|
|
|
|
while fields from tables should be specified like " your_field_here "
|
|
|
|
|
*/
|
|
|
|
|
{% macro dim_global() %}
|
|
|
|
|
{{ return({"dimension": "'global'", "dimension_value": "'global'"}) }}
|
|
|
|
|
{% endmacro %}
|
|
|
|
|
{% macro dim_billing_country() %}
|
|
|
|
|
{{
|
|
|
|
|
return(
|
|
|
|
|
{
|
|
|
|
|
"dimension": "'by_billing_country'",
|
|
|
|
|
"dimension_value": "main_billing_country_iso_3_per_deal",
|
|
|
|
|
}
|
|
|
|
|
)
|
|
|
|
|
}}
|
|
|
|
|
{% endmacro %}
|
|
|
|
|
{% macro dim_number_of_listings() %}
|
|
|
|
|
{{
|
|
|
|
|
return(
|
|
|
|
|
{
|
|
|
|
|
"dimension": "'by_number_of_listings'",
|
|
|
|
|
"dimension_value": "active_accommodations_per_deal_segmentation",
|
|
|
|
|
}
|
|
|
|
|
)
|
|
|
|
|
}}
|
|
|
|
|
{% endmacro %}
|
|
|
|
|
{% macro dim_deal() %}
|
|
|
|
|
{{ return({"dimension": "'by_deal'", "dimension_value": "id_deal"}) }}
|
|
|
|
|
{% endmacro %}
|
2025-02-11 16:19:33 +00:00
|
|
|
{% macro dim_business_scope() %}
|
|
|
|
|
{{
|
|
|
|
|
return(
|
|
|
|
|
{"dimension": "'by_business_scope'", "dimension_value": "business_scope"}
|
|
|
|
|
)
|
|
|
|
|
}}
|
Merged PR 3329: First version of KPIs refactored - created bookings
# Description
Creates skeleton for new KPIs data flow for created_bookings metric. Details are accessible [here](https://www.notion.so/knowyourguest-superhog/KPIs-Refactor-Let-s-go-daily-2024-10-23-1280446ff9c980dc87a3dc7453e95f06?pvs=4#12a0446ff9c98085bf4dfc77f6fc22f7)
In essence:
* Models are created in intermediate in a kpis folder.
* Models have a daily segmentation. This includes `created_bookings` models, but also the daily lifecycle per listing and the segmentation. It also adds a `dimension_dates` model specific for KPIs. These have all the dimensions already in place and handle all the crazy logic.
* Other time aggregation models simply read from existing daily models which are much easier (`int_kpis__metric_mtd_created_bookings` and `int_kpis__metric_monthly_created_bookings`).
* Dimensionality aggregation can be easily added within a given timeframe (daily, mtd, monthly). For instance, I do it for mtd in the `int_kpis__aggregated_mtd_created_bookings` and for monthly in `int_kpis__aggregated_monthly_created_bookings`
* Macro configuration for dimensions: Allows to set any specific dimension for `aggregated` models. By default, the subset of global, by billing country, by number of listings and by deal apply - since these are needed for Main KPIs. I added an example with Dash Source, that currently does not exist and it's currently configured as only appearing for created bookings.
* Testing `aggregated` models completeness. A new macro called `assert_dimension_completeness` is available that ensures additive metrics are consistent vs. the global result, configurable at schema level.
* Testing refactor impact. I'm aware that changing the lifecycle model to daily impacts the volumes for listing segments. For the rest, I added a `tmp` test that checks that the dimension and dimension value per date exactly match comparing new vs. old computation.
Latest edits:
* Changed naming convention
* Split of MTD and Monthly. Now these are 2 different entities, as stated in `int_kpis__dimension_dates`.
* Added start_date and end_date for models that contemplate a range (mtd, monthly).
* Added a small readme entry in the kpis folders. Mostly it states nomenclature and some first conventions.
Dbt docs:

# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs. **Likely we'll be able to add macros for mtd and dim_agg models. We will see later on.**
- [ ] I've picked the right materialization for the affected models. **Models run ok except for the daily lifecycle of listings, which lasts several minutes in the first run. Model curr...
2024-10-30 08:55:19 +00:00
|
|
|
{% endmacro %}
|
2024-11-02 11:28:22 +01:00
|
|
|
{% macro dim_has_payment() %}
|
2024-11-04 15:28:31 +01:00
|
|
|
{{ return({"dimension": "'by_has_payment'", "dimension_value": "has_payment"}) }}
|
2024-11-02 11:28:22 +01:00
|
|
|
{% endmacro %}
|
|
|
|
|
{% macro dim_has_id_check() %}
|
2024-11-04 15:28:31 +01:00
|
|
|
{{ return({"dimension": "'by_has_id_check'", "dimension_value": "has_id_check"}) }}
|
2024-11-02 11:28:22 +01:00
|
|
|
{% endmacro %}
|
2024-11-20 09:43:30 +00:00
|
|
|
{% macro dim_has_upgraded_service() %}
|
|
|
|
|
{{
|
|
|
|
|
return(
|
|
|
|
|
{
|
|
|
|
|
"dimension": "'by_has_upgraded_service'",
|
|
|
|
|
"dimension_value": "is_upgraded_service",
|
|
|
|
|
}
|
|
|
|
|
)
|
|
|
|
|
}}
|
|
|
|
|
{% endmacro %}
|
|
|
|
|
{% macro dim_pricing_service() %}
|
|
|
|
|
{{
|
|
|
|
|
return(
|
|
|
|
|
{
|
|
|
|
|
"dimension": "'by_service'",
|
|
|
|
|
"dimension_value": "service_name",
|
|
|
|
|
}
|
|
|
|
|
)
|
|
|
|
|
}}
|
|
|
|
|
{% endmacro %}
|
2024-11-26 14:19:41 +00:00
|
|
|
{% macro dim_pricing_business_type() %}
|
|
|
|
|
{{
|
|
|
|
|
return(
|
|
|
|
|
{
|
|
|
|
|
"dimension": "'by_service_business_type'",
|
|
|
|
|
"dimension_value": "service_business_type",
|
|
|
|
|
}
|
|
|
|
|
)
|
|
|
|
|
}}
|
|
|
|
|
{% endmacro %}
|
2024-11-20 09:43:30 +00:00
|
|
|
{% macro dim_new_dash_version() %}
|
|
|
|
|
{{
|
|
|
|
|
return(
|
|
|
|
|
{
|
|
|
|
|
"dimension": "'by_new_dash_version'",
|
|
|
|
|
"dimension_value": "new_dash_version",
|
|
|
|
|
}
|
|
|
|
|
)
|
|
|
|
|
}}
|
|
|
|
|
{% endmacro %}
|
Merged PR 3329: First version of KPIs refactored - created bookings
# Description
Creates skeleton for new KPIs data flow for created_bookings metric. Details are accessible [here](https://www.notion.so/knowyourguest-superhog/KPIs-Refactor-Let-s-go-daily-2024-10-23-1280446ff9c980dc87a3dc7453e95f06?pvs=4#12a0446ff9c98085bf4dfc77f6fc22f7)
In essence:
* Models are created in intermediate in a kpis folder.
* Models have a daily segmentation. This includes `created_bookings` models, but also the daily lifecycle per listing and the segmentation. It also adds a `dimension_dates` model specific for KPIs. These have all the dimensions already in place and handle all the crazy logic.
* Other time aggregation models simply read from existing daily models which are much easier (`int_kpis__metric_mtd_created_bookings` and `int_kpis__metric_monthly_created_bookings`).
* Dimensionality aggregation can be easily added within a given timeframe (daily, mtd, monthly). For instance, I do it for mtd in the `int_kpis__aggregated_mtd_created_bookings` and for monthly in `int_kpis__aggregated_monthly_created_bookings`
* Macro configuration for dimensions: Allows to set any specific dimension for `aggregated` models. By default, the subset of global, by billing country, by number of listings and by deal apply - since these are needed for Main KPIs. I added an example with Dash Source, that currently does not exist and it's currently configured as only appearing for created bookings.
* Testing `aggregated` models completeness. A new macro called `assert_dimension_completeness` is available that ensures additive metrics are consistent vs. the global result, configurable at schema level.
* Testing refactor impact. I'm aware that changing the lifecycle model to daily impacts the volumes for listing segments. For the rest, I added a `tmp` test that checks that the dimension and dimension value per date exactly match comparing new vs. old computation.
Latest edits:
* Changed naming convention
* Split of MTD and Monthly. Now these are 2 different entities, as stated in `int_kpis__dimension_dates`.
* Added start_date and end_date for models that contemplate a range (mtd, monthly).
* Added a small readme entry in the kpis folders. Mostly it states nomenclature and some first conventions.
Dbt docs:

# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs. **Likely we'll be able to add macros for mtd and dim_agg models. We will see later on.**
- [ ] I've picked the right materialization for the affected models. **Models run ok except for the daily lifecycle of listings, which lasts several minutes in the first run. Model curr...
2024-10-30 08:55:19 +00:00
|
|
|
/*
|
|
|
|
|
Macro: get_kpi_dimensions_per_model
|
|
|
|
|
|
2024-11-11 15:57:37 +00:00
|
|
|
Provides a general assignement for the Dimensions available for each KPI
|
Merged PR 3329: First version of KPIs refactored - created bookings
# Description
Creates skeleton for new KPIs data flow for created_bookings metric. Details are accessible [here](https://www.notion.so/knowyourguest-superhog/KPIs-Refactor-Let-s-go-daily-2024-10-23-1280446ff9c980dc87a3dc7453e95f06?pvs=4#12a0446ff9c98085bf4dfc77f6fc22f7)
In essence:
* Models are created in intermediate in a kpis folder.
* Models have a daily segmentation. This includes `created_bookings` models, but also the daily lifecycle per listing and the segmentation. It also adds a `dimension_dates` model specific for KPIs. These have all the dimensions already in place and handle all the crazy logic.
* Other time aggregation models simply read from existing daily models which are much easier (`int_kpis__metric_mtd_created_bookings` and `int_kpis__metric_monthly_created_bookings`).
* Dimensionality aggregation can be easily added within a given timeframe (daily, mtd, monthly). For instance, I do it for mtd in the `int_kpis__aggregated_mtd_created_bookings` and for monthly in `int_kpis__aggregated_monthly_created_bookings`
* Macro configuration for dimensions: Allows to set any specific dimension for `aggregated` models. By default, the subset of global, by billing country, by number of listings and by deal apply - since these are needed for Main KPIs. I added an example with Dash Source, that currently does not exist and it's currently configured as only appearing for created bookings.
* Testing `aggregated` models completeness. A new macro called `assert_dimension_completeness` is available that ensures additive metrics are consistent vs. the global result, configurable at schema level.
* Testing refactor impact. I'm aware that changing the lifecycle model to daily impacts the volumes for listing segments. For the rest, I added a `tmp` test that checks that the dimension and dimension value per date exactly match comparing new vs. old computation.
Latest edits:
* Changed naming convention
* Split of MTD and Monthly. Now these are 2 different entities, as stated in `int_kpis__dimension_dates`.
* Added start_date and end_date for models that contemplate a range (mtd, monthly).
* Added a small readme entry in the kpis folders. Mostly it states nomenclature and some first conventions.
Dbt docs:

# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs. **Likely we'll be able to add macros for mtd and dim_agg models. We will see later on.**
- [ ] I've picked the right materialization for the affected models. **Models run ok except for the daily lifecycle of listings, which lasts several minutes in the first run. Model curr...
2024-10-30 08:55:19 +00:00
|
|
|
model. Keep in mind that these assignations need to be previously
|
|
|
|
|
declared.
|
|
|
|
|
|
|
|
|
|
*/
|
|
|
|
|
{% macro get_kpi_dimensions_per_model(entity_name) %}
|
|
|
|
|
|
|
|
|
|
{# Base dimensions shared by all models #}
|
|
|
|
|
{% set base_dimensions = [
|
|
|
|
|
dim_global(),
|
|
|
|
|
dim_number_of_listings(),
|
|
|
|
|
dim_billing_country(),
|
|
|
|
|
] %}
|
|
|
|
|
|
|
|
|
|
{# Initialize a list to hold any model-specific dimensions #}
|
|
|
|
|
{% set additional_dimensions = [] %}
|
|
|
|
|
|
2024-11-07 10:49:06 +00:00
|
|
|
{# Adds Deal dimension to all models except DEAL metrics #}
|
2025-03-26 15:10:50 +01:00
|
|
|
{% if entity_name not in ["DEALS", "NEW_DASH_DEALS_OFFERED_SERVICES"] %}
|
2024-11-07 10:49:06 +00:00
|
|
|
{% set additional_dimensions = additional_dimensions + [dim_deal()] %}
|
|
|
|
|
{% endif %}
|
|
|
|
|
|
Merged PR 3329: First version of KPIs refactored - created bookings
# Description
Creates skeleton for new KPIs data flow for created_bookings metric. Details are accessible [here](https://www.notion.so/knowyourguest-superhog/KPIs-Refactor-Let-s-go-daily-2024-10-23-1280446ff9c980dc87a3dc7453e95f06?pvs=4#12a0446ff9c98085bf4dfc77f6fc22f7)
In essence:
* Models are created in intermediate in a kpis folder.
* Models have a daily segmentation. This includes `created_bookings` models, but also the daily lifecycle per listing and the segmentation. It also adds a `dimension_dates` model specific for KPIs. These have all the dimensions already in place and handle all the crazy logic.
* Other time aggregation models simply read from existing daily models which are much easier (`int_kpis__metric_mtd_created_bookings` and `int_kpis__metric_monthly_created_bookings`).
* Dimensionality aggregation can be easily added within a given timeframe (daily, mtd, monthly). For instance, I do it for mtd in the `int_kpis__aggregated_mtd_created_bookings` and for monthly in `int_kpis__aggregated_monthly_created_bookings`
* Macro configuration for dimensions: Allows to set any specific dimension for `aggregated` models. By default, the subset of global, by billing country, by number of listings and by deal apply - since these are needed for Main KPIs. I added an example with Dash Source, that currently does not exist and it's currently configured as only appearing for created bookings.
* Testing `aggregated` models completeness. A new macro called `assert_dimension_completeness` is available that ensures additive metrics are consistent vs. the global result, configurable at schema level.
* Testing refactor impact. I'm aware that changing the lifecycle model to daily impacts the volumes for listing segments. For the rest, I added a `tmp` test that checks that the dimension and dimension value per date exactly match comparing new vs. old computation.
Latest edits:
* Changed naming convention
* Split of MTD and Monthly. Now these are 2 different entities, as stated in `int_kpis__dimension_dates`.
* Added start_date and end_date for models that contemplate a range (mtd, monthly).
* Added a small readme entry in the kpis folders. Mostly it states nomenclature and some first conventions.
Dbt docs:

# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs. **Likely we'll be able to add macros for mtd and dim_agg models. We will see later on.**
- [ ] I've picked the right materialization for the affected models. **Models run ok except for the daily lifecycle of listings, which lasts several minutes in the first run. Model curr...
2024-10-30 08:55:19 +00:00
|
|
|
{# Add entity-specific dimensions #}
|
2025-02-11 08:47:48 +00:00
|
|
|
{% if entity_name in [
|
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
|
|
|
"MAIN_KPIS_DATES",
|
2025-02-14 12:29:18 +00:00
|
|
|
"BILLABLE_BOOKINGS",
|
2025-02-11 08:47:48 +00:00
|
|
|
"CHECK_OUT_BOOKINGS",
|
|
|
|
|
"COMPLETED_GUEST_JOURNEYS",
|
|
|
|
|
"CREATED_BOOKINGS",
|
|
|
|
|
"CREATED_GUEST_JOURNEYS",
|
2025-02-14 12:29:18 +00:00
|
|
|
"DEALS",
|
2025-02-11 08:47:48 +00:00
|
|
|
"GUEST_JOURNEYS_WITH_PAYMENT",
|
|
|
|
|
"GUEST_PAYMENTS",
|
2025-02-12 08:17:44 +00:00
|
|
|
"HOST_RESOLUTIONS",
|
2025-02-14 12:29:18 +00:00
|
|
|
"INVOICED_REVENUE",
|
2025-02-13 16:34:14 +00:00
|
|
|
"LISTINGS",
|
2025-02-14 12:29:18 +00:00
|
|
|
"STARTED_GUEST_JOURNEYS",
|
2025-02-11 08:47:48 +00:00
|
|
|
] %}
|
2025-02-11 16:19:33 +00:00
|
|
|
{% set additional_dimensions = additional_dimensions + [dim_business_scope()] %}
|
Merged PR 3329: First version of KPIs refactored - created bookings
# Description
Creates skeleton for new KPIs data flow for created_bookings metric. Details are accessible [here](https://www.notion.so/knowyourguest-superhog/KPIs-Refactor-Let-s-go-daily-2024-10-23-1280446ff9c980dc87a3dc7453e95f06?pvs=4#12a0446ff9c98085bf4dfc77f6fc22f7)
In essence:
* Models are created in intermediate in a kpis folder.
* Models have a daily segmentation. This includes `created_bookings` models, but also the daily lifecycle per listing and the segmentation. It also adds a `dimension_dates` model specific for KPIs. These have all the dimensions already in place and handle all the crazy logic.
* Other time aggregation models simply read from existing daily models which are much easier (`int_kpis__metric_mtd_created_bookings` and `int_kpis__metric_monthly_created_bookings`).
* Dimensionality aggregation can be easily added within a given timeframe (daily, mtd, monthly). For instance, I do it for mtd in the `int_kpis__aggregated_mtd_created_bookings` and for monthly in `int_kpis__aggregated_monthly_created_bookings`
* Macro configuration for dimensions: Allows to set any specific dimension for `aggregated` models. By default, the subset of global, by billing country, by number of listings and by deal apply - since these are needed for Main KPIs. I added an example with Dash Source, that currently does not exist and it's currently configured as only appearing for created bookings.
* Testing `aggregated` models completeness. A new macro called `assert_dimension_completeness` is available that ensures additive metrics are consistent vs. the global result, configurable at schema level.
* Testing refactor impact. I'm aware that changing the lifecycle model to daily impacts the volumes for listing segments. For the rest, I added a `tmp` test that checks that the dimension and dimension value per date exactly match comparing new vs. old computation.
Latest edits:
* Changed naming convention
* Split of MTD and Monthly. Now these are 2 different entities, as stated in `int_kpis__dimension_dates`.
* Added start_date and end_date for models that contemplate a range (mtd, monthly).
* Added a small readme entry in the kpis folders. Mostly it states nomenclature and some first conventions.
Dbt docs:

# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs. **Likely we'll be able to add macros for mtd and dim_agg models. We will see later on.**
- [ ] I've picked the right materialization for the affected models. **Models run ok except for the daily lifecycle of listings, which lasts several minutes in the first run. Model curr...
2024-10-30 08:55:19 +00:00
|
|
|
{% endif %}
|
|
|
|
|
|
2024-11-04 14:29:26 +01:00
|
|
|
{% if entity_name == "CHECK_IN_ATTRIBUTED_GUEST_JOURNEYS" %}
|
2024-11-07 10:49:06 +00:00
|
|
|
{% set additional_dimensions = additional_dimensions + [
|
|
|
|
|
dim_has_payment(),
|
|
|
|
|
dim_has_id_check(),
|
|
|
|
|
] %}
|
2024-10-31 18:12:44 +01:00
|
|
|
{% endif %}
|
|
|
|
|
|
2024-11-07 12:56:49 +01:00
|
|
|
{% if entity_name == "GUEST_PAYMENTS" %}
|
2024-11-07 12:09:20 +01:00
|
|
|
{% set additional_dimensions = additional_dimensions + [
|
|
|
|
|
dim_has_id_check(),
|
|
|
|
|
] %}
|
|
|
|
|
{% endif %}
|
|
|
|
|
|
2024-11-20 09:43:30 +00:00
|
|
|
{% if entity_name == "NEW_DASH_CREATED_SERVICES" %}
|
|
|
|
|
{% set additional_dimensions = additional_dimensions + [
|
|
|
|
|
dim_has_upgraded_service(),
|
|
|
|
|
dim_new_dash_version(),
|
|
|
|
|
dim_pricing_service(),
|
2024-12-02 10:54:29 +01:00
|
|
|
dim_pricing_business_type(),
|
2024-11-20 09:43:30 +00:00
|
|
|
] %}
|
|
|
|
|
{% endif %}
|
|
|
|
|
|
2024-11-26 14:19:41 +00:00
|
|
|
{% if entity_name == "NEW_DASH_CHARGEABLE_SERVICES" %}
|
|
|
|
|
{% set additional_dimensions = additional_dimensions + [
|
|
|
|
|
dim_has_upgraded_service(),
|
|
|
|
|
dim_new_dash_version(),
|
|
|
|
|
dim_pricing_service(),
|
|
|
|
|
dim_pricing_business_type(),
|
|
|
|
|
] %}
|
|
|
|
|
{% endif %}
|
|
|
|
|
|
2025-03-26 15:10:50 +01:00
|
|
|
{% if entity_name == "NEW_DASH_DEALS_OFFERED_SERVICES" %}
|
|
|
|
|
{% set additional_dimensions = additional_dimensions + [
|
|
|
|
|
dim_has_upgraded_service(),
|
|
|
|
|
dim_new_dash_version(),
|
|
|
|
|
dim_pricing_service(),
|
|
|
|
|
dim_pricing_business_type(),
|
|
|
|
|
] %}
|
|
|
|
|
{% endif %}
|
|
|
|
|
|
Merged PR 3329: First version of KPIs refactored - created bookings
# Description
Creates skeleton for new KPIs data flow for created_bookings metric. Details are accessible [here](https://www.notion.so/knowyourguest-superhog/KPIs-Refactor-Let-s-go-daily-2024-10-23-1280446ff9c980dc87a3dc7453e95f06?pvs=4#12a0446ff9c98085bf4dfc77f6fc22f7)
In essence:
* Models are created in intermediate in a kpis folder.
* Models have a daily segmentation. This includes `created_bookings` models, but also the daily lifecycle per listing and the segmentation. It also adds a `dimension_dates` model specific for KPIs. These have all the dimensions already in place and handle all the crazy logic.
* Other time aggregation models simply read from existing daily models which are much easier (`int_kpis__metric_mtd_created_bookings` and `int_kpis__metric_monthly_created_bookings`).
* Dimensionality aggregation can be easily added within a given timeframe (daily, mtd, monthly). For instance, I do it for mtd in the `int_kpis__aggregated_mtd_created_bookings` and for monthly in `int_kpis__aggregated_monthly_created_bookings`
* Macro configuration for dimensions: Allows to set any specific dimension for `aggregated` models. By default, the subset of global, by billing country, by number of listings and by deal apply - since these are needed for Main KPIs. I added an example with Dash Source, that currently does not exist and it's currently configured as only appearing for created bookings.
* Testing `aggregated` models completeness. A new macro called `assert_dimension_completeness` is available that ensures additive metrics are consistent vs. the global result, configurable at schema level.
* Testing refactor impact. I'm aware that changing the lifecycle model to daily impacts the volumes for listing segments. For the rest, I added a `tmp` test that checks that the dimension and dimension value per date exactly match comparing new vs. old computation.
Latest edits:
* Changed naming convention
* Split of MTD and Monthly. Now these are 2 different entities, as stated in `int_kpis__dimension_dates`.
* Added start_date and end_date for models that contemplate a range (mtd, monthly).
* Added a small readme entry in the kpis folders. Mostly it states nomenclature and some first conventions.
Dbt docs:

# Checklist
- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [ ] I have checked for DRY opportunities with other models and docs. **Likely we'll be able to add macros for mtd and dim_agg models. We will see later on.**
- [ ] I've picked the right materialization for the affected models. **Models run ok except for the daily lifecycle of listings, which lasts several minutes in the first run. Model curr...
2024-10-30 08:55:19 +00:00
|
|
|
{# Combine base dimensions with additional dimensions for the specific model #}
|
|
|
|
|
{% set dimensions = base_dimensions + additional_dimensions %}
|
|
|
|
|
{{ return(dimensions) }}
|
|
|
|
|
{% endmacro %}
|