data-dwh-dbt-project/models/reporting/general/schema.yml

1598 lines
57 KiB
YAML
Raw Normal View History

2024-03-13 15:47:58 +01:00
version: 2
2024-03-13 11:09:22 +01:00
models:
- name: dates
description: |
A dates dimension. Each record represents one calendar day.
2024-03-13 15:47:58 +01:00
All othe columns have handy representations of the date, its subcomponents, and other relative dates.
2024-03-13 11:09:22 +01:00
This table is generated with the dbt date package: https://hub.getdbt.com/calogica/dbt_date/latest/.
columns:
- name: date_day
data_type: date
description: The date this record represents. All relative dates are relative to this. All derived date components are derived from this.
- name: prior_date_day
data_type: date
description: The day before date day.
- name: next_date_day
data_type: date
description: The day after date day.
- name: prior_year_date_day
data_type: date
description: The same day of the same month, but in the previous year. If date day is Feb 29th, this col returns Feb 28th.
- name: prior_year_over_year_date_day
data_type: date
description: The day placed 365 days before the date day. Behaves a bit funny with leap years.
- name: day_of_week
data_type: integer
description: The day of the week as a number, were Monday is 1 and Sunday is 7.
- name: day_of_week_name
data_type: text
description: The full name of the day of the week.
- name: day_of_week_name_short
data_type: text
description: The day of the week as a 3 digit shortened version.
- name: day_of_month
data_type: integer
description: The day of the month as a number.
- name: day_of_year
data_type: integer
description: The day of the year as a number, where January 1st is 1 and December 31st is 365/366.
- name: week_start_date
data_type: date
description: |
The full date for the first day of the week of date day.
It considers Sunday to be the first day of the week.
- name: week_end_date
data_type: date
description: |
The full date for the last day of the week of date day.
It considers Saturday to be the last day of the week.
- name: prior_year_week_start_date
data_type: date
description: Same as week_start_date, but for the same date day in the previous year.
- name: prior_year_week_end_date
data_type: date
description: Same as week_end_date, but for the same date day in the previous year.
- name: week_of_year
data_type: integer
description: The week of the year as a number, where the first week is 1 and the last week is 52/53.
- name: iso_week_start_date
data_type: date
description: |
The full date for the first day of the week of date day, according to ISO specs.
It considers Monday to be the first day of the week.
Read more here: https://en.wikipedia.org/wiki/ISO_week_date
- name: iso_week_end_date
data_type: date
description: |
The full date for the last day of the week of date day, according to ISO specs.
It considers Sunday to be the last day of the week.
Read more here: https://en.wikipedia.org/wiki/ISO_week_date
- name: prior_year_iso_week_start_date
data_type: date
description: "Read more here: https://en.wikipedia.org/wiki/ISO_week_date"
- name: prior_year_iso_week_end_date
data_type: date
description: "Read more here: https://en.wikipedia.org/wiki/ISO_week_date"
- name: iso_week_of_year
data_type: integer
description: "Read more here: https://en.wikipedia.org/wiki/ISO_week_date"
- name: prior_year_week_of_year
data_type: integer
description: ""
- name: prior_year_iso_week_of_year
data_type: integer
description: "Read more here: https://en.wikipedia.org/wiki/ISO_week_date"
- name: month_of_year
data_type: integer
description: The month date day belongs to as a number (1 for Jan, 12 for Dec).
- name: month_name
data_type: text
description: The month date day belongs to in English.
- name: month_name_short
data_type: text
description: The month date day belongs to as a 3 digit shortened version.
2024-10-02 10:11:48 +02:00
- name: month_number_name
data_type: text
description: The month date number with leading zero and full month name (e.g., 01-January, 02-February).
- name: month_number_name_short
data_type: text
description: The month date number with leading zero and abbreviated month name (e.g., 01-Jan, 02-Feb).
2024-03-13 11:09:22 +01:00
- name: month_start_date
data_type: date
description: The full date for the first day of the month.
- name: month_end_date
data_type: date
description: The full date for the last day of the month.
- name: prior_year_month_start_date
data_type: date
description: The full date for the first day of the same month last year.
- name: prior_year_month_end_date
data_type: date
description: The full date for the last day of the same month last year.
- name: quarter_of_year
data_type: integer
description: The quarter date day belongs to as a number (1 for Q1, 4 for Q4).
- name: quarter_start_date
data_type: date
description: The full date for the first date of the quarter.
- name: quarter_end_date
data_type: date
description: The full date for the last date of the quarter.
- name: year_number
data_type: integer
description: The year date day belongs to as a number.
- name: year_start_date
data_type: date
description: The full date for the first day of the year.
- name: year_end_date
data_type: date
description: The full date for the last day of the year.
2024-06-19 11:52:28 +02:00
- name: daily_currency_exchange_rates
2024-12-23 12:19:52 +01:00
config:
grants:
select: ["billingdb_reader"]
2024-09-12 15:39:49 +02:00
description:
2024-06-19 11:52:28 +02:00
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.
Actual rates are sourced from xe.com data. The `guessed` and `forecast`
versions are built by simply 'pushing' the first/last exchange rate on
record. Basically, wherever we don't have data for a date, we pick the
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.
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).
tests:
- not_null
- unique
- name: from_currency
data_type: character
description: The source currency, represented as an ISO 4217 code.
tests:
- not_null
- name: to_currency
data_type: character
description: The target currency, represented as an ISO 4217 code.
tests:
- 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.
tests:
- not_negative_or_zero
- not_null
- name: rate_date_utc
data_type: date
description: The date in which the rate record is relevant.
tests:
- not_null
- name: source
data_type: text
description:
Where is the data coming from. Records that are composed from
making assumptions on real data will contain `_inferred`.
- name: rate_version
data_type: text
description:
The version of the rate. This can be one of `actual` (the rate is a
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.
tests:
- accepted_values:
values:
- guess
- actual
- forecast
- not_null
- name: updated_at_utc
data_type: timestamp with time zone
description:
For external sources, this will be the point in time when the
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.
tests:
- not_null
- name: simple_exchange_rates
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.
tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- from_currency
- to_currency
- rate_date_utc
columns:
- name: from_currency
data_type: character
description: The source currency, represented as an ISO 4217 code.
tests:
- not_null
- name: to_currency
data_type: character
description: The source currency, represented as an ISO 4217 code.
tests:
- not_null
- name: rate
data_type: numeric
description: The target currency, represented as an ISO 4217 code.
tests:
- not_null
- name: rate_date_utc
data_type: date
description: The date in which the rate record is relevant.
tests:
- not_null
- name: updated_at_utc
data_type: timestamp with time zone
description:
For external sources, this will be the point in time when the
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.
tests:
- not_null
2024-11-05 12:37:31 +01:00
- name: mtd_aggregated_metrics
description: |
This model aggregates the historic information of our business by providing
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
different metrics computed at global and dimension level.
It's the main source of information for the Main KPIs reporting, specifically
on the MTD (Month To Date) and the Monthly Overview.
2024-09-12 15:39:49 +02:00
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
columns:
- name: year
data_type: int
description: Year number of the given date.
tests:
- not_null
- name: month
2024-09-12 15:39:49 +02:00
data_type: int
description: Month number of the given date.
tests:
- not_null
- name: day
data_type: int
description: Day monthly number of the given date.
tests:
- not_null
- name: is_end_of_month
data_type: boolean
description: Is end of month, 1 for yes, 0 for no.
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.
tests:
- not_null
- 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.
tests:
- not_null
- 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.
tests:
- not_null
- name: date
data_type: date
description: |
Main date for the computation, that is used for filters.
It comes from int_dates_mtd logic.
tests:
- not_null
- latest_date_is_yesterday
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. Keep in mind that
in this reporting model this field corresponds to the
dimension_display; this is, the name of the dimension for
2024-09-12 15:39:49 +02:00
displaying purposes.
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
tests:
- not_null
2024-09-12 15:39:49 +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.
tests:
- 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 comes from int_dates_mtd logic. It's only displayed for information purposes,
should not be needed for reporting.
- name: metric
data_type: text
description: Name of the business metric.
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.
tests:
2024-09-12 15:39:49 +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:39:49 +02:00
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
2024-09-12 15:39:49 +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:39:49 +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:39:49 +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
2024-11-05 12:37:31 +01:00
- name: monthly_aggregated_metrics_history_by_deal
description: |
This model aggregates the monthly historic information regarding the different metrics computed
at deal level. The primary source of data is the `int_monthly_XXXXX_history_by_deal`
model which contain the raw metrics data per source.
This table is used to provide "By Deal" metrics in the Business Overview reporting.
2024-11-05 12:37:31 +01:00
Unlike the 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
2024-11-05 12:37:31 +01:00
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:39:49 +02:00
not necessarily the case.
2024-09-12 15:39:49 +02:00
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 for historic metrics.
tests:
- not_null
2024-09-12 15:39:49 +02:00
- name: id_deal
data_type: character varying
2024-09-12 15:39:49 +02:00
description: Id of the deal associated to the host.
tests:
- not_null
2024-09-12 14:08:36 +02:00
- name: main_deal_name
data_type: string
description: |
Main name for this ID deal.
tests:
- not_null
- 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: year
data_type: int
description: year number of the given date.
tests:
- not_null
- name: month
2024-09-12 15:39:49 +02:00
data_type: int
description: month number of the given date.
tests:
- not_null
- name: day
data_type: int
description: day monthly number of the given date.
2024-06-19 11:52:28 +02:00
tests:
2024-09-12 15:39:49 +02:00
- not_null
- name: monthly_growth_score_by_deal
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.
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.
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.
tests:
- not_null
- name: main_deal_name
data_type: string
description: |
Main name for a Deal, representing the client.
tests:
- not_null
2025-01-10 09:51:29 +01:00
- name: has_active_pms
data_type: boolean
description: |
Does the deal have an active associated PMS.
tests:
- 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
tests:
- not_null
- accepted_values:
values:
- MAJOR DECLINE
- DECLINE
- FLAT
- GAIN
- MAJOR GAIN
- UNSET
- name: new_dash_booking_summary
description: |
This model contains enriched information aggregated at Booking level regarding
the services that are applied within a Booking, only for users in New Dash.
Specifically, contains both Booking and Services attributes (aggregated), as well
as the total price in GBP at this specific moment in time. In other words,
it's the snapshot of the current status of the Booking.
It's a subset of all bookings since it only applies to bookings that come from
hosts that have been migrated into the New Dash.
columns:
- name: id_booking
data_type: bigint
description: |
The identifier of the booking. Acts as Primary Key to this table.
Cannot be null.
tests:
- not_null
- unique
- name: id_deal
data_type: string
description: |
Unique identifier of the account. It cannot be null.
tests:
- not_null
- name: main_billing_country
data_type: string
description: |
ISO 3166-1 alpha-3 main country code in which the Deal is billed.
- name: main_deal_name
data_type: string
description: |
Main name for this ID deal, according to some logic from
backend (core) data.
It's a clean version of the most repeated name within the
user tables in the fields of first_name, last_name and company name.
This field should be modified at the moment we have
a proper way to retrieve a common account name per deal.
It can contain duplicates.
tests:
- not_null
- name: hubspot_deal_name
data_type: string
description: |
Name of the deal according to Hubspot. Preferred over main_deal_name.
- name: account_manager
data_type: string
description: |
The name of the account manager that is currently taking care of this
deal.
- name: booking_status
data_type: string
description: |
The current status of the booking. Cannot be null.
tests:
- not_null
- name: program_name
data_type: string
description: |
The name of the program, or product bundle, applied to the booking.
Cannot be null.
tests:
- not_null
- name: booking_created_date_utc
data_type: date
description: |
Date of when the Booking record was created in the Backend.
Cannot be null.
tests:
- not_null
- name: booking_check_in_date_utc
data_type: timestamp
description: |
Date of the Check-in of the Booking.
Cannot be null.
tests:
- not_null
- name: booking_check_out_date_utc
data_type: date
description: |
Date of the Check-out of the Booking.
tests:
- not_null
- name: booking_number_of_nights
data_type: integer
description: |
Number of nights between Check-in date and Check-out date.
- name: host_currency_code
data_type: string
description: |
Iso 4217 currency code for the account of the Host.
It can be null.
- name: new_dash_version
data_type: string
description: |
Specifies the New Dash Version in which these users were
moved or joined.
tests:
- not_null
- name: user_in_new_dash_since_date_utc
data_type: date
description: |
The effective date since the user can be considered in New Dash. If the user
has moved from Old Dash, it will be the date of new_dash_move_at_utc.
If not, it will correspond to the date of joined_at_utc.
- name: booking_total_price_in_gbp
data_type: decimal
description: |
Identifies the current total price of the booking by adding up the
prices of each service applied to this booking, converted in GBP.
Can be null. Can vary over time depending on the service status,
payments, etc, as well as it can vary over time until the chargeable
date due to the currency rate estimation in the future.
- name: service_first_chargeable_date_utc
data_type: date
description: |
Identifies the first moment in time in which the first
service applied to this booking is supposed to be charged.
- name: service_last_chargeable_date_utc
data_type: date
description: |
Identifies the last moment in time in which the last
service applied to this booking is supposed to be charged.
- name: number_of_applied_services
data_type: integer
description: |
Total number of Services applied to this Booking.
- name: number_of_applied_upgraded_services
data_type: integer
description: |
Total number of Services different from Basic Screening
applied to this Booking.
- name: is_booking_chargeable
data_type: boolean
description: |
Flag to identify it the Booking is chargeable or not.
In essence, it solves the question: are we supposed to get
money out of this booking, or not?
To be considered as chargeable, a chargeable date needs to exist
as well as the total price converted to GBP needs to be strictly
greater than 0. The fact that a booking is not chargeable does
not necessarily mean that it won't be in the future. Similarly, if
the booking is chargeable it does not necessarily mean that is actually
charged. It cannot be null.
tests:
- not_null
- name: is_booking_cancelled
data_type: boolean
description: |
Flag to identify if the booking has been cancelled or not.
- name: has_upgraded_services
data_type: boolean
description: |
Flag to identify if the booking has any service different from
Basic Screening or not.
- name: has_screening_service_business_type
data_type: boolean
description: |
Flag to identify if the booking contains any Screening service
or not.
- name: has_deposit_management_service_business_type
data_type: boolean
description: |
Flag to identify if the booking contains any Deposit
Management service or not.
- name: has_protection_service_business_type
data_type: boolean
description: |
Flag to identify if the booking contains any Protection
service or not.
- name: 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.
tests:
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- date
- id_deal
- time_window
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.
tests:
- not_null
- name: id_deal
data_type: character varying
description: Id of the deal associated to the host.
tests:
- not_null
- name: time_window
data_type: character varying
description: |
Identifier of the time window used for the aggregation of the metrics.
tests:
- not_null
- accepted_values:
values:
- All History
- Previous 12 months
- Previous 6 months
- Previous 3 months
- Previous month
- 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.
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.
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: 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: 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.
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.
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.
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.
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.