data-dwh-dbt-project/models/intermediate/kpis/schema.yml

9136 lines
292 KiB
YAML
Raw Normal View History

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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: |
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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: |
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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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
- 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:
- not_null
- 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:
- 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:
- 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:
- 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
- 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:
- not_null
- name: year
data_type: int
description: Year number of the given date.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: month
data_type: int
description: Month number of the given date.
2025-01-13 16:00:35 +01:00
data_tests:
- 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:
- 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:
- 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:
- 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:
- 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:
- not_null
- 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:
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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.
- 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.
- 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.
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:
- 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:
- 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:
- 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:
- 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
- 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: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image%20%282%29.png) I decided to take a quick look into the main players... and surprise surprise we have Guesty: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image.png) 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: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image%20%282%29.png) I decided to take a quick look into the main players... and surprise surprise we have Guesty: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image.png) 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: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image%20%282%29.png) I decided to take a quick look into the main players... and surprise surprise we have Guesty: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image.png) 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
data_type: boolean
description: |
Does the deal have an active associated PMS.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
2025-01-09 16:31:22 +01:00
- name: active_pms_list
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.
- 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: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image%20%282%29.png) I decided to take a quick look into the main players... and surprise surprise we have Guesty: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image.png) 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: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image%20%282%29.png) I decided to take a quick look into the main players... and surprise surprise we have Guesty: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image.png) 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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,
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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
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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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"
- "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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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.
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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,
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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
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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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"
- "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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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 accumulated bookings created in a given month
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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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,
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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
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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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"
- "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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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.
- 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.
Merged PR 5044: Switch Projected Created Bookings to Billable Bookings # Description Switches Created Bookings to Billable Bookings in the scope of Projected Bookings. I opted for hard switching (thus removing Projected Created Bookings) altogether to avoid having unused models in production. This aims to set the ground to include, in the future, APIs Billable Bookings. Impact in KPIs: * `int_kpis__agg_daily_created_bookings` now is `int_kpis__agg_daily_billable_bookings`. Aside from the name change, it's reduced to 4 metrics to just one. Schema changes also apply. Impact in Projected KPIs: * `int_kpis_projected__agg_daily_created_bookings` now is `int_kpis_projected__agg_daily_billable_bookings`. Fields are also renamed accordingly. * `int_kpis_projected__agg_monthly_created_bookings` now is `int_kpis_projected__agg_monthly_billable_bookings`. Fields are also renamed accordingly. * Schema file is also updated accordingly. Impact on new model for Growth Score: * `int_created_bookings_growth_score_by_deal` now is `int_billable_bookings_growth_score_by_deal`. Fields are also renamed accordingly. * Schema is also updated accordingly. Note that since the end model `int_billable_bookings_growth_score_by_deal` is not used at the moment in reporting, there's no user-facing impact. Also, the rest of modified models are not used for other purposes. # 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: #29374
2025-04-24 12:42:21 +00:00
- name: int_kpis__agg_daily_billable_bookings
Merged PR 4665: Projected Bookings to the end of the current month # Description Computes projected Bookings to the end of the current month per dimension and dimension value KPIs changes: * Adds a int_kpis__agg_daily_created_bookings model. This is a standard KPIs model that computes created bookings at a daily level per dimension and dimension value. Projected KPIs (NEW): * Adds a new folder named projected within KPIs. This includes a simple Readme. * Adds a default dimension dates model that ranges from the past 3 complete months to the end of the current month, that is in the future. * Adds 2 projected models for created bookings: The daily one, that handles the logic of the projection (same month + last 7 days) and the monthly one, that retrieves the end of month projected value as well as some indicators of how good or bad this was for previous months. How good is the projection at 11th of March (so 10 days in the month)? `select * from intermediate.int_kpis_projected__agg_monthly_created_bookings order by actual_created_bookings desc` ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/4665/attachments/image.png) # 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: #28251
2025-03-11 14:34:30 +00:00
description: |
This model computes the dimension aggregation for
Merged PR 5044: Switch Projected Created Bookings to Billable Bookings # Description Switches Created Bookings to Billable Bookings in the scope of Projected Bookings. I opted for hard switching (thus removing Projected Created Bookings) altogether to avoid having unused models in production. This aims to set the ground to include, in the future, APIs Billable Bookings. Impact in KPIs: * `int_kpis__agg_daily_created_bookings` now is `int_kpis__agg_daily_billable_bookings`. Aside from the name change, it's reduced to 4 metrics to just one. Schema changes also apply. Impact in Projected KPIs: * `int_kpis_projected__agg_daily_created_bookings` now is `int_kpis_projected__agg_daily_billable_bookings`. Fields are also renamed accordingly. * `int_kpis_projected__agg_monthly_created_bookings` now is `int_kpis_projected__agg_monthly_billable_bookings`. Fields are also renamed accordingly. * Schema file is also updated accordingly. Impact on new model for Growth Score: * `int_created_bookings_growth_score_by_deal` now is `int_billable_bookings_growth_score_by_deal`. Fields are also renamed accordingly. * Schema is also updated accordingly. Note that since the end model `int_billable_bookings_growth_score_by_deal` is not used at the moment in reporting, there's no user-facing impact. Also, the rest of modified models are not used for other purposes. # 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: #29374
2025-04-24 12:42:21 +00:00
Daily Billable Bookings.
Merged PR 4665: Projected Bookings to the end of the current month # Description Computes projected Bookings to the end of the current month per dimension and dimension value KPIs changes: * Adds a int_kpis__agg_daily_created_bookings model. This is a standard KPIs model that computes created bookings at a daily level per dimension and dimension value. Projected KPIs (NEW): * Adds a new folder named projected within KPIs. This includes a simple Readme. * Adds a default dimension dates model that ranges from the past 3 complete months to the end of the current month, that is in the future. * Adds 2 projected models for created bookings: The daily one, that handles the logic of the projection (same month + last 7 days) and the monthly one, that retrieves the end of month projected value as well as some indicators of how good or bad this was for previous months. How good is the projection at 11th of March (so 10 days in the month)? `select * from intermediate.int_kpis_projected__agg_monthly_created_bookings order by actual_created_bookings desc` ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/4665/attachments/image.png) # 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: #28251
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:
Merged PR 5044: Switch Projected Created Bookings to Billable Bookings # Description Switches Created Bookings to Billable Bookings in the scope of Projected Bookings. I opted for hard switching (thus removing Projected Created Bookings) altogether to avoid having unused models in production. This aims to set the ground to include, in the future, APIs Billable Bookings. Impact in KPIs: * `int_kpis__agg_daily_created_bookings` now is `int_kpis__agg_daily_billable_bookings`. Aside from the name change, it's reduced to 4 metrics to just one. Schema changes also apply. Impact in Projected KPIs: * `int_kpis_projected__agg_daily_created_bookings` now is `int_kpis_projected__agg_daily_billable_bookings`. Fields are also renamed accordingly. * `int_kpis_projected__agg_monthly_created_bookings` now is `int_kpis_projected__agg_monthly_billable_bookings`. Fields are also renamed accordingly. * Schema file is also updated accordingly. Impact on new model for Growth Score: * `int_created_bookings_growth_score_by_deal` now is `int_billable_bookings_growth_score_by_deal`. Fields are also renamed accordingly. * Schema is also updated accordingly. Note that since the end model `int_billable_bookings_growth_score_by_deal` is not used at the moment in reporting, there's no user-facing impact. Also, the rest of modified models are not used for other purposes. # 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: #29374
2025-04-24 12:42:21 +00:00
- billable_bookings
Merged PR 4665: Projected Bookings to the end of the current month # Description Computes projected Bookings to the end of the current month per dimension and dimension value KPIs changes: * Adds a int_kpis__agg_daily_created_bookings model. This is a standard KPIs model that computes created bookings at a daily level per dimension and dimension value. Projected KPIs (NEW): * Adds a new folder named projected within KPIs. This includes a simple Readme. * Adds a default dimension dates model that ranges from the past 3 complete months to the end of the current month, that is in the future. * Adds 2 projected models for created bookings: The daily one, that handles the logic of the projection (same month + last 7 days) and the monthly one, that retrieves the end of month projected value as well as some indicators of how good or bad this was for previous months. How good is the projection at 11th of March (so 10 days in the month)? `select * from intermediate.int_kpis_projected__agg_monthly_created_bookings order by actual_created_bookings desc` ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/4665/attachments/image.png) # 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: #28251
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
Merged PR 5044: Switch Projected Created Bookings to Billable Bookings # Description Switches Created Bookings to Billable Bookings in the scope of Projected Bookings. I opted for hard switching (thus removing Projected Created Bookings) altogether to avoid having unused models in production. This aims to set the ground to include, in the future, APIs Billable Bookings. Impact in KPIs: * `int_kpis__agg_daily_created_bookings` now is `int_kpis__agg_daily_billable_bookings`. Aside from the name change, it's reduced to 4 metrics to just one. Schema changes also apply. Impact in Projected KPIs: * `int_kpis_projected__agg_daily_created_bookings` now is `int_kpis_projected__agg_daily_billable_bookings`. Fields are also renamed accordingly. * `int_kpis_projected__agg_monthly_created_bookings` now is `int_kpis_projected__agg_monthly_billable_bookings`. Fields are also renamed accordingly. * Schema file is also updated accordingly. Impact on new model for Growth Score: * `int_created_bookings_growth_score_by_deal` now is `int_billable_bookings_growth_score_by_deal`. Fields are also renamed accordingly. * Schema is also updated accordingly. Note that since the end model `int_billable_bookings_growth_score_by_deal` is not used at the moment in reporting, there's no user-facing impact. Also, the rest of modified models are not used for other purposes. # 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: #29374
2025-04-24 12:42:21 +00:00
- name: billable_bookings
Merged PR 4665: Projected Bookings to the end of the current month # Description Computes projected Bookings to the end of the current month per dimension and dimension value KPIs changes: * Adds a int_kpis__agg_daily_created_bookings model. This is a standard KPIs model that computes created bookings at a daily level per dimension and dimension value. Projected KPIs (NEW): * Adds a new folder named projected within KPIs. This includes a simple Readme. * Adds a default dimension dates model that ranges from the past 3 complete months to the end of the current month, that is in the future. * Adds 2 projected models for created bookings: The daily one, that handles the logic of the projection (same month + last 7 days) and the monthly one, that retrieves the end of month projected value as well as some indicators of how good or bad this was for previous months. How good is the projection at 11th of March (so 10 days in the month)? `select * from intermediate.int_kpis_projected__agg_monthly_created_bookings order by actual_created_bookings desc` ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/4665/attachments/image.png) # 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: #28251
2025-03-11 14:34:30 +00:00
data_type: bigint
Merged PR 5044: Switch Projected Created Bookings to Billable Bookings # Description Switches Created Bookings to Billable Bookings in the scope of Projected Bookings. I opted for hard switching (thus removing Projected Created Bookings) altogether to avoid having unused models in production. This aims to set the ground to include, in the future, APIs Billable Bookings. Impact in KPIs: * `int_kpis__agg_daily_created_bookings` now is `int_kpis__agg_daily_billable_bookings`. Aside from the name change, it's reduced to 4 metrics to just one. Schema changes also apply. Impact in Projected KPIs: * `int_kpis_projected__agg_daily_created_bookings` now is `int_kpis_projected__agg_daily_billable_bookings`. Fields are also renamed accordingly. * `int_kpis_projected__agg_monthly_created_bookings` now is `int_kpis_projected__agg_monthly_billable_bookings`. Fields are also renamed accordingly. * Schema file is also updated accordingly. Impact on new model for Growth Score: * `int_created_bookings_growth_score_by_deal` now is `int_billable_bookings_growth_score_by_deal`. Fields are also renamed accordingly. * Schema is also updated accordingly. Note that since the end model `int_billable_bookings_growth_score_by_deal` is not used at the moment in reporting, there's no user-facing impact. Also, the rest of modified models are not used for other purposes. # 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: #29374
2025-04-24 12:42:21 +00:00
description: The daily billable bookings for a given date, dimension and value.
Merged PR 4665: Projected Bookings to the end of the current month # Description Computes projected Bookings to the end of the current month per dimension and dimension value KPIs changes: * Adds a int_kpis__agg_daily_created_bookings model. This is a standard KPIs model that computes created bookings at a daily level per dimension and dimension value. Projected KPIs (NEW): * Adds a new folder named projected within KPIs. This includes a simple Readme. * Adds a default dimension dates model that ranges from the past 3 complete months to the end of the current month, that is in the future. * Adds 2 projected models for created bookings: The daily one, that handles the logic of the projection (same month + last 7 days) and the monthly one, that retrieves the end of month projected value as well as some indicators of how good or bad this was for previous months. How good is the projection at 11th of March (so 10 days in the month)? `select * from intermediate.int_kpis_projected__agg_monthly_created_bookings order by actual_created_bookings desc` ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/4665/attachments/image.png) # 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: #28251
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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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:
- created_bookings
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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:
- created_bookings
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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
- 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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: ![image (5).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3329/attachments/image%20%285%29.png) # 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.
- 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.
- 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,
- id_deal,
- business_scope
2025-01-13 16:00:35 +01:00
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 Guest Journeys have been created.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: created_guest_journeys
data_type: bigint
description: |
Count of accumulated guest journeys created in a given month
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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: created_guest_journeys
data_type: bigint
description: |
Count of accumulated guest journeys created 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_created_guest_journeys
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- created_guest_journeys
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: created_guest_journeys
data_type: bigint
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
2024-11-20 09:43:30 +00:00
description: The monthly created guest journeys for a given date, dimension and value.
2024-11-05 12:17:26 +01:00
- name: int_kpis__agg_mtd_created_guest_journeys
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- created_guest_journeys
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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,
- id_deal,
- business_scope
2025-01-13 16:00:35 +01:00
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 Guest Journeys have been started.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: started_guest_journeys
data_type: bigint
description: |
Count of accumulated guest journeys started in a given month
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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: started_guest_journeys
data_type: bigint
description: |
Count of accumulated guest journeys started 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_started_guest_journeys
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- started_guest_journeys
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- started_guest_journeys
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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,
- id_deal,
- business_scope.
2025-01-13 16:00:35 +01:00
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 Guest Journeys have been completed.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: completed_guest_journeys
data_type: bigint
description: |
Count of accumulated guest journeys completed in a given month
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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: completed_guest_journeys
data_type: bigint
description: |
Count of accumulated guest journeys completed 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_completed_guest_journeys
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- completed_guest_journeys
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- completed_guest_journeys
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: completed_guest_journeys
data_type: bigint
description: The month-to-date completed guest journeys for a given date, dimension and value.
- 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,
- id_deal,
- business_scope
2025-01-13 16:00:35 +01:00
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 Guest Journeys have been completed.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: guest_journeys_with_payment
data_type: bigint
description: |
Count of accumulated guest journeys completed in a given month
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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: guest_journeys_with_payment
data_type: bigint
description: |
Count of accumulated guest journeys completed 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_guest_journeys_with_payment
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- guest_journeys_with_payment
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- guest_journeys_with_payment
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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.
- 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,
- id_deal,
- has_id_check,
- business_scope
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- id_deal
- has_id_check
- business_scope
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:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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"
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:
- 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:
- 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.
Merged PR 5285: Adds Stay Disrupt (Confident Stay) Fees in KPIs Guest Payments flow # Description Propagates Stay Disrupt Guest Product in KPIs flow, within Guest Payments. This is done by: * Adding a new measure on `stay_disrupt_fees_in_gbp` in the daily model `int_kpis__metric_daily_guest_payments` * Adding stay_disrupt_fees_in_gbp in the `total_guest_payments_in_gbp` measure in the daily model `int_kpis__metric_daily_guest_payments` Afterwards this gets propagated downstream. No changes in the `total_guest_payments_in_gbp` measure in following models. However, a new measure for `stay_disrupt_fees_in_gbp` is created in the 4 Guest Payments related models of: * `int_kpis__metric_monthly_guest_payments` * `int_kpis__agg_monthly_guest_payments` * `int_kpis__metric_mtd_guest_payments` * `int_kpis__agg_mtd_guest_payments` Note that this also affects the schema entry of KPIs for both description and completion tests, in the case of aggregation models. Considering the almost non-existent usage of Guest KPIs report, I will not bother propagating Confident Stay in Product Guest KPIs, nor the report itself: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/5285/attachments/image.png) However, total Guest Revenue would include Confident Stay in Guest KPIs as well. Next steps, in a separated PR: * Propagation of new measure `stay_disrupt_fees_in_gbp` so it's available in Main KPIs. # 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: #30278
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.
- 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,
- business_scope,
2024-11-07 08:45:17 +01:00
- has_id_check,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- end_date
- id_deal
- business_scope
2024-11-07 08:45:17 +01:00
- has_id_check
- 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:
- 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:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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"
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:
- 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:
- 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.
Merged PR 5285: Adds Stay Disrupt (Confident Stay) Fees in KPIs Guest Payments flow # Description Propagates Stay Disrupt Guest Product in KPIs flow, within Guest Payments. This is done by: * Adding a new measure on `stay_disrupt_fees_in_gbp` in the daily model `int_kpis__metric_daily_guest_payments` * Adding stay_disrupt_fees_in_gbp in the `total_guest_payments_in_gbp` measure in the daily model `int_kpis__metric_daily_guest_payments` Afterwards this gets propagated downstream. No changes in the `total_guest_payments_in_gbp` measure in following models. However, a new measure for `stay_disrupt_fees_in_gbp` is created in the 4 Guest Payments related models of: * `int_kpis__metric_monthly_guest_payments` * `int_kpis__agg_monthly_guest_payments` * `int_kpis__metric_mtd_guest_payments` * `int_kpis__agg_mtd_guest_payments` Note that this also affects the schema entry of KPIs for both description and completion tests, in the case of aggregation models. Considering the almost non-existent usage of Guest KPIs report, I will not bother propagating Confident Stay in Product Guest KPIs, nor the report itself: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/5285/attachments/image.png) However, total Guest Revenue would include Confident Stay in Guest KPIs as well. Next steps, in a separated PR: * Propagation of new measure `stay_disrupt_fees_in_gbp` so it's available in Main KPIs. # 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: #30278
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.
- 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,
- business_scope,
2024-11-07 08:45:17 +01:00
- has_id_check,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- end_date
- id_deal
- business_scope
2024-11-07 08:45:17 +01:00
- has_id_check
- 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:
- 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:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: business_scope
data_type: string
description: |
Business scope identifying the metric source.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- accepted_values:
values:
- "Old Dash"
- "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,
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,
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,
in GBP in a given month up to the given date and per specified dimension.
2024-11-07 08:45:17 +01:00
Merged PR 5285: Adds Stay Disrupt (Confident Stay) Fees in KPIs Guest Payments flow # Description Propagates Stay Disrupt Guest Product in KPIs flow, within Guest Payments. This is done by: * Adding a new measure on `stay_disrupt_fees_in_gbp` in the daily model `int_kpis__metric_daily_guest_payments` * Adding stay_disrupt_fees_in_gbp in the `total_guest_payments_in_gbp` measure in the daily model `int_kpis__metric_daily_guest_payments` Afterwards this gets propagated downstream. No changes in the `total_guest_payments_in_gbp` measure in following models. However, a new measure for `stay_disrupt_fees_in_gbp` is created in the 4 Guest Payments related models of: * `int_kpis__metric_monthly_guest_payments` * `int_kpis__agg_monthly_guest_payments` * `int_kpis__metric_mtd_guest_payments` * `int_kpis__agg_mtd_guest_payments` Note that this also affects the schema entry of KPIs for both description and completion tests, in the case of aggregation models. Considering the almost non-existent usage of Guest KPIs report, I will not bother propagating Confident Stay in Product Guest KPIs, nor the report itself: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/5285/attachments/image.png) However, total Guest Revenue would include Confident Stay in Guest KPIs as well. Next steps, in a separated PR: * Propagation of new measure `stay_disrupt_fees_in_gbp` so it's available in Main KPIs. # 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: #30278
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,
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
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- deposit_fees_in_gbp
- waiver_payments_in_gbp
- checkin_cover_fees_in_gbp
Merged PR 5285: Adds Stay Disrupt (Confident Stay) Fees in KPIs Guest Payments flow # Description Propagates Stay Disrupt Guest Product in KPIs flow, within Guest Payments. This is done by: * Adding a new measure on `stay_disrupt_fees_in_gbp` in the daily model `int_kpis__metric_daily_guest_payments` * Adding stay_disrupt_fees_in_gbp in the `total_guest_payments_in_gbp` measure in the daily model `int_kpis__metric_daily_guest_payments` Afterwards this gets propagated downstream. No changes in the `total_guest_payments_in_gbp` measure in following models. However, a new measure for `stay_disrupt_fees_in_gbp` is created in the 4 Guest Payments related models of: * `int_kpis__metric_monthly_guest_payments` * `int_kpis__agg_monthly_guest_payments` * `int_kpis__metric_mtd_guest_payments` * `int_kpis__agg_mtd_guest_payments` Note that this also affects the schema entry of KPIs for both description and completion tests, in the case of aggregation models. Considering the almost non-existent usage of Guest KPIs report, I will not bother propagating Confident Stay in Product Guest KPIs, nor the report itself: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/5285/attachments/image.png) However, total Guest Revenue would include Confident Stay in Guest KPIs as well. Next steps, in a separated PR: * Propagation of new measure `stay_disrupt_fees_in_gbp` so it's available in Main KPIs. # 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: #30278
2025-05-23 10:33:26 +00:00
- stay_disrupt_fees_in_gbp
- total_guest_payments_in_gbp
- accepted_values:
values:
- global
- by_number_of_listings
- by_billing_country
- by_business_scope
- by_deal
2024-11-07 12:09:20 +01:00
- by_has_id_check
- 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:
- 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.
Merged PR 5285: Adds Stay Disrupt (Confident Stay) Fees in KPIs Guest Payments flow # Description Propagates Stay Disrupt Guest Product in KPIs flow, within Guest Payments. This is done by: * Adding a new measure on `stay_disrupt_fees_in_gbp` in the daily model `int_kpis__metric_daily_guest_payments` * Adding stay_disrupt_fees_in_gbp in the `total_guest_payments_in_gbp` measure in the daily model `int_kpis__metric_daily_guest_payments` Afterwards this gets propagated downstream. No changes in the `total_guest_payments_in_gbp` measure in following models. However, a new measure for `stay_disrupt_fees_in_gbp` is created in the 4 Guest Payments related models of: * `int_kpis__metric_monthly_guest_payments` * `int_kpis__agg_monthly_guest_payments` * `int_kpis__metric_mtd_guest_payments` * `int_kpis__agg_mtd_guest_payments` Note that this also affects the schema entry of KPIs for both description and completion tests, in the case of aggregation models. Considering the almost non-existent usage of Guest KPIs report, I will not bother propagating Confident Stay in Product Guest KPIs, nor the report itself: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/5285/attachments/image.png) However, total Guest Revenue would include Confident Stay in Guest KPIs as well. Next steps, in a separated PR: * Propagation of new measure `stay_disrupt_fees_in_gbp` so it's available in Main KPIs. # 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: #30278
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.
- 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
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- deposit_fees_in_gbp
- waiver_payments_in_gbp
- checkin_cover_fees_in_gbp
Merged PR 5285: Adds Stay Disrupt (Confident Stay) Fees in KPIs Guest Payments flow # Description Propagates Stay Disrupt Guest Product in KPIs flow, within Guest Payments. This is done by: * Adding a new measure on `stay_disrupt_fees_in_gbp` in the daily model `int_kpis__metric_daily_guest_payments` * Adding stay_disrupt_fees_in_gbp in the `total_guest_payments_in_gbp` measure in the daily model `int_kpis__metric_daily_guest_payments` Afterwards this gets propagated downstream. No changes in the `total_guest_payments_in_gbp` measure in following models. However, a new measure for `stay_disrupt_fees_in_gbp` is created in the 4 Guest Payments related models of: * `int_kpis__metric_monthly_guest_payments` * `int_kpis__agg_monthly_guest_payments` * `int_kpis__metric_mtd_guest_payments` * `int_kpis__agg_mtd_guest_payments` Note that this also affects the schema entry of KPIs for both description and completion tests, in the case of aggregation models. Considering the almost non-existent usage of Guest KPIs report, I will not bother propagating Confident Stay in Product Guest KPIs, nor the report itself: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/5285/attachments/image.png) However, total Guest Revenue would include Confident Stay in Guest KPIs as well. Next steps, in a separated PR: * Propagation of new measure `stay_disrupt_fees_in_gbp` so it's available in Main KPIs. # 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: #30278
2025-05-23 10:33:26 +00:00
- stay_disrupt_fees_in_gbp
- total_guest_payments_in_gbp
- accepted_values:
values:
- global
- by_number_of_listings
- by_billing_country
- by_business_scope
- by_deal
2024-11-07 12:15:52 +01:00
- by_has_id_check
- 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:
- 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.
Merged PR 5285: Adds Stay Disrupt (Confident Stay) Fees in KPIs Guest Payments flow # Description Propagates Stay Disrupt Guest Product in KPIs flow, within Guest Payments. This is done by: * Adding a new measure on `stay_disrupt_fees_in_gbp` in the daily model `int_kpis__metric_daily_guest_payments` * Adding stay_disrupt_fees_in_gbp in the `total_guest_payments_in_gbp` measure in the daily model `int_kpis__metric_daily_guest_payments` Afterwards this gets propagated downstream. No changes in the `total_guest_payments_in_gbp` measure in following models. However, a new measure for `stay_disrupt_fees_in_gbp` is created in the 4 Guest Payments related models of: * `int_kpis__metric_monthly_guest_payments` * `int_kpis__agg_monthly_guest_payments` * `int_kpis__metric_mtd_guest_payments` * `int_kpis__agg_mtd_guest_payments` Note that this also affects the schema entry of KPIs for both description and completion tests, in the case of aggregation models. Considering the almost non-existent usage of Guest KPIs report, I will not bother propagating Confident Stay in Product Guest KPIs, nor the report itself: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/5285/attachments/image.png) However, total Guest Revenue would include Confident Stay in Guest KPIs as well. Next steps, in a separated PR: * Propagation of new measure `stay_disrupt_fees_in_gbp` so it's available in Main KPIs. # 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: #30278
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.
- 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.
- 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,
- id_deal,
- business_scope.
2025-01-13 16:00:35 +01:00
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 Bookings have been checked-out.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: check_out_bookings
data_type: bigint
description: |
Count of daily bookings checked-out in a given date and per specified dimension.
- 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.
- 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.
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: check_out_bookings
data_type: bigint
description: |
Count of accumulated bookings checked-out in a given month
and per specified dimension.
- 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.
- 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.
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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.
- 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.
- 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
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- check_out_bookings
- cancelled_check_out_bookings
- not_cancelled_check_out_bookings
- billable_check_out_bookings
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: check_out_bookings
data_type: bigint
description: The monthly checked-out bookings for a given date, dimension and value.
- 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.
- name: billable_check_out_bookings
data_type: bigint
description: |
The monthly billable checked-out bookings for a given date, dimension and value.
- 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
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- check_out_bookings
- cancelled_check_out_bookings
- not_cancelled_check_out_bookings
- billable_check_out_bookings
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: check_out_bookings
data_type: bigint
description: The month-to-date checked-out bookings for a given date, dimension and value.
- 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.
- name: billable_check_out_bookings
data_type: bigint
description: |
The month-to-date billable checked-out bookings for a given date, dimension and value.
- 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.
- 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,
- id_deal,
- business_scope.
2025-01-13 16:00:35 +01:00
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 Bookings have been billable.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- billable_bookings
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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
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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- billable_bookings
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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
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-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.
- 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,
- id_deal,
- business_scope.
2025-01-13 16:00:35 +01:00
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 Host Resolutions transaction happened.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- xero_host_resolution_payment_count
- xero_host_resolution_amount_paid_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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- xero_host_resolution_payment_count
- xero_host_resolution_amount_paid_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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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.
- name: int_kpis__metric_daily_invoiced_revenue
description: |
This model computes the Daily Invoiced Revenue at the deepest granularity.
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.
The unique key corresponds to the deepest granularity of the model,
in this case:
- date,
- id_deal,
- business_scope.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- 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
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
in a given date and per specified dimension.
- 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.
- 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: |
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.
- name: xero_e_deposit_net_fees_in_gbp
data_type: decimal
description: |
Sum of daily E-Deposit Net Fees, in GBP, without taxes
in a given date and per specified dimension. This is an
API service.
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-06-11 14:44:07 +02:00
- name: xero_flex_api_net_fees_in_gbp
data_type: decimal
description: |
Sum of daily Flex API Net Fees, in GBP, without taxes
in a given date and per specified dimension. This is an
API service.
- name: xero_athena_net_fees_in_gbp
data_type: decimal
description: |
Sum of daily Athena (Guesty) Net Fees, in GBP, without taxes
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
in a given date and per specified dimension.
- 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.
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- 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
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
in a given month and per specified dimension.
- 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.
- 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: |
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.
- name: xero_e_deposit_net_fees_in_gbp
data_type: decimal
description: |
Sum of accummulated E-Deposit Net Fees, in GBP, without taxes
in a given month and per specified dimension. This is an
API service.
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-06-11 14:44:07 +02:00
- name: xero_flex_api_net_fees_in_gbp
data_type: decimal
description: |
Sum of daily Flex API Net Fees, in GBP, without taxes
in a given date and per specified dimension. This is an
API service.
- name: xero_athena_net_fees_in_gbp
data_type: decimal
description: |
Sum of accummulated Athena (Guesty) Net Fees, in GBP, without taxes
in a given month and per specified dimension. This is an
API service.
- name: xero_guesty_resolutions_net_fees_in_gbp
data_type: decimal
description: |
Sum of accummulated Guesty Resolutions Net Fees, in GBP, without taxes
in a given month and per specified dimension.
- 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.
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- 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
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
in a given month up to the given date and per specified dimension.
- 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.
- 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: |
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.
- name: xero_e_deposit_net_fees_in_gbp
data_type: decimal
description: |
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.
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-06-11 14:44:07 +02:00
- name: xero_flex_api_net_fees_in_gbp
data_type: decimal
description: |
Sum of daily Flex API Net Fees, in GBP, without taxes
in a given date and per specified dimension. This is an
API service.
- name: xero_athena_net_fees_in_gbp
data_type: decimal
description: |
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.
- name: xero_guesty_resolutions_net_fees_in_gbp
data_type: decimal
description: |
Sum of accummulated Guesty Resolutions Net Fees, in GBP, without taxes
in a given month up to the given date and per specified dimension.
- 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.
- 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 up to the given date and per
specified dimension.
- 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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- 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
- 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-06-11 14:44:07 +02:00
- xero_flex_api_net_fees_in_gbp
- 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
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- 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
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
for a given date, dimension and value.
- 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.
- 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: |
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.
- 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.
This is an API service.
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-06-11 14:44:07 +02:00
- name: xero_flex_api_net_fees_in_gbp
data_type: decimal
description: |
Sum of daily Flex API Net Fees, in GBP, without taxes
in a given date and per specified dimension. This is an
API service.
- name: xero_athena_net_fees_in_gbp
data_type: decimal
description: |
The monthly Athena (Guesty) Net Fees, in GBP, without taxes
for a given date, dimension and value.
This is an API service.
- name: xero_guesty_resolutions_net_fees_in_gbp
data_type: decimal
description: |
The monthly Guesty Resolutions Net Fees, in GBP, without taxes
for a given date, dimension and value.
- 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.
- 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:
- 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:
- 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:
- 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:
- assert_dimension_completeness:
2024-11-06 11:47:47 +01:00
metric_column_names:
- 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
- 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-06-11 14:44:07 +02:00
- xero_flex_api_net_fees_in_gbp
- 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
- 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.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- 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
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
for a given date, dimension and value.
- 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.
- 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: |
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.
- 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.
This is an API service.
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-06-11 14:44:07 +02:00
- name: xero_flex_api_net_fees_in_gbp
data_type: decimal
description: |
Sum of daily Flex API Net Fees, in GBP, without taxes
in a given date and per specified dimension. This is an
API service.
- name: xero_athena_net_fees_in_gbp
data_type: decimal
description: |
The month-to-date Athena (Guesty) Net Fees, in GBP, without taxes
for a given date, dimension and value.
This is an API service.
- name: xero_guesty_resolutions_net_fees_in_gbp
data_type: decimal
description: |
The month-to-date Guesty Resolutions Net Fees, in GBP, without taxes
for a given date, dimension and value.
- 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.
- name: xero_waiver_paid_back_to_host_in_gbp
data_type: decimal
description: |
The month-to-date Waiver Amount Paid Back to Hosts, in GBP, without taxes
for a given date, dimension and value.
- 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,
- business_scope,
- active_accommodations_per_deal_segmentation
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- main_billing_country_iso_3_per_deal
- business_scope
- 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:
- 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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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.
- 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.
- 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:
- 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:
- 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:
- 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
- live_deals
- accepted_values:
values:
- global
- by_number_of_listings
- by_billing_country
- by_business_scope
- 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:
- 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:
- 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:
- 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:
- 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.
- 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.
- 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,
- business_scope
- id_deal
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- id_deal
- business_scope
columns:
- name: date
data_type: date
description: Date containing the Listing metrics.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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 Listing level.
2025-01-13 16:00:35 +01:00
data_tests:
- 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:
- 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:
- 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:
- 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
- by_business_scope
- 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:
- 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:
- 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:
- 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:
- 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.
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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.
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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
- service_business_type
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
2024-11-20 09:43:30 +00:00
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
2024-11-20 09:43:30 +00:00
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- id_booking
- service_name
- service_business_type
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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: |
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"
- "GUEST_AGREEMENT"
2024-12-02 10:54:29 +01:00
- "UNKNOWN"
- "UNSET"
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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,
- id_deal,
2024-12-02 11:14:34 +01:00
- active_accommodations_per_deal_segmentation,
- service_business_type.
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
2024-11-20 09:43:30 +00:00
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
2024-11-20 09:43:30 +00:00
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- end_date
- service_name
- id_deal
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
2024-11-20 09:43:30 +00:00
- active_accommodations_per_deal_segmentation
2024-12-02 11:14:34 +01:00
- service_business_type
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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: |
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"
- "GUEST_AGREEMENT"
2024-12-02 10:54:29 +01:00
- "UNKNOWN"
- "UNSET"
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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.
- 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,
- id_deal,
2024-12-02 11:14:34 +01:00
- active_accommodations_per_deal_segmentation,
- service_business_type.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- end_date
- service_name
- id_deal
- active_accommodations_per_deal_segmentation
2024-12-02 11:14:34 +01:00
- service_business_type
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:
- 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:
- not_null
- name: service_name
data_type: string
description: Name of the created service.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
2024-12-02 10:54:29 +01:00
- name: service_business_type
data_type: string
description: |
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"
- "GUEST_AGREEMENT"
2024-12-02 10:54:29 +01:00
- "UNKNOWN"
- "UNSET"
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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
- 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:
- 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.
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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
- by_service_business_type
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
2024-11-20 09:43:30 +00:00
- accepted_values:
values:
- daily
- weekly
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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
- by_service_business_type
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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:
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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.
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
2024-11-20 09:43:30 +00:00
- name: created_services
data_type: bigint
description: |
The created services for a given time granularity, date or dates range,
dimension and value.
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
2024-11-20 09:43:30 +00:00
2025-04-02 08:22:21 +02:00
- name: created_bookings
Merged PR 3599: New Dash KPIs skeleton with Created Services # Description This PR handles the computation of KPIs for New Dash, focusing on Created Services. New dimensions configured in `business_kpis_configuration` and applied in this new models for `NEW_DASH_CREATED_SERVICES`: * `dim_host`, * `dim_has_upgraded_service`, * `dim_new_dash_version`, * `dim_pricing_service` New daily metric model `int_kpis__metric_daily_new_dash_created_services` * Follows a similar pattern as for the rest of daily metric models. The only difference is that is aggregated to `id_booking` to ensure we can handle count distinct of bookings per different time granularities. * Reads from the new pricing tables `int_core__booking_summary` and `int_core__booking_service_detail`. The main filters applied are selecting only new dash users and only services created after the user move timestamp to new dash. An additional metric model at monthly level is created `int_kpis__metric_monthly_new_dash_created_services` These finally go to a dimension aggregated model (`dimension`, `dimension_value`), respectively: * Daily: `int_kpis__agg_daily_new_dash_created_services` * Monthly: `int_kpis__agg_monthly_new_dash_created_services` A final model aims to aggregate the different dimension aggregated metrics for New Dash: `int_kpis__product_new_dash_agg_metrics` * It computes a `time_granularity` aggregation * Here I will add additional metrics (such as revenue) once we have them. A final model reading from the previous is exposed to reporting: `kpis__product_new_dash_agg_metrics` # 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: #20809
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.
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
2024-11-26 10:14:37 +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.
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
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
- service_business_type
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
2024-11-26 10:14:37 +00:00
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
2024-11-26 10:14:37 +00:00
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- id_booking
- service_name
- service_business_type
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
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:
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
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:
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
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:
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
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:
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
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:
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
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:
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
2024-11-26 10:14:37 +00:00
- 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.
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
2024-11-26 10:14:37 +00:00
Cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
2024-11-26 10:14:37 +00:00
- not_null
- accepted_values:
values:
- "SCREENING"
- "PROTECTION"
- "DEPOSIT_MANAGEMENT"
- "GUEST_AGREEMENT"
- "UNKNOWN"
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
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:
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
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:
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
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:
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # 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: #20809
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.
- 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.
- service_business_type
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- end_date
- id_booking
- service_name
- active_accommodations_per_deal_segmentation
- service_business_type
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:
- 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:
- not_null
- name: id_booking
data_type: bigint
description: Unique identifier of the Booking.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: service_name
data_type: string
description: Name of the chargeable service.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
data_tests:
- 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:
- 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:
- 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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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,
- active_accommodations_per_deal_segmentation,
- service_business_type
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- end_date
- id_booking
- service_name
- active_accommodations_per_deal_segmentation
- service_business_type
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:
- 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:
- not_null
- name: id_booking
data_type: bigint
description: Unique identifier of the Booking.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: service_name
data_type: string
description: Name of the chargeable service.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: Unique identifier of an account.
2025-01-13 16:00:35 +01:00
data_tests:
- 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:
- 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:
- 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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
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.
2025-01-13 16:00:35 +01:00
data_tests:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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:
- 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-25 17:11:02 +01:00
- name: int_kpis__metric_daily_new_dash_deals_offered_services
description: |
2025-03-25 17:11:02 +01:00
This model computes the Daily Offered Services by Deals 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:
2025-03-25 17:11:02 +01:00
- date,
2025-03-25 12:25:47 +01:00
- id_deal,
- id_user_product_bundle,
- 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
- 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.
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.
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"
- 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"
- 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-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: |
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.
- 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.
Merged PR 4926: KPIs Refactor Stage 3 - Creates dedicated Churn model in KPIs # Description Creates a new model in intermediate/kpis called `int_kpis__agg_monthly_churn_contribution`. This follows the convention (aggregated = by dimension and dimension value) and monthly (1 dimension value per dimension per date where date is unique in month). This single model aims to substitute, in the future, the 2 churn models simultaneously: * `int_monthly_12m_window_contribution_by_deal` * `int_monthly_churn_metrics` Main changes: * There's no longer a dependency with `int_monthly_aggregated_metrics_history_by_deal`. Rather, it gets the metrics and dimensions from wherever needed and nothing else. * I also took the opportunity to clean any code that was not needed after combining both models, resulting in dropping a whole CTE. * Updated schema description for clarification purposes. The output of the new model is identical to the 2nd model, `int_monthly_churn_metrics`, confirmed with the md5 trick. Model runs in 1.45 seconds in my laptop so no performance issue (it's technically faster than running the 2 current models which is around 6.3 seconds but whatever). Note that this has NO effect yet on production. The switch will be handled in a separated PR. # 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: #28948
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.
Merged PR 5055: KPIs models for API Billable Verifications # Description Changes: * 4 new models in the scope of KPIs for Billable Verifications from APIs. I believe it's more correct to say these are Billable Verifications than Billable Bookings since there's some cases in which a Booking can be duplicated and it's billed multiple times. These include: * A daily metric model - extremely simple. You will notice there's no Billing Country not Listing Segmentation. This is because for ALL API cases this is UNSET, thus, I just remove it. * An equivalent monthly metric model. * Two aggregated models per dimension, dimension value: on a daily and a monthly basis. Important change: the macro that handles the aggregations sets by default Billing Country and Listing Segmentation. I modified a bit the flow so the only required dimension is Global, and these are skipped for APIs models. This is needed for the changes intended on the Growth score. In there, I'll combine both Platform Billable Bookings with API Billable Verifications. Notice there's no MTD models. These could be added for sure; but since I'm not creating any metric in Main KPIs or similar, I opted to skip it for now. It can be done later on. # 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: #29374
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.