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

3507 lines
128 KiB
YAML
Raw Normal View History

2024-06-14 15:48:24 +02:00
models:
- name: int_daily_currency_exchange_rates
description: >-
This model holds a lot of data on currency exchange rates. The time
granularity is daily. Each record holds a currency pair for a specific
day, source and version.
2024-06-14 16:22:00 +02:00
Actual rates are sourced from xe.com data. The `guessed` and `forecast`
2024-06-14 15:48:24 +02:00
versions are built by simply 'pushing' the first/last exchange rate on
record. Basically, wherever we dont' have data for a date, we pick the
2024-06-14 16:22:00 +02:00
closest actual data point that comes from xe.com. Bear in mind this means
that `forecast` version records will change on a daily basis as actual
data moves forwards, meaning you shouldn't assume your money amounts
converted in the future should always stay put.
2024-06-14 15:48:24 +02:00
Note that, given the dimensionality, getting a simple time series for a
currency pair will require a bit of filtering.
Reverse rates are explicit. This means that, for any given day and any
given currency pair, you will find two records with opposite from/to
positions. So, for 2024-01-01, you will find both a EUR->USD record and a
USD->EUR record with the opposite rate (1/rate).
columns:
- name: id_exchange_rate
data_type: text
description: A unique ID for the record, derived from concatenating the
currencies, date, source and version. Currency order is relevant
(EURUSD != USDEUR).
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 15:48:24 +02:00
- not_null
- unique
- name: from_currency
data_type: character
description: The source currency, represented as an ISO 4217 code.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 15:48:24 +02:00
- not_null
- name: to_currency
data_type: character
description: The target currency, represented as an ISO 4217 code.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 15:48:24 +02:00
- not_null
- name: rate
data_type: numeric
description: >-
The exchange rate, represented as the units of the target currency
that one unit of source currency gets you. So, from_currency=USD to
to_currency=PLN with rate=4.2 should be read as '1 US Dollar buys me
4.2 Polish Zlotys'.
For same currency pairs (EUR to EUR, USD to USD, etc). The rate will
always be one.
The rate can be smaller than one, but can't be negative.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 15:48:24 +02:00
- not_negative_or_zero
- not_null
- name: rate_date_utc
data_type: date
description: The date in which the rate record is relevant.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 15:48:24 +02:00
- not_null
- name: source
data_type: text
2024-06-14 16:46:28 +02:00
description:
Where is the data coming from. Records that are composed from
2024-06-14 15:48:24 +02:00
making assumptions on real data will contain `_inferred`.
- name: rate_version
data_type: text
2024-06-14 16:46:28 +02:00
description:
The version of the rate. This can be one of `actual` (the rate is a
2024-06-14 15:48:24 +02:00
reality fact), `forecast` (the rate sits in the future and is a guess
in nature) or `guess` (the rate sits in the past and is a guess in
nature). Note that one currency pair can have multiple rate versions
on the same date.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 15:48:24 +02:00
- accepted_values:
values:
- guess
- actual
- forecast
2024-06-14 16:22:00 +02:00
- not_null
2024-06-14 15:48:24 +02:00
- name: updated_at_utc
data_type: timestamp with time zone
2024-06-14 16:46:28 +02:00
description:
For external sources, this will be the point in time when the
2024-06-14 15:48:24 +02:00
information was obtained from them. For stuff we make up here in the
DWH, this will be the point in time when we made the assumption.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 15:48:24 +02:00
- not_null
2024-06-14 16:44:48 +02:00
- name: int_simple_exchange_rates
2024-06-14 16:46:28 +02:00
description: >-
A simplified vision of exchange rates, derived from
`int_daily_currency_exchange_rates`. Come here if you don't want to
understand nuances and complexities and just want to convert rates.
The time granularity is daily. Each record holds a currency pair for a
specific day. You will only find one conversion rate per currency pair and
date.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 16:46:28 +02:00
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- from_currency
- to_currency
- rate_date_utc
2024-06-14 16:44:48 +02:00
columns:
- name: from_currency
data_type: character
description: The source currency, represented as an ISO 4217 code.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 16:44:48 +02:00
- not_null
- name: to_currency
data_type: character
description: The source currency, represented as an ISO 4217 code.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 16:44:48 +02:00
- not_null
- name: rate
data_type: numeric
description: The target currency, represented as an ISO 4217 code.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 16:44:48 +02:00
- not_null
- name: rate_date_utc
data_type: date
description: The date in which the rate record is relevant.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 16:44:48 +02:00
- not_null
- name: updated_at_utc
data_type: timestamp with time zone
2024-06-14 16:46:28 +02:00
description:
For external sources, this will be the point in time when the
2024-06-14 16:44:48 +02:00
information was obtained from them. For stuff we make up here in the
DWH, this will be the point in time when we made the assumption.
2025-01-13 16:00:35 +01:00
data_tests:
2024-06-14 16:44:48 +02:00
- not_null
- name: int_mtd_vs_previous_year_metrics
description: |
This model is used for global KPIs.
It aggregates all the mtd models with the different metrics per source
and computes any necessary weighted metric across different sources.
Merged PR 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +00:00
Each metric has a date, dimension and dimension value that defines
the primary key of this model.
2024-09-12 15:38:50 +02:00
Finally, it displays any metric on the current date, the previous year
date and it computes the relative increment by using the macro:
- calculate_safe_relative_increment
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +00:00
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- dimension
- dimension_value
2024-09-12 15:38:50 +02:00
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: revenue_retained_post_resolutions_in_gbp
column_B: total_revenue_in_gbp + xero_waiver_paid_back_to_host_in_gbp + xero_host_resolution_amount_paid_in_gbp
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: total_revenue_in_gbp
column_B: total_guest_payments_in_gbp + xero_apis_net_fees_in_gbp + xero_operator_net_fees_in_gbp
columns:
- name: date
data_type: date
description: The date for the month-to-date metrics.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
Merged PR 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +00:00
- 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 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +00:00
- accepted_values:
2024-09-12 15:38:50 +02:00
values:
Merged PR 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +00:00
- global
- by_number_of_listings
Merged PR 2689: KPIs by Billing Country # Description Adds Billing Country dimension in KPIs, but does not expose them to reporting yet. Silly thing, based on the macros I built, I cannot make incremental changes unless changing all models. This will need to be adapted, happy to hear your thoughts on how we do it. Additionally, I have lack of performance of the model `mtd_guest_payments_metrics`. It takes around 5 min to execute, but technically the end-to-end runs in one shoot without breaking. It's a complex PR because it changes many files, but you will see that: * It mostly changes the join conditions for the dimensions or the schema tests, * I tried to be very careful and add things step-by-step in the commits. Goal is NOT to complete the PR yet until we see how we can improve performance. I can say though that data end-to-end looks ok to me, but would benefit from checking with production data for the new dimension Update 30th Aug * Added a new commit that includes `id_user_host` in `int_core__verification_payments`. Happy to discuss if it makes sense or not. But it changes the execution from ~600 sec to ~6 sec because it avoids a massive repeated join with `verification_requests`. # Checklist - [X] The edited models and dependants run properly 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. - [ ] I've picked the right materialization for the affected models. **To check because of performance issues** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19082
2024-09-04 10:17:12 +00:00
- 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
Merged PR 4946: Allows By Deal dimension to be propagated within intermediate # Description To be able to compute By Deal KPIs similarly as we do for Main KPIs we need to propagate the "By Deal" dimension first in intermediate. This does not impact reporting since there's a macro that already cuts the dimensions to be displayed, but I modified the name so it's clearer. Changes: * In `int_mtd_vs_previous_year_metrics`, I added a new `dimension_list`. This is applied to all initial CTEs that filter by dimension. Note that I added here the `by_deal` dimension. * Modified the name of `get_kpi_dimensions_for_production` to `get_main_kpis_dimensions_for_production`. Now it's more explicit that this is the configuration for Main KPIs reporting. This affects both `business_kpis_configuration` and it's usage in `mtd_aggregated_metrics`. * Modified the tests in `int_mtd_vs_previous_year_metrics` and `int_mtd_aggregated_metrics` to include the new dimension `by_deal`. * It seems by adding this now autoformatting works again on this model! I'll tag all cases that are just because of autoformatting. MD5 trick has been applied in `reporting.mtd_aggregated_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: #28998
2025-04-08 05:37:53 +00:00
- by_deal
2024-09-12 15:38:50 +02:00
Merged PR 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +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 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +00:00
- not_null
- name: int_mtd_aggregated_metrics
description: |
The `int_mtd_aggregated_metrics` model aggregates multiple metrics on a year, month, and day basis.
The primary source of data is the `int_mtd_vs_previous_year_metrics` model, which contain the combination
of metrics data per source. This model just changes the display format to unpivot the information into
a set of metric, value, previous_year_value and relative_increment at a given date. It uses Jinja
code to avoid code replication.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- metric
Merged PR 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +00:00
- dimension
- dimension_value
2024-09-12 15:38:50 +02:00
columns:
- 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
2024-09-12 15:38:50 +02:00
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: is_end_of_month
data_type: boolean
description: True if it's end of month.
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 it's end of month or yesterday.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: is_current_month
data_type: boolean
description: |
checks if the date is within the current executed month,
1 for yes, 0 for no.
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: date
data_type: date
description: |
main date for the computation, that is used for filters.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
Merged PR 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +00:00
- 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 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +00:00
- accepted_values:
2024-09-12 15:38:50 +02:00
values:
Merged PR 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +00:00
- global
- by_number_of_listings
Merged PR 2689: KPIs by Billing Country # Description Adds Billing Country dimension in KPIs, but does not expose them to reporting yet. Silly thing, based on the macros I built, I cannot make incremental changes unless changing all models. This will need to be adapted, happy to hear your thoughts on how we do it. Additionally, I have lack of performance of the model `mtd_guest_payments_metrics`. It takes around 5 min to execute, but technically the end-to-end runs in one shoot without breaking. It's a complex PR because it changes many files, but you will see that: * It mostly changes the join conditions for the dimensions or the schema tests, * I tried to be very careful and add things step-by-step in the commits. Goal is NOT to complete the PR yet until we see how we can improve performance. I can say though that data end-to-end looks ok to me, but would benefit from checking with production data for the new dimension Update 30th Aug * Added a new commit that includes `id_user_host` in `int_core__verification_payments`. Happy to discuss if it makes sense or not. But it changes the execution from ~600 sec to ~6 sec because it avoids a massive repeated join with `verification_requests`. # Checklist - [X] The edited models and dependants run properly 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. - [ ] I've picked the right materialization for the affected models. **To check because of performance issues** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19082
2024-09-04 10:17:12 +00:00
- 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
Merged PR 4946: Allows By Deal dimension to be propagated within intermediate # Description To be able to compute By Deal KPIs similarly as we do for Main KPIs we need to propagate the "By Deal" dimension first in intermediate. This does not impact reporting since there's a macro that already cuts the dimensions to be displayed, but I modified the name so it's clearer. Changes: * In `int_mtd_vs_previous_year_metrics`, I added a new `dimension_list`. This is applied to all initial CTEs that filter by dimension. Note that I added here the `by_deal` dimension. * Modified the name of `get_kpi_dimensions_for_production` to `get_main_kpis_dimensions_for_production`. Now it's more explicit that this is the configuration for Main KPIs reporting. This affects both `business_kpis_configuration` and it's usage in `mtd_aggregated_metrics`. * Modified the tests in `int_mtd_vs_previous_year_metrics` and `int_mtd_aggregated_metrics` to include the new dimension `by_deal`. * It seems by adding this now autoformatting works again on this model! I'll tag all cases that are just because of autoformatting. MD5 trick has been applied in `reporting.mtd_aggregated_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: #28998
2025-04-08 05:37:53 +00:00
- by_deal
2024-09-12 15:38:50 +02:00
Merged PR 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +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 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # Checklist - [X] The edited models and dependants run properly 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: #19325
2024-08-20 15:42:27 +00:00
- not_null
- name: previous_year_date
data_type: date
description: |
corresponds to the date of the previous year, with respect to the field date.
It's only displayed for information purposes,
should not be needed for reporting.
- name: metric
data_type: text
description: name of the business metric.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: order_by
data_type: integer
description: |
order for displaying purposes. Null values are accepted, but keep
in mind that then there's no default controlled display order.
- name: include_in_account_reporting
data_type: boolean
description: |
Category to indicate if the metric should be included in the account
reporting (by deal). This will limit the display for reporting purposes.
data_tests:
- not_null
2025-03-21 09:40:20 +00:00
- name: display_exclusion
data_type: string
description: |
Category to indicate if the metric requires a certain exclusion due
to relying on not timely information.
This will limit the display for reporting purposes.
data_tests:
- not_null
- accepted_values:
values:
- NONE
- INVOICING
- ONGOING_MONTH
- name: number_format
data_type: text
description: allows for grouping and formatting for displaying purposes.
2025-01-13 16:00:35 +01:00
data_tests:
2024-09-12 15:38:50 +02:00
- accepted_values:
2024-09-20 14:53:43 +02:00
values:
[
"integer",
"percentage",
"currency_gbp",
"converted_metric_currency_gbp",
]
- name: value
2024-09-12 15:38:50 +02:00
data_type: numeric
description: |
numeric value (integer or decimal) that corresponds to the MTD computation of the metric
at a given date.
- name: previous_year_value
2024-09-12 15:38:50 +02:00
data_type: numeric
description: |
numeric value (integer or decimal) that corresponds to the MTD computation of the metric
on the previous year at a given date.
- name: relative_increment
2024-09-12 15:38:50 +02:00
data_type: numeric
description: |
numeric value that corresponds to the relative increment between value and previous year value,
following the computation: value / previous_year_value - 1.
- name: relative_increment_with_sign_format
2024-09-12 15:38:50 +02:00
data_type: numeric
description: |
relative_increment value multiplied by -1 in case this metric's growth doesn't have a
positive impact for Superhog, otherwise is equal to relative_increment.
This value is specially created for formatting in PBI
- name: int_monthly_aggregated_metrics_history_by_deal
deprecation_date: 2025-04-28 08:00:00
description: |
This model aggregates the monthly historic information regarding the different metrics computed
at deal level. The primary sources of data are the `int_yyy__monthly_XXXXX_history_by_deal`
models which contain the raw metrics data per source.
Unlike the int_mtd_aggregated_metrics, this model does not abstract each metric, since
no comparison versus last year is performed. In short, it just gathers the information stored
in the abovementioned models.
To keep in mind: aggregating the information of this model will not necessarily result into
the int_mtd_aggregated metrics because 1) the mtd version contains more computing dates
than the by deal version, the latest being a subset of the first, and 2) the deal based model
enforces that a booking/guest journey/listing/etc has a host with a deal assigned, which is
2024-09-12 15:38:50 +02:00
not necessarily the case.
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: The last day of the month or yesterday for historic metrics.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: character varying
2024-09-12 15:38:50 +02:00
description: Id of the deal associated to the host.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: client_type
data_type: string
description: |
Type of client. It can be either PLATFORM or API.
data_tests:
- not_null
- accepted_values:
values:
- PLATFORM
- API
2025-03-14 11:48:22 +01:00
- name: business_scope
data_type: string
description: |
Business scope identifying the metric source.
data_tests:
- not_null
- accepted_values:
values:
- "Old Dash"
- "New Dash"
- "API"
- "UNSET"
- name: main_deal_name
data_type: string
description: |
Main name for this ID deal.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
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: 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: |
ISO 3166-1 alpha-3 main country code in which the Deal is billed.
In some cases it's null.
2024-09-12 15:38:50 +02:00
- name: int_monthly_growth_score_by_deal
deprecation_date: 2025-05-10 08:00:00
description: |
The main goal of this model is to provide a growth score by deal and month.
The idea behind it is that each deal will have some business performance
associated to it over the months, and that comparing how it is currently
performing vs. historical data we can determine whether the tendency is to
grow or to decay. This is specially useful for AMs to focus their effort
towards the clients that have a negative tendency.
The computation of the growth score is based on 3 main indicators:
- Created bookings
- Listings booked in month
- Total revenue (in gbp)
The main idea is, for each deal, to compare each of these metrics by
checking the latest monthly value vs. 1) the monthly value of the equivalent
month on the previous year and 2) the monthly value of the previous month
- in other words, a year-on-year (YoY) and month-on-month (MoM) comparison.
We do this comparison by doing a relative incremental.
The growth score is computed then by averaging the outcome of the 6 scores.
Lastly, in order to provide a prioritisation sense, we have a weighted growth
score that results from the multiplication of the growth score per the revenue
weight a specific deal has provided in the previous 12 months.
However, this is not strictly true for Revenue because 1) we have an invoicing
delay and 2) in some cases, monthly revenue per deal can be negative. In this
specific cases, the YoY comparison is shifted by one month, and an effective
revenue value for the revenue share is computed, that cannot be lower than 0.
In order to keep both a properly set up score and revenue consistency, both
a real revenue value and effective revenue value are present in this model,
while no MoM or YoY value is computed if negative revenue is found.
Lastly, this model provides informative date fields, deal attributes, absolute
metric values and MoM & YoY relative incrementals to enrich reporting.
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 corresponding to the last day of the month. Given month
metrics are inclusive to this date. Together with id_deal, it
acts as the primary key of this model.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: string
description: |
Unique identifier of a Deal. Together with date, it acts as
the primary key of this model.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: client_type
data_type: string
description: |
Type of client. It can be either PLATFORM or API.
data_tests:
- not_null
- accepted_values:
values:
- PLATFORM
- API
- name: main_deal_name
data_type: string
description: |
Main name for a Deal, representing the client.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
2025-01-10 09:17:29 +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:
2025-01-10 09:17:29 +01:00
- not_null
- name: active_pms_list
data_type: string
description: |
Name of the active PMS associated with the deal. It can have more than
one PMS associated with it. It can be null if it doesn't have any PMS associated.
- name: main_billing_country_iso_3_per_deal
data_type: string
description: |
Main billing country for this client. In some cases
it can be null.
- name: deal_lifecycle_state
data_type: string
description: |
Identifier of the lifecycle state of a given deal
in a given month.
- name: deal_hubspot_stage
data_type: string
description: |
Current hubspot stage for a given deal.
- name: account_manager
data_type: string
description: |
Current Account Manager in charge of a given deal, according
to Hubspot.
- name: live_date_utc
data_type: date
description: |
Date in which the account has gone live, according to Hubspot.
- name: cancellation_date_utc
data_type: date
description: |
Date in which the account has been offboarded, according to
Hubspot.
- name: given_month_first_day_month
data_type: date
description: |
Informative field. It indicates the first day of the
month corresponding to date.
If date = 2024-09-30, this field will be 2024-09-01.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: previous_1_month_first_day_month
data_type: date
description: |
Informative field. It indicates the first day of the
previous month with respect to date.
If date = 2024-09-30, this field will be 2024-08-01.
It can be null if no previous history for that
deal is found.
- name: previous_2_month_first_day_month
data_type: date
description: |
Informative field. It indicates the first day of the
month 2 months before with respect to date.
If date = 2024-09-30, this field will be 2024-07-01.
It can be null if no previous history for that
deal is found.
- name: previous_12_month_first_day_month
data_type: date
description: |
Informative field. It indicates the first day of the
month with respect to date, but on the previous year.
If date = 2024-09-30, this field will be 2023-09-01.
It can be null if no previous history for that
deal is found.
- name: previous_13_month_first_day_month
data_type: date
description: |
Informative field. It indicates the first day of the
previous month with respect to date, but on the previous year.
If date = 2024-09-30, this field will be 2023-08-01.
It can be null if no previous history for that
deal is found.
- name: aggregated_revenue_from_first_day_month
data_type: date
description: |
Informative field. It indicates the first day of the
month from the lower bound range in which the revenue
aggregation is computed.
The aggregation uses the previous 12 months in which we
know the revenue, thus:
If date = 2024-09-30, this field will be 2023-09-01.
It can be null if no previous history for that
deal is found.
- name: aggregated_revenue_to_first_day_month
data_type: date
description: |
Informative field. It indicates the first day of the
month from the upper bound range in which the revenue
aggregation is computed.
The aggregation uses the previous 12 months in which we
know the revenue, thus:
If date = 2024-09-30, this field will be 2023-08-01.
It can be null if no previous history for that
deal is found.
- name: given_month_revenue_in_gbp
data_type: decimal
description: |
Monthly value representing revenue in GBP
for a specific deal. This value corresponds to
the given month. This value can be negative,
but not null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: previous_1_month_revenue_in_gbp
data_type: decimal
description: |
Monthly value representing revenue in GBP
for a specific deal. This value corresponds to
the previous month.
This value can be negative.
This value can be null, thus indicating that no
history is available.
- name: previous_2_month_revenue_in_gbp
data_type: decimal
description: |
Monthly value representing revenue in GBP
for a specific deal. This value corresponds to
the monthly amount generated 2 months ago
This value can be negative.
This value can be null, thus indicating that no
history is available.
- name: previous_12_month_revenue_in_gbp
data_type: decimal
description: |
Monthly value representing revenue in GBP
for a specific deal. This value corresponds to
the monthly amount generated 12 months ago.
This value can be negative.
This value can be null, thus indicating that no
history is available.
- name: previous_13_month_revenue_in_gbp
data_type: decimal
description: |
Monthly value representing revenue in GBP
for a specific deal. This value corresponds to
the monthly amount generated 13 months ago.
This value can be negative.
This value can be null, thus indicating that no
history is available.
- name: mom_revenue_growth
data_type: decimal
description: |
Relative increment of the revenue generated in the
current month with respect to the one generated in
the previous month.
It can be null if any revenue used in the computation
is null or it's negative.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: -1
strictly: false
- name: mom_1_month_shift_revenue_growth
data_type: decimal
description: |
Relative increment of the revenue generated in the
previous month with respect to the one generated 2
months ago.
It can be null if any revenue used in the computation
is null or it's negative.
This field is used for the growth score computation.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: -1
strictly: false
- name: yoy_revenue_growth
data_type: decimal
description: |
Relative increment of the revenue generated in the
current month with respect to the one generated 12
months ago.
It can be null if any revenue used in the computation
is null or it's negative.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: -1
strictly: false
- name: yoy_1_month_shift_revenue_growth
data_type: decimal
description: |
Relative increment of the revenue generated in the
previous month with respect to the one generated 13
months ago.
It can be null if any revenue used in the computation
is null or it's negative.
This field is used for the growth score computation.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: -1
strictly: false
- name: given_month_created_bookings
data_type: integer
description: |
Monthly value representing created bookings
for a specific deal. This value corresponds to
the given month. This value cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: previous_1_month_created_bookings
data_type: integer
description: |
Monthly value representing created bookings
for a specific deal. This value corresponds to
the previous month.
This value can be null, thus indicating that no
history is available.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: previous_12_month_created_bookings
data_type: integer
description: |
Monthly value representing created bookings
for a specific deal. This value corresponds to
monthly amount generated 12 months ago.
This value can be null, thus indicating that no
history is available.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: mom_created_bookings_growth
data_type: decimal
description: |
Relative increment of the bookings created in the
current month with respect to the ones created in
the previous month.
It can be null if the bookings created in the
previous month are null.
This field is used for the growth score computation.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: -1
strictly: false
- name: yoy_created_bookings_growth
data_type: decimal
description: |
Relative increment of the bookings created in the
current month with respect to the ones created 12
months ago.
It can be null if the bookings created 12 months
ago are null.
This field is used for the growth score computation.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: -1
strictly: false
- name: given_month_listings_booked_in_month
data_type: integer
description: |
Monthly value representing the listings booked in month
for a specific deal. This value corresponds to
the given month. This value cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: previous_1_month_listings_booked_in_month
data_type: integer
description: |
Monthly value representing the listings booked in month
for a specific deal. This value corresponds to
the previous month.
This value can be null, thus indicating that no
history is available.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: previous_12_month_listings_booked_in_month
data_type: integer
description: |
Monthly value representing the listings booked in month
for a specific deal. This value corresponds to
monthly amount generated 12 months ago.
This value can be null, thus indicating that no
history is available.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: mom_listings_booked_in_month_growth
data_type: decimal
description: |
Relative increment of the the listings booked in month
in the current month with respect to the ones of
the previous month.
It can be null if the listings booked in month in the
previous month are null.
This field is used for the growth score computation.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: -1
strictly: false
- name: yoy_listings_booked_in_month_growth
data_type: decimal
description: |
Relative increment of the listings booked in month
in the current month with respect to the ones of 12
months ago.
It can be null if the listings booked in month of 12
months ago are null.
This field is used for the growth score computation.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: -1
strictly: false
- name: deal_revenue_12_months_window
data_type: decimal
description: |
Total aggregated revenue in GBP generated by a deal
in the months from the period ranging from the
aggregated_revenue_from_first_day_month to
aggregated_revenue_to_first_day_month.
It can be negative if the sum is negative.
It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: effective_deal_revenue_12_months_window
data_type: decimal
description: |
Effective aggregated revenue in GBP generated by a deal
in the months from the period ranging from the
aggregated_revenue_from_first_day_month to
aggregated_revenue_to_first_day_month.
All negative monthly revenue values are settled as 0,
thus this value should not be reported.
It is used for the deal contribution share with respect
to the global revenue. It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: effective_global_revenue_12_months_window
data_type: decimal
description: |
Effective aggregated revenue in GBP generated by all deals
in the months from the period ranging from the
aggregated_revenue_from_first_day_month to
aggregated_revenue_to_first_day_month.
All negative monthly revenue values are settled as 0,
thus this value should not be reported.
It is used for the deal contribution share with respect
to the global revenue. It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: deal_contribution_share_to_global_revenue
data_type: decimal
description: |
Represents the size of the deal in terms of revenue. In
other words, what's the percentage of the global revenue
that can be attributed to this deal. It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: deal_contribution_rank_to_global_revenue
data_type: integer
description: |
Represents the ordered list of deals by descending size
in terms of revenue.
If more than one deal have the same share, the order is
not under control.
It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: deal_created_bookings_12_months_window
data_type: integer
description: |
Total created bookings generated by a deal
in the months from the period ranging from the
aggregated_revenue_from_first_day_month to
aggregated_revenue_to_first_day_month.
It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: global_created_bookings_12_months_window
data_type: integer
description: |
Total created bookings generated by any deal
in the months from the period ranging from the
aggregated_revenue_from_first_day_month to
aggregated_revenue_to_first_day_month.
It is used for the deal contribution share with respect
to the global created bookings. It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: deal_contribution_share_to_global_created_bookings
data_type: decimal
description: |
Represents the size of the deal in terms of created bookings.
In other words, what's the percentage of the global created
bookings that can be attributed to this deal.
It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: deal_contribution_rank_to_global_created_bookings
data_type: integer
description: |
Represents the ordered list of deals by descending size
in terms of created bookings.
If more than one deal have the same share, the order is
not under control.
It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: deal_avg_listings_booked_in_month_12_months_window
data_type: decimal
description: |
Average listings booked in month by a deal
in the months from the period ranging from the
aggregated_revenue_from_first_day_month to
aggregated_revenue_to_first_day_month.
It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: global_avg_listings_booked_in_month_12_months_window
data_type: decimal
description: |
Sum of the average listings booked in month by
any deal in the months from the period ranging from the
aggregated_revenue_from_first_day_month to
aggregated_revenue_to_first_day_month.
It is used for the deal contribution share with respect
to the global average listings booked in month.
It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: deal_contribution_share_to_global_avg_listings_booked_in_month
data_type: decimal
description: |
Represents the size of the deal in terms of average listings
booked in month.
In other words, what's the percentage of the global average listings
booked in month that can be attributed to this deal.
It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: deal_contribution_rank_to_global_avg_listings_booked_in_month
data_type: decimal
description: |
Represents the ordered list of deals by descending size
in terms of average listings booked in month.
If more than one deal have the same share, the order is
not under control.
It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: avg_mom_growth_score
data_type: decimal
description: |
Represents the average score of MoM growth of created
bookings, MoM growth of listings booked in month and
MoM shifted by one month of revenue.
It indicates the tendency of growth of the deal without
taking into account its revenue size. It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: avg_yoy_growth_score
data_type: decimal
description: |
Represents the average score of YoY growth of created
bookings, YoY growth of listings booked in month and
YoY shifted by one month of revenue.
It indicates the tendency of growth of the deal without
taking into account its revenue size. It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: avg_growth_score
data_type: decimal
description: |
Represents the average score of YoY and MoM growth of created
bookings, YoY and MoM growth of listings booked in month and
YoY and MoM shifted by one month of revenue.
It indicates the tendency of growth of the deal without
taking into account its revenue size. It cannot be null.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: weighted_avg_growth_score
data_type: decimal
description: |
It's the weighted version of avg_growth_score that
takes into account the client size by using the revenue
contribution share of that deal to the global amount.
It's the main indicator towards measuring both growth
(if positive) or decay (if negative) while weighting
the financial impact this deal tendency can have.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: categorisation_weighted_avg_growth_score
data_type: string
description: |
Discrete categorisation of weighted_avg_growth_score.
It helps easily identifying which accounts are top losers,
losers, flat, winners and top winners.
Currently the categorisation is based on the score itself
rather than selecting a top up/down.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- accepted_values:
values:
- MAJOR DECLINE
- DECLINE
- FLAT
- GAIN
- MAJOR GAIN
- UNSET
Merged PR 3163: First version of 12m window contribution by deal # Description This PR creates a new model that depends on int_monthly_aggregated_metrics_history_by_deal. The idea is that this is used for Churn computation (Booking Churn, Revenue Churn, Listing Churn) later on. The idea is relatively simple. Measure how much a Deal has been contributing to a Global amount (sum of metric for all deals) over the preceding period of 12 months. You will notice that there's 2 computations, the "additive" and the "average" one. This is because we still need to align with Matt/Suzannah on which approach makes more sense, but we need data for it. I'm not sure the namings are good though so happy to see your suggestions. You will also notice that there's no filter by deal_lifecycle_state = '06-Churning'. This will be done in a separated model, whenever we attribute this model to the mtd computation. The reason is simple - this model stays at deal level, thus meaning we can do the dimension aggregation and even a lifecycle aggregation if needed, depending on the needs. Be aware that this effectively means that MTD KPIs models will depend on the "monthly by deal" models. This has some cons in terms of dependency management but cannot be overcome since we the metric total revenue depends on many subsets. In essence, I don't see another way of doing it unless doing a massive KPIs refactor. I prefer to wait until the Product KPIs discussions are finished and then we see how we approach it. # Checklist - [X] The edited models and dependants run properly 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: #22691
2024-10-15 06:51:41 +00:00
2024-11-29 11:03:59 +01:00
- name: int_edeposit_and_athena_verifications
2024-11-29 09:59:35 +01:00
description:
"This table holds records on verifications for Guesty and Edeposit bookings.
It contains details on validations checked on the guests, guest information
and some booking details like checkin-checkout date or the status of the verification.
The id values found here are completely unrelated to the ones found in Core DWH.
Note that id_verifications and booking_id should normally be 1 to 1.
Though there are exception, the API will accept a duplicate booking and the users
will be charged for it. A duplicate would return a unique id_verification."
columns:
- name: id_verification
data_type: text
description: "unique Superhog generated id for this verification"
2025-01-13 16:00:35 +01:00
data_tests:
2024-11-29 09:59:35 +01:00
- unique
- not_null
- name: id_booking
data_type: text
description: "unique Superhog generated id for a booking.
note that this could be duplicated and both will be charged,
it's up to the user to no generate duplicate verifications"
- name: id_user_partner
data_type: text
description: "unique Superhog generated id for partner"
2025-01-13 16:00:35 +01:00
data_tests:
2024-11-29 09:59:35 +01:00
- not_null
- name: id_accommodation
data_type: text
description: "unique Superhog generated id for a listing"
- name: version
data_type: text
description: "value to identify if it is Guesty (V1) or E-deposit (V2)"
2025-01-13 16:00:35 +01:00
data_tests:
2024-11-29 09:59:35 +01:00
- accepted_values:
values:
- V1
- V2
- name: verification_source
data_type: text
description: "source of the verification for the booking"
2025-01-13 16:00:35 +01:00
data_tests:
2024-11-29 09:59:35 +01:00
- accepted_values:
values:
- Guesty
- Edeposit
- name: verification_status
data_type: text
description: "status of the verification"
- name: nightly_fee_local
data_type: double precision
2024-12-03 10:37:05 +01:00
description: "fee in local currency charged per night"
2024-11-29 09:59:35 +01:00
- name: number_nights
data_type: integer
description: "number of nights for the booking"
2024-12-02 08:44:24 +01:00
- name: total_fee_local
data_type: double precision
2024-12-03 10:37:05 +01:00
description: "total fee in local currency for the booking"
2024-12-02 08:44:24 +01:00
2024-11-29 09:59:35 +01:00
- name: email_flag
data_type: text
description: "screening result for email"
- name: phone_flag
data_type: text
description: "screening result for phone"
- name: watch_list
data_type: text
description: "screening result of the guest"
- name: channel
data_type: text
description: ""
- name: checkin_at_utc
data_type: timestamp without time zone
description: "Timestamp of checkin for the booking"
- name: checkin_date_utc
data_type: date
description: "Date of checkin for the booking"
- name: checkout_at_utc
data_type: timestamp without time zone
description: "Timestamp of checkout for the booking"
- name: checkout_date_utc
data_type: date
description: "Date of checkout for the booking"
- name: is_cancelled
data_type: boolean
description: ""
- name: cancelled_at_utc
data_type: timestamp without time zone
description: "Timestamp of cancellation of the booking"
- name: cancelled_date_utc
data_type: date
description: "Date of cancellation for the booking"
- name: user_email
data_type: text
description: ""
- name: guest_email
data_type: text
description: ""
- name: guest_last_name
data_type: text
description: ""
- name: guest_first_name
data_type: text
description: ""
- name: guest_telephone
data_type: text
description: ""
- name: company_name
data_type: text
description: ""
- name: property_manager_name
data_type: text
description: ""
- name: property_manager_email
data_type: text
description: ""
- name: listing_name
data_type: text
description: ""
2024-12-03 10:37:05 +01:00
- name: listing_address
data_type: text
description: ""
2024-11-29 09:59:35 +01:00
- name: listing_town
data_type: text
description: ""
- name: listing_country
data_type: text
description: ""
- name: listing_postcode
data_type: text
description: ""
- name: pets_allowed
data_type: boolean
description: ""
- name: level_of_protection_amount
data_type: integer
description: ""
- name: level_of_protection_currency
data_type: text
description: ""
- name: status_updated_at_utc
data_type: timestamp without time zone
description: "Timestamp when status was last updated"
- name: status_updated_date_utc
data_type: date
description: "Date of last status update of the verification"
- name: updated_at_utc
data_type: timestamp without time zone
description: "Timestamp of last updated of the verification"
- name: updated_date_utc
data_type: date
description: "Date of last update of the verification"
- name: athena_creation_at_utc
data_type: timestamp without time zone
description:
"Athena timestamp referring to when the booking was created.
It's provided by Guesty, but is not mandatory.
In case of doubt use created_at_utc or created_date_utc fields"
- name: athena_creation_date_utc
data_type: date
description: "Athena date referring to when the booking was created.
It's provided by Guesty, but is not mandatory.
In case of doubt use created_at_utc or created_date_utc fields"
- name: created_at_utc
data_type: timestamp without time zone
description: "Timestamp of creation of the verification in the system"
- name: created_date_utc
data_type: date
description: "Date of creation of the verification in the system"
- name: int_monthly_aggregated_metrics_history_by_deal_by_time_window
description: |
This model aggregates monthly historic metrics for deals over different time windows.
It provides insights into bookings, listings, revenue, retained revenue and
additional metrics.
The data is segmented by deal and time window for detailed analysis.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- id_deal
- time_window
Merged PR 4970: Fix data quality issue on Revenue Retained metrics # Description As raised by Kayla, Retained metrics are not computed correctly in AM Account Margin report, see screenshot: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/4970/attachments/image.png) Issue lies in the fact that Guest Payments contains more dimensions than the rest of the models. This is generating duplicates in the combination_of_sources CTE, but these are effectively hidden because of the sum() applied of the metrics. In the case of a Deal having in the same day Guest Payments with different dimensions from those selected, AND on the same day having a value on Invoiced Revenue or Host Resolutions, then the Invoiced Revenue or Host Resolutions would be duplicated. This PR aims to fix this issue, and also adds a few tests on the base model for AM Account Margin to ensure this is kind of error raises an alert. I'll be debugging other affected models and increase the robustness test-wise; as well as gathering the full impact. # Checklist - [X] The edited models and dependants run properly 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. - [ ] 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: #29227
2025-04-10 07:23:31 +00:00
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: total_revenue_in_gbp
column_B: invoiced_revenue_in_gbp + guest_payments_in_gbp
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: revenue_retained_in_gbp
column_B: total_revenue_in_gbp + waiver_paid_back_to_host_in_gbp
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: revenue_retained_post_resolutions_in_gbp
column_B: revenue_retained_in_gbp + host_resolution_amount_paid_in_gbp
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: guest_revenue_retained_in_gbp
column_B: guest_payments_in_gbp + waiver_paid_back_to_host_in_gbp
columns:
- name: date
data_type: date
description: |
The last day of the month or yesterday for historic metrics.
It's the same date as for KPIs related models.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: id_deal
data_type: character varying
description: Id of the deal associated to the host.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- name: time_window
data_type: character varying
description: |
Identifier of the time window used for the aggregation of the metrics.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
- accepted_values:
values:
- All History
- Previous 12 months
- Previous 6 months
- Previous 3 months
- Previous month
- name: client_type
data_type: string
description: |
Type of client. It can be either PLATFORM or API.
data_tests:
- not_null
- accepted_values:
values:
- PLATFORM
- API
2025-03-14 11:48:22 +01:00
- name: business_scope
data_type: string
description: |
Business scope identifying the metric source.
data_tests:
- not_null
- accepted_values:
values:
- "Old Dash"
- "New Dash"
- "API"
- "UNSET"
- name: metric_from_date
data_type: date
description: |
The first day of the month corresponding to the lower bound
range in which the metric is computed. It can be null if
there's no previous history for that deal. It can vary from
deal to deal depending on the number of months the deal has
been active.
- name: metric_to_date
data_type: date
description: |
The first day of the month corresponding to the upper bound
range in which the metric is computed. It can be null if
there's no previous history for that deal.
- name: main_deal_name
data_type: string
description: |
Main name for this ID deal.
2025-01-13 16:00:35 +01:00
data_tests:
- not_null
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: 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: |
ISO 3166-1 alpha-3 main country code in which the Deal is billed.
In some cases it's null.
- name: deal_lifecycle_state
data_type: string
description: |
Lifecycle state of the deal.
- name: deal_hubspot_stage
data_type: string
description: |
Hubspot stage of the deal.
In some cases it's null.
- name: account_manager
data_type: string
description: |
Account manager of the deal.
In some cases it's null.
- name: live_date_utc
data_type: date
description: |
Date when the deal went live according to
Hubspot. In some cases it's null.
- name: cancellation_date_utc
data_type: date
description: |
Date when the deal was cancelled according to
Hubspot. It can be null if the deal has never
churned.
- name: months_between_live_and_churn
2025-03-07 10:17:11 +01:00
data_type: integer
description: |
Number of months between the live date and the
2025-03-07 10:17:11 +01:00
churn date.
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: last_contacted_date_utc
data_type: date
description: |
Date when the deal was last contacted according to
Hubspot.
- name: days_between_last_contacted_and_churn
data_type: integer
description: |
Number of days between the last contacted date
and the churn date.
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: amount_times_contacted
data_type: integer
description: |
Number of times the deal was contacted according
to Hubspot.
2025-03-14 10:12:54 +01:00
- name: cancellation_category
data_type: text
description: Categorization as to why they cancelled the account
- name: cancellation_details
data_type: text
description: Free text with additional comments on why they cancelled the account
2025-03-07 11:32:09 +01:00
- name: is_churning
2025-03-07 10:17:11 +01:00
data_type: boolean
description: |
2025-03-07 11:32:09 +01:00
Flag to identify if the deal is churning or not.
- name: churn_reason
data_type: string
description: |
Reason why the deal is churning.
data_tests:
- accepted_values:
values:
- "INACTIVITY"
- "ACCOUNT CANCELLATION"
2025-03-07 10:17:11 +01:00
- name: created_bookings
data_type: integer
description: |
Total amount of bookings created by the deal
in the time window. It can be null if no bookings
were created.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: listings_booked_in_month
data_type: decimal
description: |
Average amount of listings booked in month by the deal
in the time window. It can be null if no listings
were booked.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: total_revenue_in_gbp
data_type: decimal
description: |
Total revenue in GBP generated by the deal in the
time window. It can be null if no revenue was generated.
It can be negative.
- name: revenue_retained_in_gbp
data_type: decimal
description: |
Total revenue in GBP retained by the deal in the
time window, post host takeaway waivers.
It can be null if no revenue was retained.
It can be negative.
- name: waiver_paid_back_to_host_in_gbp
data_type: decimal
description: |
Total amount of waivers paid back to the host in GBP
in the time window. It can be null if no waivers were
paid back. It's displayed as a negative value.
- name: invoiced_revenue_in_gbp
data_type: decimal
description: |
Total amount of revenue in GBP invoiced to the host
in the time window. It considers both Operator revenue as
well as APIs revenue. It can be null if no revenue was
invoiced to the host. It can be negative.
- name: guest_payments_in_gbp
data_type: decimal
description: |
Total amount of payments in GBP made by the guest
in the time window. It can be null if no payments
were made by the guest. It can be negative.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: guest_revenue_retained_in_gbp
data_type: decimal
description: |
Total amount of revenue in GBP retained by the deal
from the guest in the time window, post host takeaway waivers.
It can be null if no revenue was retained from the guest.
It can be negative.
- name: host_resolution_payment_count
data_type: integer
description: |
Total amount of resolution payments made to the host
in the time window. It can be null if no resolution
payments were made by the host.
2025-01-13 16:00:35 +01:00
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: host_resolution_amount_paid_in_gbp
data_type: decimal
description: |
Total amount of resolution payments made to the host
in GBP in the time window. It can be null if no resolution
payments were made by the host. It can be negative.
It's displayed as a negative value. In some extreme
cases, it can be higher than 0.
- name: revenue_retained_post_resolutions_in_gbp
data_type: decimal
description: |
Total amount of revenue in GBP retained by the deal
post waiver payouts and resolution payouts in the time window.
It can be null if no revenue was retained post resolution payments.
It can be negative, thus indicating that we are losing money.
2025-01-03 11:29:58 +01:00
- name: int_deals_consolidation
description: |
"This table contains all deal ids from different sources used in Superhog.
It contains the source (Hubspot, Xero or Core), the id_deal and the name"
columns:
- name: id_deal
data_type: character varying
description: "Unique ID for this deal."
2025-01-13 16:00:35 +01:00
data_tests:
2025-01-03 11:29:58 +01:00
- unique
- not_null
- name: core_company_name
data_type: character varying
description: "Company name of the deal as shown in Core."
- name: core_company_name_count
data_type: integer
description: "Count of distinct names the deal has in Core.
It might be the case that a deal has ony NULL value for a name,
so the count will be 0"
2025-01-13 16:00:35 +01:00
data_tests:
2025-01-03 11:29:58 +01:00
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: hubspot_deal_name
data_type: character varying
description: "Name of the deal as shown in Hubspot."
- name: hubspot_deal_name_count
data_type: integer
description: "Count of distinct names the deal has in Hubspot.
It might be the case that a deal has ony NULL value for a name,
so the count will be 0"
2025-01-13 16:00:35 +01:00
data_tests:
2025-01-03 11:29:58 +01:00
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: xero_contact_name
data_type: character varying
description: "Contact name of the deal as shown in Xero."
- name: xero_contact_name_count
data_type: integer
description: "Count of distinct names the deal has in Xero.
It might be the case that a deal has ony NULL value for a name,
so the count will be 0"
2025-01-13 16:00:35 +01:00
data_tests:
2025-01-03 11:29:58 +01:00
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: is_deal_in_core
data_type: boolean
description: "Flag to indicate if the deal is in Core."
- name: is_deal_in_hubspot
data_type: boolean
description: "Flag to indicate if the deal is in Hubspot."
- name: is_deal_in_xero
data_type: boolean
description: "Flag to indicate if the deal is in Xero."
2025-01-13 17:26:34 +01:00
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: int_ytd_mtd_main_metrics_overview
description: |
This model provides a high-level overview of the main metrics for the month-to-date
and financial year-to-date periods.
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- dimension
- dimension_value
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: current_month_mtd_revenue_retained_post_resolutions_in_gbp
column_B: current_month_mtd_total_revenue_in_gbp + current_month_mtd_xero_waiver_paid_back_to_host_in_gbp + current_month_mtd_xero_host_resolution_amount_paid_in_gbp
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: current_ytd_revenue_retained_post_resolutions_in_gbp
column_B: current_ytd_total_revenue_in_gbp + current_ytd_xero_waiver_paid_back_to_host_in_gbp + current_ytd_xero_host_resolution_amount_paid_in_gbp
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: current_month_mtd_total_revenue_in_gbp
column_B: current_month_mtd_total_guest_payments_in_gbp + current_month_mtd_xero_apis_net_fees_in_gbp + current_month_mtd_xero_operator_net_fees_in_gbp
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: current_ytd_total_revenue_in_gbp
column_B: current_ytd_total_guest_payments_in_gbp + current_ytd_xero_apis_net_fees_in_gbp + current_ytd_xero_operator_net_fees_in_gbp
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
columns:
- name: date
data_type: date
description: |
The date for the month-to-date and year-to-date metrics.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
data_tests:
- not_null
- name: dimension
data_type: string
description: |
The dimension or granularity of the metrics.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
data_tests:
- accepted_values:
values:
- global
- name: dimension_value
data_type: string
description: |
The value or segment available for the selected dimension.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
data_tests:
- not_null
- name: calendar_year
data_type: integer
description: |
The calendar year associated with the data.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: financial_year
data_type: integer
description: |
The financial year associated with the data.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_date
data_type: date
description: |
The equivalent date in the previous year.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_billable_bookings
data_type: integer
description: |
Total billable bookings for the current month MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_churning_deals
data_type: integer
description: |
Number of churning deals for the current month MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_live_deals
data_type: integer
description: |
Number of live deals for the current month MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_new_deals
data_type: integer
description: |
Number of new deals for the current month MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_operator_revenue_per_billable_booking
data_type: numeric
description: |
Operator revenue per billable booking for the
current month MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_resolutions_payout_rate
data_type: numeric
description: |
Resolutions payout rate for the current month MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_revenue_retained_post_resolutions_in_gbp
data_type: numeric
description: |
Revenue retained after resolutions for the current
month MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_total_guest_payments_in_gbp
data_type: numeric
description: |
Total guest payments for the current month MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_total_revenue_in_gbp
data_type: numeric
description: |
Total revenue for the current month MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_waiver_payments_in_gbp
data_type: numeric
description: |
Total waiver payments made in GBP for the current month MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_waiver_payout_rate
data_type: numeric
description: |
Waiver payout rate for the current month MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_waiver_revenue_per_billable_booking
data_type: numeric
description: |
Waiver revenue per billable booking for the current month MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_xero_apis_net_fees_in_gbp
data_type: numeric
description: |
Net fees for APIs processed through Xero for
the current month MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_xero_host_resolution_amount_paid_in_gbp
data_type: numeric
description: |
Amount paid to hosts for resolutions processed
through Xero for the current month MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_xero_operator_net_fees_in_gbp
data_type: numeric
description: |
Net fees for operators processed through Xero
for the current month MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_xero_waiver_paid_back_to_host_in_gbp
data_type: numeric
description: |
Waiver amounts paid back to hosts via Xero
for the current month MTD in GBP.
- name: current_month_mtd_total_revenue_churn_12m
data_type: numeric
description: |
Total revenue in the last 12 months that was generated by
deals that have churned in the current month MTD.
- name: current_month_mtd_total_revenue_global_12m
data_type: numeric
description: |
Total revenue in the last 12 months that was generated by any
deal, indistinctly of it being active, churn, etc. for the
current month MTD. This is only used to compute the churn rate.
- name: current_month_mtd_total_revenue_churn_rate
data_type: numeric
description: |
Total revenue churn rate for the current month MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_month_mtd_booking_net_fees_in_gbp
data_type: numeric
description: |
Total Booking net fees in gbp for the current month MTD.
- name: current_month_mtd_booking_net_fees_per_billable_booking
data_type: numeric
description: |
Total Booking net fees per billable booking for the current month MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_billable_bookings
data_type: integer
description: |
Total billable bookings for the previous year (12 months ago) MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_churning_deals
data_type: integer
description: |
Number of churning deals for the previous year (12 months ago) MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_live_deals
data_type: integer
description: |
Number of live deals for the previous year (12 months ago) MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_new_deals
data_type: integer
description: |
Number of new deals for the previous year (12 months ago) MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_operator_revenue_per_billable_booking
data_type: numeric
description: |
Operator revenue per billable booking for the
previous year (12 months ago) MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_resolutions_payout_rate
data_type: numeric
description: |
Resolutions payout rate for the previous year
(12 months ago) MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_revenue_retained_post_resolutions_in_gbp
data_type: numeric
description: |
Revenue retained after resolutions for the previous year
(12 months ago) MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_total_guest_payments_in_gbp
data_type: numeric
description: |
Total guest payments for the previous year (12 months ago)
MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_total_revenue_in_gbp
data_type: numeric
description: |
Total revenue for the previous year (12 months ago) MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_waiver_payments_in_gbp
data_type: numeric
description: |
Total waiver payments made in GBP for the previous
year (12 months ago) MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_waiver_payout_rate
data_type: numeric
description: |
Waiver payout rate for the previous year (12 months ago) MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_waiver_revenue_per_billable_booking
data_type: numeric
description: |
Waiver revenue per billable booking for the
previous year (12 months ago) MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_xero_apis_net_fees_in_gbp
data_type: numeric
description: |
Net fees for APIs processed through Xero for the
previous year (12 months ago) MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_xero_host_resolution_amount_paid_in_gbp
data_type: numeric
description: |
Amount paid to hosts for resolutions processed through
Xero for the previous year (12 months ago) MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_xero_operator_net_fees_in_gbp
data_type: numeric
description: |
Net fees for operators processed through Xero for the
previous year (12 months ago) MTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_xero_waiver_paid_back_to_host_in_gbp
data_type: numeric
description: |
Waiver amounts paid back to hosts via Xero for the
previous year (12 months ago) MTD in GBP.
- name: previous_year_mtd_total_revenue_churn_12m
data_type: numeric
description: |
Total revenue in the last 12 months that was generated by
deals that have churned in the previous year
(12 months ago) MTD.
- name: previous_year_mtd_total_revenue_global_12m
data_type: numeric
description: |
Total revenue generated globally in the last 12 months
for the previous year (12 months ago) MTD.
This is only used to compute the churn rate.
- name: previous_year_mtd_total_revenue_churn_rate
data_type: numeric
description: |
Total revenue churn rate for the previous year
(12 months ago) MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_year_mtd_booking_net_fees_in_gbp
data_type: numeric
description: |
Total Booking net fees in gbp for the previous
year (12 months ago) MTD.
- name: previous_year_mtd_booking_net_fees_per_billable_booking
data_type: numeric
description: |
Total Booking net fees per billable booking for the
previous year (12 months ago) MTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_billable_bookings
data_type: integer
description: |
Total billable bookings for the current financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_churning_deals
data_type: integer
description: |
Number of churning deals for the current financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_live_deals
data_type: integer
description: |
Number of live deals for the current financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_new_deals
data_type: integer
description: |
Number of new deals for the current financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_operator_revenue_per_billable_booking
data_type: numeric
description: |
Operator revenue per billable booking for the current
financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_resolutions_payout_rate
data_type: numeric
description: |
Resolutions payout rate for the current financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_revenue_retained_post_resolutions_in_gbp
data_type: numeric
description: |
Revenue retained after resolutions for the current
financial year YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_total_guest_payments_in_gbp
data_type: numeric
description: |
Total guest payments for the current financial year
YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_total_revenue_in_gbp
data_type: numeric
description: |
Total revenue for the current financial year YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_waiver_payments_in_gbp
data_type: numeric
description: |
Total waiver payments made in GBP for the current
financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_waiver_payout_rate
data_type: numeric
description: |
Waiver payout rate for the current financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_waiver_revenue_per_billable_booking
data_type: numeric
description: |
Waiver revenue per billable booking for the current
financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_xero_apis_net_fees_in_gbp
data_type: numeric
description: |
Net fees for APIs processed through Xero for
the current financial year YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_xero_host_resolution_amount_paid_in_gbp
data_type: numeric
description: |
Amount paid to hosts for resolutions processed through
Xero for the current financial year YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_xero_operator_net_fees_in_gbp
data_type: numeric
description: |
Net fees for operators processed through Xero
for the current financial year YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_xero_waiver_paid_back_to_host_in_gbp
data_type: numeric
description: |
Waiver amounts paid back to hosts via Xero
for the current financial year YTD in GBP.
- name: current_ytd_total_revenue_churn_12m
data_type: numeric
description: |
Total revenue in the last 12 months that was generated by
deals that have churned in the period of the current
financial year YTD.
- name: current_ytd_total_revenue_global_12m
data_type: numeric
description: |
Total revenue generated globally in the last 12 months
for the current financial year YTD.
This is only used to compute the churn rate.
- name: current_ytd_total_revenue_churn_rate
data_type: numeric
description: |
Total revenue churn rate for the current financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: current_ytd_booking_net_fees_in_gbp
data_type: numeric
description: |
Total booking net fees in gbp for the current financial year YTD.
- name: current_ytd_booking_net_fees_per_billable_booking
data_type: numeric
description: |
Total booking net fees per billable booking for the
current financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_billable_bookings
data_type: integer
description: |
Total billable bookings for the previous financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_churning_deals
data_type: integer
description: |
Number of churning deals for the previous financial
year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_live_deals
data_type: integer
description: |
Number of live deals for the previous financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_new_deals
data_type: integer
description: |
Number of new deals for the previous financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_operator_revenue_per_billable_booking
data_type: numeric
description: |
Operator revenue per billable booking for the previous
financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_resolutions_payout_rate
data_type: numeric
description: |
Resolutions payout rate for the previous financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_revenue_retained_post_resolutions_in_gbp
data_type: numeric
description: |
Revenue retained after resolutions for the previous
financial year YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_total_guest_payments_in_gbp
data_type: numeric
description: |
Total guest payments for the previous financial year YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_total_revenue_in_gbp
data_type: numeric
description: |
Total revenue for the previous financial year YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_waiver_payments_in_gbp
data_type: numeric
description: |
Total waiver payments made in GBP for the previous
financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_waiver_payout_rate
data_type: numeric
description: |
Waiver payout rate for the previous financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_waiver_revenue_per_billable_booking
data_type: numeric
description: |
Waiver revenue per billable booking for
the previous financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_xero_apis_net_fees_in_gbp
data_type: numeric
description: |
Net fees for APIs processed through Xero
for the previous financial year YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_xero_host_resolution_amount_paid_in_gbp
data_type: numeric
description: |
Amount paid to hosts for resolutions processed
through Xero for the previous financial year YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_xero_operator_net_fees_in_gbp
data_type: numeric
description: |
Net fees for operators processed through Xero
for the previous financial year YTD in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_xero_waiver_paid_back_to_host_in_gbp
data_type: numeric
description: |
Waiver amounts paid back to hosts via Xero
for the previous financial year YTD in GBP.
- name: previous_ytd_total_revenue_churn_12m
data_type: numeric
description: |
Total revenue in the last 12 months that was generated by
deals that have churned in the period of the previous
financial year YTD.
- name: previous_ytd_total_revenue_global_12m
data_type: numeric
description: |
Total revenue generated globally in the last 12 months
for the previous financial year YTD.
This is only used to compute the churn rate.
- name: previous_ytd_total_revenue_churn_rate
data_type: numeric
description: |
Total revenue churn rate for the previous
financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_ytd_booking_net_fees_in_gbp
data_type: numeric
description: |
Total booking net fees in gbp for the previous financial year YTD.
- name: previous_ytd_booking_net_fees_per_billable_booking
data_type: numeric
description: |
Total booking net fees per billable booking for the
previous financial year YTD.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_billable_bookings
data_type: integer
description: |
Total billable bookings for the previous month,
at the end of the month.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_churning_deals
data_type: integer
description: |
Number of churning deals for the previous month,
at the end of the month.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_live_deals
data_type: integer
description: |
Number of live deals for the previous month,
at the end of the month.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_new_deals
data_type: integer
description: |
Number of new deals for the previous month,
at the end of the month.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_operator_revenue_per_billable_booking
data_type: numeric
description: |
Operator revenue per billable booking for
the previous month, at the end of the month.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_resolutions_payout_rate
data_type: numeric
description: |
Resolutions payout rate for the previous month,
at the end of the month.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_revenue_retained_post_resolutions_in_gbp
data_type: numeric
description: |
Revenue retained after resolutions for the
previous month, at the end of the month in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_total_guest_payments_in_gbp
data_type: numeric
description: |
Total guest payments for the previous month,
at the end of the month in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_total_revenue_in_gbp
data_type: numeric
description: |
Total revenue for the previous month, at the
end of the month in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_waiver_payments_in_gbp
data_type: numeric
description: |
Total waiver payments made in GBP for the previous
month, at the end of the month.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_waiver_payout_rate
data_type: numeric
description: |
Waiver payout rate for the previous month,
at the end of the month.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_waiver_revenue_per_billable_booking
data_type: numeric
description: |
Waiver revenue per billable booking for the previous month,
at the end of the month.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_xero_apis_net_fees_in_gbp
data_type: numeric
description: |
Net fees for APIs processed through Xero for the previous month,
at the end of the month in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_xero_host_resolution_amount_paid_in_gbp
data_type: numeric
description: |
Amount paid to hosts for resolutions processed through Xero for
the previous month, at the end of the month in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_xero_operator_net_fees_in_gbp
data_type: numeric
description: |
Net fees for operators processed through Xero for the previous month,
at the end of the month in GBP.
Merged PR 4439: First version of int_ytd_mtd_main_metrics_overview # Description New model for the purpose of Main KPIs - Overview. It computes: * Current MTD value * Previous Month EOM value * Previous Year MTD value (12 months ago) * Current YTD value * Previous Year YTD value for the metrics: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Host Resolutions Amount Paid * Damage Host Waiver Payments * Billable Bookings * New Deals * Churning Deals * Live Deals (dedicated logic handling) * Waiver Revenue Additionally it properly computes the following derived metrics: * Waiver Payout Rate * Resolutions Payout Rate * Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking Only for dimension = 'global', though should be easy to extend to other dimensions. This does not handle (yet) Onboarding MRR nor Revenue Churn Rate, mostly because I need to think how this can be properly attributed in a YTD basis. This does not compute variations (abs. diff. or rel. diff.) yet. This does not handle the "hiding" of invoicing metrics due to the invoicing cycle yet. This does not handle targets... yet! # Checklist - [X] The edited models and dependants run properly 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: #27609
2025-02-18 14:30:12 +00:00
- name: previous_month_eom_xero_waiver_paid_back_to_host_in_gbp
data_type: numeric
description: |
Waiver amounts paid back to hosts via Xero for the previous month,
at the end of the month in GBP.
- name: previous_month_eom_total_revenue_churn_12m
data_type: numeric
description: |
Total revenue in the last 12 months that was generated by
deals that have churned in the previous month, at the end of
the month, in GBP.
- name: previous_month_eom_total_revenue_global_12m
data_type: numeric
description: |
Total revenue generated globally in the last 12 months
for the previous month, at the end of the month.
This is only used to compute the churn rate.
- name: previous_month_eom_total_revenue_churn_rate
data_type: numeric
description: |
Total revenue churn rate for the previous month,
at the end of the month.
Merged PR 4443: First version of the aggregated model for YTD/MTD Overview # Description First version of the model int_ytd_mtd_aggregated_main_metrics_overview It aggregates data at the level of: * Date * Dimension * Dimension Value * Metric Name (or Id Metric) This computes differences and relative differences in: * current MTD vs previous month EOM * current MTD vs previous year MTD * current year YTD vs previous year YTD This is applied to 13 metrics, namely: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Billable Bookings * Live Deals * New Deals * Churning Deals * Damage Waiver Payout Rate * Host Resolutions Payout Rate * Invoiced Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking This still does not handle: * Comparison vs. targets (to be done later, need input) * Missing metrics on Onboarding MRR / Revenue Churn (to be done later) * Invoicing dependant data exclusion (to be done in reporting) # Checklist - [X] The edited models and dependants run properly 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. **At the moment I keep everything as views and seems ok. We'll see if this needs to be materialised as tables later on** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27609
2025-02-18 15:45:24 +00:00
- name: previous_month_eom_booking_net_fees_in_gbp
data_type: numeric
description: |
Total booking net fees in gbp for the previous
month at the end of the month.
- name: previous_month_eom_booking_net_fees_per_billable_booking
data_type: numeric
description: |
Total booking net fees per billable booking for the
previous month at the end of the month.
Merged PR 4443: First version of the aggregated model for YTD/MTD Overview # Description First version of the model int_ytd_mtd_aggregated_main_metrics_overview It aggregates data at the level of: * Date * Dimension * Dimension Value * Metric Name (or Id Metric) This computes differences and relative differences in: * current MTD vs previous month EOM * current MTD vs previous year MTD * current year YTD vs previous year YTD This is applied to 13 metrics, namely: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Billable Bookings * Live Deals * New Deals * Churning Deals * Damage Waiver Payout Rate * Host Resolutions Payout Rate * Invoiced Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking This still does not handle: * Comparison vs. targets (to be done later, need input) * Missing metrics on Onboarding MRR / Revenue Churn (to be done later) * Invoicing dependant data exclusion (to be done in reporting) # Checklist - [X] The edited models and dependants run properly 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. **At the moment I keep everything as views and seems ok. We'll see if this needs to be materialised as tables later on** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27609
2025-02-18 15:45:24 +00:00
- name: int_ytd_mtd_aggregated_main_metrics_overview
description: |
This model provides a high-level overview of the main metrics for the month-to-date
and financial year-to-date periods. Data is aggregated at metric level, and provides
evolutions current month MTD vs. previous month EOM, current month MTD vs. previous
year MTD and current YTD vs. previous YTD.
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- dimension
- dimension_value
- metric_name
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- dimension
- dimension_value
- id_metric
columns:
- name: date
data_type: date
description: The date for the month-to-date and year-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
- name: dimension_value
data_type: string
description: The value or segment available for the selected dimension.
data_tests:
- not_null
- name: calendar_year
data_type: integer
description: The calendar year associated with the data.
data_tests:
- not_null
- name: financial_year
data_type: integer
description: The financial year associated with the data.
data_tests:
- not_null
- name: previous_year_date
data_type: date
description: |
The equivalent date in the previous year. It can be null if the
metric is not available in the previous year
- name: id_metric
data_type: integer
description: |
Unique ID for this metric. It is preferable to use this ID when
building a report to ensure changes in the metric name do not
affect the report.
data_tests:
- not_null
- name: metric_name
data_type: string
description: |
Name of the metric. It is preferable to use the ID of the metric
when building a report to ensure changes in the metric name do not
affect the report.
data_tests:
- not_null
- name: number_format
data_type: string
description: |
Number format to display the metric in the report.
data_tests:
- not_null
- accepted_values:
values:
- INTEGER
- PERCENTAGE_2_DECIMALS
- CURRENCY_GBP_INTEGER
- CURRENCY_GBP_1_DECIMAL
- name: display_exclusion
data_type: string
Merged PR 4443: First version of the aggregated model for YTD/MTD Overview # Description First version of the model int_ytd_mtd_aggregated_main_metrics_overview It aggregates data at the level of: * Date * Dimension * Dimension Value * Metric Name (or Id Metric) This computes differences and relative differences in: * current MTD vs previous month EOM * current MTD vs previous year MTD * current year YTD vs previous year YTD This is applied to 13 metrics, namely: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Billable Bookings * Live Deals * New Deals * Churning Deals * Damage Waiver Payout Rate * Host Resolutions Payout Rate * Invoiced Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking This still does not handle: * Comparison vs. targets (to be done later, need input) * Missing metrics on Onboarding MRR / Revenue Churn (to be done later) * Invoicing dependant data exclusion (to be done in reporting) # Checklist - [X] The edited models and dependants run properly 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. **At the moment I keep everything as views and seems ok. We'll see if this needs to be materialised as tables later on** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27609
2025-02-18 15:45:24 +00:00
description: |
Category to indicate if the metric requires a certain exclusion due
to relying on not timely information.
Merged PR 4443: First version of the aggregated model for YTD/MTD Overview # Description First version of the model int_ytd_mtd_aggregated_main_metrics_overview It aggregates data at the level of: * Date * Dimension * Dimension Value * Metric Name (or Id Metric) This computes differences and relative differences in: * current MTD vs previous month EOM * current MTD vs previous year MTD * current year YTD vs previous year YTD This is applied to 13 metrics, namely: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Billable Bookings * Live Deals * New Deals * Churning Deals * Damage Waiver Payout Rate * Host Resolutions Payout Rate * Invoiced Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking This still does not handle: * Comparison vs. targets (to be done later, need input) * Missing metrics on Onboarding MRR / Revenue Churn (to be done later) * Invoicing dependant data exclusion (to be done in reporting) # Checklist - [X] The edited models and dependants run properly 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. **At the moment I keep everything as views and seems ok. We'll see if this needs to be materialised as tables later on** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27609
2025-02-18 15:45:24 +00:00
This will limit the display for reporting purposes.
data_tests:
- not_null
- accepted_values:
values:
- NONE
- INVOICING
- ONGOING_MONTH
Merged PR 4443: First version of the aggregated model for YTD/MTD Overview # Description First version of the model int_ytd_mtd_aggregated_main_metrics_overview It aggregates data at the level of: * Date * Dimension * Dimension Value * Metric Name (or Id Metric) This computes differences and relative differences in: * current MTD vs previous month EOM * current MTD vs previous year MTD * current year YTD vs previous year YTD This is applied to 13 metrics, namely: * Total Revenue * Revenue Retained Post-Resolutions * Guest Revenue * Invoiced Operator Revenue * Invoiced APIs Revenue * Billable Bookings * Live Deals * New Deals * Churning Deals * Damage Waiver Payout Rate * Host Resolutions Payout Rate * Invoiced Operator Revenue per Billable Booking * Waiver Revenue per Billable Booking This still does not handle: * Comparison vs. targets (to be done later, need input) * Missing metrics on Onboarding MRR / Revenue Churn (to be done later) * Invoicing dependant data exclusion (to be done in reporting) # Checklist - [X] The edited models and dependants run properly 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. **At the moment I keep everything as views and seems ok. We'll see if this needs to be materialised as tables later on** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27609
2025-02-18 15:45:24 +00:00
- name: current_month_mtd
data_type: numeric
description: |
Value of the metric for the current month MTD.
- name: previous_month_eom
data_type: numeric
description: |
Value of the metric for the previous month EOM.
- name: previous_year_mtd
data_type: numeric
description: |
Value of the metric for the previous year MTD.
- name: current_year_ytd
data_type: numeric
description: |
Value of the metric for the current year YTD.
- name: previous_year_ytd
data_type: numeric
description: |
Value of the metric for the previous year YTD.
- name: diff_current_month_mtd_vs_previous_month_eom
data_type: numeric
description: |
Difference between the current month MTD and the previous month EOM.
- name: diff_current_month_mtd_vs_previous_year_mtd
data_type: numeric
description: |
Difference between the current month MTD and the previous year MTD.
- name: diff_current_ytd_vs_previous_ytd
data_type: numeric
description: |
Difference between the current year YTD and the previous year YTD.
- name: rel_diff_current_month_mtd_vs_previous_month_eom
data_type: numeric
description: |
Relative difference between the current month MTD and the previous month EOM.
- name: rel_diff_current_month_mtd_vs_previous_year_mtd
data_type: numeric
description: |
Relative difference between the current month MTD and the previous year MTD.
- name: rel_diff_current_ytd_vs_previous_ytd
data_type: numeric
description: |
Relative difference between the current year YTD and the previous year YTD.
- name: target_eom_value
data_type: numeric
description: |
The EOM target value for this metric. This is the value that we aim to
achieve by the end of the month. It can be null if the target is not
available.
- name: target_ytd_value
data_type: numeric
description: |
The YTD target value for this metric. This is the cumulative value that we
aim to achieve by the end of each month with respect to the beginning of the
financial year, that will put us to reach the EOFY target. It can be null if
the target is not available.
- name: target_eofy_value
data_type: numeric
description: |
The EOFY target value for this metric. This is the value that we aim to
achieve by the end of the financial year. It can be null if the target is
not available.
- name: diff_current_month_mtd_vs_eom_target
data_type: numeric
description: |
Difference between the current month MTD and the EOM target. It can be null
if the target is not available.
- name: diff_current_ytd_vs_ytd_target
data_type: numeric
description: |
Difference between the current year YTD and the YTD target. It can be null
if the target is not available.
- name: diff_current_ytd_vs_eofy_target
data_type: numeric
description: |
Difference between the current year YTD and the EOFY target. It can be null
if the target is not available.
- name: rel_diff_current_month_mtd_vs_eom_target
data_type: numeric
description: |
Relative difference between the current month MTD and the EOM target. It can be null
if the target is not available.
- name: rel_diff_current_ytd_vs_ytd_target
data_type: numeric
description: |
Relative difference between the current year YTD and the YTD target. It can be null
if the target is not available.
- name: achievement_rate_current_ytd_vs_eofy_target
data_type: numeric
description: |
Achievement rate between the current year YTD and the EOFY target. It can be null
if the target is not available.
- name: rel_diff_with_sign_current_month_mtd_vs_previous_month_eom
data_type: numeric
description: |
Relative difference between the current month MTD and the previous month EOM,
with a sign to represent if the relative difference is good (positive) or bad
(negative) for our business.
- name: rel_diff_with_sign_current_month_mtd_vs_previous_year_mtd
data_type: numeric
description: |
Relative difference between the current month MTD and the previous year MTD,
with a sign to represent if the relative difference is good (positive) or bad
(negative) for our business.
- name: rel_diff_with_sign_current_ytd_vs_previous_ytd
data_type: numeric
description: |
Relative difference between the current year YTD and the previous year YTD,
with a sign to represent if the relative difference is good (positive) or bad
(negative) for our business.
- name: rel_diff_with_sign_current_month_mtd_vs_eom_target
data_type: numeric
description: |
Relative difference between the current month MTD and the EOM target,
with a sign to represent if the relative difference is good (positive) or bad
(negative) for our business.
- name: rel_diff_with_sign_current_ytd_vs_ytd_target
data_type: numeric
description: |
Relative difference between the current year YTD and the YTD target,
with a sign to represent if the relative difference is good (positive) or bad
(negative) for our business.
- name: int_mtd_aggregated_metrics_by_deal
description: |
This model aggregates the historic information of our business by providing
different metrics at account level (by id_deal).
Additionally it provides Deal attributes.
Metrics displayed in the model range for the past 24 months. Also, churned
accounts are available for historical values, until 3 months after the offboarding
date.
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- metric
- id_deal
columns:
- name: year
data_type: int
description: Year number of the given date.
- name: month
data_type: int
description: Month number of the given date.
- name: day
data_type: int
description: Day monthly number of the given date.
- name: is_end_of_month
data_type: boolean
description: Is end of month, 1 for yes, 0 for no.
- name: is_current_month
data_type: boolean
description: |
Checks if the date is within the current executed month,
1 for yes, 0 for no.
- name: is_end_of_month_or_yesterday
data_type: boolean
description: |
Checks if the date is end of month or yesterday,
1 for yes, 0 for no.
- name: first_day_month
data_type: date
description: |
First day of the month corresponding to the date field.
It comes from int_dates_mtd logic.
- name: date
data_type: date
description: |
Main date for the computation, that is used for filters.
It comes from int_dates_mtd logic.
data_tests:
- not_null
- name: id_deal
data_type: string
description: |
Unique ID for a deal, or account.
data_tests:
- not_null
- name: deal
data_type: string
description: |
Combination of the ID and the Name of the deal.
- 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.
- name: main_billing_country_iso_3_per_deal
data_type: string
description: |
ISO 3166-1 alpha-3 main country code in which the Deal is billed.
In some cases it's null.
- name: business_scope
data_type: string
description: |
Business scope identifying the metric source.
- name: account_manager
data_type: string
description: |
Account manager of the deal.
In some cases it's null.
- name: deal_lifecycle_state
data_type: string
description: |
Lifecycle state of the deal.
- name: metric
data_type: text
description: Name of the business metric.
data_tests:
- not_null
- name: order_by
data_type: integer
description: |
Order for displaying purposes. Null values are accepted, but keep
in mind that then there's no default controlled display order.
- name: number_format
data_type: text
description: Allows for grouping and formatting for displaying purposes.
- name: value
data_type: numeric
description: |
Numeric value (integer or decimal) that corresponds to the MTD computation of the metric
at a given date. Note that if the month is not in progress, then this value corresponds
to the monthly figure.
- name: previous_year_value
data_type: numeric
description: |
Numeric value (integer or decimal) that corresponds to the MTD computation of the metric
on the previous year at a given date.
- name: relative_increment
data_type: numeric
description: |
Numeric value that corresponds to the relative increment between value and previous year value,
following the computation: value / previous_year_value - 1.
- name: relative_increment_with_sign_format
data_type: numeric
description: |
Relative_increment value multiplied by -1 in case this metric's growth doesn't have a
positive impact for Truvi, otherwise is equal to relative_increment.
This value is specially created for formatting in PBI
- name: display_exclusion
data_type: string
description: |
Category to indicate if the metric requires a certain exclusion due
to relying on not timely information.
This will limit the display for reporting purposes.
data_tests:
- not_null
- accepted_values:
values:
- NONE
- INVOICING
- ONGOING_MONTH
Merged PR 4996: First tracking of flagging performance # Description Creates 2 new models in the scope of flagging: how good are we at identifying "at risk" bookings vs. 1) the number of claims generated and 2) the number of submitted payouts? This only applies for Protected Bookings in New Dash that have been completed (14 days after the check-out) with potential resolutions appearing in Resolutions Center. The first table `int_flagging_booking_categorisation` contains all the heavy logic to categorise the bookings. The second view `int_flagging_performance_analysis` computes standard binary classification scores, for the 2 possible ways of tracking. Tables are already in prod to help you understand while reviewing. You'll see that the figures are still quite low, specially due to small amount of claims/submitted payouts. This makes the true positives being just... 1. There's heavy test and documentation coverage to ensure there's no mistakes on the computation. # Checklist - [X] The edited models and dependants run properly 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. **Materialising as table the first model despite being just 1 record since otherwise tests takes ages** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #29284
2025-04-15 10:14:02 +00:00
- name: int_flagging_booking_categorisation
description: |
A model that computes different Booking counts depending whether these
had claims or not, if these were categorised at risk or not, and if there
was a submitted payout or not.
This only applies for Bookings:
- that come from New Dash users
- that are protected, either by a protection or a deposit management service
Additionally, we track Completed Bookings as those Bookings which, as of today,
have been checked out for more than natural 14 days.
From these Bookings, we check if these had an incident related in Resolution
Center:
- that is linked to a Booking
- that is not in a duplicated status
Since Bookings can be duplicated in the incidents data, we effectively consider:
- Bookings with "any" claim
- Bookings with a finished claim, either with a payout or not
- Bookings with a finished claim and a submitted amount for payout
data_tests:
- dbt_expectations.expect_table_row_count_to_equal:
value: 1
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: total_bookings
column_B: completed_bookings + not_completed_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: total_with_claim_bookings
column_B: completed_with_claim_bookings + not_completed_with_claim_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_bookings
column_B: completed_with_claim_bookings + completed_without_claim_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_bookings
column_B: completed_risk_bookings + completed_no_risk_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_risk_bookings
column_B: completed_risk_with_claim_bookings + completed_risk_without_claim_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_with_claim_bookings
column_B: completed_risk_with_claim_bookings + completed_no_risk_with_claim_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_no_risk_bookings
column_B: completed_no_risk_with_claim_bookings + completed_no_risk_without_claim_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_without_claim_bookings
column_B: completed_risk_without_claim_bookings + completed_no_risk_without_claim_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_bookings
column_B: completed_awaiting_resolution_bookings + completed_not_awaiting_resolution_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_not_awaiting_resolution_bookings
column_B: completed_with_submitted_payout_bookings + completed_without_submitted_payout_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_with_submitted_payout_bookings
column_B: completed_risk_with_submitted_payout_bookings + completed_no_risk_with_submitted_payout_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_without_submitted_payout_bookings
column_B: completed_risk_without_submitted_payout_bookings + completed_no_risk_without_submitted_payout_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_bookings
column_B: completed_risk_with_claim_bookings + completed_no_risk_without_claim_bookings + completed_risk_without_claim_bookings + completed_no_risk_with_claim_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_not_awaiting_resolution_bookings
column_B: completed_risk_with_submitted_payout_bookings + completed_no_risk_without_submitted_payout_bookings + completed_risk_without_submitted_payout_bookings + completed_no_risk_with_submitted_payout_bookings
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: total_amount_paid_in_gbp
column_B: completed_amount_paid_in_gbp + not_completed_amount_paid_in_gbp
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_amount_paid_in_gbp
column_B: completed_finished_incidents_amount_paid_in_gbp + completed_awaiting_finish_incidents_amount_paid_in_gbp
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: completed_finished_incidents_amount_paid_in_gbp
column_B: completed_risk_with_submitted_payout_amount_paid_in_gbp + completed_no_risk_with_submitted_payout_amount_paid_in_gbp
Merged PR 4996: First tracking of flagging performance # Description Creates 2 new models in the scope of flagging: how good are we at identifying "at risk" bookings vs. 1) the number of claims generated and 2) the number of submitted payouts? This only applies for Protected Bookings in New Dash that have been completed (14 days after the check-out) with potential resolutions appearing in Resolutions Center. The first table `int_flagging_booking_categorisation` contains all the heavy logic to categorise the bookings. The second view `int_flagging_performance_analysis` computes standard binary classification scores, for the 2 possible ways of tracking. Tables are already in prod to help you understand while reviewing. You'll see that the figures are still quite low, specially due to small amount of claims/submitted payouts. This makes the true positives being just... 1. There's heavy test and documentation coverage to ensure there's no mistakes on the computation. # Checklist - [X] The edited models and dependants run properly 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. **Materialising as table the first model despite being just 1 record since otherwise tests takes ages** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #29284
2025-04-15 10:14:02 +00:00
columns:
- name: total_bookings
data_type: integer
description: |
Current count of New Dash Protected Bookings, either a Protection Service
or a Deposit Management service, for reference.
- name: completed_bookings
data_type: integer
description: |
Current count of New Dash Protected Bookings with a Checkout happening
more than 14 days ago.
- name: not_completed_bookings
data_type: integer
description: |
Current count of New Dash Protected Bookings with a Checkout happening
between 14 days ago and today, or in the future.
- name: total_with_claim_bookings
data_type: integer
description: |
Current count of New Dash Protected Bookings that have had a claim,
indistinctly of these bookings being considered as completed or not.
- name: completed_with_claim_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
had a claim.
- name: not_completed_with_claim_bookings
data_type: integer
description: |
Current count of New Dash Protected, NOT Completed Bookings that have
had a claim.
- name: completed_without_claim_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
NOT had a claim.
- name: completed_risk_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
been flagged as at Risk.
- name: completed_no_risk_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
NOT been flagged as at Risk.
- name: completed_awaiting_resolution_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
a claim and are in a resolution status that is not finished. These
Bookings are excluded for the submitted payout-based performance
analysis, as we don't know if the claim will be paid out or not.
- name: completed_not_awaiting_resolution_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that are
not awaiting resolution, either because they have a claim in a finished
status or because they don't have a claim at all.
- name: completed_with_submitted_payout_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
had a submitted payout, with the claim being in a finished status.
- name: completed_without_submitted_payout_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
NOT had a submitted payout, either because there's a claim being in
a finished status without a payout or because there's no claim at all.
- name: completed_risk_with_claim_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
been flagged as at Risk AND that have had a claim.
For the claim-based performance analysis, this would be the true positive.
- name: completed_no_risk_without_claim_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
NOT been flagged as at Risk AND that have NOT had a claim.
For the claim-based performance analysis, this would be the true negative.
- name: completed_risk_without_claim_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
been flagged as at Risk AND that have NOT had a claim.
For the claim-based performance analysis, this would be the false positive.
- name: completed_no_risk_with_claim_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
NOT been flagged as at Risk AND that have had a claim.
For the claim-based performance analysis, this would be the false negative.
- name: completed_risk_with_submitted_payout_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
been flagged as at Risk AND that have had a submitted payout, with
the claim being in a finished status.
For the submitted payout-based performance analysis, this would be
the true positive.
- name: completed_no_risk_without_submitted_payout_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
NOT been flagged as at Risk AND that have NOT had a submitted payout,
either because there's a claim being in a finished status without a
payout or because there's no claim at all.
For the submitted payout-based performance analysis, this would be
the true negative.
- name: completed_risk_without_submitted_payout_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
been flagged as at Risk AND that have NOT had a submitted payout,
either because there's a claim being in a finished status without a
payout or because there's no claim at all.
For the submitted payout-based performance analysis, this would be
the false positive.
- name: completed_no_risk_with_submitted_payout_bookings
data_type: integer
description: |
Current count of New Dash Protected and Completed Bookings that have
NOT been flagged as at Risk AND that have had a submitted payout, with
the claim being in a finished status.
For the submitted payout-based performance analysis, this would be
the false negative.
- name: total_amount_paid_in_gbp
data_type: numeric
description: |
Total amount paid in GBP in terms of Resolutions Payouts for all
Bookings.
- name: completed_amount_paid_in_gbp
data_type: numeric
description: |
Total amount paid in GBP in terms of Resolutions Payouts for Completed
Bookings.
- name: not_completed_amount_paid_in_gbp
data_type: numeric
description: |
Total amount paid in GBP in terms of Resolutions Payouts for
Bookings that are not completed, for reference.
- name: completed_finished_incidents_amount_paid_in_gbp
data_type: numeric
description: |
Total amount paid in GBP in terms of Resolutions Payouts for Completed
Bookings that have had a claim in a finished status.
- name: completed_awaiting_finish_incidents_amount_paid_in_gbp
data_type: numeric
description: |
Total amount paid in GBP in terms of Resolutions Payouts for Completed
Bookings that have had a claim in a status that is not finished. These
Bookings are excluded for the submitted payout-based performance
analysis, as technically the incident has not finished so there might
be further updates.
- name: completed_risk_with_submitted_payout_amount_paid_in_gbp
data_type: numeric
description: |
Total amount paid in GBP in terms of Resolutions Payouts for Completed
Bookings that have been flagged as at Risk AND that have had a
submitted payout, with the claim being in a finished status.
- name: completed_no_risk_with_submitted_payout_amount_paid_in_gbp
data_type: numeric
description: |
Total amount paid in GBP in terms of Resolutions Payouts for Completed
Bookings that have NOT been flagged as at Risk AND that have had a
submitted payout, with the claim being in a finished status.
Merged PR 4996: First tracking of flagging performance # Description Creates 2 new models in the scope of flagging: how good are we at identifying "at risk" bookings vs. 1) the number of claims generated and 2) the number of submitted payouts? This only applies for Protected Bookings in New Dash that have been completed (14 days after the check-out) with potential resolutions appearing in Resolutions Center. The first table `int_flagging_booking_categorisation` contains all the heavy logic to categorise the bookings. The second view `int_flagging_performance_analysis` computes standard binary classification scores, for the 2 possible ways of tracking. Tables are already in prod to help you understand while reviewing. You'll see that the figures are still quite low, specially due to small amount of claims/submitted payouts. This makes the true positives being just... 1. There's heavy test and documentation coverage to ensure there's no mistakes on the computation. # Checklist - [X] The edited models and dependants run properly 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. **Materialising as table the first model despite being just 1 record since otherwise tests takes ages** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #29284
2025-04-15 10:14:02 +00:00
- name: int_flagging_performance_analysis
description: |
Provides a basic statistical analysis with binary classification metrics
on the flagging performance for New Dash Protected bookings, in the scope
of claims raised or submitted payouts.
data_tests:
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: count_total
column_B: count_true_positive + count_true_negative + count_false_positive + count_false_negative
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: recall_score
column_B: 1.0 * count_true_positive / (count_true_positive + count_false_negative)
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: precision_score
column_B: 1.0 * count_true_positive / (count_true_positive + count_false_positive)
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: false_positive_rate_score
column_B: 1.0 * count_false_positive / (count_false_positive + count_true_negative)
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: f1_score
column_B: 2.0 * count_true_positive / (2 * count_true_positive + count_false_negative + count_false_positive)
- dbt_expectations.expect_column_pair_values_to_be_equal:
column_A: f2_score
column_B: 5.0 * count_true_positive / (5 * count_true_positive + 4 * count_false_negative + count_false_positive)
columns:
- name: flagging_analysis_type
data_type: string
description: |
Type of the analysis conducted, i.e., what do we consider as a
positive - predicted (flagged) vs. actual (claim, payout).
data_tests:
- not_null
- unique
- accepted_values:
values:
- RISK_VS_CLAIM
- RISK_VS_SUBMITTED_PAYOUT
- name: count_total
data_type: integer
description: |
Total count of bookings considered for the flagging performance analysis.
- name: count_true_positive
data_type: integer
description: |
Count of True Positives: predicted positives that are also an actual positive.
- name: count_true_negative
data_type: integer
description: |
Count of True Negatives: predicted negatives that are also an actual negative.
- name: count_false_positive
data_type: integer
description: |
Count of False Positives: predicted positives that are not an actual positive.
- name: count_false_negative
data_type: integer
description: |
Count of False Negatives: predicted negatives that are not an actual negative.
- name: true_positive_score
data_type: decimal
description: |
True Positives as a ratio over 1. This is the count of true positives divided
by the total count of bookings considered for the flagging performance analysis.
- name: true_negative_score
data_type: decimal
description: |
True Negatives, as a ratio over 1. This is the count of true negatives divided
by the total count of bookings considered for the flagging performance analysis.
- name: false_positive_score
data_type: decimal
description: |
False Positives, as a ratio over 1. This is the count of false positives divided
by the total count of bookings considered for the flagging performance analysis.
- name: false_negative_score
data_type: decimal
description: |
False Negative, as a ratio over 1. This is the count of false negatives divided
by the total count of bookings considered for the flagging performance analysis.
- name: recall_score
data_type: decimal
description: |
Recall score, or true positive rate. This corresponds to the proportion of all
actual positives that were classified correctly as a positive. It can be seen
as a probability of detection: in our case, it answers the question "what
fraction of claim/payouts were flagged as at risk?".
This is the count of true positives divided by the sum of true positives and
false negatives. Recall improves when false negatives decrease.
A hypothetical perfect model would have zero false negatives, and thus a
recall of 1.0, or 100% detection rate.
- name: precision_score
data_type: decimal
description: |
Precision score, or positive predictive value. This corresponds to the
proportion of all predicted positives that were classified correctly as a
2025-04-15 13:37:57 +02:00
positive. In our case, it answers the question "what fraction of Bookings
flagged as at Risk actually generated a Claim/Payout?".
Merged PR 4996: First tracking of flagging performance # Description Creates 2 new models in the scope of flagging: how good are we at identifying "at risk" bookings vs. 1) the number of claims generated and 2) the number of submitted payouts? This only applies for Protected Bookings in New Dash that have been completed (14 days after the check-out) with potential resolutions appearing in Resolutions Center. The first table `int_flagging_booking_categorisation` contains all the heavy logic to categorise the bookings. The second view `int_flagging_performance_analysis` computes standard binary classification scores, for the 2 possible ways of tracking. Tables are already in prod to help you understand while reviewing. You'll see that the figures are still quite low, specially due to small amount of claims/submitted payouts. This makes the true positives being just... 1. There's heavy test and documentation coverage to ensure there's no mistakes on the computation. # Checklist - [X] The edited models and dependants run properly 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. **Materialising as table the first model despite being just 1 record since otherwise tests takes ages** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #29284
2025-04-15 10:14:02 +00:00
This is the count of true positives divided by the sum of true positives and
false positives. Precision improves when false positives decrease.
A hypothetical perfect model would have zero false positives, and thus a
precision of 1.0, or 100% precision rate.
- name: false_positive_rate_score
data_type: decimal
description: |
False positive rate, or fall-out. This corresponds to the proportion of all
actual negatives that were classified incorrectly as a positive. It can be seen
2025-04-15 13:37:57 +02:00
as a probability of false alarm: in our case, it answers the question "what
fraction of bookings without a claim/payout were flagged as at risk?".
Merged PR 4996: First tracking of flagging performance # Description Creates 2 new models in the scope of flagging: how good are we at identifying "at risk" bookings vs. 1) the number of claims generated and 2) the number of submitted payouts? This only applies for Protected Bookings in New Dash that have been completed (14 days after the check-out) with potential resolutions appearing in Resolutions Center. The first table `int_flagging_booking_categorisation` contains all the heavy logic to categorise the bookings. The second view `int_flagging_performance_analysis` computes standard binary classification scores, for the 2 possible ways of tracking. Tables are already in prod to help you understand while reviewing. You'll see that the figures are still quite low, specially due to small amount of claims/submitted payouts. This makes the true positives being just... 1. There's heavy test and documentation coverage to ensure there's no mistakes on the computation. # Checklist - [X] The edited models and dependants run properly 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. **Materialising as table the first model despite being just 1 record since otherwise tests takes ages** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #29284
2025-04-15 10:14:02 +00:00
This is the count of false positives divided by the sum of true positives and
false positives.
A hypothetical perfect model would have zero false positives, and thus a
false positive rate of 0.0, or 0% false alarm rate.
- name: f1_score
data_type: decimal
description: |
F1 score, which computes the harmonic mean of precision and recall.
This metric balances the trade-off between precision and recall, and is useful
when we want to find an optimal balance between the two.
It is defined as 2 * (precision * recall) / (precision + recall).
A hypothetical perfect model would have an F1 score of 1.0, or 100%.
When precision and recall are far apart, the F1 score will be closer to the
lower of the two.
- name: f2_score
data_type: decimal
description: |
F2 score, which computes the harmonic mean of precision and recall, but
with a twice higher weight on recall. In our case, it effectively means
that we want to reduce the number of false negatives, meaning reducing
the number of claims/payouts that are not flagged as at risk, while still
keeping a good precision.
This metric is useful when we want to prioritize recall over precision,
and is defined as 5 * (precision * recall) / (4 * precision + recall).
A hypothetical perfect model would have an F2 score of 1.0, or 100%.
When precision and recall are far apart, the F2 score will be closer to the
lower of the two.
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
- name: int_billable_items_growth_score_by_deal
description: |
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
This model computes the growth score of the billable items for each deal.
The growth score is computed as the average between:
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
- The billable items of a given month vs. the average of the previous
3 months.
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
- The share a deal has in terms of billable items of a given month
if compared to the rest of the deals vs. the average of the previous 3
months.
The growth score is capped between -1 and 1.
It is important to note that if we check the current month, the count of
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
billable items and the corresponding share will be based on the projection,
rather than the actual figure. In this case, the MAE and MAPE of the projected
value are indicated in the model.
While the growth score is computed at a monthly basis, the value will update
every day with the latest available projection.
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- end_date
- id_deal
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- start_date
- id_deal
columns:
- name: start_date
data_type: date
description: |
Start date of the period for which the growth score is computed.
data_tests:
- not_null
- name: end_date
data_type: date
description: |
End date of the period for which the growth score is computed.
data_tests:
- not_null
- name: id_deal
data_type: string
description: |
Unique ID for a deal, or account.
data_tests:
- not_null
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
- name: current_month_billable_items
data_type: integer
description: |
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
Monthly billable items. If the month is in progress
then this value corresponds to the projected figure.
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
This is indicated by "are_billable_items_projected"
flag.
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
- name: prior_3_months_avg_monthly_billable_items
data_type: integer
description: |
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
Average of the billable items for the previous 3 months.
If the selected range is from 1st April 2025 to 30th April 2025,
then this average will be based between 1st January 2025 to
31st March 2025.
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
- name: current_month_share_billable_items
data_type: decimal
description: |
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
Share of the billable items for a given deal in the current month.
If the month is in progress then this value corresponds to the
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
projected figure. This is indicated by "are_billable_items_projected"
flag.
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
- name: prior_3_months_avg_monthly_share_billable_items
data_type: decimal
description: |
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
Average of the share of the billable items for a given deal in the
previous 3 months. If the selected range is from 1st April 2025 to
30th April 2025, then this average will be based between 1st January
2025 to 31st March 2025.
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
- name: growth_vs_prior_3_avg_billable_items
data_type: decimal
description: |
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
Growth score of the billable items based purely on the relative
difference between the current month billable items vs. the
prior 3 months average.
This is a subcomputation of the growth score, for information
purposes.
It can be null.
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
- name: growth_vs_prior_3_avg_share_billable_items
data_type: decimal
description: |
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
Growth score of the billable items based purely on the relative
difference between the current month share billable items vs. the
prior 3 months average.
This is a subcomputation of the growth score, for information
purposes.
It can be null.
- name: growth_score
data_type: decimal
description: |
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
Growth score of the billable items, based on the average between:
- The billable items of a given month vs. the average of the previous
3 months.
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
- The share a deal has in terms of billable items of a given month
if compared to the rest of the deals vs. the average of the previous 3
months.
The growth score is capped between -1 and 1.
It cannot be null.
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: -1
max_value: 1
strictly: false
- name: projection_mean_absolute_error
data_type: decimal
description: |
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
Mean absolute error of the projection of the billable items.
It is null if the month is not in progress or value is projected
but there's no prior data to compare the projection against.
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
- name: projection_mean_absolute_percentage_error
data_type: decimal
description: |
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
Mean absolute percentage error of the projection of the billable items.
It is null if the month is not in progress or value is projected
but there's no prior data to compare the projection against.
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: false
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
- name: are_billable_items_projected
data_type: boolean
description: |
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
Flag indicating if the billable items are projected or not.
If the month is in progress then this value corresponds to the
Merged PR 5058: Propagate API deals to growth score # Description I opted to name the combination of (Platform) Billable Bookings and (API) Billable Verifications as Billable Items. This is to ensure consistent naming. Changes: * Renamed `int_kpis_projected__agg_daily_billable_bookings` to `int_kpis_projected__agg_daily_billable_items`. This now has a new CTE named combination_of_billable_items that combines both API and Platform billable items. Renamed any "bookings" field to "items". * Renamed `int_kpis_projected__agg_monthly_billable_bookings` to `int_kpis_projected__agg_monthly_billable_items`. Renamed any "bookings" field to "items". * Renamed `int_billable_bookings_growth_score_by_deal` to `int_billable_items_growth_score_by_deal`. This now has a new CTE named `aggregated_monthly_billable_items` that combines the historical information both API and Platform on billable items. Renamed any "bookings" field to "items". * Changes Schema accordingly. Small note here that the assert dimension completeness stops working since there's dimensions specific to API or Platform, thus I removed it. # Checklist - [X] The edited models and dependants run properly 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-25 07:27:22 +00:00
projected figure. This is indicated by "are_billable_items_projected"
flag.
data_tests:
- not_null
- name: int_unified_api_verifications
description: |
This model unifies the API verifications data from different sources
(Athena, E-Deposit, Check In Hero, Screen & Protect) into a single table.
It also includes information regarding the Booking.
Since the data is coming from different sources, the model provides a
minimal set of columns that are relevant for this unified view.
data_tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- id_verification
- api_source
columns:
- name: api_source
data_type: string
description: |
Source of the API verification (e.g., ATHENA, E-DEPOSIT, CHECK_IN_HERO,
SCREEN_AND_PROTECT). This field is mandatory and cannot be null.
data_tests:
- not_null
- accepted_values:
values:
- ATHENA
- E-DEPOSIT
- CHECK_IN_HERO
- SCREEN_AND_PROTECT
- name: id_verification
data_type: string
description: |
Unique ID for a verification. This ID is generated by each API,
thus it can potentially be duplicated across different sources.
data_tests:
- not_null
- name: id_booking
data_type: string
description: |
Unique ID for a booking. It can be duplicated, as
reflected in the field "is_duplicate_booking".
data_tests:
- not_null
- name: id_deal
data_type: string
description: |
Unique ID for a deal, or account.
data_tests:
- not_null
- name: verification_status
data_type: string
description: |
Status of the verification. It can be null
for some sources. Status depends on the source.
- name: check_in_date_utc
data_type: date
description: |
Check-in date in UTC. It cannot be null.
data_tests:
- not_null
- name: check_out_date_utc
data_type: date
description: |
Check-out date in UTC. It cannot be null.
data_tests:
- not_null
- name: created_date_utc
data_type: date
description: |
Created date in UTC. It cannot be null.
data_tests:
- not_null
- name: billable_date_utc
data_type: date
description: |
Billable date in UTC. This is the point in time in
which the verification can be billed. It cannot be null.
data_tests:
- not_null
- name: is_cancelled
data_type: boolean
description: |
Flag indicating if the booking linked to the verification
is cancelled or not. It can be null for some sources.
- name: is_duplicate_booking
data_type: boolean
description: |
Flag indicating if the booking linked to the verification
is a duplicate or not. It cannot be null.
data_tests:
- not_null
- name: booking_is_duplicated_n_times
data_type: integer
description: |
Number of times the booking linked to the verification
is duplicated. It cannot be null.
data_tests:
- not_null
- dbt_expectations.expect_column_values_to_be_between:
min_value: 1
strictly: false