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'",
|
|
|
|
|
},
|
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 #}
|
|
|
|
|
{% if entity_name != "DEALS" %}
|
|
|
|
|
{% 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 [
|
|
|
|
|
"CHECK_OUT_BOOKINGS",
|
|
|
|
|
"COMPLETED_GUEST_JOURNEYS",
|
|
|
|
|
"CREATED_BOOKINGS",
|
|
|
|
|
"CREATED_GUEST_JOURNEYS",
|
|
|
|
|
"GUEST_JOURNEYS_WITH_PAYMENT",
|
|
|
|
|
"GUEST_PAYMENTS",
|
|
|
|
|
"STARTED_GUEST_JOURNEYS",
|
2025-02-12 08:17:44 +00:00
|
|
|
"INVOICED_REVENUE",
|
|
|
|
|
"HOST_RESOLUTIONS",
|
2025-02-13 16:34:14 +00:00
|
|
|
"LISTINGS",
|
|
|
|
|
"DEALS",
|
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 %}
|
|
|
|
|
|
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 %}
|