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
|
|
|
version: 2
|
|
|
|
|
|
|
|
|
|
models:
|
|
|
|
|
- name: int_kpis__dimension_dates
|
|
|
|
|
description: |
|
|
|
|
|
This model provides the daily time dimensionality needed for KPIs.
|
|
|
|
|
It only considers dates up-to-yesterday.
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Specific date. It's the primary key of this model.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- unique
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: year
|
|
|
|
|
data_type: int
|
|
|
|
|
description: Year number of the given date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: month
|
|
|
|
|
data_type: int
|
|
|
|
|
description: Month number of the given date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
2024-11-05 13:28:12 +01:00
|
|
|
- name: week
|
|
|
|
|
data_type: int
|
|
|
|
|
description: Week number of the given date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 13:28:12 +01:00
|
|
|
- not_null
|
|
|
|
|
|
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
|
|
|
- name: day
|
|
|
|
|
data_type: int
|
|
|
|
|
description: Day monthly number of the given date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: first_day_month
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
2024-11-11 15:57:37 +00:00
|
|
|
First day of the month corresponding to the date field.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: last_day_month
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
2024-11-11 15:57:37 +00:00
|
|
|
Last day of the month corresponding to the date field.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_end_of_month
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: True if it's end of month, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_current_month
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
True if the date is within the current month, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_month_to_date
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
True if the date is within the scope of month-to-date, false otherwise.
|
|
|
|
|
The scope of month-to-date takes into account both 1) a date being in
|
|
|
|
|
the current month or 2) a date corresponding to the same month of the
|
|
|
|
|
previous year, which day number cannot be higher than yesterday's day
|
|
|
|
|
number.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
2024-11-05 13:28:12 +01:00
|
|
|
- name: first_day_week
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
First day of the week corresponding to the date field.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 13:28:12 +01:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: last_day_week
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
Last day of the week corresponding to the date field.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 13:28:12 +01:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_end_of_week
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: True if it's end of week, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 13:28:12 +01:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_current_week
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
True if the date is within the current week, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 13:28:12 +01:00
|
|
|
- not_null
|
|
|
|
|
|
2024-12-09 16:13:52 +00:00
|
|
|
- name: is_yesterday
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
True if the date is yesterday, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-12-09 16:13:52 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2024-11-11 15:57:37 +00:00
|
|
|
- name: int_kpis__agg_dates_main_kpis
|
|
|
|
|
description: |
|
|
|
|
|
This model provides the skeleton of dates and dimensions needed for Main KPIs display.
|
|
|
|
|
It encapsulates the multiple manners to present data in the reporting, namely, Monthly+MTD
|
|
|
|
|
per a given dimension or specifically Monthly by Deal.
|
|
|
|
|
The rest of the metrics computed are attached to this master table.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-11 15:57:37 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics that will be
|
|
|
|
|
available in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-11 15:57:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-11 15:57:37 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- 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
|
|
|
- by_business_scope
|
2024-11-11 15:57:37 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-11 15:57:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: year
|
|
|
|
|
data_type: int
|
|
|
|
|
description: Year number of the given date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-11 15:57:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: month
|
|
|
|
|
data_type: int
|
|
|
|
|
description: Month number of the given date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-11 15:57:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: day
|
|
|
|
|
data_type: int
|
|
|
|
|
description: Day monthly number of the given date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-11 15:57:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: first_day_month
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
First day of the month corresponding to the date field.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-11 15:57:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: last_day_month
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
Last day of the month corresponding to the date field.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-11 15:57:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_end_of_month
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: True if it's end of month, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-11 15:57:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_current_month
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
True if the date is within the current month, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-11 15:57:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2024-12-09 16:13:52 +00:00
|
|
|
- name: is_end_of_month_or_yesterday
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
True if the date is the end of the month OR yesterday, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-12-09 16:13:52 +00:00
|
|
|
- not_null
|
|
|
|
|
|
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
|
|
|
- name: int_kpis__lifecycle_daily_accommodation
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the daily lifecycle segment for each accommodation, also known as
|
|
|
|
|
listings.
|
|
|
|
|
The information regarding the booking-related time allows for the current status of any listing
|
|
|
|
|
regarding its activity. This information is encapsulated in the following columns:
|
|
|
|
|
|
|
|
|
|
accommodation_lifecycle_state: contains one of the following states
|
|
|
|
|
- 01-New: Listings that have been created in the current month, without bookings
|
|
|
|
|
- 02-Never Booked: Listings that have been created before the current month, without bookings.
|
|
|
|
|
- 03-First Time Booked: Listings that have been booked for the first time in the current month.
|
|
|
|
|
- 04-Active: Listings that have booking activity in the past 12 months (that are not FTB nor reactivated)
|
|
|
|
|
- 05-Churning: Listings that are becoming inactive because of lack of bookings in the past 12 months
|
|
|
|
|
- 06-Inactive: Listings that have not had a booking for more than 12 months.
|
|
|
|
|
- 07-Reactivated: Listings that have had a booking in the current month that were inactive or churning before.
|
|
|
|
|
- Finally, if none of the logic applies, which should not happen, null will be set and a dbt alert will raise.
|
|
|
|
|
|
|
|
|
|
Since the states of Active, First Time Booked and Reactivated indicate certain booking activity and are
|
|
|
|
|
mutually exclusive, the model also provides information of the recency of the bookings by the following
|
|
|
|
|
booleans:
|
|
|
|
|
- has_been_booked_within_current_month: If a listing has had a booking created in the current month
|
|
|
|
|
- has_been_booked_within_last_6_months: If a listing has had a booking created in the past 6 months
|
|
|
|
|
- has_been_booked_within_last_12_months: If a listing has had a booking created in the past 12 months
|
|
|
|
|
Note that if a listing has had a booking created in a given month, all 3 columns will be true. Similarly,
|
|
|
|
|
if the last booking created to a listing was 5 months ago, only the column has_been_booked_in_1_month
|
|
|
|
|
will be false; while the other 2 will be true.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_accommodation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date in which a Listing has a given lifecycle state.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_accommodation
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Id of the accommodation or listing.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: creation_date_utc
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when the listing was created.
|
|
|
|
|
|
|
|
|
|
- name: first_time_booked_date_utc
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
Date of the first booking created for a given listing. Can be null if the listing
|
|
|
|
|
has never had a booking associated with it.
|
|
|
|
|
|
|
|
|
|
- name: last_time_booked_date_utc
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
Date of the last booking created for a given listing. Can be null if the listing
|
|
|
|
|
has never had a booking associated with it. Can be the same as first_time_booked_date_utc
|
|
|
|
|
if the listing only had 1 booking in its history.
|
|
|
|
|
|
|
|
|
|
- name: second_to_last_time_booked_date_utc
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
Date of the second-to-last booking created for a given listing, meaning the creation
|
|
|
|
|
date of the booking that precedes the last one. It's relevant for the reactivation computation
|
|
|
|
|
on the lifecycle. Can be null if the listing has never had a booking associated with it or if
|
|
|
|
|
the listing only had 1 booking in its history.
|
|
|
|
|
|
|
|
|
|
- name: accommodation_lifecycle_state
|
|
|
|
|
data_type: character varying
|
|
|
|
|
description: |
|
|
|
|
|
Contains the lifecycle state of a Listing. The accepted values are:
|
|
|
|
|
01-New, 02-Never Booked, 03-First Time Booked, 04-Active, 05-Churning, 06-Inactive,
|
|
|
|
|
07-Reactivated. Failing to implement the logic will result in alert.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- 01-New
|
|
|
|
|
- 02-Never Booked
|
|
|
|
|
- 03-First Time Booked
|
|
|
|
|
- 04-Active
|
|
|
|
|
- 05-Churning
|
|
|
|
|
- 06-Inactive
|
|
|
|
|
- 07-Reactivated
|
|
|
|
|
|
|
|
|
|
- name: has_been_booked_within_current_month
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: If the listing has had a booking created in the current month.
|
|
|
|
|
|
|
|
|
|
- name: has_been_booked_within_last_6_months
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: If the listing has had a booking created in the past 6 months.
|
|
|
|
|
|
|
|
|
|
- name: has_been_booked_within_last_12_months
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: If the listing has had a booking created in the past 12 months.
|
|
|
|
|
|
2024-11-07 10:49:06 +00:00
|
|
|
- name: int_kpis__lifecycle_daily_deal
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the daily lifecycle of accounts, at deal level.
|
|
|
|
|
The information regarding the booking-related time allows for the current status of any
|
|
|
|
|
deal regarding its activity. This information is encapsulated in the following columns:
|
|
|
|
|
|
|
|
|
|
deal_lifecycle_state: contains one of the following states
|
2025-03-14 11:19:22 +01:00
|
|
|
- 01-New: Deals that have been created in the current month, that are not offboarded.
|
|
|
|
|
- 02-Never Booked: Deals that have been created before the current month, without bookings, that are not offboarded.
|
2025-01-27 14:55:53 +01:00
|
|
|
- 04-Active: Deals that have booking activity in the past 12 months (not reactivated), that are not offboarded.
|
2024-11-07 10:49:06 +00:00
|
|
|
- 05-Churning: Either Deals that are offboarded in that month or Deals that are becoming inactive because of lack of bookings in the past 12 months
|
|
|
|
|
- 06-Inactive: Either Deals that have been previously offboarded or Deals that have not had a booking for more than 12 months.
|
|
|
|
|
- 07-Reactivated: Deals that have had a booking in the current month that were inactive or churning before, that are not offboarded.
|
2025-03-14 10:39:01 +01:00
|
|
|
- 99-Not in HubSpot: Deals that are not in HubSpot so we can't determine the lifecycle state.
|
2024-11-07 10:49:06 +00:00
|
|
|
|
|
|
|
|
Since the states of Active, First Time Booked and Reactivated indicate certain booking activity and are
|
|
|
|
|
mutually exclusive, the model also provides information of the recency of the bookings by the following
|
|
|
|
|
booleans:
|
|
|
|
|
- has_been_booked_within_current_month: If a deal has had a booking created in the current month
|
|
|
|
|
- has_been_booked_within_last_6_months: If a deal has had a booking created in the past 6 months
|
|
|
|
|
- has_been_booked_within_last_12_months: If a deal has had a booking created in the past 12 months
|
|
|
|
|
Note that if a deal has had a booking created in a given month, all 3 columns will be true. Similarly,
|
|
|
|
|
if the last booking created to a deal was 5 months ago, only the column has_been_booked_in_1_month
|
|
|
|
|
will be false; while the other 2 will be true.
|
|
|
|
|
Some final considerations:
|
|
|
|
|
- It's possible but not common that a Deal gets offboarded on the same month that has had some bookings created.
|
|
|
|
|
- It shouldn't happen that a Deal that is Inactive has some bookings created. However, there's few cases in which
|
|
|
|
|
this happens likely because of misconfiguration between Hubspot and Core. This should be reported to increase
|
|
|
|
|
data quality.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date in which a Deal has a given lifecycle state.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: character varying
|
|
|
|
|
description: Unique identifier of the Account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: creation_date_utc
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when the first host associated to that deal was created.
|
|
|
|
|
|
|
|
|
|
- name: first_time_booked_date_utc
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
Date of the first booking created for a given deal. Can be null if the deal
|
|
|
|
|
has never had a booking associated with it.
|
|
|
|
|
|
|
|
|
|
- name: last_time_booked_date_utc
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
Date of the last booking created for a given deal. Can be null if the deal
|
|
|
|
|
has never had a booking associated with it. Can be the same as first_time_booked_date_utc
|
|
|
|
|
if the deal only had 1 booking in its history.
|
|
|
|
|
|
|
|
|
|
- name: second_to_last_time_booked_date_utc
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
Date of the second-to-last booking created for a given deal, meaning the creation
|
|
|
|
|
date of the booking that precedes the last one. It's relevant for the reactivation computation
|
|
|
|
|
on the lifecycle. Can be null if the deal has never had a booking associated with it or if
|
|
|
|
|
the deal only had 1 booking in its history.
|
|
|
|
|
|
|
|
|
|
- name: cancellation_date_utc
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
Date of when the deal was cancelled, according to Hubspot. This is the date we're considering
|
|
|
|
|
for hard offboarding. It can be null, meaning the account has not been offboarded.
|
|
|
|
|
|
|
|
|
|
- name: deal_lifecycle_state
|
|
|
|
|
data_type: character varying
|
|
|
|
|
description: |
|
|
|
|
|
Contains the lifecycle state of a deal. The accepted values are:
|
2025-01-27 14:55:53 +01:00
|
|
|
01-New, 02-Never Booked, 04-Active, 05-Churning, 06-Inactive,
|
2025-03-14 10:39:01 +01:00
|
|
|
07-Reactivated, 99-Not in Husbpot.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- 01-New
|
|
|
|
|
- 02-Never Booked
|
|
|
|
|
- 04-Active
|
|
|
|
|
- 05-Churning
|
|
|
|
|
- 06-Inactive
|
|
|
|
|
- 07-Reactivated
|
2025-03-14 10:39:01 +01:00
|
|
|
- 99-Not in HubSpot
|
2024-11-07 10:49:06 +00:00
|
|
|
|
|
|
|
|
- name: has_been_booked_within_current_month
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
If the deal has had a booking already created in the current month.
|
|
|
|
|
Note that if the Booking is created on the 5th day, this column will
|
|
|
|
|
be false for the days 1st to 4th, and true from the day 5th onwards.
|
|
|
|
|
|
|
|
|
|
- name: has_been_booked_within_last_6_months
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
If the deal has had a booking created in the past 6 months.
|
|
|
|
|
|
|
|
|
|
- name: has_been_booked_within_last_12_months
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
If the deal has had a booking created in the past 12 months.
|
|
|
|
|
|
|
|
|
|
- name: has_been_offboarded
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
If the deal has been cancelled or not. Note that if the Deal
|
|
|
|
|
has been offboarded on the 5th day, this column will be false
|
|
|
|
|
for the days 1st to 4th, and true from the day 5th onwards.
|
|
|
|
|
|
Merged PR 3914: Include Hubspot deals for KPIs
# Description
Context: I'm intending to work on Account Managers reporting, that mostly will include reporting at Deal level the Resolutions Payouts as well as the new Retained metrics. While checking the great increase on Resolutions Payouts for October 2024:

I decided to take a quick look into the main players... and surprise surprise we have Guesty:

So Guesty represents 37k over the 73K of October. 50%. Not bad.
The main issue is that we've been aware for months now (since Churn efforts, mostly) that we're not reporting in KPIs those deals that are NOT created in Core. Most notably, API deals which includes... well, Guesty. So creating this kind of in-depth Account Managers improvement without reporting Guesty I think it would be very misleading. Note that the overall figures (Global dimension) are still accurate, though.
What's new:
* A new model named `int_kpis__dimension_deals` that basically retrieves Deals from both Core (as before) and Hubspot. It combines information from both and mostly assumes Hubspot as a better source of information than Core - although we do not have the Main Billing Country there afaik.
* Propagates changes, mostly in the monthly by deal view of Main KPIs. Here I confirm that now Guesty appears, and it only has metrics that come from Xero (APIs Revenue, Total Revenue, Resolutions, etc)
# 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: #25829
2024-12-31 15:12:38 +00:00
|
|
|
- name: int_kpis__dimension_deals
|
|
|
|
|
description: |
|
|
|
|
|
This model provides the main baseline for deals for KPIs.
|
|
|
|
|
It combines deals from both Hubspot and Core. In case of a deal
|
|
|
|
|
being present in both systems, Hubspot data will take precedence
|
|
|
|
|
in terms of deal name. Besides, the model provides the main billing
|
|
|
|
|
country according to core, in case core deals exist. Lastly, the first
|
|
|
|
|
date considered as effective date corresponds to the minimum between the
|
|
|
|
|
date a deal has gone live according to Hubspot and the first date a user
|
|
|
|
|
host has been created according to Core.
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: ID of the account, or deal.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
Merged PR 3914: Include Hubspot deals for KPIs
# Description
Context: I'm intending to work on Account Managers reporting, that mostly will include reporting at Deal level the Resolutions Payouts as well as the new Retained metrics. While checking the great increase on Resolutions Payouts for October 2024:

I decided to take a quick look into the main players... and surprise surprise we have Guesty:

So Guesty represents 37k over the 73K of October. 50%. Not bad.
The main issue is that we've been aware for months now (since Churn efforts, mostly) that we're not reporting in KPIs those deals that are NOT created in Core. Most notably, API deals which includes... well, Guesty. So creating this kind of in-depth Account Managers improvement without reporting Guesty I think it would be very misleading. Note that the overall figures (Global dimension) are still accurate, though.
What's new:
* A new model named `int_kpis__dimension_deals` that basically retrieves Deals from both Core (as before) and Hubspot. It combines information from both and mostly assumes Hubspot as a better source of information than Core - although we do not have the Main Billing Country there afaik.
* Propagates changes, mostly in the monthly by deal view of Main KPIs. Here I confirm that now Guesty appears, and it only has metrics that come from Xero (APIs Revenue, Total Revenue, Resolutions, etc)
# 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: #25829
2024-12-31 15:12:38 +00:00
|
|
|
- not_null
|
|
|
|
|
- unique
|
|
|
|
|
- name: main_deal_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main deal name according to Hubspot. In case of a deal being present
|
|
|
|
|
in both systems, Hubspot data will take precedence in terms of deal name.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
Merged PR 3914: Include Hubspot deals for KPIs
# Description
Context: I'm intending to work on Account Managers reporting, that mostly will include reporting at Deal level the Resolutions Payouts as well as the new Retained metrics. While checking the great increase on Resolutions Payouts for October 2024:

I decided to take a quick look into the main players... and surprise surprise we have Guesty:

So Guesty represents 37k over the 73K of October. 50%. Not bad.
The main issue is that we've been aware for months now (since Churn efforts, mostly) that we're not reporting in KPIs those deals that are NOT created in Core. Most notably, API deals which includes... well, Guesty. So creating this kind of in-depth Account Managers improvement without reporting Guesty I think it would be very misleading. Note that the overall figures (Global dimension) are still accurate, though.
What's new:
* A new model named `int_kpis__dimension_deals` that basically retrieves Deals from both Core (as before) and Hubspot. It combines information from both and mostly assumes Hubspot as a better source of information than Core - although we do not have the Main Billing Country there afaik.
* Propagates changes, mostly in the monthly by deal view of Main KPIs. Here I confirm that now Guesty appears, and it only has metrics that come from Xero (APIs Revenue, Total Revenue, Resolutions, etc)
# 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: #25829
2024-12-31 15:12:38 +00:00
|
|
|
- not_null
|
2025-03-13 17:19:34 +01:00
|
|
|
- name: is_deal_in_hubspot
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
Does the deal exist in HubSpot.
|
2025-01-09 16:31:22 +01:00
|
|
|
- name: has_active_pms
|
2025-01-09 15:56:58 +01:00
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
Does the deal have an active associated PMS.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2025-01-09 15:56:58 +01:00
|
|
|
- not_null
|
2025-01-09 16:31:22 +01:00
|
|
|
- name: active_pms_list
|
2025-01-09 15:56:58 +01:00
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Name of the active PMS associated with the deal. It can have more than
|
2025-01-09 16:31:22 +01:00
|
|
|
one PMS associated with it. It can be null if it doesn't have any PMS associated.
|
2025-02-11 15:13:42 +00:00
|
|
|
- name: client_type
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Type of client associated with the deal.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- API
|
|
|
|
|
- PLATFORM
|
Merged PR 3914: Include Hubspot deals for KPIs
# Description
Context: I'm intending to work on Account Managers reporting, that mostly will include reporting at Deal level the Resolutions Payouts as well as the new Retained metrics. While checking the great increase on Resolutions Payouts for October 2024:

I decided to take a quick look into the main players... and surprise surprise we have Guesty:

So Guesty represents 37k over the 73K of October. 50%. Not bad.
The main issue is that we've been aware for months now (since Churn efforts, mostly) that we're not reporting in KPIs those deals that are NOT created in Core. Most notably, API deals which includes... well, Guesty. So creating this kind of in-depth Account Managers improvement without reporting Guesty I think it would be very misleading. Note that the overall figures (Global dimension) are still accurate, though.
What's new:
* A new model named `int_kpis__dimension_deals` that basically retrieves Deals from both Core (as before) and Hubspot. It combines information from both and mostly assumes Hubspot as a better source of information than Core - although we do not have the Main Billing Country there afaik.
* Propagates changes, mostly in the monthly by deal view of Main KPIs. Here I confirm that now Guesty appears, and it only has metrics that come from Xero (APIs Revenue, Total Revenue, Resolutions, etc)
# 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: #25829
2024-12-31 15:12:38 +00:00
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level according to
|
|
|
|
|
Core. It can be null if the deal is only present in Hubspot or if the
|
|
|
|
|
field is null in Core.
|
|
|
|
|
- name: effective_deal_start_date_utc
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
2025-03-13 11:33:15 +01:00
|
|
|
Effective start date of the deal, this corresponds to the date a deal has
|
|
|
|
|
gone live according to Hubspot.
|
2025-03-13 17:29:24 +01:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
2025-01-14 16:48:49 +01:00
|
|
|
- name: effective_deal_start_month
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
2025-03-13 11:33:15 +01:00
|
|
|
This field represents the first day of the month of the effective deal
|
|
|
|
|
start date. This is obtained by truncating the effective deal start date
|
|
|
|
|
to the month.
|
2025-03-13 17:29:24 +01:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
2025-03-14 14:20:57 +01:00
|
|
|
- name: min_user_in_new_dash_since_date_utc
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The date when the first user host appeared in New Dash for this deal.
|
2025-01-14 17:25:59 +01:00
|
|
|
- name: hubspot_deal_cancellation_date_utc
|
2025-01-14 16:48:49 +01:00
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
Effective date at which the deal cancelled it's partnership with Superhog.
|
2025-01-14 17:25:59 +01:00
|
|
|
- name: hubspot_deal_cancellation_month
|
2025-01-14 16:48:49 +01:00
|
|
|
data_type: date
|
|
|
|
|
description: |
|
2025-01-14 17:25:59 +01:00
|
|
|
This field represents the first day of the month of the cancellation date
|
|
|
|
|
of the deal. This is obtained by truncating the cancellation deal date
|
|
|
|
|
to the month.
|
2025-01-14 16:48:49 +01:00
|
|
|
- name: hubspot_listing_segmentation
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
2025-01-14 17:25:59 +01:00
|
|
|
Segment value based on the number of properties managed by the deal
|
|
|
|
|
according to what was set in HubSpot.
|
2025-01-14 16:48:49 +01:00
|
|
|
data_tests:
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
Merged PR 3914: Include Hubspot deals for KPIs
# Description
Context: I'm intending to work on Account Managers reporting, that mostly will include reporting at Deal level the Resolutions Payouts as well as the new Retained metrics. While checking the great increase on Resolutions Payouts for October 2024:

I decided to take a quick look into the main players... and surprise surprise we have Guesty:

So Guesty represents 37k over the 73K of October. 50%. Not bad.
The main issue is that we've been aware for months now (since Churn efforts, mostly) that we're not reporting in KPIs those deals that are NOT created in Core. Most notably, API deals which includes... well, Guesty. So creating this kind of in-depth Account Managers improvement without reporting Guesty I think it would be very misleading. Note that the overall figures (Global dimension) are still accurate, though.
What's new:
* A new model named `int_kpis__dimension_deals` that basically retrieves Deals from both Core (as before) and Hubspot. It combines information from both and mostly assumes Hubspot as a better source of information than Core - although we do not have the Main Billing Country there afaik.
* Propagates changes, mostly in the monthly by deal view of Main KPIs. Here I confirm that now Guesty appears, and it only has metrics that come from Xero (APIs Revenue, Total Revenue, Resolutions, etc)
# 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: #25829
2024-12-31 15:12:38 +00:00
|
|
|
|
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
|
|
|
- name: int_kpis__dimension_daily_accommodation
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the deal segmentation per number of
|
|
|
|
|
listings in a daily manner.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Specific date in which the segmentation applies.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- name: accommodations_booked_in_12_months
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description:
|
|
|
|
|
Actual volume of listings that have been booked in the past 12 months
|
|
|
|
|
for a given deal and date.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_created_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Created Bookings at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- 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
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- 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
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Bookings have been created.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: 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
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
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
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily bookings created in a given date and per specified dimension.
|
|
|
|
|
|
2025-02-06 13:13:02 +00:00
|
|
|
- name: cancelled_created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily bookings created in a given date and per specified dimension
|
|
|
|
|
that have been cancelled.
|
|
|
|
|
|
|
|
|
|
- name: not_cancelled_created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily bookings created in a given date and per specified dimension
|
|
|
|
|
that have not been cancelled.
|
|
|
|
|
|
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
|
|
|
- name: int_kpis__metric_monthly_created_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Created Bookings at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- 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
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- 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
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: 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
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
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
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2024-10-31 09:03:15 +00:00
|
|
|
Count of accumulated bookings created in a given month
|
2024-10-30 11:45:45 +00:00
|
|
|
and per specified dimension.
|
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
|
|
|
|
2025-02-06 13:13:02 +00:00
|
|
|
- name: cancelled_created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings created in a given month
|
|
|
|
|
and per specified dimension that have been cancelled.
|
|
|
|
|
|
|
|
|
|
- name: not_cancelled_created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings created in a given month
|
|
|
|
|
and per specified dimension that have not been cancelled.
|
|
|
|
|
|
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
|
|
|
- name: int_kpis__metric_mtd_created_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Month-To-Date Created Bookings at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- 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
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- 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
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: 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
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
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
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2024-10-31 09:03:15 +00:00
|
|
|
Count of accumulated bookings created in a given month up to the
|
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
|
|
|
given date and per specified dimension.
|
|
|
|
|
|
2025-02-06 13:13:02 +00:00
|
|
|
- name: cancelled_created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings created in a given month up to the
|
|
|
|
|
given date and per specified dimension that have been cancelled.
|
|
|
|
|
|
|
|
|
|
- name: not_cancelled_created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings created in a given month up to the
|
|
|
|
|
given date and per specified dimension that have not been cancelled.
|
|
|
|
|
|
2025-04-24 12:42:21 +00:00
|
|
|
- name: int_kpis__agg_daily_billable_bookings
|
2025-03-11 14:34:30 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
2025-04-24 12:42:21 +00:00
|
|
|
Daily Billable Bookings.
|
2025-03-11 14:34:30 +00:00
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start and end date of the time range considered for
|
|
|
|
|
the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
2025-04-24 12:42:21 +00:00
|
|
|
- billable_bookings
|
2025-03-11 14:34:30 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_business_scope
|
|
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
2025-04-24 12:42:21 +00:00
|
|
|
- name: billable_bookings
|
2025-03-11 14:34:30 +00:00
|
|
|
data_type: bigint
|
2025-04-24 12:42:21 +00:00
|
|
|
description: The daily billable bookings for a given date, dimension and value.
|
2025-03-11 14:34:30 +00:00
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_monthly_created_bookings
|
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
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Created Bookings.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- created_bookings
|
2025-02-06 13:13:02 +00:00
|
|
|
- cancelled_created_bookings
|
|
|
|
|
- not_cancelled_created_bookings
|
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
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_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
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_bookings
|
|
|
|
|
data_type: bigint
|
2024-10-30 11:45:45 +00:00
|
|
|
description: The monthly created bookings for a given date, dimension and value.
|
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
|
|
|
|
2025-02-06 13:13:02 +00:00
|
|
|
- name: cancelled_created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The monthly cancelled created bookings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: not_cancelled_created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The monthly not cancelled created bookings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: cancelled_created_bookings_rate
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly rate of cancelled created bookings for a given date, dimension and value.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_mtd_created_bookings
|
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
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Month-To-Date Created Bookings.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- created_bookings
|
2025-02-06 13:13:02 +00:00
|
|
|
- cancelled_created_bookings
|
|
|
|
|
- not_cancelled_created_bookings
|
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
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_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
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
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
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The month-to-date created bookings for a given date, dimension and value.
|
2024-10-30 11:45:45 +00:00
|
|
|
|
2025-02-06 13:13:02 +00:00
|
|
|
- name: cancelled_created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date cancelled created bookings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: not_cancelled_created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date not cancelled created bookings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: cancelled_created_bookings_rate
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date rate of cancelled created bookings for a given date, dimension and value.
|
|
|
|
|
|
2024-10-30 11:45:45 +00:00
|
|
|
- name: int_kpis__metric_daily_created_guest_journeys
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Created Guest Journeys at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
2025-02-11 07:12:46 +00:00
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Guest Journeys have been created.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 07:12:46 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 07:12:46 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 07:12:46 +00:00
|
|
|
|
2024-10-30 11:45:45 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys created in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_created_guest_journeys
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Created Guest Journeys at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 08:47:48 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 08:47:48 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 08:47:48 +00:00
|
|
|
|
2024-10-30 11:45:45 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2024-10-31 09:03:15 +00:00
|
|
|
Count of accumulated guest journeys created in a given month
|
2024-10-30 11:45:45 +00:00
|
|
|
and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_mtd_created_guest_journeys
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Month-To-Date Created Guest Journeys at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 08:47:48 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 08:47:48 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 08:47:48 +00:00
|
|
|
|
2024-10-30 11:45:45 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2024-10-31 09:03:15 +00:00
|
|
|
Count of accumulated guest journeys created in a given month up to the
|
2024-10-30 11:45:45 +00:00
|
|
|
given date and per specified dimension.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_monthly_created_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Created Guest Journeys.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- created_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_guest_journeys
|
|
|
|
|
data_type: bigint
|
2024-11-20 09:43:30 +00:00
|
|
|
description: The monthly created guest journeys for a given date, dimension and value.
|
2024-10-30 11:45:45 +00:00
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_mtd_created_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Month-To-Date Created Guest Journeys.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- created_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The month-to-date created guest journeys for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_started_guest_journeys
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Started Guest Journeys at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
2025-02-11 07:12:46 +00:00
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Guest Journeys have been started.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 07:12:46 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 07:12:46 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 07:12:46 +00:00
|
|
|
|
2024-10-30 11:45:45 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: started_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys started in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_started_guest_journeys
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Started Guest Journeys at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 08:47:48 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 08:47:48 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 08:47:48 +00:00
|
|
|
|
2024-10-30 11:45:45 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: started_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2024-10-31 09:03:15 +00:00
|
|
|
Count of accumulated guest journeys started in a given month
|
2024-10-30 11:45:45 +00:00
|
|
|
and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_mtd_started_guest_journeys
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Month-To-Date Started Guest Journeys at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 08:47:48 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 08:47:48 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 08:47:48 +00:00
|
|
|
|
2024-10-30 11:45:45 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: started_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2024-10-31 09:03:15 +00:00
|
|
|
Count of accumulated guest journeys started in a given month up to the
|
2024-10-30 11:45:45 +00:00
|
|
|
given date and per specified dimension.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_monthly_started_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Started Guest Journeys.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- started_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: started_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The monthly started guest journeys for a given date, dimension and value.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_mtd_started_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Month-To-Date Started Guest Journeys.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- started_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: started_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The month-to-date started guest journeys for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_completed_guest_journeys
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Completed Guest Journeys at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
2025-02-11 07:12:46 +00:00
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope.
|
2024-10-30 11:45:45 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Guest Journeys have been completed.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 07:12:46 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 07:12:46 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 07:12:46 +00:00
|
|
|
|
2024-10-30 11:45:45 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: completed_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys completed in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_completed_guest_journeys
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Completed Guest Journeys at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 08:47:48 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 08:47:48 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 08:47:48 +00:00
|
|
|
|
2024-10-30 11:45:45 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: completed_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2024-10-31 09:03:15 +00:00
|
|
|
Count of accumulated guest journeys completed in a given month
|
2024-10-30 11:45:45 +00:00
|
|
|
and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_mtd_completed_guest_journeys
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Month-To-Date Completed Guest Journeys at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 08:47:48 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 08:47:48 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 08:47:48 +00:00
|
|
|
|
2024-10-30 11:45:45 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: completed_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2024-10-31 09:03:15 +00:00
|
|
|
Count of accumulated guest journeys completed in a given month up to the
|
2024-10-30 11:45:45 +00:00
|
|
|
given date and per specified dimension.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_monthly_completed_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Completed Guest Journeys.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- completed_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: completed_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The monthly completed guest journeys for a given date, dimension and value.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_mtd_completed_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Month-To-Date Completed Guest Journeys.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- completed_guest_journeys
|
2024-10-30 11:45:45 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-30 11:45:45 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 11:45:45 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: completed_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The month-to-date completed guest journeys for a given date, dimension and value.
|
2024-10-30 16:43:50 +00:00
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_guest_journeys_with_payment
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Guest Journeys with Payment at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
2025-02-11 07:12:46 +00:00
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 16:43:50 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 16:43:50 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Guest Journeys have been completed.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 07:12:46 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 07:12:46 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 07:12:46 +00:00
|
|
|
|
2024-10-30 16:43:50 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: guest_journeys_with_payment
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys completed in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_guest_journeys_with_payment
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Guest Journeys with Payment at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-10-30 16:43:50 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 16:43:50 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 08:47:48 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 08:47:48 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 08:47:48 +00:00
|
|
|
|
2024-10-30 16:43:50 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: guest_journeys_with_payment
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2024-10-31 09:03:15 +00:00
|
|
|
Count of accumulated guest journeys completed in a given month
|
2024-10-30 16:43:50 +00:00
|
|
|
and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_mtd_guest_journeys_with_payment
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Month-To-Date Guest Journeys with Payment at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-10-30 16:43:50 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-30 16:43:50 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 08:47:48 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 08:47:48 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 08:47:48 +00:00
|
|
|
|
2024-10-30 16:43:50 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: guest_journeys_with_payment
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2024-10-31 09:03:15 +00:00
|
|
|
Count of accumulated guest journeys completed in a given month up to the
|
2024-10-30 16:43:50 +00:00
|
|
|
given date and per specified dimension.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_monthly_guest_journeys_with_payment
|
2024-10-30 16:43:50 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Guest Journeys with Payment.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- guest_journeys_with_payment
|
2024-10-30 16:43:50 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-30 16:43:50 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: guest_journeys_with_payment
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The monthly guest journeys with payment for a given date, dimension and value.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_mtd_guest_journeys_with_payment
|
2024-10-30 16:43:50 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Month-To-Date Guest Journeys with Payment.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- guest_journeys_with_payment
|
2024-10-30 16:43:50 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-30 16:43:50 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-30 16:43:50 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: guest_journeys_with_payment
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The month-to-date guest journeys with payment for a given date, dimension and value.
|
2024-10-31 09:03:15 +00:00
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_guest_payments
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Guest Payments at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
2024-11-06 12:34:33 +01:00
|
|
|
- id_deal,
|
2025-02-11 07:12:46 +00:00
|
|
|
- has_id_check,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-31 09:03:15 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
2024-11-06 12:34:33 +01:00
|
|
|
- has_id_check
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-31 09:03:15 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Guest Journeys have been completed.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 07:12:46 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 07:12:46 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 07:12:46 +00:00
|
|
|
|
2024-11-07 08:45:17 +01:00
|
|
|
- name: has_id_check
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Does the verification in the guest journey
|
|
|
|
|
includes Government Id Check for the bookings.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 08:45:17 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- W/O Id Check
|
|
|
|
|
- With Id Check
|
|
|
|
|
|
2024-10-31 09:03:15 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: deposit_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of deposit fees paid by guests, without taxes, in GBP
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: waiver_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of waiver payments paid by guests, without taxes, in GBP
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: checkin_cover_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of checkin cover fees paid by guests, without taxes, in GBP
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
2025-05-23 10:33:26 +00:00
|
|
|
- name: stay_disrupt_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of stay disrupt fees paid by guests, without taxes, in GBP
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
2024-10-31 09:03:15 +00:00
|
|
|
- name: total_guest_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of total payments paid by guests, without taxes, in GBP
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_guest_payments
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Guest Payments at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
2024-11-07 08:45:17 +01:00
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-11-07 08:45:17 +01:00
|
|
|
- has_id_check,
|
2024-10-31 09:03:15 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-11-07 08:45:17 +01:00
|
|
|
- has_id_check
|
2024-10-31 09:03:15 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-11 08:47:48 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-11 08:47:48 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-11 08:47:48 +00:00
|
|
|
|
2024-11-07 08:45:17 +01:00
|
|
|
- name: has_id_check
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Does the verification in the guest journey
|
|
|
|
|
includes Government Id Check for the bookings.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 08:45:17 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- W/O Id Check
|
|
|
|
|
- With Id Check
|
|
|
|
|
|
2024-10-31 09:03:15 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: deposit_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated deposit fees paid by guests, without taxes,
|
|
|
|
|
in GBP in a given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: waiver_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated waiver payments paid by guests, without taxes,
|
|
|
|
|
in GBP in a given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: checkin_cover_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated checkin cover fees by guests, without taxes,
|
|
|
|
|
in GBP in a given month and per specified dimension.
|
|
|
|
|
|
2025-05-23 10:33:26 +00:00
|
|
|
- name: stay_disrupt_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated stay disrupt fees by guests, without taxes,
|
|
|
|
|
in GBP in a given month and per specified dimension.
|
|
|
|
|
|
2024-10-31 09:03:15 +00:00
|
|
|
- name: total_guest_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated total payments paid by guests, without taxes,
|
|
|
|
|
in GBP in a given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_mtd_guest_payments
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Month-To-Date Guest Payments at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
2024-11-07 08:45:17 +01:00
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-11-07 08:45:17 +01:00
|
|
|
- has_id_check,
|
2024-10-31 09:03:15 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-11-07 08:45:17 +01:00
|
|
|
- has_id_check
|
2024-10-31 09:03:15 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2024-10-31 09:03:15 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
2025-02-11 08:47:48 +00:00
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2024-11-07 08:45:17 +01:00
|
|
|
|
|
|
|
|
- name: has_id_check
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Does the verification in the guest journey
|
|
|
|
|
includes Government Id Check for the bookings.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 08:45:17 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- W/O Id Check
|
|
|
|
|
- With Id Check
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 08:45:17 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 08:45:17 +01:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: deposit_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated deposit fees paid by guests, without taxes,
|
2025-02-11 08:47:48 +00:00
|
|
|
in GBP in a given month up to the given date and per specified dimension.
|
2024-11-07 08:45:17 +01:00
|
|
|
|
|
|
|
|
- name: waiver_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated waiver payments paid by guests, without taxes,
|
2025-02-11 08:47:48 +00:00
|
|
|
in GBP in a given month up to the given date and per specified dimension.
|
2024-11-07 08:45:17 +01:00
|
|
|
|
|
|
|
|
- name: checkin_cover_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated checkin cover fees by guests, without taxes,
|
2025-02-11 08:47:48 +00:00
|
|
|
in GBP in a given month up to the given date and per specified dimension.
|
2024-11-07 08:45:17 +01:00
|
|
|
|
2025-05-23 10:33:26 +00:00
|
|
|
- name: stay_disrupt_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated stay disrupt fees by guests, without taxes,
|
|
|
|
|
in GBP in a given month up to the given date and per specified dimension.
|
|
|
|
|
|
2024-11-07 08:45:17 +01:00
|
|
|
- name: total_guest_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated total payments paid by guests, without taxes,
|
2025-02-11 08:47:48 +00:00
|
|
|
in GBP in a given month up to the given date and per specified dimension.
|
2024-11-07 08:45:17 +01:00
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_monthly_guest_payments
|
2024-10-31 09:03:15 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Guest Payments.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- deposit_fees_in_gbp
|
|
|
|
|
- waiver_payments_in_gbp
|
|
|
|
|
- checkin_cover_fees_in_gbp
|
2025-05-23 10:33:26 +00:00
|
|
|
- stay_disrupt_fees_in_gbp
|
2024-11-05 16:45:59 +01:00
|
|
|
- total_guest_payments_in_gbp
|
2024-10-31 09:03:15 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-31 09:03:15 +00:00
|
|
|
- by_deal
|
2024-11-07 12:09:20 +01:00
|
|
|
- by_has_id_check
|
2024-10-31 09:03:15 +00:00
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: deposit_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly deposit fees paid by guests, without taxes, in GBP
|
|
|
|
|
for a given range date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: waiver_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly waiver payments paid by guests, without taxes, in GBP
|
|
|
|
|
for a given range date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: checkin_cover_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly checkin cover fees paid by guests, without taxes, in GBP
|
|
|
|
|
for a given range date, dimension and value.
|
|
|
|
|
|
2025-05-23 10:33:26 +00:00
|
|
|
- name: stay_disrupt_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly stay disrupt fees paid by guests, without taxes, in GBP
|
|
|
|
|
for a given range date, dimension and value.
|
|
|
|
|
|
2024-10-31 09:03:15 +00:00
|
|
|
- name: total_guest_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly total payments paid by guests, without taxes, in GBP
|
|
|
|
|
for a given range date, dimension and value.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_mtd_guest_payments
|
2024-10-31 09:03:15 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Month-To-Date Guest Payments.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- deposit_fees_in_gbp
|
|
|
|
|
- waiver_payments_in_gbp
|
|
|
|
|
- checkin_cover_fees_in_gbp
|
2025-05-23 10:33:26 +00:00
|
|
|
- stay_disrupt_fees_in_gbp
|
2024-11-05 16:45:59 +01:00
|
|
|
- total_guest_payments_in_gbp
|
2024-10-31 09:03:15 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-31 09:03:15 +00:00
|
|
|
- by_deal
|
2024-11-07 12:15:52 +01:00
|
|
|
- by_has_id_check
|
2024-10-31 09:03:15 +00:00
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 09:03:15 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: deposit_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date deposit fees paid by guests, without taxes, in GBP
|
|
|
|
|
for a given range date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: waiver_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date waiver payments paid by guests, without taxes, in GBP
|
|
|
|
|
for a given range date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: checkin_cover_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date checkin cover fees paid by guests, without taxes, in GBP
|
|
|
|
|
for a given range date, dimension and value.
|
|
|
|
|
|
2025-05-23 10:33:26 +00:00
|
|
|
- name: stay_disrupt_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date stay disrupt fees paid by guests, without taxes, in GBP
|
|
|
|
|
for a given range date, dimension and value.
|
|
|
|
|
|
2024-10-31 09:03:15 +00:00
|
|
|
- name: total_guest_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date total payments paid by guests, without taxes, in GBP
|
|
|
|
|
for a given range date, dimension and value.
|
2024-10-31 14:31:19 +00:00
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_check_out_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Check-out Bookings at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
2025-02-06 10:53:24 +00:00
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope.
|
2024-10-31 14:31:19 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-31 14:31:19 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Bookings have been checked-out.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-06 10:53:24 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-06 10:53:24 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-06 10:53:24 +00:00
|
|
|
|
2024-10-31 14:31:19 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily bookings checked-out in a given date and per specified dimension.
|
|
|
|
|
|
2025-02-06 12:01:24 +00:00
|
|
|
- name: cancelled_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily bookings checked-out in a given date and per specified dimension
|
|
|
|
|
that have been cancelled.
|
|
|
|
|
|
|
|
|
|
- name: not_cancelled_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily bookings checked-out in a given date and per specified dimension
|
|
|
|
|
that have not been cancelled.
|
|
|
|
|
|
2025-02-17 15:59:21 +00:00
|
|
|
- name: billable_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily bookings checked-out in a given date and per specified dimension
|
|
|
|
|
that are billable. Note that the consideration for billable booking is different
|
|
|
|
|
depending on the business scope of the booking.
|
|
|
|
|
|
2024-10-31 14:31:19 +00:00
|
|
|
- name: int_kpis__metric_monthly_check_out_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Check-out Bookings at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-10-31 14:31:19 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-31 14:31:19 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-06 10:53:24 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-06 10:53:24 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-06 10:53:24 +00:00
|
|
|
|
2024-10-31 14:31:19 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings checked-out in a given month
|
|
|
|
|
and per specified dimension.
|
|
|
|
|
|
2025-02-06 12:01:24 +00:00
|
|
|
- name: cancelled_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings checked-out in a given month
|
|
|
|
|
and per specified dimension that have been cancelled.
|
|
|
|
|
|
|
|
|
|
- name: not_cancelled_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings checked-out in a given month
|
|
|
|
|
and per specified dimension that have not been cancelled.
|
|
|
|
|
|
2025-02-17 15:59:21 +00:00
|
|
|
- name: billable_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings checked-out in a given month
|
|
|
|
|
and per specified dimension that are billable.
|
|
|
|
|
Note that the consideration for billable booking is different
|
|
|
|
|
depending on the business scope of the booking.
|
|
|
|
|
|
2024-10-31 14:31:19 +00:00
|
|
|
- name: int_kpis__metric_mtd_check_out_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Month-To-Date Check-out Bookings at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope,
|
2024-10-31 14:31:19 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-11 16:19:33 +00:00
|
|
|
- business_scope
|
2024-10-31 14:31:19 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 16:19:33 +00:00
|
|
|
- name: business_scope
|
2025-02-06 10:53:24 +00:00
|
|
|
data_type: string
|
2025-02-11 16:19:33 +00:00
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
2025-02-06 10:53:24 +00:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
2025-02-11 16:19:33 +00:00
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
2025-02-06 10:53:24 +00:00
|
|
|
|
2024-10-31 14:31:19 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings checked-out in a given month up to the
|
|
|
|
|
given date and per specified dimension.
|
|
|
|
|
|
2025-02-06 12:01:24 +00:00
|
|
|
- name: cancelled_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings checked-out in a given month up to the
|
|
|
|
|
given date and per specified dimension that have been cancelled.
|
|
|
|
|
|
|
|
|
|
- name: not_cancelled_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings checked-out in a given month up to the
|
|
|
|
|
given date and per specified dimension that have not been cancelled.
|
|
|
|
|
|
2025-02-17 15:59:21 +00:00
|
|
|
- name: billable_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings checked-out in a given month up to the
|
|
|
|
|
given date and per specified dimension that are billable.
|
|
|
|
|
Note that the consideration for billable booking is different
|
|
|
|
|
depending on the business scope of the booking.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_monthly_check_out_bookings
|
2024-10-31 14:31:19 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Check-out Bookings.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- check_out_bookings
|
2025-02-06 12:01:24 +00:00
|
|
|
- cancelled_check_out_bookings
|
|
|
|
|
- not_cancelled_check_out_bookings
|
2025-02-17 15:59:21 +00:00
|
|
|
- billable_check_out_bookings
|
2024-10-31 14:31:19 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-31 14:31:19 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The monthly checked-out bookings for a given date, dimension and value.
|
|
|
|
|
|
2025-02-06 12:01:24 +00:00
|
|
|
- name: cancelled_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The monthly cancelled checked-out bookings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: not_cancelled_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The monthly not cancelled checked-out bookings for a given date, dimension and value.
|
|
|
|
|
|
2025-02-17 15:59:21 +00:00
|
|
|
- name: billable_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The monthly billable checked-out bookings for a given date, dimension and value.
|
|
|
|
|
|
2025-02-06 12:01:24 +00:00
|
|
|
- name: cancelled_check_out_bookings_rate
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly rate of cancelled checked-out bookings for a given date, dimension and value.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_mtd_check_out_bookings
|
2024-10-31 14:31:19 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Month-To-Date Check-out Bookings.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- check_out_bookings
|
2025-02-06 12:01:24 +00:00
|
|
|
- cancelled_check_out_bookings
|
|
|
|
|
- not_cancelled_check_out_bookings
|
2025-02-17 15:59:21 +00:00
|
|
|
- billable_check_out_bookings
|
2024-10-31 14:31:19 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-11 16:19:33 +00:00
|
|
|
- by_business_scope
|
2024-10-31 14:31:19 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The month-to-date checked-out bookings for a given date, dimension and value.
|
|
|
|
|
|
2025-02-06 12:01:24 +00:00
|
|
|
- name: cancelled_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date cancelled checked-out bookings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: not_cancelled_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date not cancelled checked-out bookings for a given date, dimension and value.
|
|
|
|
|
|
2025-02-17 15:59:21 +00:00
|
|
|
- name: billable_check_out_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date billable checked-out bookings for a given date, dimension and value.
|
|
|
|
|
|
2025-02-06 12:01:24 +00:00
|
|
|
- name: cancelled_check_out_bookings_rate
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date rate of cancelled checked-out bookings for a given date, dimension and value.
|
|
|
|
|
|
2024-10-31 14:31:19 +00:00
|
|
|
- name: int_kpis__metric_daily_billable_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Billable Bookings at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
2025-02-14 12:29:18 +00:00
|
|
|
- id_deal,
|
|
|
|
|
- business_scope.
|
2024-10-31 14:31:19 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
2025-02-14 12:29:18 +00:00
|
|
|
- business_scope
|
2024-10-31 14:31:19 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Bookings have been billable.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-14 12:29:18 +00:00
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-10-31 14:31:19 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: billable_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily bookings billable in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_billable_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Billable Bookings at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-14 12:29:18 +00:00
|
|
|
- business_scope,
|
2024-10-31 14:31:19 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-14 12:29:18 +00:00
|
|
|
- business_scope
|
2024-10-31 14:31:19 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-14 12:29:18 +00:00
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-10-31 14:31:19 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: billable_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings billable in a given month
|
|
|
|
|
and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_mtd_billable_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Month-To-Date Billable Bookings at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-14 12:29:18 +00:00
|
|
|
- business_scope,
|
2024-10-31 14:31:19 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-14 12:29:18 +00:00
|
|
|
- business_scope
|
2024-10-31 14:31:19 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-14 12:29:18 +00:00
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-10-31 14:31:19 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: billable_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated bookings billable in a given month up to the
|
|
|
|
|
given date and per specified dimension.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_monthly_billable_bookings
|
2024-10-31 14:31:19 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Billable Bookings.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- billable_bookings
|
2024-10-31 14:31:19 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-14 12:29:18 +00:00
|
|
|
- by_business_scope
|
2024-10-31 14:31:19 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: billable_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The monthly billable bookings for a given date, dimension and value.
|
|
|
|
|
|
2024-11-05 12:17:26 +01:00
|
|
|
- name: int_kpis__agg_mtd_billable_bookings
|
2024-10-31 14:31:19 +00:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Month-To-Date Billable Bookings.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- billable_bookings
|
2024-10-31 14:31:19 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-14 12:29:18 +00:00
|
|
|
- by_business_scope
|
2024-10-31 14:31:19 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 14:31:19 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: billable_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The month-to-date billable bookings for a given date, dimension and value.
|
|
|
|
|
|
2024-11-04 15:28:31 +01:00
|
|
|
- name: int_kpis__metric_daily_check_in_attributed_guest_journeys
|
2024-10-31 11:44:26 +01:00
|
|
|
description: |
|
|
|
|
|
This model computes Guest Journey metrics at the deepest granularity
|
|
|
|
|
level for the Guest Products KPIs.
|
|
|
|
|
This model uses the Check-In date of the bookings for the date attribute.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
|
|
|
|
- id_deal,
|
|
|
|
|
- has_payment,
|
|
|
|
|
- has_id_check.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 11:44:26 +01:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
|
|
|
|
- has_payment
|
|
|
|
|
- has_id_check
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of Check-In of the bookings for the guest journeys.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 11:44:26 +01:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 11:44:26 +01:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: has_payment
|
2024-11-04 15:28:31 +01:00
|
|
|
data_type: string
|
|
|
|
|
description: Has there been any guest payments on the guest journey.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-04 15:28:31 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- W/O Payment
|
|
|
|
|
- With Payment
|
2024-10-31 11:44:26 +01:00
|
|
|
|
|
|
|
|
- name: has_id_check
|
2024-11-04 15:28:31 +01:00
|
|
|
data_type: string
|
|
|
|
|
description: Does the verification in the guest journey
|
2024-11-05 07:45:41 +00:00
|
|
|
includes Government Id Check for the bookings.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-04 15:28:31 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- W/O Id Check
|
|
|
|
|
- With Id Check
|
2024-10-31 11:44:26 +01:00
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 11:44:26 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-10-31 11:44:26 +01:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_guest_journeys_not_cancelled
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys created, excluding cancelled bookings,
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: started_guest_journeys_not_cancelled
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys started, excluding cancelled bookings,
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: completed_guest_journeys_not_cancelled
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys completed, excluding cancelled bookings,
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: created_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys created in a given date and
|
|
|
|
|
per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: started_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys started in a given date and
|
|
|
|
|
per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: completed_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys completed in a given date and
|
|
|
|
|
per specified dimension.
|
2024-11-05 07:45:41 +00:00
|
|
|
|
2024-11-04 16:51:24 +01:00
|
|
|
- name: count_csat_score
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys with CSAT (customer satisfaction score)
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: average_csat_score
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Average daily CSAT score in a given date and per specified dimension.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
2024-11-05 07:45:41 +00:00
|
|
|
- name: int_kpis__metric_daily_host_resolutions
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Host Resolutions at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
2025-02-11 15:13:42 +00:00
|
|
|
- id_deal,
|
|
|
|
|
- business_scope.
|
2024-11-05 07:45:41 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
2025-02-11 15:13:42 +00:00
|
|
|
- business_scope
|
2024-11-05 07:45:41 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Host Resolutions transaction happened.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 15:13:42 +00:00
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-11-05 07:45:41 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: xero_host_resolution_payment_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily Host Resolution Payment Count in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: xero_host_resolution_amount_paid_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Host Resolution Amount Paid, in GBP, in a given
|
|
|
|
|
date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_host_resolutions
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Host Resolutions at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-12 08:17:44 +00:00
|
|
|
- business_scope,
|
2024-11-05 07:45:41 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-12 08:17:44 +00:00
|
|
|
- business_scope
|
2024-11-05 07:45:41 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-12 08:17:44 +00:00
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-11-05 07:45:41 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: xero_host_resolution_payment_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated Host Resolution Payment Count in a
|
|
|
|
|
given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: xero_host_resolution_amount_paid_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Host Resolution Amount Paid, in GBP, in a
|
|
|
|
|
given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_mtd_host_resolutions
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Month-To-Date Host Resolutions at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-12 08:17:44 +00:00
|
|
|
- business_scope,
|
2024-11-05 07:45:41 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-12 08:17:44 +00:00
|
|
|
- business_scope
|
2024-11-05 07:45:41 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-12 08:17:44 +00:00
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-11-05 07:45:41 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: xero_host_resolution_payment_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of accumulated Host Resolution Payment Count in a
|
|
|
|
|
given month up to the given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: xero_host_resolution_amount_paid_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Host Resolution Amount Paid, in GBP, in a
|
|
|
|
|
given month up to the given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_monthly_host_resolutions
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Host Resolutions.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- xero_host_resolution_payment_count
|
|
|
|
|
- xero_host_resolution_amount_paid_in_gbp
|
2024-11-05 07:45:41 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-12 08:17:44 +00:00
|
|
|
- by_business_scope
|
2024-11-05 07:45:41 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: xero_host_resolution_payment_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Host Resolution Payment Count for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_host_resolution_amount_paid_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Host Resolution Amount Paid, in GBP, for a
|
|
|
|
|
given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_mtd_host_resolutions
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Month-To-Date Host Resolutions.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2024-11-05 16:45:59 +01:00
|
|
|
- xero_host_resolution_payment_count
|
|
|
|
|
- xero_host_resolution_amount_paid_in_gbp
|
2024-11-05 07:45:41 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-12 08:17:44 +00:00
|
|
|
- by_business_scope
|
2024-11-05 07:45:41 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 07:45:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: xero_host_resolution_payment_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Host Resolution Payment Count for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_host_resolution_amount_paid_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Host Resolution Amount Paid, in GBP, for a
|
|
|
|
|
given date, dimension and value.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_invoiced_revenue
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Invoiced Revenue at the deepest granularity.
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
The logic behind this model is mostly retrieving different revenue sources
|
|
|
|
|
that are invoiced to the hosts. This considers both Invoices and Credit Notes,
|
|
|
|
|
thus metrics correspond to the net amount.
|
|
|
|
|
|
|
|
|
|
Data is retrieved by account codes following accounting standards, and is
|
|
|
|
|
aggregated at different levels of business revenue understanding.
|
|
|
|
|
Only documents with status equal to Authorised or Paid are considered. Revenue is
|
|
|
|
|
computed without taxes, in GBP. Revenue is attributed to the document issued date,
|
|
|
|
|
thus it might show some differences vs. financials since we do not consider accrued
|
|
|
|
|
revenue.
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
2025-02-11 15:13:42 +00:00
|
|
|
- id_deal,
|
|
|
|
|
- business_scope.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
2025-02-11 15:13:42 +00:00
|
|
|
- business_scope
|
2024-11-05 16:57:23 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when the document was issued.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-11 15:13:42 +00:00
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_basic_protection_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Basic Protection Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_waiver_pro_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Waiver Pro Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_id_verification_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily ID Verification Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_protection_plus_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Protection Pro Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_screening_plus_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Screening Plus Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_sex_offenders_check_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Sex Offenders Check Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_protection_pro_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Protection Pro Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_basic_screening_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Basic Screening Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
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
|
|
|
- name: xero_old_dashboard_booking_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
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
|
|
|
Sum of daily Old Dashboard Booking Net Fees, in GBP, without taxes
|
2024-11-05 16:57:23 +00:00
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
2025-03-20 13:45:44 +00:00
|
|
|
- name: xero_booking_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Total Booking Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension. This takes into
|
|
|
|
|
account both Old Dashboard and New Dashboard.
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: xero_listing_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Listing Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: xero_verification_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Verification Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: xero_operator_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
Sum of daily Operator Net Fees, which include New Dash Services,
|
|
|
|
|
Booking, Listing and Verification Net Fees for Old Dash;
|
|
|
|
|
in GBP, without taxes in a given date and per specified dimension.
|
|
|
|
|
Partial data of 2022 corresponds to revenue categorised as Other Revenue
|
|
|
|
|
according to the financials.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
|
|
|
|
- name: xero_e_deposit_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily E-Deposit Net Fees, in GBP, without taxes
|
2025-01-20 14:18:05 +00:00
|
|
|
in a given date and per specified dimension. This is an
|
|
|
|
|
API service.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
2025-04-16 14:27:23 +02:00
|
|
|
- name: xero_check_in_hero_api_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Check-In Hero API Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension. This is an
|
|
|
|
|
API service.
|
|
|
|
|
|
2025-04-16 16:18:14 +02:00
|
|
|
- name: xero_screen_and_protect_net_fees_in_gbp
|
2025-04-16 14:27:23 +02:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Screen & Protect API Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension. This is an
|
|
|
|
|
API service.
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_athena_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Athena (Guesty) Net Fees, in GBP, without taxes
|
2025-01-20 14:18:05 +00:00
|
|
|
in a given date and per specified dimension. This is an
|
|
|
|
|
API service.
|
|
|
|
|
|
|
|
|
|
- name: xero_guesty_resolutions_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Guesty Resolutions Net Fees, in GBP, without taxes
|
2024-11-05 16:57:23 +00:00
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_guesty_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Athena (Guesty) Net Fees and Guesty Resolutions
|
|
|
|
|
Net Fees, in GBP, without taxes in a given date and per specified
|
|
|
|
|
dimension.
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: xero_apis_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily API Net Fees, which include E-Deposit,
|
|
|
|
|
and Athena (Guesty) Net Fees, in GBP, without taxes
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: xero_waiver_paid_back_to_host_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of daily Waiver Amount Paid Back to Hosts, in GBP,
|
|
|
|
|
without taxes in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_invoiced_revenue
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Invoiced Revenue at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-12 08:17:44 +00:00
|
|
|
- business_scope,
|
2024-11-05 16:57:23 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-12 08:17:44 +00:00
|
|
|
- business_scope
|
2024-11-05 16:57:23 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-12 08:17:44 +00:00
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_basic_protection_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Basic Protection Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_waiver_pro_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Waiver Pro Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_id_verification_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated ID Verification Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_protection_plus_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Protection Plus Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_screening_plus_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Screening Plus Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_sex_offenders_check_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Sex Offenders Check Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_protection_pro_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Protection Pro Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_basic_screening_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Basic Screening Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension. This is a New
|
|
|
|
|
Dashboard service.
|
|
|
|
|
|
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
|
|
|
- name: xero_old_dashboard_booking_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
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
|
|
|
Sum of accumulated Old Dashboard Booking Net Fees, in GBP, without taxes
|
2024-11-05 16:57:23 +00:00
|
|
|
in a given month and per specified dimension.
|
|
|
|
|
|
2025-03-20 13:45:44 +00:00
|
|
|
- name: xero_booking_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Total Booking Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension. This takes into
|
|
|
|
|
account both Old Dashboard and New Dashboard.
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: xero_listing_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Listing Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: xero_verification_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Verification Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: xero_operator_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
Sum of accummulated Operator Net Fees, which include New Dash Services,
|
|
|
|
|
Booking, Listing and Verification Net Fees for Old Dash;
|
|
|
|
|
in GBP, without taxes in a given month and per specified dimension.
|
|
|
|
|
Partial data of 2022 corresponds to revenue categorised as Other Revenue
|
|
|
|
|
according to the financials.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
|
|
|
|
- name: xero_e_deposit_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
Sum of accummulated E-Deposit Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension. This is an
|
|
|
|
|
API service.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
2025-04-16 14:27:23 +02:00
|
|
|
- name: xero_check_in_hero_api_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accummulated Check-In Hero API Net Fees, in GBP, without taxes
|
2025-04-16 16:18:14 +02:00
|
|
|
in a given month and per specified dimension. This is an
|
2025-04-16 14:27:23 +02:00
|
|
|
API service.
|
|
|
|
|
|
2025-04-16 16:18:14 +02:00
|
|
|
- name: xero_screen_and_protect_net_fees_in_gbp
|
2025-04-16 14:27:23 +02:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accummulated Screen & Protect API Net Fees, in GBP, without taxes
|
2025-04-16 16:18:14 +02:00
|
|
|
in a given month and per specified dimension. This is an
|
2025-04-16 14:27:23 +02:00
|
|
|
API service.
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_athena_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
Sum of accummulated Athena (Guesty) Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month and per specified dimension. This is an
|
|
|
|
|
API service.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_guesty_resolutions_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
Sum of accummulated Guesty Resolutions Net Fees, in GBP, without taxes
|
2024-11-05 16:57:23 +00:00
|
|
|
in a given month and per specified dimension.
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_guesty_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accummulated Athena (Guesty) Net Fees and Guesty Resolutions
|
|
|
|
|
Net Fees, in GBP, without taxes in a given month and per specified
|
|
|
|
|
dimension.
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: xero_waiver_paid_back_to_host_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Waiver Amount Paid Back to Hosts, in GBP,
|
|
|
|
|
without taxes in a given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_mtd_invoiced_revenue
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Month-To-Date Invoiced Revenue at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
2025-02-12 08:17:44 +00:00
|
|
|
- business_scope,
|
2024-11-05 16:57:23 +00:00
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
2025-02-12 08:17:44 +00:00
|
|
|
- business_scope
|
2024-11-05 16:57:23 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-12 08:17:44 +00:00
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_basic_protection_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Basic Protection Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_waiver_pro_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Waiver Pro Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_id_verification_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated ID Verification Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_protection_plus_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Protection Plus Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_screening_plus_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Screening Plus Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_sex_offenders_check_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Sex Offenders Check Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_protection_pro_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Protection Pro Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_basic_screening_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Basic Screening Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
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
|
|
|
- name: xero_old_dashboard_booking_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
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
|
|
|
Sum of accumulated Old Dashboard Booking Net Fees, in GBP, without taxes
|
2024-11-05 16:57:23 +00:00
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
|
2025-03-20 13:45:44 +00:00
|
|
|
- name: xero_booking_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Total Booking Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This takes into account both Old Dashboard and New Dashboard.
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: xero_listing_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Listing Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: xero_verification_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accumulated Verification Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: xero_operator_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
Sum of accummulated Operator Net Fees, which include New Dash Services,
|
|
|
|
|
Booking, Listing and Verification Net Fees for Old Dash;
|
|
|
|
|
in GBP, without taxes in a given month up to the given date
|
|
|
|
|
and per specified dimension.
|
|
|
|
|
Partial data of 2022 corresponds to revenue categorised as Other Revenue
|
|
|
|
|
according to the financials.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
|
|
|
|
- name: xero_e_deposit_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
Sum of accummulated E-Deposit Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is an API service.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
2025-04-16 14:27:23 +02:00
|
|
|
- name: xero_check_in_hero_api_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accummulated Check-In Hero API Net Fees, in GBP, without taxes
|
2025-04-16 16:18:14 +02:00
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is an API service.
|
2025-04-16 14:27:23 +02:00
|
|
|
|
2025-04-16 16:18:14 +02:00
|
|
|
- name: xero_screen_and_protect_net_fees_in_gbp
|
2025-04-16 14:27:23 +02:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accummulated Screen & Protect API Net Fees, in GBP, without taxes
|
2025-04-16 16:18:14 +02:00
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is an API service.
|
2025-04-16 14:27:23 +02:00
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_athena_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
Sum of accummulated Athena (Guesty) Net Fees, in GBP, without taxes
|
|
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
This is an API service.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_guesty_resolutions_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
Sum of accummulated Guesty Resolutions Net Fees, in GBP, without taxes
|
2024-11-05 16:57:23 +00:00
|
|
|
in a given month up to the given date and per specified dimension.
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_guesty_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of accummulated Athena (Guesty) Net Fees and Guesty Resolutions
|
|
|
|
|
Net Fees, in GBP, without taxes in a given month up to the given date
|
|
|
|
|
and per specified dimension.
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: xero_waiver_paid_back_to_host_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
Sum of accumulated Waiver Amount Paid Back to Hosts, in GBP,
|
|
|
|
|
without taxes in a given month up to the given date and per
|
|
|
|
|
specified dimension.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
|
|
|
|
- name: int_kpis__agg_monthly_invoiced_revenue
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Invoiced Revenue.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2025-01-20 14:18:05 +00:00
|
|
|
- xero_basic_protection_net_fees_in_gbp
|
|
|
|
|
- xero_waiver_pro_net_fees_in_gbp
|
|
|
|
|
- xero_id_verification_net_fees_in_gbp
|
|
|
|
|
- xero_protection_plus_net_fees_in_gbp
|
|
|
|
|
- xero_screening_plus_net_fees_in_gbp
|
|
|
|
|
- xero_sex_offenders_check_net_fees_in_gbp
|
|
|
|
|
- xero_protection_pro_net_fees_in_gbp
|
|
|
|
|
- xero_basic_screening_net_fees_in_gbp
|
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
|
|
|
- xero_old_dashboard_booking_net_fees_in_gbp
|
2025-03-20 13:45:44 +00:00
|
|
|
- xero_booking_net_fees_in_gbp
|
2024-11-06 08:35:30 +01:00
|
|
|
- xero_listing_net_fees_in_gbp
|
|
|
|
|
- xero_verification_net_fees_in_gbp
|
|
|
|
|
- xero_operator_net_fees_in_gbp
|
|
|
|
|
- xero_e_deposit_net_fees_in_gbp
|
2025-04-16 14:27:23 +02:00
|
|
|
- xero_check_in_hero_api_net_fees_in_gbp
|
2025-04-16 16:18:14 +02:00
|
|
|
- xero_screen_and_protect_net_fees_in_gbp
|
2025-01-20 14:18:05 +00:00
|
|
|
- xero_athena_net_fees_in_gbp
|
|
|
|
|
- xero_guesty_resolutions_net_fees_in_gbp
|
2024-11-06 08:35:30 +01:00
|
|
|
- xero_guesty_net_fees_in_gbp
|
|
|
|
|
- xero_apis_net_fees_in_gbp
|
|
|
|
|
- xero_waiver_paid_back_to_host_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-12 08:17:44 +00:00
|
|
|
- by_business_scope
|
2024-11-05 16:57:23 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_basic_protection_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Basic Protection Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_waiver_pro_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Waiver Pro Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_id_verification_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly ID Verification Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_protection_plus_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Protection Plus Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_screening_plus_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Screening Plus Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_sex_offenders_check_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Sex Offenders Check Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_protection_pro_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Protection Pro Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_basic_screening_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Basic Screening Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
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
|
|
|
- name: xero_old_dashboard_booking_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
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
|
|
|
The monthly Old Dashboard Booking Net Fees, in GBP, without taxes
|
2024-11-05 16:57:23 +00:00
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
2025-03-20 13:45:44 +00:00
|
|
|
- name: xero_booking_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Total Booking Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
This takes into account both Old Dashboard and New Dashboard.
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: xero_listing_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Listing Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_verification_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Verification Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_operator_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
The monthly Operator Net Fees, which include New Dash Services,
|
|
|
|
|
Booking, Listing and Verification Net Fees for Old Dash;
|
|
|
|
|
in GBP, without taxes for a given date, dimension and value.
|
|
|
|
|
Partial data of 2022 corresponds to revenue categorised as Other Revenue
|
|
|
|
|
according to the financials.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
|
|
|
|
- name: xero_e_deposit_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly E-Deposit Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
2025-01-20 14:18:05 +00:00
|
|
|
This is an API service.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
2025-04-16 14:27:23 +02:00
|
|
|
- name: xero_check_in_hero_api_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Check-In Hero API Net Fees, in GBP, without taxes
|
2025-04-16 16:18:14 +02:00
|
|
|
for a given date, dimension and value.
|
|
|
|
|
This is an API service.
|
2025-04-16 14:27:23 +02:00
|
|
|
|
2025-04-16 16:18:14 +02:00
|
|
|
- name: xero_screen_and_protect_net_fees_in_gbp
|
2025-04-16 14:27:23 +02:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Screen & Protect API Net Fees, in GBP, without taxes
|
2025-04-16 16:18:14 +02:00
|
|
|
for a given date, dimension and value.
|
|
|
|
|
This is an API service.
|
2025-04-16 14:27:23 +02:00
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_athena_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Athena (Guesty) Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
2025-01-20 14:18:05 +00:00
|
|
|
This is an API service.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_guesty_resolutions_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
The monthly Guesty Resolutions Net Fees, in GBP, without taxes
|
2024-11-05 16:57:23 +00:00
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_guesty_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Athena (Guesty) Net Fees and Guesty Resolutions
|
|
|
|
|
Net Fees, in GBP, without taxes for a given date, dimension and value.
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: xero_waiver_paid_back_to_host_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Waiver Amount Paid Back to Hosts, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_mtd_invoiced_revenue
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Month-To-Date Invoiced Revenue.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- assert_dimension_completeness:
|
2024-11-06 11:47:47 +01:00
|
|
|
metric_column_names:
|
2025-01-20 14:18:05 +00:00
|
|
|
- xero_basic_protection_net_fees_in_gbp
|
|
|
|
|
- xero_waiver_pro_net_fees_in_gbp
|
|
|
|
|
- xero_id_verification_net_fees_in_gbp
|
|
|
|
|
- xero_protection_plus_net_fees_in_gbp
|
|
|
|
|
- xero_screening_plus_net_fees_in_gbp
|
|
|
|
|
- xero_sex_offenders_check_net_fees_in_gbp
|
|
|
|
|
- xero_protection_pro_net_fees_in_gbp
|
|
|
|
|
- xero_basic_screening_net_fees_in_gbp
|
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
|
|
|
- xero_old_dashboard_booking_net_fees_in_gbp
|
2025-03-20 13:45:44 +00:00
|
|
|
- xero_booking_net_fees_in_gbp
|
2024-11-06 08:35:30 +01:00
|
|
|
- xero_listing_net_fees_in_gbp
|
|
|
|
|
- xero_verification_net_fees_in_gbp
|
|
|
|
|
- xero_operator_net_fees_in_gbp
|
|
|
|
|
- xero_e_deposit_net_fees_in_gbp
|
2025-04-16 14:27:23 +02:00
|
|
|
- xero_check_in_hero_api_net_fees_in_gbp
|
2025-04-16 16:18:14 +02:00
|
|
|
- xero_screen_and_protect_net_fees_in_gbp
|
2025-01-20 14:18:05 +00:00
|
|
|
- xero_athena_net_fees_in_gbp
|
|
|
|
|
- xero_guesty_resolutions_net_fees_in_gbp
|
2024-11-06 08:35:30 +01:00
|
|
|
- xero_guesty_net_fees_in_gbp
|
|
|
|
|
- xero_apis_net_fees_in_gbp
|
|
|
|
|
- xero_waiver_paid_back_to_host_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-12 08:17:44 +00:00
|
|
|
- by_business_scope
|
2024-11-05 16:57:23 +00:00
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-05 16:57:23 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_basic_protection_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Basic Protection Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_waiver_pro_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Waiver Pro Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_id_verification_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date ID Verification Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_protection_plus_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Protection Plus Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_screening_plus_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Screening Plus Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_sex_offenders_check_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Sex Offenders Check Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_protection_pro_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Protection Pro Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
|
|
|
|
- name: xero_basic_screening_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Basic Screening Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
This is a New Dashboard service.
|
|
|
|
|
|
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
|
|
|
- name: xero_old_dashboard_booking_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
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
|
|
|
The month-to-date Old Dashboard Booking Net Fees, in GBP, without taxes
|
2024-11-05 16:57:23 +00:00
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
2025-03-20 13:45:44 +00:00
|
|
|
- name: xero_booking_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Total Booking Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
This takes into account both Old Dashboard and New Dashboard.
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: xero_listing_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Listing Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_verification_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Verification Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: xero_operator_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
The month-to-date Operator Net Fees, which include New Dash Services,
|
|
|
|
|
Booking, Listing and Verification Net Fees for Old Dash;
|
|
|
|
|
in GBP, without taxes for a given date, dimension and value.
|
|
|
|
|
Partial data of 2022 corresponds to revenue categorised as Other Revenue
|
|
|
|
|
according to the financials.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
|
|
|
|
- name: xero_e_deposit_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date E-Deposit Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
2025-01-20 14:18:05 +00:00
|
|
|
This is an API service.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
2025-04-16 14:27:23 +02:00
|
|
|
- name: xero_check_in_hero_api_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Check-In Hero API Net Fees, in GBP, without taxes
|
2025-04-16 16:18:14 +02:00
|
|
|
for a given date, dimension and value.
|
|
|
|
|
This is an API service.
|
2025-04-16 14:27:23 +02:00
|
|
|
|
2025-04-16 16:18:14 +02:00
|
|
|
- name: xero_screen_and_protect_net_fees_in_gbp
|
2025-04-16 14:27:23 +02:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Screen & Protect API Net Fees, in GBP, without taxes
|
2025-04-16 16:18:14 +02:00
|
|
|
for a given date, dimension and value.
|
|
|
|
|
This is an API service.
|
2025-04-16 14:27:23 +02:00
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_athena_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Athena (Guesty) Net Fees, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
2025-01-20 14:18:05 +00:00
|
|
|
This is an API service.
|
2024-11-05 16:57:23 +00:00
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_guesty_resolutions_net_fees_in_gbp
|
2024-11-05 16:57:23 +00:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
The month-to-date Guesty Resolutions Net Fees, in GBP, without taxes
|
2024-11-05 16:57:23 +00:00
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
2025-01-20 14:18:05 +00:00
|
|
|
- name: xero_guesty_net_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Athena (Guesty) Net Fees and Guesty Resolutions
|
|
|
|
|
Net Fees, in GBP, without taxes for a given date, dimension and value.
|
|
|
|
|
|
2024-11-05 16:57:23 +00:00
|
|
|
- name: xero_waiver_paid_back_to_host_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
2025-01-20 14:18:05 +00:00
|
|
|
The month-to-date Waiver Amount Paid Back to Hosts, in GBP, without taxes
|
|
|
|
|
for a given date, dimension and value.
|
2024-11-07 10:49:06 +00:00
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_deals
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Deal metrics at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
Be aware that this Deal entity will differ from how the rest of models
|
|
|
|
|
usually operate. This is because we compute Deal metrics, thus it does
|
|
|
|
|
not make sense to compute these at Deal level.
|
|
|
|
|
|
|
|
|
|
Also, Deal metrics at daily level already contain the time dimension
|
|
|
|
|
aggregates needed, thus we won't have mtd or monthly equivalent models,
|
|
|
|
|
but rather just select from this daily model the needed days to recover
|
|
|
|
|
the necessary information.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
|
|
|
|
- main_billing_country_iso_3_per_deal,
|
2025-02-13 16:34:14 +00:00
|
|
|
- business_scope,
|
2024-11-07 10:49:06 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- main_billing_country_iso_3_per_deal
|
2025-02-13 16:34:14 +00:00
|
|
|
- business_scope
|
2024-11-07 10:49:06 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date containing the Deal metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-13 16:34:14 +00:00
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-11-07 10:49:06 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: new_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of new deals in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: never_booked_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of never booked deals in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: active_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of active deals in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: inactive_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of inactive deals in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: churning_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of churning deals in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: reactivated_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of reactivated deals in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: deals_booked_in_month
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of deals booked within the month in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: deals_booked_in_6_months
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of deals booked within the past 6 months in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: deals_booked_in_12_months
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of deals booked within the past 12 months in a given date and per specified dimension.
|
|
|
|
|
|
2025-02-13 16:34:14 +00:00
|
|
|
- name: live_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of live deals in a given date and per specified dimension.
|
|
|
|
|
This accounts for New Deals, Active Deals and Reactivated Deals.
|
|
|
|
|
|
2024-11-07 10:49:06 +00:00
|
|
|
- name: int_kpis__agg_daily_deals
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Daily Deal metrics.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
|
|
|
|
Be aware that this Deal entity will differ from how the rest of models
|
|
|
|
|
usually operate. This is because we compute Deal metrics, thus it does
|
|
|
|
|
not make sense to compute these at Deal level.
|
|
|
|
|
|
|
|
|
|
Also, Deal metrics at daily level already contain the time dimension
|
|
|
|
|
aggregates needed, thus we won't have mtd or monthly equivalent models,
|
|
|
|
|
but rather just select from this daily model the needed days to recover
|
|
|
|
|
the necessary information.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date containing the Deal metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- new_deals
|
|
|
|
|
- never_booked_deals
|
|
|
|
|
- active_deals
|
|
|
|
|
- churning_deals
|
|
|
|
|
- inactive_deals
|
|
|
|
|
- reactivated_deals
|
|
|
|
|
- deals_booked_in_month
|
|
|
|
|
- deals_booked_in_6_months
|
|
|
|
|
- deals_booked_in_12_months
|
2025-02-13 16:34:14 +00:00
|
|
|
- live_deals
|
2024-11-07 10:49:06 +00:00
|
|
|
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
2025-02-13 16:34:14 +00:00
|
|
|
- by_business_scope
|
2024-11-07 10:49:06 +00:00
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_end_of_month
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: True if it's end of month, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_current_month
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
True if the date is within the current month, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_month_to_date
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
True if the date is within the scope of month-to-date, false otherwise.
|
|
|
|
|
The scope of month-to-date takes into account both 1) a date being in
|
|
|
|
|
the current month or 2) a date corresponding to the same month of the
|
|
|
|
|
previous year, which day number cannot be higher than yesterday's day
|
|
|
|
|
number.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 10:49:06 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: new_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of new deals for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: never_booked_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of never booked deals for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: active_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of active deals for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: inactive_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of inactive deals for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: churning_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of churning deals for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: reactivated_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of reactivated deals for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: deals_booked_in_month
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of deals booked within the month for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: deals_booked_in_6_months
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of deals booked within the past 6 months for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: deals_booked_in_12_months
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of deals booked within the past 12 months for a given date, dimension and value.
|
2024-11-07 16:56:43 +00:00
|
|
|
|
2025-02-13 16:34:14 +00:00
|
|
|
- name: live_deals
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of live deals in a given date and per specified dimension.
|
|
|
|
|
This accounts for New Deals, Never Booked Deals, Active Deals and Reactivated Deals.
|
|
|
|
|
|
2024-11-07 16:56:43 +00:00
|
|
|
- name: int_kpis__metric_daily_listings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Listing metrics at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
Listing metrics at daily level already contain the time dimension
|
|
|
|
|
aggregates needed, thus we won't have mtd or monthly equivalent models,
|
|
|
|
|
but rather just select from this daily model the needed days to recover
|
|
|
|
|
the necessary information.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
2025-02-13 16:34:14 +00:00
|
|
|
- business_scope
|
2024-11-07 16:56:43 +00:00
|
|
|
- id_deal
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
2025-02-13 16:34:14 +00:00
|
|
|
- business_scope
|
2024-11-07 16:56:43 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date containing the Listing metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-02-13 16:34:14 +00:00
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-11-07 16:56:43 +00:00
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Listing level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: new_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of new listings in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: never_booked_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of never booked listings in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: first_time_booked_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of first-time booked listings in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: active_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of active listings in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: inactive_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of inactive listings in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: churning_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of churning listings in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: reactivated_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of reactivated listings in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: listings_booked_in_month
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of listings booked within the month in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: listings_booked_in_6_months
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of listings booked within the past 6 months in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: listings_booked_in_12_months
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of listings booked within the past 12 months in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_daily_listings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Daily Listing metrics.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
|
|
|
|
Listing metrics at daily level already contain the time dimension
|
|
|
|
|
aggregates needed, thus we won't have mtd or monthly equivalent models,
|
|
|
|
|
but rather just select from this daily model the needed days to recover
|
|
|
|
|
the necessary information.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date containing the Listing metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- new_listings
|
|
|
|
|
- never_booked_listings
|
|
|
|
|
- first_time_booked_listings
|
|
|
|
|
- active_listings
|
|
|
|
|
- churning_listings
|
|
|
|
|
- inactive_listings
|
|
|
|
|
- reactivated_listings
|
|
|
|
|
- listings_booked_in_month
|
|
|
|
|
- listings_booked_in_6_months
|
|
|
|
|
- listings_booked_in_12_months
|
|
|
|
|
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_deal
|
2025-02-13 16:34:14 +00:00
|
|
|
- by_business_scope
|
2024-11-07 16:56:43 +00:00
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_end_of_month
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: True if it's end of month, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_current_month
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
True if the date is within the current month, false otherwise.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_month_to_date
|
|
|
|
|
data_type: boolean
|
|
|
|
|
description: |
|
|
|
|
|
True if the date is within the scope of month-to-date, false otherwise.
|
|
|
|
|
The scope of month-to-date takes into account both 1) a date being in
|
|
|
|
|
the current month or 2) a date corresponding to the same month of the
|
|
|
|
|
previous year, which day number cannot be higher than yesterday's day
|
|
|
|
|
number.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-07 16:56:43 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: new_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of new listings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: never_booked_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of never booked listings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: first_time_booked_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of first-time booked listings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: active_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of active listings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: inactive_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of inactive listings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: churning_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of churning listings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: reactivated_listings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of reactivated listings for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: listings_booked_in_month
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of listings booked within the month for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: listings_booked_in_6_months
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of listings booked within the past 6 months for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: listings_booked_in_12_months
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of listings booked within the past 12 months for a given date, dimension and value.
|
2024-11-08 15:25:11 +01:00
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: int_kpis__dimension_date_product_guest
|
2024-11-08 15:25:11 +01:00
|
|
|
description: |
|
|
|
|
|
This model computes a cross join of dates with all combinations of
|
|
|
|
|
guest products dimensions.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-08 15:25:11 +01:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date_day
|
|
|
|
|
- has_payment
|
|
|
|
|
- has_id_check
|
2024-11-25 11:53:14 +01:00
|
|
|
- main_billing_country_iso_3_per_deal
|
2024-11-08 15:25:11 +01:00
|
|
|
columns:
|
|
|
|
|
- name: date_day
|
|
|
|
|
data_type: date
|
|
|
|
|
description: "Date of when Guest Journeys have been completed."
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-08 15:25:11 +01:00
|
|
|
- not_null
|
|
|
|
|
|
2024-11-18 11:23:25 +01:00
|
|
|
- name: date_week
|
|
|
|
|
data_type: string
|
|
|
|
|
description: "Week number of when Guest Journeys have been completed."
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-18 11:23:25 +01:00
|
|
|
- not_null
|
|
|
|
|
|
2024-11-08 15:25:11 +01:00
|
|
|
- name: has_payment
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Has there been any guest payments on the guest journey.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-08 15:25:11 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- W/O Payment
|
|
|
|
|
- With Payment
|
|
|
|
|
|
|
|
|
|
- name: has_id_check
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Does the verification in the guest journey
|
|
|
|
|
includes Government Id Check for the bookings.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-08 15:25:11 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- W/O Id Check
|
|
|
|
|
- With Id Check
|
|
|
|
|
|
2024-11-25 11:53:14 +01:00
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-25 11:53:14 +01:00
|
|
|
- not_null
|
|
|
|
|
|
2024-11-08 15:25:11 +01:00
|
|
|
- name: int_kpis__product_guest_daily_metrics
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Guest Metrics at the deepest granularity.
|
|
|
|
|
Here all metrics are attributed to the Check-in Date of the associated
|
|
|
|
|
booking, except for payments which are attributed to payment date.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
2024-11-11 16:22:13 +01:00
|
|
|
- date_day,
|
|
|
|
|
- py_date_day,
|
2024-11-08 15:25:11 +01:00
|
|
|
- id_deal,
|
2024-11-25 11:53:14 +01:00
|
|
|
- has_id_check,
|
|
|
|
|
- main_billing_country_iso_3_per_deal.
|
2024-11-08 15:25:11 +01:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-08 15:25:11 +01:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
2024-11-09 15:21:20 +01:00
|
|
|
- date_day
|
2024-11-11 16:22:13 +01:00
|
|
|
- py_date_day
|
2024-11-08 15:25:11 +01:00
|
|
|
- has_payment
|
|
|
|
|
- has_id_check
|
2024-11-25 11:53:14 +01:00
|
|
|
- main_billing_country_iso_3_per_deal
|
2024-11-08 15:25:11 +01:00
|
|
|
columns:
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: date_day
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: date
|
|
|
|
|
description: "Date of when Guest Journeys have been completed."
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-08 15:25:11 +01:00
|
|
|
- not_null
|
|
|
|
|
|
2024-11-18 11:23:25 +01:00
|
|
|
- name: date_week
|
|
|
|
|
data_type: string
|
|
|
|
|
description: "Week number of when Guest Journeys have been completed."
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-18 11:23:25 +01:00
|
|
|
- not_null
|
|
|
|
|
|
2024-11-11 16:22:13 +01:00
|
|
|
- name: py_date_day
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
Date on the previous year of when Guest Journeys have been completed.
|
|
|
|
|
Note that this date can be NULL for leap days (29th February)
|
|
|
|
|
|
2024-11-08 15:25:11 +01:00
|
|
|
- name: has_payment
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Has there been any guest payments on the guest journey.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-08 15:25:11 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- W/O Payment
|
|
|
|
|
- With Payment
|
|
|
|
|
|
|
|
|
|
- name: has_id_check
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Does the verification in the guest journey
|
|
|
|
|
includes Government Id Check for the bookings.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-08 15:25:11 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- W/O Id Check
|
|
|
|
|
- With Id Check
|
|
|
|
|
|
2024-11-25 11:53:14 +01:00
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-25 11:53:14 +01:00
|
|
|
- not_null
|
|
|
|
|
|
2024-11-08 15:25:11 +01:00
|
|
|
- name: created_guest_journeys_not_cancelled
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys created, excluding cancelled bookings,
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: started_guest_journeys_not_cancelled
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys started, excluding cancelled bookings,
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: completed_guest_journeys_not_cancelled
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys completed, excluding cancelled bookings,
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: created_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys created in a given date and
|
|
|
|
|
per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: started_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys started in a given date and
|
|
|
|
|
per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: completed_guest_journeys
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys completed in a given date and
|
|
|
|
|
per specified dimension.
|
|
|
|
|
|
2024-11-26 10:16:08 +01:00
|
|
|
- name: total_csat_score_count
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys with CSAT (customer satisfaction score)
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: average_csat_score
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Average daily CSAT score in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: deposit_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of deposit fees paid by guests, without taxes, in GBP
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: waiver_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of waiver payments paid by guests, without taxes, in GBP
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: checkin_cover_fees_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of checkin cover fees paid by guests, without taxes, in GBP
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: total_guest_payments_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of total payments paid by guests, without taxes, in GBP
|
|
|
|
|
in a given date and per specified dimension.
|
|
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: py_created_guest_journeys_not_cancelled
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys created (excluding canceled bookings)
|
|
|
|
|
on the same date in the previous year, segmented by the specified dimension.
|
|
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: py_started_guest_journeys_not_cancelled
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys started (excluding canceled bookings)
|
|
|
|
|
on the same date in the previous year, segmented by the specified dimension.
|
|
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: py_completed_guest_journeys_not_cancelled
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys completed (excluding canceled bookings)
|
|
|
|
|
on the same date in the previous year, segmented by the specified dimension.
|
|
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: py_created_guest_journeys
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys created on the same date in the previous year,
|
|
|
|
|
segmented by the specified dimension.
|
|
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: py_started_guest_journeys
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys started on the same date in the previous year,
|
|
|
|
|
segmented by the specified dimension.
|
|
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: py_completed_guest_journeys
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys completed on the same date in the previous year,
|
|
|
|
|
segmented by the specified dimension.
|
|
|
|
|
|
2024-11-26 10:16:08 +01:00
|
|
|
- name: py_total_csat_score_count
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily guest journeys with CSAT (customer satisfaction score)
|
|
|
|
|
on the same date in the previous year, segmented by the specified dimension.
|
|
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: py_average_csat_score
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Average daily CSAT score on the same date in the previous year,
|
|
|
|
|
segmented by the specified dimension.
|
|
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: py_deposit_fees_in_gbp
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of deposit fees paid by guests, excluding taxes, in GBP
|
|
|
|
|
on the same date in the previous year, segmented by the specified dimension.
|
|
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: py_waiver_payments_in_gbp
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of waiver payments paid by guests, excluding taxes, in GBP
|
|
|
|
|
on the same date in the previous year, segmented by the specified dimension.
|
|
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: py_checkin_cover_fees_in_gbp
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of check-in cover fees paid by guests, excluding taxes, in GBP
|
|
|
|
|
on the same date in the previous year, segmented by the specified dimension.
|
|
|
|
|
|
2024-11-09 15:21:20 +01:00
|
|
|
- name: py_total_guest_payments_in_gbp
|
2024-11-08 15:25:11 +01:00
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of total payments paid by guests, excluding taxes, in GBP
|
|
|
|
|
on the same date in the previous year, segmented by the specified dimension.
|
2024-11-20 09:43:30 +00:00
|
|
|
|
2024-11-26 14:05:03 +01:00
|
|
|
- name: int_kpis__product_guest_agg_metrics
|
|
|
|
|
description:
|
|
|
|
|
This model aggregates multiple metrics on a Year-to-date, Month-to-date or
|
|
|
|
|
Week-to-date basis. This model changes the display format of the model
|
|
|
|
|
int_kpis__product_guest_daily_metrics pivoting the metrics columns and
|
|
|
|
|
adding a timeframe dimension.
|
|
|
|
|
columns:
|
|
|
|
|
- name: metric
|
|
|
|
|
data_type: text
|
|
|
|
|
description: Name of the business metric
|
|
|
|
|
|
|
|
|
|
- name: has_payment
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Has there been any guest payments on the guest journey.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:05:03 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- W/O Payment
|
|
|
|
|
- With Payment
|
|
|
|
|
|
|
|
|
|
- name: has_id_check
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Does the verification in the guest journey
|
|
|
|
|
includes Government Id Check for the bookings.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:05:03 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- W/O Id Check
|
|
|
|
|
- With Id Check
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:05:03 +01:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: timeframe
|
|
|
|
|
data_type: text
|
|
|
|
|
description: |
|
|
|
|
|
Timeframe considered for the aggregation, it could be Year-to-date,
|
|
|
|
|
Month-to-date or Week-to-date
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:05:03 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- YTD
|
|
|
|
|
- MTD
|
|
|
|
|
- WTD
|
|
|
|
|
|
|
|
|
|
- name: current_value
|
|
|
|
|
data_type: numeric
|
|
|
|
|
description: |
|
|
|
|
|
Numeric value (integer or decimal) that corresponds to the timeframe
|
|
|
|
|
computation of the metric at the current date.
|
|
|
|
|
For example if the current date is 27/11/2024 and the timeframe is MTD,
|
|
|
|
|
then this value would correspond to the computation of the metric for
|
|
|
|
|
the dates between 01/11/2024 and 27/11/2024.
|
|
|
|
|
|
|
|
|
|
- name: py_value
|
|
|
|
|
data_type: numeric
|
|
|
|
|
description: |
|
|
|
|
|
Numeric value (integer or decimal) that corresponds to the timeframe
|
|
|
|
|
computation of the metric at the current date but on the previous year.
|
|
|
|
|
For example if the current date is 27/11/2024 and the timeframe is MTD,
|
|
|
|
|
then this value would correspond to the computation of the metric for
|
|
|
|
|
the dates between 01/11/2023 and 27/11/2023.
|
|
|
|
|
|
|
|
|
|
- name: pp_value
|
|
|
|
|
data_type: numeric
|
|
|
|
|
description: |
|
|
|
|
|
Numeric value (integer or decimal) that corresponds to the timeframe
|
|
|
|
|
computation of the metric at the current date but on the previous period.
|
|
|
|
|
For example if the current date is 27/11/2024 and the timeframe is MTD,
|
|
|
|
|
then this value would correspond to the computation of the metric for
|
|
|
|
|
the dates between 01/10/2024 and 27/10/2024.
|
|
|
|
|
|
2024-11-20 09:43:30 +00:00
|
|
|
- name: int_kpis__metric_daily_new_dash_created_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Created Services at the deepest granularity.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
|
|
|
|
- id_booking,
|
|
|
|
|
- service_name
|
2024-12-02 12:42:47 +01:00
|
|
|
- service_business_type
|
2024-11-20 09:43:30 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_booking
|
|
|
|
|
- service_name
|
2024-12-02 12:42:47 +01:00
|
|
|
- service_business_type
|
2024-11-20 09:43:30 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Services have been created.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_booking
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of the Booking.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: service_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Name of the created service.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_upgraded_service
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Whether the service is an upgraded version of the
|
|
|
|
|
default. In other words, if it's not Basic Screening.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "YES"
|
|
|
|
|
- "NO"
|
|
|
|
|
|
2024-12-02 10:54:29 +01:00
|
|
|
- name: service_business_type
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
2025-02-28 11:14:40 +01:00
|
|
|
Identifies the service type (Screening, Deposit Management, Protection
|
|
|
|
|
or Guest Agreement) according to New Pricing documentation.
|
2024-12-02 10:54:29 +01:00
|
|
|
Cannot be null.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-12-02 10:54:29 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "SCREENING"
|
|
|
|
|
- "PROTECTION"
|
|
|
|
|
- "DEPOSIT_MANAGEMENT"
|
2025-02-28 11:14:40 +01:00
|
|
|
- "GUEST_AGREEMENT"
|
2024-12-02 10:54:29 +01:00
|
|
|
- "UNKNOWN"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-11-20 09:43:30 +00:00
|
|
|
- name: new_dash_version
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
The version of the New Dash. It corresponds to the
|
|
|
|
|
release or migration phase from user point of view.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_services
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily services created in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_new_dash_created_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Created Services at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- service_name,
|
2024-11-21 16:30:47 +00:00
|
|
|
- id_deal,
|
2024-12-02 11:14:34 +01:00
|
|
|
- active_accommodations_per_deal_segmentation,
|
|
|
|
|
- service_business_type.
|
2024-11-20 09:43:30 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- service_name
|
2024-11-21 16:30:47 +00:00
|
|
|
- id_deal
|
2024-11-20 09:43:30 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
2024-12-02 11:14:34 +01:00
|
|
|
- service_business_type
|
2024-11-20 09:43:30 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: service_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Name of the created service.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2024-12-02 10:54:29 +01:00
|
|
|
- name: service_business_type
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
2025-02-28 11:14:40 +01:00
|
|
|
Identifies the service type (Screening, Deposit Management,
|
|
|
|
|
Protection or Guest Agreement) according to New Pricing documentation.
|
2024-12-02 10:54:29 +01:00
|
|
|
Cannot be null.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-12-02 10:54:29 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "SCREENING"
|
|
|
|
|
- "PROTECTION"
|
|
|
|
|
- "DEPOSIT_MANAGEMENT"
|
2025-02-28 11:14:40 +01:00
|
|
|
- "GUEST_AGREEMENT"
|
2024-12-02 10:54:29 +01:00
|
|
|
- "UNKNOWN"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-11-20 09:43:30 +00:00
|
|
|
- name: is_upgraded_service
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Whether the service is an upgraded version of the
|
|
|
|
|
default. In other words, if it's not Basic Screening.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "YES"
|
|
|
|
|
- "NO"
|
|
|
|
|
|
|
|
|
|
- name: new_dash_version
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
The version of the New Dash. It corresponds to the
|
|
|
|
|
release or migration phase from user point of view.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_services
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of services created in a given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: booking_with_created_services_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of unique bookings in a given month and per specified dimension.
|
|
|
|
|
This is an approximation to booking count since different services can
|
|
|
|
|
apply to the same booking and these do not need to be created in the same
|
|
|
|
|
time period. Therefore, it's not an additive metric.
|
|
|
|
|
|
2024-11-21 11:30:36 +00:00
|
|
|
- name: int_kpis__metric_weekly_new_dash_created_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Weekly Created Services at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
Be aware that any dimension that can change over the weekly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- service_name,
|
2024-11-21 16:30:47 +00:00
|
|
|
- id_deal,
|
2024-12-02 11:14:34 +01:00
|
|
|
- active_accommodations_per_deal_segmentation,
|
|
|
|
|
- service_business_type.
|
2024-11-21 11:30:36 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- service_name
|
2024-11-21 16:30:47 +00:00
|
|
|
- id_deal
|
2024-11-21 11:30:36 +00:00
|
|
|
- active_accommodations_per_deal_segmentation
|
2024-12-02 11:14:34 +01:00
|
|
|
- service_business_type
|
2024-11-21 11:30:36 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: service_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Name of the created service.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2024-12-02 10:54:29 +01:00
|
|
|
- name: service_business_type
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
2025-02-28 11:14:40 +01:00
|
|
|
Identifies the service type (Screening, Deposit Management,
|
|
|
|
|
Protection or Guest Agreement) according to New Pricing documentation.
|
2024-12-02 10:54:29 +01:00
|
|
|
Cannot be null.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-12-02 10:54:29 +01:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "SCREENING"
|
|
|
|
|
- "PROTECTION"
|
|
|
|
|
- "DEPOSIT_MANAGEMENT"
|
2025-02-28 11:14:40 +01:00
|
|
|
- "GUEST_AGREEMENT"
|
2024-12-02 10:54:29 +01:00
|
|
|
- "UNKNOWN"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2024-11-21 11:30:36 +00:00
|
|
|
- name: is_upgraded_service
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Whether the service is an upgraded version of the
|
|
|
|
|
default. In other words, if it's not Basic Screening.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "YES"
|
|
|
|
|
- "NO"
|
|
|
|
|
|
|
|
|
|
- name: new_dash_version
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
The version of the New Dash. It corresponds to the
|
|
|
|
|
release or migration phase from user point of view.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_services
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of services created in a given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: booking_with_created_services_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of unique bookings in a given month and per specified dimension.
|
|
|
|
|
This is an approximation to booking count since different services can
|
|
|
|
|
apply to the same booking and these do not need to be created in the same
|
|
|
|
|
time period. Therefore, it's not an additive metric.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_weekly_new_dash_created_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Weekly Created Services.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is end_date, dimension and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- created_services
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
2024-12-02 11:14:34 +01:00
|
|
|
- by_service_business_type
|
2024-11-21 11:30:36 +00:00
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-21 11:30:36 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_services
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The weekly created services for a given date range, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: booking_with_created_services_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The weekly bookings with created services for a given date range, dimension and value.
|
|
|
|
|
This is an approximation to booking count since different services can
|
|
|
|
|
apply to the same booking and these do not need to be created in the same
|
|
|
|
|
time period. Therefore, it's not an additive metric.
|
|
|
|
|
|
2024-11-20 09:43:30 +00:00
|
|
|
- name: int_kpis__agg_monthly_new_dash_created_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Monthly Created Services.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is end_date, dimension and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- created_services
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
2024-12-02 11:14:34 +01:00
|
|
|
- by_service_business_type
|
2024-11-20 09:43:30 +00:00
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_services
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The monthly created services for a given date range, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: booking_with_created_services_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The monthly bookings with created services for a given date range, dimension and value.
|
|
|
|
|
This is an approximation to booking count since different services can
|
|
|
|
|
apply to the same booking and these do not need to be created in the same
|
|
|
|
|
time period. Therefore, it's not an additive metric.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_daily_new_dash_created_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Daily Created Services.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is date, dimension and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The daily date acting as time range for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- created_services
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
2024-12-02 12:42:47 +01:00
|
|
|
- by_service_business_type
|
2024-11-20 09:43:30 +00:00
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_services
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The daily created services for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: booking_with_created_services_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The daily bookings with created services for a given date, dimension and value.
|
|
|
|
|
This is an approximation to booking count since different services can
|
|
|
|
|
apply to the same booking and these do not need to be created in the same
|
|
|
|
|
time period. Therefore, it's not an additive metric.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__product_new_dash_agg_metrics
|
|
|
|
|
description: |
|
|
|
|
|
This model serves as the skeleton for New Dash metrics and dimensions.
|
|
|
|
|
This model computes the time granularity aggregation per previously computed
|
|
|
|
|
dimension aggregation.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- time_granularity
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range specified in the time_granularity
|
|
|
|
|
for the dimension, dimension_value and metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: time_granularity
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The time dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- daily
|
2024-11-21 11:30:36 +00:00
|
|
|
- weekly
|
2024-11-20 09:43:30 +00:00
|
|
|
- monthly
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
2024-11-26 14:19:41 +00:00
|
|
|
- by_service_business_type
|
2024-11-20 09:43:30 +00:00
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-20 09:43:30 +00:00
|
|
|
- not_null
|
|
|
|
|
|
2025-03-27 14:27:38 +01:00
|
|
|
- name: deal_with_offered_service_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The count of deals with services offered by a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: accommodation_with_offered_service_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The count of accommodations with services offered by a given date, dimension and value.
|
|
|
|
|
|
2024-11-20 09:43:30 +00:00
|
|
|
- name: created_services
|
|
|
|
|
data_type: bigint
|
2024-11-26 14:19:41 +00:00
|
|
|
description: |
|
|
|
|
|
The created services for a given time granularity, date or dates range,
|
|
|
|
|
dimension and value.
|
2024-11-20 09:43:30 +00:00
|
|
|
|
2025-04-02 08:22:21 +02:00
|
|
|
- name: created_bookings
|
2024-11-20 09:43:30 +00:00
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2025-04-02 08:22:21 +02:00
|
|
|
The amount of created bookings for a given time granularity, date or dates range,
|
|
|
|
|
dimension and value.
|
2024-11-26 10:14:37 +00:00
|
|
|
|
2024-11-26 14:19:41 +00:00
|
|
|
- name: total_chargeable_services
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The total chargeable services for a given time granularity, date or
|
|
|
|
|
dates range, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: total_chargeable_amount_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The total daily chargeable amount for a given time granularity, date or
|
|
|
|
|
dates range, dimension and value, in GBP.
|
|
|
|
|
|
|
|
|
|
- name: unique_chargeable_bookings
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The unique daily chargeable bookings for a given time granularity, date or
|
|
|
|
|
dates range, dimension and value.
|
|
|
|
|
This metric is not additive, and its value can vary depending on the time
|
|
|
|
|
period considered.
|
|
|
|
|
|
|
|
|
|
- name: unique_chargeable_listings
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The unique daily chargeable accommodations, or listings, for a given time
|
|
|
|
|
granularity, date or dates range, dimension and value.
|
|
|
|
|
This metric is not additive, and its value can vary depending on the time
|
|
|
|
|
period considered.
|
|
|
|
|
|
2024-11-26 10:14:37 +00:00
|
|
|
- name: int_kpis__metric_daily_new_dash_chargeable_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Chargeable Services at the deepest granularity.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services chargeable after the user has moved to New Dash.
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
|
|
|
|
- id_booking,
|
|
|
|
|
- service_name
|
2024-12-02 12:42:47 +01:00
|
|
|
- service_business_type
|
2024-11-26 10:14:37 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 10:14:37 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_booking
|
|
|
|
|
- service_name
|
2024-12-02 12:42:47 +01:00
|
|
|
- service_business_type
|
2024-11-26 10:14:37 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Services are supposed to be charged.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 10:14:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_booking
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of the Booking.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 10:14:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: service_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Name of the chargeable service.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 10:14:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 10:14:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_accommodation
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of an accommodation, or listing.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 10:14:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_upgraded_service
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Whether the service is an upgraded version of the
|
|
|
|
|
default. In other words, if it's not Basic Screening.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 10:14:37 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "YES"
|
|
|
|
|
- "NO"
|
|
|
|
|
|
|
|
|
|
- name: service_business_type
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
2025-02-28 11:14:40 +01:00
|
|
|
Identifies the service type (Screening, Deposit Management,
|
|
|
|
|
Protection or Guest Agreement) according to New Pricing documentation.
|
2024-11-26 10:14:37 +00:00
|
|
|
Cannot be null.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 10:14:37 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "SCREENING"
|
|
|
|
|
- "PROTECTION"
|
|
|
|
|
- "DEPOSIT_MANAGEMENT"
|
2025-02-28 11:14:40 +01:00
|
|
|
- "GUEST_AGREEMENT"
|
2024-12-02 12:42:47 +01:00
|
|
|
- "UNKNOWN"
|
2024-11-26 10:14:37 +00:00
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: new_dash_version
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
The version of the New Dash. It corresponds to the
|
|
|
|
|
release or migration phase from user point of view.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 10:14:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 10:14:37 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 10:14:37 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: chargeable_services
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily chargeable services in a given date and per specified
|
|
|
|
|
dimension.
|
|
|
|
|
|
|
|
|
|
- name: service_total_price_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of the total prices of the chargeable services in a given date and
|
|
|
|
|
per specified dimension, in GBP.
|
2024-11-26 14:19:41 +00:00
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_new_dash_chargeable_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Chargeable Services at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services chargeable after the user has moved to New Dash.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- service_name,
|
|
|
|
|
- id_booking,
|
|
|
|
|
- active_accommodations_per_deal_segmentation.
|
2024-12-02 12:42:47 +01:00
|
|
|
- service_business_type
|
2024-11-26 14:19:41 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_booking
|
|
|
|
|
- service_name
|
|
|
|
|
- active_accommodations_per_deal_segmentation
|
2024-12-02 12:42:47 +01:00
|
|
|
- service_business_type
|
2024-11-26 14:19:41 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_booking
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of the Booking.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: service_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Name of the chargeable service.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_accommodation
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of an accommodation, or listing.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_upgraded_service
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Whether the service is an upgraded version of the
|
|
|
|
|
default. In other words, if it's not Basic Screening.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "YES"
|
|
|
|
|
- "NO"
|
|
|
|
|
|
|
|
|
|
- name: service_business_type
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
2025-02-28 11:14:40 +01:00
|
|
|
Identifies the service type (Screening, Deposit Management,
|
|
|
|
|
Protection or Guest Agreement) according to New Pricing documentation.
|
2024-11-26 14:19:41 +00:00
|
|
|
Cannot be null.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "SCREENING"
|
|
|
|
|
- "PROTECTION"
|
|
|
|
|
- "DEPOSIT_MANAGEMENT"
|
2025-02-28 11:14:40 +01:00
|
|
|
- "GUEST_AGREEMENT"
|
2024-12-02 12:42:47 +01:00
|
|
|
- "UNKNOWN"
|
2024-11-26 14:19:41 +00:00
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: new_dash_version
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
The version of the New Dash. It corresponds to the
|
|
|
|
|
release or migration phase from user point of view.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: chargeable_services
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
Count of monthly chargeable services in a given date and per specified
|
|
|
|
|
dimension.
|
|
|
|
|
|
|
|
|
|
- name: service_total_price_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of the total prices of the chargeable services in a given time range
|
|
|
|
|
and per specified dimension, in GBP.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_weekly_new_dash_chargeable_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Weekly Chargeable Services at the
|
|
|
|
|
deepest granularity.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services chargeable after the user has moved to New Dash.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- service_name,
|
|
|
|
|
- id_booking,
|
2024-12-02 12:42:47 +01:00
|
|
|
- active_accommodations_per_deal_segmentation,
|
|
|
|
|
- service_business_type
|
2024-11-26 14:19:41 +00:00
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_booking
|
|
|
|
|
- service_name
|
|
|
|
|
- active_accommodations_per_deal_segmentation
|
2024-12-02 12:42:47 +01:00
|
|
|
- service_business_type
|
2024-11-26 14:19:41 +00:00
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_booking
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of the Booking.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: service_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Name of the chargeable service.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_accommodation
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of an accommodation, or listing.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_upgraded_service
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Whether the service is an upgraded version of the
|
|
|
|
|
default. In other words, if it's not Basic Screening.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "YES"
|
|
|
|
|
- "NO"
|
|
|
|
|
|
|
|
|
|
- name: service_business_type
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
2025-02-28 11:14:40 +01:00
|
|
|
Identifies the service type (Screening, Deposit Management,
|
|
|
|
|
Protection or Guest Agreement) according to New Pricing documentation.
|
2024-11-26 14:19:41 +00:00
|
|
|
Cannot be null.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "SCREENING"
|
|
|
|
|
- "PROTECTION"
|
|
|
|
|
- "DEPOSIT_MANAGEMENT"
|
2025-02-28 11:14:40 +01:00
|
|
|
- "GUEST_AGREEMENT"
|
2024-12-02 12:42:47 +01:00
|
|
|
- "UNKNOWN"
|
2024-11-26 14:19:41 +00:00
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: new_dash_version
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
The version of the New Dash. It corresponds to the
|
|
|
|
|
release or migration phase from user point of view.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: chargeable_services
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
Count of weekly chargeable services in a given date and per specified
|
|
|
|
|
dimension.
|
|
|
|
|
|
|
|
|
|
- name: service_total_price_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of the total prices of the chargeable services in a given time range
|
|
|
|
|
and per specified dimension, in GBP.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_weekly_new_dash_chargeable_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Weekly Chargeable Services.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services chargeable after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is end_date, dimension and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- total_chargeable_services
|
|
|
|
|
- total_chargeable_amount_in_gbp
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: total_chargeable_services
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The total weekly chargeable services in a given time range and per specified
|
|
|
|
|
dimension.
|
|
|
|
|
|
|
|
|
|
- name: total_chargeable_amount_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The total weekly chargeable amount in a given time range and per specified
|
|
|
|
|
dimension, in GBP.
|
|
|
|
|
|
|
|
|
|
- name: unique_chargeable_bookings
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The unique weekly chargeable bookings in a given time range and per specified
|
|
|
|
|
dimension. This metric is not additive, and its value can vary depending
|
|
|
|
|
on the time period considered.
|
|
|
|
|
|
|
|
|
|
- name: unique_chargeable_listings
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The unique weekly chargeable accommodations, or listings, in a given time range
|
|
|
|
|
and per specified dimension. This metric is not additive, and its value
|
|
|
|
|
can vary depending on the time period considered.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_monthly_new_dash_chargeable_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Monthly Chargeable Services.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services chargeable after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is end_date, dimension and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- total_chargeable_services
|
|
|
|
|
- total_chargeable_amount_in_gbp
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: total_chargeable_services
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The total monthly chargeable services in a given time range and per specified
|
|
|
|
|
dimension.
|
|
|
|
|
|
|
|
|
|
- name: total_chargeable_amount_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The total monthly chargeable amount in a given time range and per specified
|
|
|
|
|
dimension, in GBP.
|
|
|
|
|
|
|
|
|
|
- name: unique_chargeable_bookings
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The unique monthly chargeable bookings in a given time range and per specified
|
|
|
|
|
dimension. This metric is not additive, and its value can vary depending
|
|
|
|
|
on the time period considered.
|
|
|
|
|
|
|
|
|
|
- name: unique_chargeable_listings
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The unique monthly chargeable accommodations, or listings, in a given time range
|
|
|
|
|
and per specified dimension. This metric is not additive, and its value
|
|
|
|
|
can vary depending on the time period considered.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_daily_new_dash_chargeable_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Daily Chargeable Services.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services chargeable after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is date, dimension and dimension_value.
|
|
|
|
|
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The daily date acting as time range for the metrics in this record.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- total_chargeable_services
|
|
|
|
|
- total_chargeable_amount_in_gbp
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
2025-01-13 16:00:35 +01:00
|
|
|
data_tests:
|
2024-11-26 14:19:41 +00:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: total_chargeable_services
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The total daily chargeable services in a given time range and per specified
|
|
|
|
|
dimension.
|
|
|
|
|
|
|
|
|
|
- name: total_chargeable_amount_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The total daily chargeable amount in a given time range and per specified
|
|
|
|
|
dimension, in GBP.
|
|
|
|
|
|
|
|
|
|
- name: unique_chargeable_bookings
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The unique daily chargeable bookings in a given time range and per specified
|
|
|
|
|
dimension. This metric is not additive, and its value can vary depending
|
|
|
|
|
on the time period considered.
|
|
|
|
|
|
|
|
|
|
- name: unique_chargeable_listings
|
|
|
|
|
data_type: integer
|
|
|
|
|
description: |
|
|
|
|
|
The unique daily chargeable accommodations, or listings, in a given time range
|
|
|
|
|
and per specified dimension. This metric is not additive, and its value
|
|
|
|
|
can vary depending on the time period considered.
|
2025-03-24 13:00:24 +01:00
|
|
|
|
2025-03-25 17:11:02 +01:00
|
|
|
- name: int_kpis__metric_daily_new_dash_deals_offered_services
|
2025-03-24 13:00:24 +01:00
|
|
|
description: |
|
2025-03-25 17:11:02 +01:00
|
|
|
This model computes the Daily Offered Services by Deals at the deepest granularity.
|
2025-03-24 13:00:24 +01:00
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
2025-03-25 17:11:02 +01:00
|
|
|
- date,
|
2025-03-25 12:25:47 +01:00
|
|
|
- id_deal,
|
|
|
|
|
- id_user_product_bundle,
|
2025-03-24 13:00:24 +01:00
|
|
|
- service_name,
|
|
|
|
|
- service_business_type
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
2025-03-25 12:25:47 +01:00
|
|
|
- id_deal
|
2025-03-24 13:00:24 +01:00
|
|
|
- id_user_product_bundle
|
|
|
|
|
- service_name
|
|
|
|
|
- service_business_type
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when user has a bundle with service active.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
2025-03-25 12:25:47 +01:00
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
2025-03-24 13:00:24 +01:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
2025-03-25 12:25:47 +01:00
|
|
|
- name: id_user_product_bundle
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of the User Product Bundle.
|
2025-03-24 13:00:24 +01:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: service_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Name of the created service.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: service_business_type
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Identifies the service type (Screening, Deposit Management, Protection
|
|
|
|
|
or Guest Agreement) according to New Pricing documentation.
|
|
|
|
|
Cannot be null.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "SCREENING"
|
|
|
|
|
- "PROTECTION"
|
|
|
|
|
- "DEPOSIT_MANAGEMENT"
|
|
|
|
|
- "GUEST_AGREEMENT"
|
|
|
|
|
|
2025-03-25 12:25:47 +01:00
|
|
|
- name: is_upgraded_service
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Whether the service is an upgraded version of the
|
|
|
|
|
default. In other words, if it's not Basic Screening.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "YES"
|
|
|
|
|
- "NO"
|
|
|
|
|
|
2025-03-24 13:00:24 +01:00
|
|
|
- name: new_dash_version
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
The version of the New Dash. It corresponds to the
|
|
|
|
|
release or migration phase from user point of view.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
2025-03-25 16:47:26 +01:00
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_new_dash_accommodation_offered_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Offered Services by Listings at the deepest granularity.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
|
|
|
|
- id_accommodation,
|
|
|
|
|
- id_user_product_bundle,
|
|
|
|
|
- service_name,
|
|
|
|
|
- service_business_type
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_accommodation
|
|
|
|
|
- id_user_product_bundle
|
|
|
|
|
- service_name
|
|
|
|
|
- service_business_type
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when user has a bundle with service active.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- name: id_accommodation
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of an accommodation, or listing.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- name: id_user_product_bundle
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of the User Product Bundle.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- name: service_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Name of the created service.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- name: service_business_type
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Identifies the service type (Screening, Deposit Management, Protection
|
|
|
|
|
or Guest Agreement) according to New Pricing documentation.
|
|
|
|
|
Cannot be null.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "SCREENING"
|
|
|
|
|
- "PROTECTION"
|
|
|
|
|
- "DEPOSIT_MANAGEMENT"
|
|
|
|
|
- "GUEST_AGREEMENT"
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- name: is_upgraded_service
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Whether the service is an upgraded version of the
|
|
|
|
|
default. In other words, if it's not Basic Screening.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "YES"
|
|
|
|
|
- "NO"
|
|
|
|
|
- name: new_dash_version
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
The version of the New Dash. It corresponds to the
|
|
|
|
|
release or migration phase from user point of view.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
2025-03-24 13:00:24 +01:00
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
|
|
|
|
data_tests:
|
2025-03-26 15:10:50 +01:00
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_daily_new_dash_deals_offered_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Daily Deals Offered Services.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is date, dimension and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The daily date acting as time range for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
2025-03-26 18:56:57 +01:00
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- deal_with_offered_service_count
|
|
|
|
|
where: "dimension in ('by_number_of_listings', 'by_billing_country', 'by_new_dash_version')"
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: deal_with_offered_service_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The daily count of deals with services offered for a given date, dimension and value.
|
|
|
|
|
|
2025-03-26 19:00:47 +01:00
|
|
|
- name: int_kpis__agg_weekly_new_dash_deals_offered_services
|
2025-03-26 18:56:57 +01:00
|
|
|
description: |
|
2025-03-26 19:00:47 +01:00
|
|
|
This model computes the dimension aggregation for Number of Deals with
|
|
|
|
|
Offered Services by the end of each week.
|
2025-03-26 18:56:57 +01:00
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
2025-03-26 19:00:47 +01:00
|
|
|
The primary key of this model is date, dimension and dimension_value.
|
2025-03-26 18:56:57 +01:00
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
2025-03-26 19:00:47 +01:00
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
2025-03-26 18:56:57 +01:00
|
|
|
|
|
|
|
|
columns:
|
2025-03-26 19:00:47 +01:00
|
|
|
- name: date
|
2025-03-26 18:56:57 +01:00
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the week.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
2025-03-26 19:00:47 +01:00
|
|
|
- name: dimension
|
2025-03-26 18:56:57 +01:00
|
|
|
data_type: string
|
2025-03-26 19:00:47 +01:00
|
|
|
description: The dimension or granularity of the metrics.
|
2025-03-26 18:56:57 +01:00
|
|
|
data_tests:
|
2025-03-26 19:00:47 +01:00
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- deal_with_offered_service_count
|
|
|
|
|
where: "dimension in ('by_number_of_listings', 'by_billing_country', 'by_new_dash_version')"
|
2025-03-26 18:56:57 +01:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
2025-03-26 19:00:47 +01:00
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
2025-03-26 18:56:57 +01:00
|
|
|
|
2025-03-26 19:00:47 +01:00
|
|
|
- name: dimension_value
|
2025-03-26 18:56:57 +01:00
|
|
|
data_type: string
|
2025-03-26 19:00:47 +01:00
|
|
|
description: The value or segment available for the selected dimension.
|
2025-03-26 18:56:57 +01:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: deal_with_offered_service_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2025-03-27 11:17:18 +01:00
|
|
|
The count of deals with services offered by the end of a given week, dimension and value.
|
2025-03-26 18:56:57 +01:00
|
|
|
|
2025-03-26 19:00:47 +01:00
|
|
|
- name: int_kpis__agg_monthly_new_dash_deals_offered_services
|
2025-03-26 18:56:57 +01:00
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Number of Deals with
|
2025-03-26 19:00:47 +01:00
|
|
|
Offered Services by the end of each month.
|
2025-03-26 18:56:57 +01:00
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is date, dimension and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
2025-03-26 19:00:47 +01:00
|
|
|
The end date of the month.
|
2025-03-26 18:56:57 +01:00
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
2025-03-26 15:10:50 +01:00
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- deal_with_offered_service_count
|
2025-03-26 15:42:26 +01:00
|
|
|
where: "dimension in ('by_number_of_listings', 'by_billing_country', 'by_new_dash_version')"
|
2025-03-26 15:10:50 +01:00
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: deal_with_offered_service_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2025-03-27 11:17:18 +01:00
|
|
|
The count of deals with services offered by the end of a given month, dimension and value.
|
2025-04-01 13:44:30 +00:00
|
|
|
|
2025-03-27 11:17:18 +01:00
|
|
|
- name: int_kpis__agg_daily_new_dash_accommodation_offered_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Daily Accommodation Offered Services.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is date, dimension and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The daily date acting as time range for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
2025-03-27 11:40:08 +01:00
|
|
|
- accommodation_with_offered_service_count
|
2025-03-27 11:17:18 +01:00
|
|
|
where: "dimension in ('by_number_of_listings', 'by_billing_country', 'by_new_dash_version', 'by_deal')"
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: accommodation_with_offered_service_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The daily count of accommodations with services offered for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_weekly_new_dash_accommodation_offered_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Number of Accommodation with
|
|
|
|
|
Offered Services by the end of each week.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is date, dimension and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the week.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
2025-03-27 11:40:08 +01:00
|
|
|
- accommodation_with_offered_service_count
|
2025-03-27 11:17:18 +01:00
|
|
|
where: "dimension in ('by_number_of_listings', 'by_billing_country', 'by_new_dash_version', 'by_deal')"
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: accommodation_with_offered_service_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The count of accommodations with services offered by the end of a given week, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_monthly_new_dash_accommodation_offered_services
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Number of Accommodation with
|
|
|
|
|
Offered Services by the end of each month.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is date, dimension and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the month.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
2025-03-27 11:40:08 +01:00
|
|
|
- accommodation_with_offered_service_count
|
2025-03-27 11:17:18 +01:00
|
|
|
where: "dimension in ('by_number_of_listings', 'by_billing_country', 'by_new_dash_version', 'by_deal')"
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: accommodation_with_offered_service_count
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
2025-04-01 13:44:30 +00:00
|
|
|
The count of accommodations with services offered by the end of a given month, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_total_and_retained_revenue
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Total Revenue and Revenue Retained metrics
|
|
|
|
|
at the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The logic behind this model is to combine the daily revenue and payouts
|
|
|
|
|
from different sources:
|
|
|
|
|
- Guest Revenue (from int_kpis__metric_daily_guest_payments)
|
|
|
|
|
- Invoiced Revenue and Payouts (from int_kpis__metric_daily_invoiced_revenue)
|
|
|
|
|
- Host Resolutions Payouts (from int_kpis__metric_daily_host_resolutions)
|
|
|
|
|
in order to compute Total Revenue, Retained Revenue and Retained Revenue Post-Resolutions.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
|
|
|
|
- id_deal,
|
|
|
|
|
- business_scope.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
|
|
|
|
- business_scope
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when the document was issued.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: total_revenue_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of Guest Revenue, Invoiced Operator Revenue and APIs Revenue,
|
|
|
|
|
in GBP, without taxes, in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: revenue_retained_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Total Revenue minus Waiver Payouts due to Host Takes Risk,
|
|
|
|
|
in GBP, without taxes, in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: revenue_retained_post_resolutions_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Revenue Retained minus Host Resolutions Payouts due to resolutions,
|
|
|
|
|
in GBP, without taxes, in a given date and per specified dimension.
|
2025-04-01 17:27:37 +02:00
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_total_and_retained_revenue
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Total Revenue, Retained
|
|
|
|
|
Revenue and Revenue Retained Post-Resolutions at the deepest
|
|
|
|
|
granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
|
|
|
|
- business_scope,
|
|
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
|
|
|
|
- business_scope
|
|
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: total_revenue_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of Guest Revenue, Invoiced Operator Revenue and APIs Revenue,
|
|
|
|
|
in GBP, without taxes, in a given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: revenue_retained_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Total Revenue minus Waiver Payouts due to Host Takes Risk,
|
|
|
|
|
in GBP, without taxes, in a given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: revenue_retained_post_resolutions_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Revenue Retained minus Host Resolutions Payouts due to resolutions,
|
|
|
|
|
in GBP, without taxes, in a given month and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_mtd_total_and_retained_revenue
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Month-To-Date Total Revenue, Retained
|
|
|
|
|
Revenue and Revenue Retained Post-Resolutions at the deepest
|
|
|
|
|
granularity.
|
|
|
|
|
Be aware that any dimension that can change over the monthly period,
|
|
|
|
|
such as daily segmentations, are included in the primary key of the
|
|
|
|
|
model.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
|
|
|
|
- business_scope,
|
|
|
|
|
- active_accommodations_per_deal_segmentation.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
|
|
|
|
- business_scope
|
|
|
|
|
- active_accommodations_per_deal_segmentation
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "Old Dash"
|
|
|
|
|
- "New Dash"
|
|
|
|
|
- "API"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: total_revenue_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Sum of Guest Revenue, Invoiced Operator Revenue and APIs Revenue,
|
|
|
|
|
in GBP, without taxes, in a given month to the current date
|
|
|
|
|
and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: revenue_retained_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Total Revenue minus Waiver Payouts due to Host Takes Risk,
|
|
|
|
|
in GBP, without taxes, in a given month to the current date
|
|
|
|
|
and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: revenue_retained_post_resolutions_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
Revenue Retained minus Host Resolutions Payouts due to resolutions,
|
|
|
|
|
in GBP, without taxes, in a given month to the current date
|
|
|
|
|
and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_monthly_total_and_retained_revenue
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Total Revenue, Retained Revenue and
|
|
|
|
|
Revenue Retained Post-Resolutions.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- total_revenue_in_gbp
|
|
|
|
|
- revenue_retained_in_gbp
|
|
|
|
|
- revenue_retained_post_resolutions_in_gbp
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_business_scope
|
|
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: total_revenue_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Total Revenue in GBP
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: revenue_retained_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Revenue Retained in GBP
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: revenue_retained_post_resolutions_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The monthly Revenue Retained Post-Resolutions in GBP
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_mtd_total_and_retained_revenue
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Month-To-Date Total Revenue, Retained Revenue and
|
|
|
|
|
Revenue Retained Post-Resolutions.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- total_revenue_in_gbp
|
|
|
|
|
- revenue_retained_in_gbp
|
|
|
|
|
- revenue_retained_post_resolutions_in_gbp
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_business_scope
|
|
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: total_revenue_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Total Revenue in GBP
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: revenue_retained_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Revenue Retained in GBP
|
|
|
|
|
for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: revenue_retained_post_resolutions_in_gbp
|
|
|
|
|
data_type: decimal
|
|
|
|
|
description: |
|
|
|
|
|
The month-to-date Revenue Retained Post-Resolutions in GBP
|
|
|
|
|
for a given date, dimension and value.
|
2025-04-02 12:07:39 +02:00
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_new_dash_created_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Created Bookings with Services at the deepest granularity.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
|
|
|
|
- id_booking,
|
|
|
|
|
- id_user_product_bundle,
|
|
|
|
|
- service_name,
|
|
|
|
|
- service_business_type
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_booking
|
|
|
|
|
- id_user_product_bundle
|
|
|
|
|
- service_name
|
|
|
|
|
- service_business_type
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when the Booking was created.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_booking
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of the Booking.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_user_product_bundle
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: Unique identifier of the User Product Bundle.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: service_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Name of the created service.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: is_upgraded_service
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Whether the service is an upgraded version of the
|
|
|
|
|
default. In other words, if it's not Basic Screening.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "YES"
|
|
|
|
|
- "NO"
|
|
|
|
|
|
|
|
|
|
- name: service_business_type
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Identifies the service type (Screening, Deposit Management, Protection
|
|
|
|
|
or Guest Agreement) according to New Pricing documentation.
|
|
|
|
|
Cannot be null.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "SCREENING"
|
|
|
|
|
- "PROTECTION"
|
|
|
|
|
- "DEPOSIT_MANAGEMENT"
|
|
|
|
|
- "GUEST_AGREEMENT"
|
|
|
|
|
- "UNKNOWN"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: new_dash_version
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
The version of the New Dash. It corresponds to the
|
|
|
|
|
release or migration phase from user point of view.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: active_accommodations_per_deal_segmentation
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Segment value based on the number of listings booked in 12 months
|
|
|
|
|
for a given deal and date.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "0"
|
|
|
|
|
- "01-05"
|
|
|
|
|
- "06-20"
|
|
|
|
|
- "21-60"
|
|
|
|
|
- "61+"
|
|
|
|
|
- "UNSET"
|
|
|
|
|
|
|
|
|
|
- name: main_billing_country_iso_3_per_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Main billing country of the host aggregated at Deal level.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_weekly_new_dash_created_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Weekly Created Bookings with Services.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is end_date, dimension and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- created_bookings
|
|
|
|
|
where: "dimension in ('by_number_of_listings', 'by_billing_country', 'by_new_dash_version', 'by_deal')"
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The weekly created bookings for a given date range, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_monthly_new_dash_created_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Monthly Created Bookings with Services.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is end_date, dimension and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- created_bookings
|
|
|
|
|
where: "dimension in ('by_number_of_listings', 'by_billing_country', 'by_new_dash_version', 'by_deal')"
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The monthly created bookings for a given date range, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_daily_new_dash_created_bookings
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for Daily Created Bookings with Services.
|
|
|
|
|
It only retrieves services that come from users that are in New Dash, as well
|
|
|
|
|
as it only considers services created after the user has moved to New Dash.
|
|
|
|
|
The primary key of this model is date, dimension and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The daily date acting as time range for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- created_bookings
|
|
|
|
|
where: "dimension in ('by_number_of_listings', 'by_billing_country', 'by_new_dash_version', 'by_deal')"
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
- by_deal
|
|
|
|
|
- by_new_dash_version
|
|
|
|
|
- by_has_upgraded_service
|
|
|
|
|
- by_service
|
|
|
|
|
- by_service_business_type
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: created_bookings
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The daily created bookings for a given date, dimension and value.
|
|
|
|
|
|
2025-04-04 14:02:32 +00:00
|
|
|
- name: int_kpis__agg_monthly_churn_contribution
|
|
|
|
|
description: |
|
|
|
|
|
This model calculates monthly churn contributions by dimension, dimension_value,
|
|
|
|
|
and date. Unlike typical KPI models, it relies exclusively on monthly metrics
|
|
|
|
|
computed at deal level and does not include data for the current month.
|
|
|
|
|
|
|
|
|
|
At its core, the model computes each deal's 12-month rolling contribution to global
|
|
|
|
|
metrics. Afterwards, it aggregates these contributions for deals classified as
|
|
|
|
|
'05-Churning' within the month. The output includes three churn-related contribution
|
|
|
|
|
metrics, expressed as ratios over global totals:
|
|
|
|
|
- total_revenue_churn_average_contribution
|
|
|
|
|
- created_bookings_churn_average_contribution
|
|
|
|
|
- listings_booked_in_month_churn_average_contribution
|
|
|
|
|
Besides these 3 metrics, the actual total revenue churned in the month and the global
|
|
|
|
|
total revenue windows are also included in the output. This is later used for YTD/MTD
|
|
|
|
|
dedicated models, which only require it for Total Revenue.
|
|
|
|
|
|
|
|
|
|
These are calculated using an average contribution approach over the prior 12 months.
|
|
|
|
|
If a deal has not been active for the full 12-month period, the average is still
|
|
|
|
|
computed based on the number of months the deal has been active within that window.
|
|
|
|
|
|
|
|
|
|
Note: When analysing dimensions other than 'global', the metrics represent the additive
|
|
|
|
|
share of churn relative to the global total. For example, if the total churn rate in a
|
|
|
|
|
month is 10%, it may be broken down as 9% from the USA and 1% from GBR — still totaling 10%.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: The date for the month-to-date metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: total_revenue_churn_preceding_12_months
|
|
|
|
|
data_type: numeric
|
|
|
|
|
description: |
|
|
|
|
|
Total Revenue attributed to have churned considering the
|
|
|
|
|
revenue generated by the deals in the 12 months period.
|
|
|
|
|
|
|
|
|
|
- name: total_revenue_global_preceding_12_months
|
|
|
|
|
data_type: numeric
|
|
|
|
|
description: |
|
|
|
|
|
Total Revenue generated by all deals in the 12 months period.
|
|
|
|
|
|
|
|
|
|
- name: total_revenue_churn_average_contribution
|
|
|
|
|
data_type: numeric
|
|
|
|
|
description: Total Revenue churn rate (average approach).
|
|
|
|
|
|
|
|
|
|
- name: created_bookings_churn_average_contribution
|
|
|
|
|
data_type: numeric
|
|
|
|
|
description: Created Bookings churn rate (average approach).
|
|
|
|
|
|
|
|
|
|
- name: listings_booked_in_month_churn_average_contribution
|
|
|
|
|
data_type: numeric
|
|
|
|
|
description: Listings Booked in Month churn rate (average approach).
|
Merged PR 4935: KPIs Refactor Stage 4 - Onboarding MRR model in KPIs
# Description
Creates a single model in KPIs, aggregated by dimension/dimension value, in a monthly basis; named: `int_kpis__agg_monthly_onboarding_mrr`.
Attention! This substitutes both current models, namely `int_monthly_onboarding_mrr_per_deal` and `int_mtd_agg_onboarding_mrr_revenue`. However, both models are currently used to retrieve data for Main KPIs. I just combined both into one, so it will simplify also the gathering of data later on.
Note that this model is special in the sense that the onboarding mrr per deal is computed for global, listing segmentation and billing country dimensions; while the total onboarding mrr is only done for global and listing segmentation (as it's based on the number of listings segmentation for the total compute).
This has been tested with dbt audit helper and md5. This has been a bit more complex since it's comparing 1 new model vs 2 existing models. For reference, this is the md5 comparison used:
```
SELECT md5(array_agg(md5((t1.*)::varchar))::varchar)
FROM (
SELECT
mrr.date,
mrr.dimension,
mrr.dimension_value,
mrr.expected_mrr_per_deal,
total.number_of_new_deals,
total.expected_mrr as total_expected_mrr
FROM intermediate.int_monthly_onboarding_mrr_per_deal mrr
left join intermediate.int_mtd_agg_onboarding_mrr_revenue total
on mrr.date = total.date
and mrr.dimension = total.dimension
and mrr.dimension_value = total.dimension_value
ORDER BY date, dimension, dimension_value
) AS t1
union all
SELECT md5(array_agg(md5((t2.*)::varchar))::varchar)
FROM (
SELECT *
FROM intermediate.int_kpis__agg_monthly_onboarding_mrr
ORDER BY date, dimension, dimension_value
) AS t2
```
# 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: #27120, #28949
2025-04-07 12:27:28 +00:00
|
|
|
|
|
|
|
|
- name: int_kpis__agg_monthly_onboarding_mrr
|
|
|
|
|
description: |
|
|
|
|
|
This model contains the monthly aggregated metrics for onboarding MRR.
|
|
|
|
|
|
|
|
|
|
These metrics refer to the expectation of how much revenue is expected to
|
|
|
|
|
be generated from new deals, in average, in a monthly basis. This is a
|
|
|
|
|
projected value. Since Revenue is not a timely figure, the onboarding MRR
|
|
|
|
|
is shifted by one month. Keep in mind that the number of new deals are
|
|
|
|
|
the actual new deals onboarded in the month.
|
|
|
|
|
|
|
|
|
|
The metrics computed for this model are as follows:
|
|
|
|
|
- onboarding_mrr_per_new_deal_in_gbp: How much revenue in a month is expected
|
|
|
|
|
to be generated by a new deal?
|
|
|
|
|
- total_onboarding_mrr_in_gbp: How much revenue in a month is expected to be
|
|
|
|
|
generated by ALL new deals onboarded on that same month?
|
|
|
|
|
|
|
|
|
|
Additionally, it also contains "new_deals_count" for information purposes.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: The date for the monthly metrics, corresponding to the EOM.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_number_of_listings
|
|
|
|
|
- by_billing_country
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: new_deals_count
|
|
|
|
|
data_type: numeric
|
|
|
|
|
description: Number of new deals in the month, for information purposes.
|
|
|
|
|
|
|
|
|
|
- name: onboarding_mrr_per_new_deal_in_gbp
|
|
|
|
|
data_type: numeric
|
|
|
|
|
description: |
|
|
|
|
|
Expected onboarding MRR per new deal in GBP.
|
|
|
|
|
This is computed by:
|
|
|
|
|
- Gathering all live deals that have a hubspot listing segmentation available.
|
|
|
|
|
- Retrieving the total revenue of these deals in a given month.
|
|
|
|
|
- Dividing the total revenue by the number of live deals.
|
|
|
|
|
This is assumed to be the expected onboarding MRR per each new deal.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: total_onboarding_mrr_in_gbp
|
|
|
|
|
data_type: numeric
|
|
|
|
|
description: |
|
|
|
|
|
Total expected Onboarding MRR in GBP per date, dimension and dimension value.
|
|
|
|
|
This is computed by:
|
|
|
|
|
- Gathering the expected onboarding MRR per new deal for the dimension 'by_number_of_listings'
|
|
|
|
|
- Gathering the number of new deals for the dimension 'by_number_of_listings'
|
|
|
|
|
- Multiplying the two values, to get the total onboarding MRR for each listing segment
|
|
|
|
|
- Rolling up the total onboarding MRR for each listing segment to get the total onboarding MRR
|
|
|
|
|
for the Global dimension.
|
|
|
|
|
This is not available for 'by_billing_country' dimension, thus null values are expected.
|
2025-04-24 15:01:04 +00:00
|
|
|
|
|
|
|
|
- name: int_kpis__metric_daily_api_billable_verifications
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Daily Billable Verifications from APIs at
|
|
|
|
|
the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- date,
|
|
|
|
|
- id_deal,
|
|
|
|
|
- service_name.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- id_deal
|
|
|
|
|
- service_name
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: Date of when Verifications have been billable.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "API"
|
|
|
|
|
|
|
|
|
|
- name: service_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Name of the API service that has been billable.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "ATHENA"
|
|
|
|
|
- "E-DEPOSIT"
|
|
|
|
|
- "CHECK_IN_HERO"
|
|
|
|
|
- "SCREEN_AND_PROTECT"
|
|
|
|
|
|
|
|
|
|
- name: billable_verifications
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of daily verifications billable in a given date and per specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_daily_api_billable_verifications
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Daily Billable Verifications, from APIs.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start and end date of the time range considered for
|
|
|
|
|
the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- billable_verifications
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_service
|
|
|
|
|
- by_business_scope
|
|
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: billable_verifications
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: The daily billable verifications for a given date, dimension and value.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__metric_monthly_api_billable_verifications
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the Monthly Billable Verifications from APIs at
|
|
|
|
|
the deepest granularity.
|
|
|
|
|
|
|
|
|
|
The unique key corresponds to the deepest granularity of the model,
|
|
|
|
|
in this case:
|
|
|
|
|
- end_date,
|
|
|
|
|
- id_deal,
|
|
|
|
|
- service_name.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- id_deal
|
|
|
|
|
- service_name
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: id_deal
|
|
|
|
|
data_type: string
|
|
|
|
|
description: Unique identifier of an account.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: business_scope
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Business scope identifying the metric source.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "API"
|
|
|
|
|
|
|
|
|
|
- name: service_name
|
|
|
|
|
data_type: string
|
|
|
|
|
description: |
|
|
|
|
|
Name of the API service that has been billable.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- "ATHENA"
|
|
|
|
|
- "E-DEPOSIT"
|
|
|
|
|
- "CHECK_IN_HERO"
|
|
|
|
|
- "SCREEN_AND_PROTECT"
|
|
|
|
|
|
|
|
|
|
- name: billable_verifications
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
Count of monthly verifications billable in a given month and per
|
|
|
|
|
specified dimension.
|
|
|
|
|
|
|
|
|
|
- name: int_kpis__agg_monthly_api_billable_verifications
|
|
|
|
|
description: |
|
|
|
|
|
This model computes the dimension aggregation for
|
|
|
|
|
Monthly Billable Verifications, from APIs.
|
|
|
|
|
|
|
|
|
|
The primary key of this model is end_date, dimension
|
|
|
|
|
and dimension_value.
|
|
|
|
|
|
|
|
|
|
data_tests:
|
|
|
|
|
- dbt_utils.unique_combination_of_columns:
|
|
|
|
|
combination_of_columns:
|
|
|
|
|
- end_date
|
|
|
|
|
- dimension
|
|
|
|
|
- dimension_value
|
|
|
|
|
|
|
|
|
|
columns:
|
|
|
|
|
- name: start_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The start date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: end_date
|
|
|
|
|
data_type: date
|
|
|
|
|
description: |
|
|
|
|
|
The end date of the time range considered for the metrics in this record.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: dimension
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The dimension or granularity of the metrics.
|
|
|
|
|
data_tests:
|
|
|
|
|
- assert_dimension_completeness:
|
|
|
|
|
metric_column_names:
|
|
|
|
|
- billable_verifications
|
|
|
|
|
- accepted_values:
|
|
|
|
|
values:
|
|
|
|
|
- global
|
|
|
|
|
- by_service
|
|
|
|
|
- by_business_scope
|
|
|
|
|
- by_deal
|
|
|
|
|
|
|
|
|
|
- name: dimension_value
|
|
|
|
|
data_type: string
|
|
|
|
|
description: The value or segment available for the selected dimension.
|
|
|
|
|
data_tests:
|
|
|
|
|
- not_null
|
|
|
|
|
|
|
|
|
|
- name: billable_verifications
|
|
|
|
|
data_type: bigint
|
|
|
|
|
description: |
|
|
|
|
|
The monthly billable verifications for a given date, dimension and value.
|