counterweight/data-dwh-dbt-project
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
data-dwh-dbt-project/models/intermediate/core/schema.yml

5859 lines
201 KiB
YAML
Raw Normal View History

docs and moving stuff
2024-04-08 09:44:32 +02:00
version: 2
models:
- name: int_core__duplicate_bookings
description: |
A list of bookings which are considered duplicates of other bookings.
We currently consider two bookings to be duplicate if they have the same:
- Guest user id
- Accomodation id
- Check-in date
Bear in mind these bookings do have different booking ids.
Out of a duplicated tuple of 2 or more bookings:
- Our logic will consider the oldest one to be the "original", not duplicate one.
- This table will contain only the duplicates, and not the original.
columns:
- name: id_booking
data_type: bigint
description: The unique, Superhog generated id for this booking.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Included tests
2024-07-31 12:48:57 +02:00
- unique
- not_null
docs and moving stuff
2024-04-08 09:44:32 +02:00
- name: is_duplicate_booking
data_type: boolean
description: |
True if the booking is duplicate.
If you are thinking that this is redundant, you are right. All
records in this table will be true. But we keep this field to
make your life easier when joining with other tables.
- name: is_duplicating_booking_with_id
data_type: bigint
description: |
Indicates what's the original booking being duplicated.
If there is a tuple of duplicate bookings {A, B, C}, where A is the
original and the others are the duplicates:
- B and C will appear in this table, A will not.
- The value of this field for both B and C will be A's id.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Included tests
2024-07-31 12:48:57 +02:00
- not_null
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
docs and moving stuff
2024-04-08 09:44:32 +02:00
- name: int_core__booking_charge_events
description: |
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
docs and moving stuff
2024-04-08 09:44:32 +02:00
Booking charge events is a fancy word for saying: a booking happened,
the related host had a booking fee set up at the right time, hence we
need to charge him.
The table contains one record per booking and shows the associated
booking fee, as well as the point in time in which the charge event was
considered.
Be wary of the booking fees: they don't have an associated currency.
Crazy, I know, but we currently don't store that information in the
backend.
As for the charge dates: the exact point in time at which we consider
that we should be charging a fee depends on billing details of the host
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
customer. For some bookings, this will be the check-in. For others, it's
when the guest 'begins the verification process'. Here, depending on whether
the booking has or not a verification request linked to it, we will consider
either by when the guest joined or when the verification request was last
updated. Be aware that this 'begins the verification process' logic is different
from other DWH models; the current one explained here aiming to replicate what
is currently being done for invoicing.
Note: even though we aim to replicate what is happening for the invoicing process,
you need to be aware that the monthly volumes do not match exactly with what we
have in the invoicing exporter.
An additional column called is_booking_created_after_charging_date exemplifies the
fact that some bookings will get created after the verification process should have
happened - thus these are likely billable bookings that have not been billed.
docs and moving stuff
2024-04-08 09:44:32 +02:00
Not all bookings appear here since we don't charge a fee for all
bookings.
columns:
- name: id_booking
data_type: bigint
description: The unique, Superhog generated id for this booking.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- not_null
- unique
docs and moving stuff
2024-04-08 09:44:32 +02:00
- name: id_price_plan
data_type: bigint
description: The id of the price plan that relates to this booking.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- not_null
docs and moving stuff
2024-04-08 09:44:32 +02:00
- name: booking_fee_local
data_type: numeric
description: The fee to apply to the booking, in host currency.
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- name: account_currency_iso4217
data_type: character varying
description: Currency used by host/pm/platform users.
- name: booking_fee_in_gbp
data_type: numeric
description: The fee to apply to the booking, in GBP.
docs and moving stuff
2024-04-08 09:44:32 +02:00
- name: booking_fee_charge_at_utc
data_type: timestamp without time zone
description: |
The point in time in which the booking should be invoiced.
This could be the check-in date of the booking or the date in which the guest verification
started, depending on the billing settings of the host.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- not_null
docs and moving stuff
2024-04-08 09:44:32 +02:00
- name: booking_fee_charge_date_utc
data_type: date
description: |
The date in which the booking should be invoiced.
This could be the check-in date of the booking or the date in which the guest verification
started, depending on the billing settings of the host.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- not_null
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- name: is_booking_created_after_charging_date
data_type: boolean
description: |
Flag to identify if the booking was created after the
expected charge date. It can identify cases that might not
be covered within the current invoicing process.
mroe docs
2024-05-07 17:52:35 +02:00
- name: int_core__check_in_cover_prices
description: |
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
mroe docs
2024-05-07 17:52:35 +02:00
This table shows the active price and cover for the Check-In Hero
product.
The prices are obtained through a gross `GROUP BY` thrown at the payment
validation sets table. It works this way because the price settings of
this product were done with a terrible backend data model design.
How could the prices be changed remains a mystery, and the current design
does not support any kind of history tracking. When the time comes to
adjust prices, we will have a lot of careful work to do to make sure that
we keep history and that no downstream dependencies of this model blow
up.
columns:
- name: local_currency_iso_4217
data_type: character varying
description: A currency code.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
add missing test
2024-11-20 10:09:03 +01:00
- not_null
- unique
mroe docs
2024-05-07 17:52:35 +02:00
- name: checkin_cover_guest_fee_local_curr
data_type: numeric
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
mroe docs
2024-05-07 17:52:35 +02:00
The fee that the guest user must pay if he wants to purchase the
Merged PR 2865: Propagate tax exclusive check in hero payments # Description This PR propagates tax exclusive check in hero payments for the reporting of Check in Hero. Additionally, it keeps propagating the amounts with tax inclusiveness in case, at some point, we need them. These are with the new naming convention. In order not to break anything, the previous amounts are duplicated and aliased in reporting. Lastly, I spent some time adding some clarifications and documenting payments set to currency and the dependant used for check in hero. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20046
2024-09-17 07:25:09 +00:00
cover. This fee is tax inclusive if happen in a country in which
taxes are to be applied
mroe docs
2024-05-07 17:52:35 +02:00
- name: checkin_cover_cover_amount_local_curr
data_type: numeric
description: |
The amount for which the guest user is covered if he faces problems
during check-in.
add tests
2024-06-10 16:23:45 +02:00
- name: int_core__unified_user
columns:
- name: id_user
data_type: character varying
description: The unique ID for the user.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
add tests
2024-06-10 16:23:45 +02:00
- not_null
- unique
Merged PR 3878: Propagates account type to intermediate # Description Propagates account type to intermediate. Also, adds minimal documentation to `int_core__unified_user`. There's only 54 test accounts in Unified User and 49 that are considered as User Hosts. So it's not, by all means, an extensive list of test accounts... There's a mismatch between the `created_date_utc` and `updated_date_utc` that these are timestamps. There's another ticket in the backlog to handle this alongside the dependency, so it's not included here. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #18944
2024-12-19 16:33:35 +00:00
- name: id_account_type
data_type: bigint
description: |
The ID of the account type. Might be null and not necessarily up to date.
- name: account_type
data_type: character varying
description: |
The name of the account type. Might be null and not necessarily up to date.
- name: id_billing_country
data_type: bigint
description: The ID of the billing country. Can be null.
- name: billing_country_name
data_type: character varying
description: The name of the billing country. Can be null.
- name: billing_country_iso_2
data_type: char(2)
description: The ISO 3166-1 alpha-2 code of the billing country. Can be null.
- name: billing_country_iso_3
data_type: char(3)
description: The ISO 3166-1 alpha-3 code of the billing country. Can be null.
- name: account_currency_iso4217
data_type: char(3)
description: The ISO 4217 code of the account currency. Can be null.
- name: user_code
data_type: bigint
description: The user code.
- name: first_name
data_type: character varying
description: The first name of the user.
- name: last_name
data_type: character varying
description: The last name of the user.
- name: email
data_type: character varying
description: The email of the user.
- name: phone_number
data_type: character varying
description: The phone number of the user.
- name: title
data_type: character varying
description: The title of the user.
- name: id_deal
data_type: character varying
description: |
The ID of the deal of the user. It only applies to client accounts.
Can be null.
- name: is_deleted
data_type: boolean
description: |
True if the user has been deleted. False otherwise.
- name: joined_at_utc
data_type: timestamp
description: The timestamp when the user joined.
- name: joined_date_utc
data_type: date
description: The date when the user joined.
- name: user_name
data_type: character varying
description: The user name.
- name: code_prefix
data_type: character varying
description: The code prefix.
- name: billing_town
data_type: character varying
description: The billing town.
- name: company_name
data_type: character varying
description: The company name.
- name: is_email_confirmed
data_type: boolean
description: |
True if the email of the user has been confirmed. False otherwise.
- name: is_lockout_enabled
data_type: boolean
description: |
True if the lockout has been enabled. False otherwise.
- name: billing_postcode
data_type: character varying
description: The billing postcode.
- name: is_twofactor_enabled
data_type: boolean
description: |
True if the two-factor authentication has been enabled. False otherwise.
- name: access_failed_count
data_type: bigint
description: The access failed count.
- name: lockout_end_date_utc
data_type: timestamp
description: The lockout end date.
- name: avatar
data_type: character varying
description: The avatar of the user.
- name: id_airbnb
data_type: character varying
description: The ID of the Airbnb.
- name: airbnb_url
data_type: character varying
description: The Airbnb URL.
Merged PR 3909: Fixes created_date_utc and updated_date_utc in SH User and its dependencies # Description The model `stg_core__superhog_user` contained the fields `created_date_utc` and `updated_date_utc`, which were actually timestamps, not dates. This created issues a while ago in KPIs that were fixed by forcing a date conversion at `int_kpis` level, but the source issue remained unfixed. This PR just creates the proper fields in staging, meaning: * `created_at_utc` and `created_date_utc` * `updated_at_utc` and `updated_date_utc` And propagates the changes through all dependencies. On KPIs, it also removes the hardcoded date conversion since it's no longer needed. It also adds the different schema entries on which these fields were already defined. Note I didn't update the staging entry since there's no entry for the rest of the fields. I recommend checking this PR in the commits order. What I've tested: * Unified User and User Host have plenty of dependencies that I've checked one by one, at each dependency layer by using dbt docs. * Run `core__unified_user` and the full execution of +`mtd_aggregated_metrics` What clearly will fail: * There's the famous `Users_dashboard` PBI report that shouldn't exist that has a dependency with `core__unified_user`. This report will fail. But it does not exist. I'd like to drop it once and forever # Checklist - [X] The edited models and dependants run properly with production data. **See above** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **The staging model is incremental!** Related work items: #23703
2024-12-31 08:04:03 +00:00
- name: created_at_utc
data_type: timestamp
description: The timestamp when the user was created.
Merged PR 3878: Propagates account type to intermediate # Description Propagates account type to intermediate. Also, adds minimal documentation to `int_core__unified_user`. There's only 54 test accounts in Unified User and 49 that are considered as User Hosts. So it's not, by all means, an extensive list of test accounts... There's a mismatch between the `created_date_utc` and `updated_date_utc` that these are timestamps. There's another ticket in the backlog to handle this alongside the dependency, so it's not included here. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #18944
2024-12-19 16:33:35 +00:00
- name: created_date_utc
Merged PR 3909: Fixes created_date_utc and updated_date_utc in SH User and its dependencies # Description The model `stg_core__superhog_user` contained the fields `created_date_utc` and `updated_date_utc`, which were actually timestamps, not dates. This created issues a while ago in KPIs that were fixed by forcing a date conversion at `int_kpis` level, but the source issue remained unfixed. This PR just creates the proper fields in staging, meaning: * `created_at_utc` and `created_date_utc` * `updated_at_utc` and `updated_date_utc` And propagates the changes through all dependencies. On KPIs, it also removes the hardcoded date conversion since it's no longer needed. It also adds the different schema entries on which these fields were already defined. Note I didn't update the staging entry since there's no entry for the rest of the fields. I recommend checking this PR in the commits order. What I've tested: * Unified User and User Host have plenty of dependencies that I've checked one by one, at each dependency layer by using dbt docs. * Run `core__unified_user` and the full execution of +`mtd_aggregated_metrics` What clearly will fail: * There's the famous `Users_dashboard` PBI report that shouldn't exist that has a dependency with `core__unified_user`. This report will fail. But it does not exist. I'd like to drop it once and forever # Checklist - [X] The edited models and dependants run properly with production data. **See above** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **The staging model is incremental!** Related work items: #23703
2024-12-31 08:04:03 +00:00
data_type: date
description: The date when the user was created.
- name: updated_at_utc
Merged PR 3878: Propagates account type to intermediate # Description Propagates account type to intermediate. Also, adds minimal documentation to `int_core__unified_user`. There's only 54 test accounts in Unified User and 49 that are considered as User Hosts. So it's not, by all means, an extensive list of test accounts... There's a mismatch between the `created_date_utc` and `updated_date_utc` that these are timestamps. There's another ticket in the backlog to handle this alongside the dependency, so it's not included here. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #18944
2024-12-19 16:33:35 +00:00
data_type: timestamp
Merged PR 3909: Fixes created_date_utc and updated_date_utc in SH User and its dependencies # Description The model `stg_core__superhog_user` contained the fields `created_date_utc` and `updated_date_utc`, which were actually timestamps, not dates. This created issues a while ago in KPIs that were fixed by forcing a date conversion at `int_kpis` level, but the source issue remained unfixed. This PR just creates the proper fields in staging, meaning: * `created_at_utc` and `created_date_utc` * `updated_at_utc` and `updated_date_utc` And propagates the changes through all dependencies. On KPIs, it also removes the hardcoded date conversion since it's no longer needed. It also adds the different schema entries on which these fields were already defined. Note I didn't update the staging entry since there's no entry for the rest of the fields. I recommend checking this PR in the commits order. What I've tested: * Unified User and User Host have plenty of dependencies that I've checked one by one, at each dependency layer by using dbt docs. * Run `core__unified_user` and the full execution of +`mtd_aggregated_metrics` What clearly will fail: * There's the famous `Users_dashboard` PBI report that shouldn't exist that has a dependency with `core__unified_user`. This report will fail. But it does not exist. I'd like to drop it once and forever # Checklist - [X] The edited models and dependants run properly with production data. **See above** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **The staging model is incremental!** Related work items: #23703
2024-12-31 08:04:03 +00:00
description: The timestamp when the user was updated.
Merged PR 3878: Propagates account type to intermediate # Description Propagates account type to intermediate. Also, adds minimal documentation to `int_core__unified_user`. There's only 54 test accounts in Unified User and 49 that are considered as User Hosts. So it's not, by all means, an extensive list of test accounts... There's a mismatch between the `created_date_utc` and `updated_date_utc` that these are timestamps. There's another ticket in the backlog to handle this alongside the dependency, so it's not included here. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #18944
2024-12-19 16:33:35 +00:00
- name: updated_date_utc
Merged PR 3909: Fixes created_date_utc and updated_date_utc in SH User and its dependencies # Description The model `stg_core__superhog_user` contained the fields `created_date_utc` and `updated_date_utc`, which were actually timestamps, not dates. This created issues a while ago in KPIs that were fixed by forcing a date conversion at `int_kpis` level, but the source issue remained unfixed. This PR just creates the proper fields in staging, meaning: * `created_at_utc` and `created_date_utc` * `updated_at_utc` and `updated_date_utc` And propagates the changes through all dependencies. On KPIs, it also removes the hardcoded date conversion since it's no longer needed. It also adds the different schema entries on which these fields were already defined. Note I didn't update the staging entry since there's no entry for the rest of the fields. I recommend checking this PR in the commits order. What I've tested: * Unified User and User Host have plenty of dependencies that I've checked one by one, at each dependency layer by using dbt docs. * Run `core__unified_user` and the full execution of +`mtd_aggregated_metrics` What clearly will fail: * There's the famous `Users_dashboard` PBI report that shouldn't exist that has a dependency with `core__unified_user`. This report will fail. But it does not exist. I'd like to drop it once and forever # Checklist - [X] The edited models and dependants run properly with production data. **See above** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **The staging model is incremental!** Related work items: #23703
2024-12-31 08:04:03 +00:00
data_type: date
description: The date when the user was updated.
Merged PR 3878: Propagates account type to intermediate # Description Propagates account type to intermediate. Also, adds minimal documentation to `int_core__unified_user`. There's only 54 test accounts in Unified User and 49 that are considered as User Hosts. So it's not, by all means, an extensive list of test accounts... There's a mismatch between the `created_date_utc` and `updated_date_utc` that these are timestamps. There's another ticket in the backlog to handle this alongside the dependency, so it's not included here. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #18944
2024-12-19 16:33:35 +00:00
- name: verified_at_utc
data_type: timestamp
description: The timestamp when the user was verified.
- name: verified_date_utc
data_type: date
description: The date when the user was verified.
- name: flag_as_problem
data_type: boolean
description: |
True if the user has been flagged as a problem. False otherwise.
- name: number_of_properties
data_type: bigint
description: |
The number of properties according to the backend. For a better
figure we recommend using Hubspot data. For a real figure
of properties actually being active in our business, we recommend
using other sources of data.
- name: id_superhog_verified_set
data_type: bigint
description: The ID of the Superhog verified set.
- name: platform_comms_recipient
data_type: boolean
description: |
True if the user is a platform comms recipient. False otherwise.
- name: id_user_verification_status
data_type: bigint
description: The ID of the user verification status.
- name: is_test_account
data_type: boolean
description: |
True if the user is a test account. False otherwise.
Note that there might be other users that are test accounts
that are not controlled by this field. However it provides
a first level of filtering.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2005: Replace Guest Details in CheckIn Cover models with details coming from User table Fixes https://guardhog.visualstudio.com/Data/_boards/board/t/Data%20Team/Stories/?workitem=17240 Related work items: #17240
2024-06-10 15:30:26 +00:00
- name: int_core__vr_check_in_cover
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: "This tables holds information on verification requests
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
with Ckeck-in Hero available for the guests."
Merged PR 2005: Replace Guest Details in CheckIn Cover models with details coming from User table Fixes https://guardhog.visualstudio.com/Data/_boards/board/t/Data%20Team/Stories/?workitem=17240 Related work items: #17240
2024-06-10 15:30:26 +00:00
columns:
- name: id_verification_request
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
data_type: bigint
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description:
"Unique, incremental, internal ID for the related verification
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
request."
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2005: Replace Guest Details in CheckIn Cover models with details coming from User table Fixes https://guardhog.visualstudio.com/Data/_boards/board/t/Data%20Team/Stories/?workitem=17240 Related work items: #17240
2024-06-10 15:30:26 +00:00
- unique
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
- not_null
- name: uuid_verification_request
data_type: text
description: "uuid for the related verification request"
- name: id_verification_set
data_type: bigint
description: ""
- name: id_superhog_verified_set
data_type: bigint
description: ""
- name: id_payment_validation_set
data_type: bigint
description: ""
- name: id_user_guest
data_type: character varying
description: Unique, incremental, internal ID for the guest user.
- name: id_user_host
data_type: character varying
description: Unique, incremental, internal ID for the host user.
- name: id_booking
data_type: bigint
description: ""
- name: id_accommodation
data_type: bigint
description: "Id of the accommodation or listing."
- name: is_verification_request_complete
data_type: boolean
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: "True if the verification request is considered
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
complete, AKA the guest has finished the full guest journey."
- name: is_past_check_in
data_type: boolean
description: ""
- name: is_awaiting_check_in
data_type: boolean
description: ""
- name: cover_was_purchased
data_type: boolean
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: "Boolean to indicate if the cover was purchased by the guest or not."
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
- name: cover_was_rejected
data_type: boolean
description: ""
- name: verification_url
data_type: character varying
description: ""
- name: callback_url
data_type: character varying
description: ""
- name: redirect_url
data_type: character varying
description: ""
- name: logo
data_type: character varying
description: ""
- name: guest_email
data_type: character varying
description: "The email of the guest"
- name: last_name
data_type: character varying
description: The last name of the guest.
- name: first_name
data_type: character varying
description: The first name of the guest.
- name: guest_phone_number
data_type: character varying
description: The phone number of the guest.
- name: telephone_code
data_type: character varying
description: The telephone code of the guest.
- name: guest_phone_number_2
data_type: character varying
description: ""
- name: check_in_at_utc
data_type: timestamp without time zone
description: ""
- name: check_in_date_utc
data_type: date
description: ""
- name: check_out_at_utc
data_type: timestamp without time zone
description: ""
- name: check_out_date_utc
data_type: date
description: ""
- name: verification_start_at_utc
data_type: timestamp without time zone
description: ""
- name: verification_start_date_utc
data_type: date
description: ""
- name: verification_end_at_utc
data_type: timestamp without time zone
description: ""
- name: verification_end_date_utc
data_type: date
description: ""
- name: link_used_at_utc
data_type: timestamp without time zone
description: ""
- name: link_used_date_utc
data_type: date
description: ""
- name: expire_at_utc
data_type: timestamp without time zone
description: ""
- name: expire_date_utc
data_type: date
description: ""
- name: is_deleted
data_type: boolean
description: ""
- name: redirect_name
data_type: character varying
description: ""
- name: id_one_step_link
data_type: bigint
description: ""
- name: success_message
data_type: character varying
description: ""
- name: summary
data_type: character varying
description: ""
- name: rejection_reason
data_type: character varying
description: ""
- name: has_switched_to_mobile
data_type: boolean
description: ""
- name: is_verifier_rejected
data_type: boolean
description: ""
- name: config
data_type: character varying
description: ""
- name: metadata
data_type: character varying
description: ""
- name: created_at_utc
data_type: timestamp without time zone
description: "Date and time at which the validation was created."
- name: created_date_utc
data_type: date
description: ""
- name: updated_at_utc
data_type: timestamp without time zone
description: "Date and time at which the validation was last updated."
- name: updated_date_utc
data_type: date
description: ""
- name: dwh_extracted_at_utc
data_type: timestamp with time zone
description: "Date and time at which the record was extracted from the backend into the DWH."
- name: amount_in_txn_currency
data_type: numeric
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description:
"The payment amount in the currency in which the transaction actually happened.
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
If the guest paid in Australian Dollars, this is measured in AUD."
- name: currency
data_type: text
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: "The currency in which the transaction actually happened."
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
- name: amount_in_gbp
data_type: numeric
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description:
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
"The payment amount value, converted to GBP, using the exchange rate for
the day on which the payment happened."
- name: payment_status
data_type: character varying
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: "The status of the payment. It can be one of: Paid, Refunded, Refund Failed."
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
- name: payment_paid_date_utc
data_type: date
description: ""
- name: checkin_cover_limit_amount_local_curr
data_type: numeric
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description:
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
"The amount for which the guest user is covered if he faces problems
during check-in in their local currency."
- name: checkin_cover_limit_amount_in_gbp
data_type: numeric
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description:
Added Address_validation to int_core__vr_check_in_cover
2024-08-20 09:27:49 +02:00
"The amount for which the guest user is covered if he faces problems
during check-in in GBP."
Merged PR 2005: Replace Guest Details in CheckIn Cover models with details coming from User table Fixes https://guardhog.visualstudio.com/Data/_boards/board/t/Data%20Team/Stories/?workitem=17240 Related work items: #17240
2024-06-10 15:30:26 +00:00
Merged PR 2020: Verification request completeness for intermediate steps + schema documentation Add more detailed logic into the verification request completeness for intermediate stages. Added schema documentation Related work items: #17268
2024-06-13 08:14:11 +00:00
- name: int_core__verification_request_completeness
description: |
The `int_core__verification_request_completeness` model allows to determine if a verification request is
completed or not. To achieve it, it encapsulates the logic to determine the different possibilites. Its main
output is the column is_verification_request_complete, but it also provides outputs of the intermediate logic
steps to be used for further modeling, such as determining the completion date.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2020: Verification request completeness for intermediate steps + schema documentation Add more detailed logic into the verification request completeness for intermediate stages. Added schema documentation Related work items: #17268
2024-06-13 08:14:11 +00:00
columns:
- name: id_verification_request
data_type: bigint
description: id of the verification request. It's the unique key for this model.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2020: Verification request completeness for intermediate steps + schema documentation Add more detailed logic into the verification request completeness for intermediate stages. Added schema documentation Related work items: #17268
2024-06-13 08:14:11 +00:00
- not_null
- unique
- name: expected_verification_count
data_type: int
description: count of verifications that are expected to be passed in order to complete the request.
- name: confirmed_from_same_verification_request_count
data_type: int
description: count of confirmed verifications that its logic is computed from the same verification request.
- name: confirmed_from_previous_verification_requests_count
data_type: int
description: count of confirmed verifications that its logic is computed from previous verification requests.
- name: confirmed_verification_count
data_type: int
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2020: Verification request completeness for intermediate steps + schema documentation Add more detailed logic into the verification request completeness for intermediate stages. Added schema documentation Related work items: #17268
2024-06-13 08:14:11 +00:00
total count of confirmed verifications. Mainly, it's the sum of the confirmed verifications
that come from the same verification request plus the ones that come from previous verifications requests.
- name: is_verification_request_complete
data_type: boolean
description: if the verification request can be considered as completed or not.
- name: used_verification_from_same_verification_request
data_type: boolean
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2020: Verification request completeness for intermediate steps + schema documentation Add more detailed logic into the verification request completeness for intermediate stages. Added schema documentation Related work items: #17268
2024-06-13 08:14:11 +00:00
if the verification request can be considered as completed and has at least one confirmed verification
from the same verification request.
- name: used_verification_from_previous_verification_requests
data_type: boolean
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2020: Verification request completeness for intermediate steps + schema documentation Add more detailed logic into the verification request completeness for intermediate stages. Added schema documentation Related work items: #17268
2024-06-13 08:14:11 +00:00
if the verification request can be considered as completed and has at least one confirmed verification
from a previous verification request.
- name: is_complete_only_from_previous_verification_requests
data_type: boolean
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2020: Verification request completeness for intermediate steps + schema documentation Add more detailed logic into the verification request completeness for intermediate stages. Added schema documentation Related work items: #17268
2024-06-13 08:14:11 +00:00
if the verification request can be considered as completed and all confirmed verifications are from
previous verification requests.
Merged PR 2028: guest journey estimated completed date This PR includes the logic to handle the completed date of guest journey Check the schema file to understand the logic implemented. It's an estimation, and in some cases, weird stuff happens on end dates before link usage dates, which effectively breaks the computation. I added a boolean for this Related work items: #17268
2024-06-13 13:30:22 +00:00
- name: int_core__verification_request_completed_date
description: |
The `int_core__verification_request_completed_date` model allows to retrieve the time in which the guest
journey, or verification request, was completed. It only considers that a guest journey is completed based
on the positive outcome of the is_verification_complete boolean coming from verification_request_completeness
model.
The completion time is computed as follows:
- Only considering verification requests that have been tagged as completed. From here, we have:
- If the verification request has, at least, one verification linked; the date will be the creation date
of the last verification created linked to that verification request.
To keep in mind: for some cases, the last verification can have updates after the creation, but these
generally happen with very low time differences with respect to the creation date. However, there are
some outliers - mostly linked to admin override - that we're not considering here, since these might
not necessarily be linked to the Guest completing the Guest Journey.
- If the verification request does not have any verification linked; we assume an automatic completion.
In this case, we use the time from which the verification request was created.
For some cases, it is possible that this logic still generates some completed times that are actually
before a user usage of the link. For these cases, we do an override and we apply the used_link_at_utc
as the completed time. To account for this cases, check the boolean column
is_completed_at_overriden_with_used_link_at.
In summary, the guest journey completion time provided here is an estimation.
Finally, this model only contains those request that have been completed, so keep it in mind when joining this
table.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2028: guest journey estimated completed date This PR includes the logic to handle the completed date of guest journey Check the schema file to understand the logic implemented. It's an estimation, and in some cases, weird stuff happens on end dates before link usage dates, which effectively breaks the computation. I added a boolean for this Related work items: #17268
2024-06-13 13:30:22 +00:00
columns:
- name: id_verification_request
data_type: bigint
description: id of the completed verification request. It's the unique key for this model.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2028: guest journey estimated completed date This PR includes the logic to handle the completed date of guest journey Check the schema file to understand the logic implemented. It's an estimation, and in some cases, weird stuff happens on end dates before link usage dates, which effectively breaks the computation. I added a boolean for this Related work items: #17268
2024-06-13 13:30:22 +00:00
- not_null
- unique
- name: estimated_completed_at_utc
data_type: timestamp
description: estimated timestamp of when the verification request was completed.
- name: estimated_completed_date_utc
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
data_type: date
Merged PR 2028: guest journey estimated completed date This PR includes the logic to handle the completed date of guest journey Check the schema file to understand the logic implemented. It's an estimation, and in some cases, weird stuff happens on end dates before link usage dates, which effectively breaks the computation. I added a boolean for this Related work items: #17268
2024-06-13 13:30:22 +00:00
description: estimated date from the timestamp of when the verification request was completed.
- name: is_completed_at_overriden_with_used_link_at
add docs and tests
2024-06-18 13:10:47 +02:00
data_type: boolean
description: >
boolean indicating if the estimated dates have been overriden with the
fix docs
2024-06-18 13:40:36 +02:00
used link since the initial computation was still considering an end
date before a starting date.
add docs and tests
2024-06-18 13:10:47 +02:00
- name: int_core__verification_payments
commit2
2024-09-18 11:26:23 +02:00
latest_version: 2
fix docs
2024-06-18 13:40:36 +02:00
description: >-
A simplified table that holds guest journey payments with details around
when they happen, what service was being paid, what was the related
verification request, etc.
Currency rates are converted to GBP with our simple exchange rates view.
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
Guest taxes get calculated here. You can find out more about Guest Tax
calculation here: https://www.notion.so/knowyourguest-superhog/Guest-Services-Taxes-How-to-calculate-a5ab4c049d61427fafab669dbbffb3a2?pvs=4
add docs and tests
2024-06-18 13:10:47 +02:00
columns:
- name: id_verification_to_payment
data_type: bigint
formatting
2024-06-18 13:41:32 +02:00
description: Unique ID for the relation between the payment verification
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
and the payment at hand.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
add docs and tests
2024-06-18 13:10:47 +02:00
- unique
- not_null
- name: id_payment
data_type: bigint
description: Unique ID for the payment itself.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
add docs and tests
2024-06-18 13:10:47 +02:00
- unique
- not_null
- name: is_refundable
data_type: boolean
- name: created_at_utc
data_type: timestamp without time zone
- name: updated_at_utc
data_type: timestamp without time zone
- name: payment_due_at_utc
data_type: timestamp without time zone
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
add docs and tests
2024-06-18 13:10:47 +02:00
- not_null
- name: payment_due_date_utc
data_type: date
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
add docs and tests
2024-06-18 13:10:47 +02:00
- not_null
- name: payment_paid_at_utc
data_type: timestamp without time zone
- name: payment_paid_date_utc
data_type: date
- name: payment_reference
data_type: character varying
- name: refund_due_at_utc
data_type: timestamp without time zone
- name: refund_due_date_utc
data_type: date
- name: payment_refunded_at_utc
data_type: timestamp without time zone
- name: payment_refunded_date_utc
data_type: date
- name: refund_payment_reference
data_type: character varying
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
- name: id_user_host
data_type: character varying
description: |
UUID of the Host linked to the Verification Request
that has a payment. It's included here to speed up
KPIs execution, even though the host itself has nothing
to do with the guest payments.
add docs and tests
2024-06-18 13:10:47 +02:00
- name: id_guest_user
data_type: character varying
- name: id_verification
data_type: bigint
- name: id_verification_request
data_type: bigint
- name: verification_payment_type
data_type: character varying
- name: currency
data_type: character varying
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
add docs and tests
2024-06-18 13:10:47 +02:00
- not_null
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
- name: amount_in_txn_currency
data_type: numeric
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
- not_null
add docs and tests
2024-06-18 13:10:47 +02:00
- name: amount_in_gbp
data_type: numeric
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
add docs and tests
2024-06-18 13:10:47 +02:00
- not_null
- name: payment_status
data_type: character varying
- name: notes
data_type: character varying
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
versions:
- v: 2
columns:
commit wip
2025-02-10 14:51:03 +01:00
- name: is_host_taking_waiver_risk
data_type: boolean
description: Boolean indicating whether the host is taking the risk
- name: payaway_percentage
data_type: numeric
description: Percentage of the payment that goes to Superhog.
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
max_value: 0.99
strictly: false
- name: payaway_minimum_commission_local_curr
data_type: numeric
description: Minimum commission amount in local currency.
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
- name: total_amount_in_txn_currency
data_type: numeric
description: |
The total amount due created by the interaction, in the currency
of the transaction.
Should we refund the payment, this is also the amount we will give
back to the guest.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
- not_null
- name: total_amount_in_gbp
data_type: numeric
description: |
The total amount due created by the interaction, in GBP.
clarify refund is not in GBP
2024-09-13 13:09:01 +02:00
Should we refund the payment, this is the GBP equivalent of the
amount we will give back to the guest, but we won't be paying in
GBP unless the original payment was in GBP.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
- not_null
- name: tax_amount_in_txn_currency
data_type: numeric
description: |
The tax amount applicable to this transaction, in the currency of
the transaction.
If the transaction accrues no taxes, will be 0.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
- not_null
- name: tax_amount_in_gbp
data_type: numeric
description: |
The tax amount applicable to this transaction, in GBP.
If the transaction accrues no taxes, will be 0.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
- not_null
- name: amount_without_taxes_in_txn_currency
data_type: numeric
description: |
The total amount minus taxes, in the currency of the transaction.
This is what should be considered net-of-taxes revenue for
Superhog.
If the transaction accrues no taxes, will be equal to the field
total_amount_in_txn_currency.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
- not_null
- name: amount_without_taxes_in_gbp
data_type: numeric
description: |
The total amount minus taxes, in GBP.
This is what should be considered net-of-taxes revenue for
Superhog.
If the transaction accrues no taxes, will be equal to the field
total_amount_in_txn_currency.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
- not_null
add columns
2024-09-10 17:10:37 +02:00
- name: vat_rate
data_type: numeric
description: |
The applicable VAT rate to this payment. This is inferred from (1)
which service is the payment related to and (2) what's the billing
country of the guest.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
add columns
2024-09-10 17:10:37 +02:00
- not_null
replace custom generic test with standard range between one
2024-09-13 15:14:32 +02:00
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
max_value: 0.99 # If we ever have a 100% tax rate... Let's riot working please
strictly: false
add columns
2024-09-10 17:10:37 +02:00
- name: is_service_subject_to_vat
data_type: boolean
description: |
Whether the related payment is subject to VAT. For instance,
deposit payments are not.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
add columns
2024-09-10 17:10:37 +02:00
- not_null
finish columns and schema
2024-09-12 14:37:45 +02:00
- name: is_vat_taxed
add columns
2024-09-10 17:10:37 +02:00
data_type: boolean
description: |
clarify refund is not in GBP
2024-09-13 13:09:01 +02:00
Syntactic sugar to indicate if there's any VAT on this payment.
add columns
2024-09-10 17:10:37 +02:00
Will be true if so, false if not for any reason (guest country has
no VAT, the payment is for a deposit, etc.)
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
finish columns and schema
2024-09-12 14:37:45 +02:00
- not_null
commit wip
2025-02-10 14:51:03 +01:00
- name: amount_due_to_host_in_txn_currency
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The amount payable to the host with taxes, in local currency.
commit wip
2025-02-10 14:51:03 +01:00
- name: amount_due_to_host_in_gbp
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The amount payable to the host with taxes, in GBP.
- name: amount_due_to_host_without_taxes_in_txn_currency
data_type: numeric
description: |
The amount payable to the host without taxes, in local currency.
- name: amount_due_to_host_without_taxes_in_gbp
data_type: numeric
description: |
The amount payable to the host without taxes, in GBP.
commit wip
2025-02-10 14:51:03 +01:00
- name: superhog_fee_in_txn_currency
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The service fee charged by Superhog with taxes, in local currency.
commit wip
2025-02-10 14:51:03 +01:00
- name: superhog_fee_in_gbp
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The service fee charged by Superhog with taxes, in GBP.
- name: superhog_fee_without_taxes_in_txn_currency
data_type: numeric
description: |
The service fee charged by Superhog without taxes, in local currency.
- name: superhog_fee_without_taxes_in_gbp
data_type: numeric
description: |
The service fee charged by Superhog without taxes, in GBP.
commit wip
2025-02-10 14:51:03 +01:00
finish columns and schema
2024-09-12 14:37:45 +02:00
- name: is_missing_user_country
data_type: boolean
description: |
True if, for some reason, the user doesn't have an informed
country.
The only known, justified reason for this is that the user was
deleted, along with the billing details.
If this turns true in any other case, you should really find out
why the guest doesn't have a billing country.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
activate one test, prepare another but keep it commented
2024-09-27 16:11:34 +02:00
- not_null
- accepted_values:
values:
- false
where: (are_user_details_deleted != true and are_user_details_deleted is not null)
finish columns and schema
2024-09-12 14:37:45 +02:00
- name: is_missing_vat_rate_for_country
data_type: boolean
description: |
True if the user country is informed, but no VAT rates were found
for it.
This has to be a joining issue, since our database for VAT rates
covers all the countries in the world. We simply assign a 0% rate
to countries where we don't collect taxes.
If this turns true in any other case, you should really find out
what's happening.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3024: Activate country test for taxes # Description Activates a commented out test for verification payments v2. The test was deactivated because of some master data issues in the backend, but they were fixed after #22148. # Checklist - [NA] The edited models and dependants run properly with production data. - [NA ] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20043
2024-10-02 09:09:18 +00:00
- not_null
- accepted_values:
values:
- false
where: (are_user_details_deleted != true and are_user_details_deleted is not null)
finish columns and schema
2024-09-12 14:37:45 +02:00
- name: are_user_details_deleted
data_type: boolean
description: |
True if the user has been deleted, which is a possible explanation
for why there might be no country informed.
clarify refund is not in GBP
2024-09-13 13:09:01 +02:00
finish columns and schema
2024-09-12 14:37:45 +02:00
- name: is_missing_vat_details_without_known_cause
data_type: boolean
description: |
True if the VAT rate is missing as a fallback for any
other reason beyond the other one specified in the table.
If this turns true, you have an unhandled problem and you should
fix it.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
clarify refund is not in GBP
2024-09-13 13:09:01 +02:00
- not_null
finish columns and schema
2024-09-12 14:37:45 +02:00
- accepted_values:
values:
- false
yaml for new version, plus deprecation
2024-09-06 17:22:52 +02:00
- include: all
exclude: [amount_in_txn_currency, amount_in_gbp]
Merged PR 2077: Adding Country to intermediate Adding Country to intermediate, both model + documentation. At this stage, the model is set as a view but we can discuss what is the best approach Related work items: #17312
2024-06-19 15:34:15 +00:00
- name: int_core__country
description: |
This model contains information regarding countries, such as codes,
names and preferred currencies
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2077: Adding Country to intermediate Adding Country to intermediate, both model + documentation. At this stage, the model is set as a view but we can discuss what is the best approach Related work items: #17312
2024-06-19 15:34:15 +00:00
columns:
- name: id_country
data_type: bigint
description: id of the country. It's the unique key for this model.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2077: Adding Country to intermediate Adding Country to intermediate, both model + documentation. At this stage, the model is set as a view but we can discuss what is the best approach Related work items: #17312
2024-06-19 15:34:15 +00:00
- not_null
- unique
- name: iso_2
data_type: char(2)
description: ISO 3166-1 alpha-2 country code. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2077: Adding Country to intermediate Adding Country to intermediate, both model + documentation. At this stage, the model is set as a view but we can discuss what is the best approach Related work items: #17312
2024-06-19 15:34:15 +00:00
- not_null
- name: iso_3
data_type: char(3)
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2077: Adding Country to intermediate Adding Country to intermediate, both model + documentation. At this stage, the model is set as a view but we can discuss what is the best approach Related work items: #17312
2024-06-19 15:34:15 +00:00
ISO 3166-1 alpha-3 country code. Some countries can have this value as not set,
therefore it's nullable.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2077: Adding Country to intermediate Adding Country to intermediate, both model + documentation. At this stage, the model is set as a view but we can discuss what is the best approach Related work items: #17312
2024-06-19 15:34:15 +00:00
- name: country_name
data_type: character varying
description: name of the country. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2077: Adding Country to intermediate Adding Country to intermediate, both model + documentation. At this stage, the model is set as a view but we can discuss what is the best approach Related work items: #17312
2024-06-19 15:34:15 +00:00
- not_null
- name: iso_num_code
data_type: int
description: |
ISO 3166-1 numeric code. Usually it's 3 digits, but since it's categorised as
an integer, the preceding zeros are removed. Nullable.
- name: phone_code
data_type: int
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2077: Adding Country to intermediate Adding Country to intermediate, both model + documentation. At this stage, the model is set as a view but we can discuss what is the best approach Related work items: #17312
2024-06-19 15:34:15 +00:00
Phone code prefix for a given country. Can contain default / duplicated values.
- name: id_preferred_currency
data_type: int
description: |
Id of the preferred currency for a given country. Might not be the only currency
used in the country, it's just the preferred one.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2077: Adding Country to intermediate Adding Country to intermediate, both model + documentation. At this stage, the model is set as a view but we can discuss what is the best approach Related work items: #17312
2024-06-19 15:34:15 +00:00
- not_null
- name: preferred_currency_name
data_type: character varying
description: |
Currency name of the preferred currency for a given country.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2077: Adding Country to intermediate Adding Country to intermediate, both model + documentation. At this stage, the model is set as a view but we can discuss what is the best approach Related work items: #17312
2024-06-19 15:34:15 +00:00
- not_null
- name: preferred_iso4217_code
data_type: char(3)
description: |
Three-letter code assigned to the preferred currency for a given country by the ISO.
These codes are part of the ISO 4217 standard.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2077: Adding Country to intermediate Adding Country to intermediate, both model + documentation. At this stage, the model is set as a view but we can discuss what is the best approach Related work items: #17312
2024-06-19 15:34:15 +00:00
- not_null
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2084: Adding int_core__accommodation Adding int_core__accommodation Includes both: - Main information of the accommodation, mostly coming from stg_core__accommodation and int_core__country. - Listing lifecycle computation, based on the created bookings from stg_core__bookings. It's just the current state, no history. Some considerations: - I opted to use stg_core__bookings and not int_core__bookings. Main reason is in case at some point we want to add listing-based information to the booking table, it would avoid cyclic references. - I opted to keep all the logic of 1) accommodation info and 2) lifecycle in the same model. This could be easily split into: lifecycle first that reads uniquely from staging and then the int_core__accommodation that could read from the staging version to retrieve accommodation attributes + the lifecycle one. Up to you I'd suggest to review first the documentation in schema since it explains the logic applied. Notion page linked to this task: https://www.notion.so/knowyourguest-superhog/Listing-lifecycle-4dc0311b21ca44f8859969e419872ebd Related work items: #17312
2024-06-20 16:02:16 +00:00
- name: int_core__accommodation
description: |
This model contains information regarding accommodations, also known as listings.
It contains information regarding the host this accommodation is linked to,
the geographic details, the preferred currency according to the country, details about
the listing itself (floors, bedrooms, etc) and time-related information of when the
Merged PR 2094: Removing lifecycle logic from int_core__accommodation Removing lifecycle logic from int_core__accommodation This logic is now available on int_core__mtd_accommodation_lifecycle Related work items: #17312
2024-06-21 14:13:42 +00:00
listing was created.
Merged PR 2084: Adding int_core__accommodation Adding int_core__accommodation Includes both: - Main information of the accommodation, mostly coming from stg_core__accommodation and int_core__country. - Listing lifecycle computation, based on the created bookings from stg_core__bookings. It's just the current state, no history. Some considerations: - I opted to use stg_core__bookings and not int_core__bookings. Main reason is in case at some point we want to add listing-based information to the booking table, it would avoid cyclic references. - I opted to keep all the logic of 1) accommodation info and 2) lifecycle in the same model. This could be easily split into: lifecycle first that reads uniquely from staging and then the int_core__accommodation that could read from the staging version to retrieve accommodation attributes + the lifecycle one. Up to you I'd suggest to review first the documentation in schema since it explains the logic applied. Notion page linked to this task: https://www.notion.so/knowyourguest-superhog/Listing-lifecycle-4dc0311b21ca44f8859969e419872ebd Related work items: #17312
2024-06-20 16:02:16 +00:00
columns:
- name: id_accommodation
data_type: bigint
description: Id of the accommodation or listing. It's the unique key for this model.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2084: Adding int_core__accommodation Adding int_core__accommodation Includes both: - Main information of the accommodation, mostly coming from stg_core__accommodation and int_core__country. - Listing lifecycle computation, based on the created bookings from stg_core__bookings. It's just the current state, no history. Some considerations: - I opted to use stg_core__bookings and not int_core__bookings. Main reason is in case at some point we want to add listing-based information to the booking table, it would avoid cyclic references. - I opted to keep all the logic of 1) accommodation info and 2) lifecycle in the same model. This could be easily split into: lifecycle first that reads uniquely from staging and then the int_core__accommodation that could read from the staging version to retrieve accommodation attributes + the lifecycle one. Up to you I'd suggest to review first the documentation in schema since it explains the logic applied. Notion page linked to this task: https://www.notion.so/knowyourguest-superhog/Listing-lifecycle-4dc0311b21ca44f8859969e419872ebd Related work items: #17312
2024-06-20 16:02:16 +00:00
- not_null
- unique
- name: id_user_host
data_type: character varying
description: The unique ID for the host. Can be null.
- name: id_payment_validation_set
data_type: bigint
description: Id of the payment validation set linked to a listing. Can be null.
- name: friendly_name
data_type: character varying
- name: country_iso_2
data_type: char(2)
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: ISO 3166-1 alpha-2 country code where the listing is located.
Merged PR 2084: Adding int_core__accommodation Adding int_core__accommodation Includes both: - Main information of the accommodation, mostly coming from stg_core__accommodation and int_core__country. - Listing lifecycle computation, based on the created bookings from stg_core__bookings. It's just the current state, no history. Some considerations: - I opted to use stg_core__bookings and not int_core__bookings. Main reason is in case at some point we want to add listing-based information to the booking table, it would avoid cyclic references. - I opted to keep all the logic of 1) accommodation info and 2) lifecycle in the same model. This could be easily split into: lifecycle first that reads uniquely from staging and then the int_core__accommodation that could read from the staging version to retrieve accommodation attributes + the lifecycle one. Up to you I'd suggest to review first the documentation in schema since it explains the logic applied. Notion page linked to this task: https://www.notion.so/knowyourguest-superhog/Listing-lifecycle-4dc0311b21ca44f8859969e419872ebd Related work items: #17312
2024-06-20 16:02:16 +00:00
- name: country_name
data_type: character varying
description: Name of the country where the listing is located.
- name: country_preferred_currency_code
data_type: char(3)
description: |
Three-letter code assigned to the preferred currency for a given country by the ISO.
These codes are part of the ISO 4217 standard. Keep in mind this are preferred, not
necessarily the actual currency.
- name: is_active
data_type: boolean
description: |
Boolean to indicate if the listing is active or not. If false, this is considered as a
hard deactivation - meaning no more bookings can be assigned to this listing. However,
even if a listing is active, that does not necessarily mean that it's receiving bookings.
Merged PR 3472: Remove unused models and schema entries for deals and accommodations # Description Eliminates models that have been switched with new kpis flow. Also deletes temporary tests and schema entries. # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #23762
2024-11-08 12:05:40 +00:00
Do not confuse this column with the lifecycle activity of a listing.
Merged PR 2084: Adding int_core__accommodation Adding int_core__accommodation Includes both: - Main information of the accommodation, mostly coming from stg_core__accommodation and int_core__country. - Listing lifecycle computation, based on the created bookings from stg_core__bookings. It's just the current state, no history. Some considerations: - I opted to use stg_core__bookings and not int_core__bookings. Main reason is in case at some point we want to add listing-based information to the booking table, it would avoid cyclic references. - I opted to keep all the logic of 1) accommodation info and 2) lifecycle in the same model. This could be easily split into: lifecycle first that reads uniquely from staging and then the int_core__accommodation that could read from the staging version to retrieve accommodation attributes + the lifecycle one. Up to you I'd suggest to review first the documentation in schema since it explains the logic applied. Notion page linked to this task: https://www.notion.so/knowyourguest-superhog/Listing-lifecycle-4dc0311b21ca44f8859969e419872ebd Related work items: #17312
2024-06-20 16:02:16 +00:00
- name: town
data_type: character varying
- name: postcode
data_type: character varying
- name: address_line_1
data_type: character varying
- name: address_line_2
data_type: character varying
- name: number_of_bedrooms
data_type: integer
- name: number_of_bathrooms
data_type: integer
- name: created_at_utc
data_type: timestamp
description: Timestamp of when the listing was created. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2084: Adding int_core__accommodation Adding int_core__accommodation Includes both: - Main information of the accommodation, mostly coming from stg_core__accommodation and int_core__country. - Listing lifecycle computation, based on the created bookings from stg_core__bookings. It's just the current state, no history. Some considerations: - I opted to use stg_core__bookings and not int_core__bookings. Main reason is in case at some point we want to add listing-based information to the booking table, it would avoid cyclic references. - I opted to keep all the logic of 1) accommodation info and 2) lifecycle in the same model. This could be easily split into: lifecycle first that reads uniquely from staging and then the int_core__accommodation that could read from the staging version to retrieve accommodation attributes + the lifecycle one. Up to you I'd suggest to review first the documentation in schema since it explains the logic applied. Notion page linked to this task: https://www.notion.so/knowyourguest-superhog/Listing-lifecycle-4dc0311b21ca44f8859969e419872ebd Related work items: #17312
2024-06-20 16:02:16 +00:00
- not_null
- name: created_date_utc
data_type: date
description: Date of when the listing was created
- name: updated_at_utc
data_type: timestamp
description: Timestamp of when the listing was last updated according to the backend.
- name: updated_date_utc
data_type: date
description: Date of when the listing was last updated according to the backend.
- name: dwh_extracted_at_utc
data_type: timestamp
description: Timestamp of when the accommodation record was extracted from the backend into the DWH.
add docs and tests
2024-06-18 13:10:47 +02:00
Fixed merge error
2024-06-27 10:18:29 +02:00
- name: int_core__check_in_cover_users
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description:
Completed the schema for the model
2024-06-27 10:40:44 +02:00
This model contains information about hosts that offer check in cover.
It has basic information on the users like name, phone, email or joined date.
Addressed comments
2024-06-27 12:13:27 +02:00
This model is restricted to active user so it doesn't include historical data
like users that had check-in cover but are currently inactive.
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
columns:
Fixing errors raised by texts
2024-07-04 16:41:41 +02:00
- name: id_user_host
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
data_type: character varying
Completed the schema for the model
2024-06-27 10:40:44 +02:00
description: Unique id value for the user
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Completed the schema for the model
2024-06-27 10:40:44 +02:00
- not_null
- unique
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
Added id_deal to both intermediate and report model
2024-07-01 10:48:00 +02:00
- name: id_deal
data_type: character varying
description: ""
Fixed merge error
2024-06-27 10:18:29 +02:00
- name: last_name
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
data_type: character varying
Completed the schema for the model
2024-06-27 10:40:44 +02:00
description: Last name of the user
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
Fixed merge error
2024-06-27 10:18:29 +02:00
- name: user_name
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
data_type: character varying
Completed the schema for the model
2024-06-27 10:40:44 +02:00
description: User name of the user
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
Fixed merge error
2024-06-27 10:18:29 +02:00
- name: first_name
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
data_type: character varying
Completed the schema for the model
2024-06-27 10:40:44 +02:00
description: First name of the user
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
Fixing errors raised by texts
2024-07-04 16:41:41 +02:00
- name: host_email
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
data_type: character varying
Completed the schema for the model
2024-06-27 10:40:44 +02:00
description: Email of the user
Fixed merge error
2024-06-27 10:18:29 +02:00
- name: phone_number
data_type: character varying
Completed the schema for the model
2024-06-27 10:40:44 +02:00
description: Phone number of the user
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
- name: joined_at_utc
data_type: timestamp without time zone
Completed the schema for the model
2024-06-27 10:40:44 +02:00
description: Date and time the user joined
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
- name: joined_date_utc
data_type: date
Completed the schema for the model
2024-06-27 10:40:44 +02:00
description: Date the user joined
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
Modified date name to stick to convention
2024-07-04 08:24:23 +02:00
- name: check_in_cover_added_date_utc
Added date of adaptation
2024-07-03 15:05:12 +02:00
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Date the user first included check-in cover
Added date of adaptation
2024-07-03 15:05:12 +02:00
Fixed merge error
2024-06-27 10:18:29 +02:00
- name: billing_town
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
data_type: character varying
description: ""
Fixed merge error
2024-06-27 10:18:29 +02:00
- name: company_name
Removed accommodations from the model
2024-06-27 08:40:25 +02:00
data_type: character varying
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
description: ""
- name: int_core__guest_satisfaction_responses
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description:
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
This model contains information on guests satisfaction survey responses,
it contains some basic information on the guests, a rating of their experience
and some comments on it.
It also includes information on the services provided by Superhog that they payed for.
columns:
- name: id_verification_request
data_type: bigint
description: Unique id value for the verification request
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
- not_null
- unique
Added date of birth and kept age
2024-07-03 15:18:05 +02:00
- name: id_user_guest
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
data_type: character varying
description: Unique id value for the guest
Added date of birth and kept age
2024-07-03 15:18:05 +02:00
- name: guest_email
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
data_type: character varying
description: Guest email
Added verification_request_booking_source to int_core__guest_satisfaction_responses model
2024-07-12 12:38:52 +02:00
- name: verification_request_booking_source
data_type: text
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Source type of host of the booking, this could be either;
Added verification_request_booking_source to int_core__guest_satisfaction_responses model
2024-07-12 12:38:52 +02:00
- PMS
- OSL
- API/MANUAL
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Added verification_request_booking_source to int_core__guest_satisfaction_responses model
2024-07-12 12:38:52 +02:00
- not_null
- accepted_values:
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
values:
- "PMS"
- "OSL"
- "API/MANUAL"
Added verification_request_booking_source to int_core__guest_satisfaction_responses model
2024-07-12 12:38:52 +02:00
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
- name: experience_rating
data_type: bigint
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Guest rating of their experience with Superhog from 1 to 5
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
- name: guest_comments
data_type: character varying
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Guest comments on their experience with Superhog
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
- name: is_contactable
data_type: boolean
description: |
True if the guest allows to be contacted for more feedback
- name: created_at_utc
data_type: timestamp without time zone
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Date and time of response creation
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
- name: updated_at_utc
data_type: timestamp without time zone
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Date and time of last update of response
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
Added date of birth and kept age
2024-07-03 15:18:05 +02:00
- name: selected_payment_option
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
data_type: character varying
description: ""
Added date of birth and kept age
2024-07-03 15:18:05 +02:00
- name: date_of_birth
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
data_type: numeric
description: ""
Added date of birth and kept age
2024-07-03 15:18:05 +02:00
- name: age_of_guest
data_type: numeric
description: ""
Changed names of types of payments for better clarity
2024-07-03 16:23:52 +02:00
- name: has_check_in_cover_payment
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
data_type: boolean
Changed names of types of payments for better clarity
2024-07-03 16:23:52 +02:00
description: |
True if guest payed for check-in cover
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
Changed names of types of payments for better clarity
2024-07-03 16:23:52 +02:00
- name: has_waiver_payment
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
data_type: boolean
Changed names of types of payments for better clarity
2024-07-03 16:23:52 +02:00
description: |
True if guest payed the waiver
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
Changed names of types of payments for better clarity
2024-07-03 16:23:52 +02:00
- name: has_deposit_payment
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
data_type: boolean
Changed names of types of payments for better clarity
2024-07-03 16:23:52 +02:00
description: |
True if guest payed the deposit
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
Changed names of types of payments for better clarity
2024-07-03 16:23:52 +02:00
- name: has_fee_payment
Addresed Uri's comments and also included new reports in exposures.ymal
2024-07-03 12:29:01 +02:00
data_type: boolean
Changed names of types of payments for better clarity
2024-07-03 16:23:52 +02:00
description: |
Created model int_core__verification_request_booking_source to have easier access to host category type in different models
2024-07-11 15:36:32 +02:00
True if guest payed the fee
- name: int_core__verification_request_booking_source
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: This model contains information on verification requests
Created model int_core__verification_request_booking_source to have easier access to host category type in different models
2024-07-11 15:36:32 +02:00
and the category type of host that manages the associated
booking.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
For PMS (Property Manager System) we use the id_integration
Removed bookings_id so we have unique values for id_verification_request, added details as to how we classify the hosts
2024-07-11 16:26:41 +02:00
from stg_core__booking, if it isn't Null then the host is PMS type.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
For OSL (One Step Link) we use the id_one_step_link from
stg_core__verification_request, similarly if it isn't Null then
Removed bookings_id so we have unique values for id_verification_request, added details as to how we classify the hosts
2024-07-11 16:26:41 +02:00
the host is OSL type.
Removed bookings_id so we have unique values for id_verification_request, added details as to how we classify the hosts
2024-07-11 16:19:33 +02:00
Finally if both id_integration and id_one_step_link are Null,
then we classify them as API/MANUAL. (At this point we can't
differentiate between these 2 categories so for now we keep
them together)
Created model int_core__verification_request_booking_source to have easier access to host category type in different models
2024-07-11 15:36:32 +02:00
columns:
- name: id_verification_request
data_type: bigint
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Id value for the verification request, there can be more
Created model int_core__verification_request_booking_source to have easier access to host category type in different models
2024-07-11 15:36:32 +02:00
than 1 record for each verification request since they can
be associated to more than 1 booking
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Created model int_core__verification_request_booking_source to have easier access to host category type in different models
2024-07-11 15:36:32 +02:00
- not_null
Removed bookings_id so we have unique values for id_verification_request, added details as to how we classify the hosts
2024-07-11 16:19:33 +02:00
- unique
Created model int_core__verification_request_booking_source to have easier access to host category type in different models
2024-07-11 15:36:32 +02:00
- name: created_at_utc
data_type: timestamp without time zone
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Date and time of creation of the verification request
Created model int_core__verification_request_booking_source to have easier access to host category type in different models
2024-07-11 15:36:32 +02:00
- name: created_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Date of creation of the verification request
Created model int_core__verification_request_booking_source to have easier access to host category type in different models
2024-07-11 15:36:32 +02:00
Removed guests_id and modified query structure
2024-07-11 16:49:24 +02:00
- name: verification_request_booking_source
Created model int_core__verification_request_booking_source to have easier access to host category type in different models
2024-07-11 15:36:32 +02:00
data_type: text
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Source type of host of the booking, this could be either;
Created model int_core__verification_request_booking_source to have easier access to host category type in different models
2024-07-11 15:36:32 +02:00
- PMS
- OSL
Removed bookings_id so we have unique values for id_verification_request, added details as to how we classify the hosts
2024-07-11 16:19:33 +02:00
- API/MANUAL
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Removed guests_id and modified query structure
2024-07-11 16:49:24 +02:00
- not_null
Removed bookings_id so we have unique values for id_verification_request, added details as to how we classify the hosts
2024-07-11 16:19:33 +02:00
- accepted_values:
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
values:
- "PMS"
- "OSL"
- "API/MANUAL"
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: int_core__verification_requests
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description:
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
This is a table that shows all guest journey from our guests users with
each record matching each guest journey.
It holds information about the guests like name, email, phone, etc.., as
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
well as dates regarding the process of the guest journey like when it
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
was started or finished.
columns:
- name: id_verification_request
data_type: bigint
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description:
Unique, incremental, internal ID for the related verification
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
request.
- name: uuid_verification_request
data_type: text
description: uuid for the related verification request.
- name: id_verification_set
data_type: bigint
description: ""
- name: id_superhog_verified_set
data_type: bigint
description: ""
- name: id_payment_validation_set
data_type: bigint
description: ""
- name: id_user_guest
data_type: character varying
description: Unique, incremental, internal ID for the guest user.
- name: id_user_host
data_type: character varying
description: Unique, incremental, internal ID for the host user.
- name: is_verification_request_complete
data_type: boolean
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: True if the verification request is considered
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
complete, AKA the guest has finished the full guest journey.
- name: verification_url
data_type: character varying
description: ""
- name: callback_url
data_type: character varying
description: ""
- name: redirect_url
data_type: character varying
description: ""
- name: logo
data_type: character varying
description: ""
- name: guest_email
data_type: character varying
description: The email of the guest.
- name: last_name
data_type: character varying
description: The last name of the guest.
- name: first_name
data_type: character varying
description: The first name of the guest.
- name: guest_phone_number
data_type: character varying
description: The phone number of the guest.
- name: telephone_code
data_type: character varying
description: The telephone code of the guest.
- name: guest_phone_number_2
data_type: character varying
description: ""
Fixed schema names
2024-07-12 11:06:09 +02:00
- name: verification_estimated_started_at_utc
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
data_type: timestamp without time zone
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The estimated date and time at which the guest started the guest journey.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
Fixed schema names
2024-07-12 11:06:09 +02:00
- name: verification_estimated_started_date_utc
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The estimated date on which the guest started the guest journey.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
Fixed schema names
2024-07-12 11:06:09 +02:00
- name: verification_estimated_completed_at_utc
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
data_type: timestamp without time zone
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The estimated date and time at which the guest finished the guest journey.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
Fixed schema names
2024-07-12 11:06:09 +02:00
- name: verification_estimated_completed_date_utc
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The estimated date on which the guest finished the guest journey.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: link_used_at_utc
data_type: timestamp without time zone
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The date and time at which the guest used the link for the verification.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: link_used_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The date on which the guest used the link for the verification.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: expire_at_utc
data_type: timestamp without time zone
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The date and time at which the link for the verification expires.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: expire_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The date on which the link for the verification expires.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: is_deleted
data_type: boolean
description: |
True if the link for verification expired before finishing the
verification.
- name: redirect_name
data_type: character varying
description: ""
- name: id_one_step_link
data_type: bigint
description: ""
- name: verification_request_booking_source
data_type: text
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Source type of host of the booking, this could be either;
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- PMS
- OSL
- API/MANUAL
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- not_null
- accepted_values:
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
values:
- "PMS"
- "OSL"
- "API/MANUAL"
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: success_message
data_type: character varying
description: ""
- name: summary
data_type: character varying
description: ""
- name: rejection_reason
data_type: character varying
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Reason as to why the guest was rejected.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: has_switched_to_mobile
data_type: boolean
description: |
True if the guest changed has switched to mobile
during the verification process.
- name: is_verifier_rejected
data_type: boolean
description: ""
- name: config
data_type: character varying
description: ""
- name: metadata
data_type: character varying
description: ""
- name: created_at_utc
data_type: timestamp without time zone
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The date and time at which the verification process was created.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: created_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The date on which the verification process was created.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: updated_at_utc
data_type: timestamp without time zone
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The date and time at which the last update on the entry happened.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: updated_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: The date on which the last update on the entry happened.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: dwh_extracted_at_utc
data_type: timestamp with time zone
description: ""
- name: int_core__bookings
description: ""
columns:
- name: id_booking
data_type: bigint
description: "The unique, Superhog generated id for this booking."
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- unique
- not_null
- name: id_user_guest
data_type: character varying
description: "The unique, Superhog generated id for the guest"
- name: id_user_host
data_type: character varying
description: "The unique, Superhog generated id for the host"
- name: id_integration
data_type: character varying
description: ""
- name: id_accommodation
data_type: bigint
description: "The ID of the booked listing."
- name: id_booking_source
data_type: bigint
description: ""
- name: id_verification_request
data_type: bigint
description: "Id value for the verification request, there can be more than 1 record for each verification request since they can be associated to more than 1 booking"
- name: verification_request_booking_source
data_type: text
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Source type of host of the booking, this could be either;
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- PMS
- OSL
- API/MANUAL
fixed bookings test to include null for verification_request_booking_source
2024-08-27 15:45:22 +02:00
- null (bookings without verification request)
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- accepted_values:
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
values:
- "PMS"
- "OSL"
- "API/MANUAL"
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: is_duplicate_booking
data_type: boolean
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: A flag that identifies whether the booking is a duplicate.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
A booking is considered a duplicate if there's an older booking with the same user,
accomodation and check-in date. If there are two or more bookings with the same user,
accomodation and check-in date, the oldest one will have False as a value in this field,
and the other ones will have True as a value in this Failed."
I modified the model of duplicated_bookings, I saw it had some errors and data that was not being used
2024-07-31 12:44:54 +02:00
Put simply, if you don't want to receive duplicates, filter this field to False.
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: is_duplicating_booking_with_id
data_type: bigint
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: "If is_duplicate_booking is True then gives id_booking"
Added models in schema for intermediate
2024-07-12 10:11:51 +02:00
- name: booking_state
data_type: character varying
description: ""
- name: check_in_at_utc
data_type: timestamp without time zone
description: ""
- name: check_in_date_utc
data_type: date
description: ""
- name: check_out_at_utc
data_type: timestamp without time zone
description: ""
- name: check_out_date_utc
data_type: date
description: ""
- name: check_in_sits_in_future
data_type: boolean
description: ""
- name: check_out_sits_in_future
data_type: boolean
description: ""
- name: booking_fee_local
data_type: numeric
description: "The fee to apply to the booking, in host currency."
- name: booking_fee_charge_at_utc
data_type: timestamp without time zone
description: The point in time in which the booking should be invoiced.
This could be the check-in date of the booking or the date in which the guest verification
started, depending on the billing settings of the host.
- name: booking_fee_charge_date_utc
data_type: date
description: The date in which the booking should be invoiced.
This could be the check-in date of the booking or the date in which the guest verification
started, depending on the billing settings of the host.
- name: summary
data_type: character varying
description: ""
- name: guest_email
data_type: character varying
description: ""
- name: guest_last_name
data_type: character varying
description: ""
- name: guest_first_name
data_type: character varying
description: ""
- name: guest_telephone
data_type: character varying
description: ""
- name: unsubscribe_verification_reminder
data_type: boolean
description: ""
- name: created_at_utc
data_type: timestamp without time zone
description: "Date and time of creation of the verification request"
- name: created_date_utc
data_type: date
description: "Date of creation of the verification request"
- name: updated_at_utc
data_type: timestamp without time zone
description: ""
- name: updated_date_utc
data_type: date
description: ""
- name: dwh_extracted_at_utc
data_type: timestamp with time zone
Created new model with listings with check in hero active
2024-07-24 16:53:16 +02:00
description: ""
- name: int_core__check_in_cover_listings
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: This model contains information about hosts and their listings
Created new model with listings with check in hero active
2024-07-24 16:53:16 +02:00
that offer check in cover.
It has basic information on the users and listings like country,
town, address and if they are active or not.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
This model is restricted to active user so it doesn't include historical
Created new model with listings with check in hero active
2024-07-24 16:53:16 +02:00
data like users that had check-in cover but are currently inactive.
columns:
- name: id_user_host
data_type: character varying
description: Unique id value for the user
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Created new model with listings with check in hero active
2024-07-24 16:53:16 +02:00
- not_null
- name: id_deal
data_type: character varying
description: ""
- name: last_name
data_type: character varying
description: Last name of the user
- name: user_name
data_type: character varying
description: User name of the user
- name: first_name
data_type: character varying
description: First name of the user
- name: host_email
data_type: character varying
description: Email of the user
- name: phone_number
data_type: character varying
description: Phone number of the user
- name: joined_at_utc
data_type: timestamp without time zone
description: Date and time the user joined
- name: joined_date_utc
data_type: date
description: Date the user joined
- name: check_in_cover_added_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Date the user first included check-in cover
Created new model with listings with check in hero active
2024-07-24 16:53:16 +02:00
- name: billing_town
data_type: character varying
description: ""
- name: company_name
data_type: character varying
description: ""
- name: id_accommodation
data_type: bigint
description: "Id of the accommodation or listing. It's the unique key for this model."
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Created new model with listings with check in hero active
2024-07-24 16:53:16 +02:00
- not_null
- unique
- name: is_active
data_type: boolean
description: "Boolean to indicate if the accommodation is active or not"
- name: friendly_name
data_type: character varying
description: "Name of the accommodation"
- name: country_name
data_type: character varying
description: "Name of the country where the accommodation is located."
- name: town
data_type: character varying
description: "Town in which the accommodation is located"
- name: postcode
data_type: character varying
description: ""
- name: address_line_1
data_type: character varying
description: ""
- name: check_in_cover_purchased
data_type: bigint
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: "Count of how many Check-in covers have been
Creation of host_booking_fees
2024-07-31 15:16:15 +02:00
purchased for this accommodation"
- name: int_core__host_booking_fees
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: Bookings that have been processed by the Superhog backend.
Creation of host_booking_fees
2024-07-31 15:16:15 +02:00
Each record matches one booking and has information on host
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
booking fees, when they were charged and the currency used by
Creation of host_booking_fees
2024-07-31 15:16:15 +02:00
the host.
columns:
- name: id_booking
data_type: bigint
description: "The unique, Superhog generated id for this booking."
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Creation of host_booking_fees
2024-07-31 15:16:15 +02:00
- unique
- not_null
- name: id_user_guest
data_type: character varying
description: The UUID of the Superhog user playing the guest role in the booking.
- name: id_user_host
data_type: character varying
description: The UUID of the Superhog user playing the host role in the booking.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Creation of host_booking_fees
2024-07-31 15:16:15 +02:00
- not_null
- name: id_accommodation
data_type: bigint
description: The ID of the booked listing.
- name: booking_state
data_type: character varying
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description:
Creation of host_booking_fees
2024-07-31 15:16:15 +02:00
"State in which the booking is, could be either of the following:
- Approved
- NotApproved
- Cancelled
- Rejected
- NoFlags
- Flagged
- IncompleteInformation"
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Creation of host_booking_fees
2024-07-31 15:16:15 +02:00
- accepted_values:
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
values:
- "Approved"
- "NotApproved"
- "Cancelled"
- "Rejected"
- "NoFlags"
- "Flagged"
- "IncompleteInformation"
Creation of host_booking_fees
2024-07-31 15:16:15 +02:00
- name: is_duplicate_booking
data_type: boolean
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Creation of host_booking_fees
2024-07-31 15:16:15 +02:00
A flag that identifies whether the booking is a duplicate.
A booking is considered a duplicate if there's an older booking with the same user,
accomodation and check-in date. If there are two or more bookings with the same user,
accomodation and check-in date, the oldest one will have False as a value in this field,
and the other ones will have True as a value in this Failed."
Put simply, if you don't want to receive duplicates, filter this field to False.
- name: booking_fee_local
data_type: numeric
description: "The fee to apply to the booking, in host currency."
- name: account_currency_iso4217
data_type: character varying
description: "Currency used by host/pm/platform users."
Modified filter and table used
2024-08-01 14:32:45 +02:00
- name: booking_fee_in_gbp
Included the exchange rate to GBP in the model
2024-08-01 12:58:36 +02:00
data_type: numeric
Modified filter and table used
2024-08-01 14:32:45 +02:00
description: "The fee to apply to the booking, in GBP"
Included the exchange rate to GBP in the model
2024-08-01 12:58:36 +02:00
Creation of host_booking_fees
2024-07-31 15:16:15 +02:00
- name: booking_fee_charge_at_utc
data_type: timestamp without time zone
description: |
The point in time in which the booking should be invoiced.
This could be the check-in date of the booking or the date in which the guest verification
started, depending on the billing settings of the host.
- name: booking_fee_charge_date_utc
data_type: date
description: |
The date in which the booking should be invoiced.
This could be the check-in date of the booking or the date in which the guest verification
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
started, depending on the billing settings of the host.
- name: int_core__user_role
description: |
This model contains the relationship of user has a role.
A User in this table can have 1 or more than 1 roles.
Not all Users in this table appear in the standard user table,
meaning that not all users have a role assigned.
The possible roles are:
- Host
- Platform
- EDeposit
- Guest
- Admin
- KnowYourGuest
Merged PR 3653: Adds new role ResolutionApi in accepted values of int_core__user_role # Description Adds new role `ResolutionApi` in accepted values of `int_core__user_role` # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged.
2024-11-26 09:12:09 +00:00
- ScreeningApi
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- PropertyVerificationManager
Added new role
2024-09-27 09:55:37 +02:00
- CheckInHeroApi
Add new API role CancellationApi in user_role accepted values
2024-10-09 08:58:36 +02:00
- CancellationApi
Merged PR 3653: Adds new role ResolutionApi in accepted values of int_core__user_role # Description Adds new role `ResolutionApi` in accepted values of `int_core__user_role` # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged.
2024-11-26 09:12:09 +00:00
- ScreenAndProtectApi
- ResolutionApi
Merged PR 4215: Fixes # Description Small PR to fix stuff # 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. Fixes Related work items: #27096
2025-01-29 12:46:53 +00:00
- StayDisruptApi
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- id_user
- role_name
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
columns:
- name: id_user
data_type: string
description: |
The identifier of the user. Can be duplicated if it has multiple roles.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- not_null
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- name: role_name
data_type: string
description: The name of the role a user has.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- accepted_values:
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
values:
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- Host
- Platform
- EDeposit
- Guest
- Admin
- KnowYourGuest
- ScreeningApi
- PropertyVerificationManager
Added new role
2024-09-27 09:55:37 +02:00
- CheckInHeroApi
Add new API role CancellationApi in user_role accepted values
2024-10-09 08:58:36 +02:00
- CancellationApi
Merged PR 3597: Adds new API roles as hosts # Description This fixes the data alert raised in today execution. We have the first user with the role `ScreenAndProtectApi`. Changes: * Adds `CancellationApi`, `CheckInHeroApi` and `ScreenAndProtectApi` as accepted roles for `int_core__user_host` computation * Adds the new `ScreenAndProtectApi` role as accepted values in the `int_core__user_role` model # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #24475
2024-11-20 09:02:22 +00:00
- ScreenAndProtectApi
Merged PR 3653: Adds new role ResolutionApi in accepted values of int_core__user_role # Description Adds new role `ResolutionApi` in accepted values of `int_core__user_role` # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged.
2024-11-26 09:12:09 +00:00
- ResolutionApi
Merged PR 4215: Fixes # Description Small PR to fix stuff # 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. Fixes Related work items: #27096
2025-01-29 12:46:53 +00:00
- StayDisruptApi
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- name: int_core__user_host
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
This table provides information of the users that act as Hosts.
A Host needs to be understood in the broad sense of the term. Here host means any
user that acts as a "B2B" client.
The categorisation as a Host is based on two possibilities: the role of the user or if
the user comes from Know Your Guest (KYG) within the claim table. Any user that has
any of the following roles will be considered as a Host in this table:
- Host
- Platform
- EDeposit
- KnowYourGuest
- ScreeningAPI
- PropertyVerificationManager
Merged PR 3597: Adds new API roles as hosts # Description This fixes the data alert raised in today execution. We have the first user with the role `ScreenAndProtectApi`. Changes: * Adds `CancellationApi`, `CheckInHeroApi` and `ScreenAndProtectApi` as accepted roles for `int_core__user_host` computation * Adds the new `ScreenAndProtectApi` role as accepted values in the `int_core__user_role` model # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #24475
2024-11-20 09:02:22 +00:00
- CancellationApi
- CheckInHeroApi
- ScreenAndProtectApi
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Additionally, any user that has any of these claim types will be considered as a Host:
- KygRegistrationSignUpType
- KygRegistrationIntegrationTypeName
- KygMvp
Merged PR 3597: Adds new API roles as hosts # Description This fixes the data alert raised in today execution. We have the first user with the role `ScreenAndProtectApi`. Changes: * Adds `CancellationApi`, `CheckInHeroApi` and `ScreenAndProtectApi` as accepted roles for `int_core__user_host` computation * Adds the new `ScreenAndProtectApi` role as accepted values in the `int_core__user_role` model # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #24475
2024-11-20 09:02:22 +00:00
- NewDashVersion
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Lastly, in case a user satisfies multiple conditions, it will only appear once in this table.
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
columns:
- name: id_user_host
data_type: character varying
description: The unique user ID for the Host.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- not_null
- unique
Merged PR 3878: Propagates account type to intermediate # Description Propagates account type to intermediate. Also, adds minimal documentation to `int_core__unified_user`. There's only 54 test accounts in Unified User and 49 that are considered as User Hosts. So it's not, by all means, an extensive list of test accounts... There's a mismatch between the `created_date_utc` and `updated_date_utc` that these are timestamps. There's another ticket in the backlog to handle this alongside the dependency, so it's not included here. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #18944
2024-12-19 16:33:35 +00:00
- name: account_type
data_type: string
description: |
Name of the account type. Can be null and might be not up-to-date.
- name: is_test_account
data_type: boolean
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
description: |
Merged PR 3878: Propagates account type to intermediate # Description Propagates account type to intermediate. Also, adds minimal documentation to `int_core__unified_user`. There's only 54 test accounts in Unified User and 49 that are considered as User Hosts. So it's not, by all means, an extensive list of test accounts... There's a mismatch between the `created_date_utc` and `updated_date_utc` that these are timestamps. There's another ticket in the backlog to handle this alongside the dependency, so it's not included here. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #18944
2024-12-19 16:33:35 +00:00
Flag to identify if the user is a test account.
Can be null and might be not up-to-date. Be aware that
this might not include all test accounts, but it provides
a first level of filtering.
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- name: id_billing_country
data_type: integer
description: |
ID of the country in which the Host is billed.
In some cases it's null.
Merged PR 2676: Propagates Billing Country information # Description Propagates Billing Country information in unified_user and user_host intermediate models. This is a necessary step towards providing KPIs segmented by Billing Country. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19082
2024-08-29 08:25:05 +00:00
- name: billing_country_name
data_type: string
description: |
Name of the country in which the Host is billed.
In some cases it's null.
- name: billing_country_iso_2
data_type: string
description: |
ISO 3166-1 alpha-2 country code in which the Host is billed.
In some cases it's null.
- name: billing_country_iso_3
data_type: string
description: |
ISO 3166-1 alpha-3 country code in which the Host is billed.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
In some cases it's null.
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- name: account_currency_iso4217
data_type: string
description: |
3 character currency code linked to the account.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
In some cases it's null.
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- name: user_code
data_type: integer
description: |
A code identifying users.
- name: first_name
data_type: string
description: |
First name of the Host.
- name: last_name
data_type: string
description: |
Last name of the Host.
- name: company_name
data_type: string
description: |
Name of the company. In some cases, it's the same
as the first_name, the last_name, a concatenation of
both, or something different. Can be null and empty.
- name: email
data_type: string
description: |
Electronic mail of the Host.
- name: id_deal
data_type: string
description: |
Main identifier of the B2B clients. A Deal can have multiple Hosts.
A Host can have only 1 Deal or no Deal at all. This field can be null.
Added PMS info
2025-01-20 14:26:37 +01:00
- name: has_active_pms
data_type: boolean
description: |
Addressed comments
2025-01-20 17:18:39 +01:00
Does the host have an active associated PMS.
Added PMS info
2025-01-20 14:26:37 +01:00
data_tests:
- not_null
- name: active_pms_list
data_type: string
description: |
Addressed comments
2025-01-20 17:18:39 +01:00
Name of the active PMS associated with the host. It can have more than
Added PMS info
2025-01-20 14:26:37 +01:00
one PMS associated with it. It can be null if it doesn't have any PMS associated.
Merged PR 2743: Fixes deal-based issues on the billing country dimension # Description Before deploying KPIs by Billing Country, we spotted some issues that were basically increases on the volumes of any metric on the by billing country dimension that was based on Deal. This means, `int_core__mtd_deal_metrics` and `int_xero__mtd_invoicing_metrics`. This PR changes the following: * Now the 2 abovementioned models depend on the `int_core__deal` model, instead of `int_core__user_host` (thus removing duplicated stuff) * Now all models use the main billing country at deal level, instead of doing it so at host level. The reason is that some small amount of hosts that share the same deal can have a different billing country. To avoid weird stuff, everything points to this simplification - that in general, it's not a massive change in the output. * In order to do so easily, the 3 main billing country per deal fields have been propagated to `int_core__user_host` To exemplify the solution, find here a snapshot of the differences in behavior: ``` select dimension, sum(deals_booked_in_month) as deals_booked_1, sum(deals_booked_in_6_months) as deals_booked_6, sum(deals_booked_in_12_months) as deals_booked_12, sum(total_revenue_in_gbp) as total_revenue, sum(xero_operator_net_fees_in_gbp) as operator_revenue, sum(xero_booking_net_fees_in_gbp) as booking_fees, sum(xero_listing_net_fees_in_gbp) as listing_fees, sum(xero_verification_net_fees_in_gbp) as verification_fees, sum(total_guest_revenue_in_gbp) as guest_revenue, sum(xero_waiver_paid_back_to_host_in_gbp) as waiver_paid_back_to_hosts, sum(waiver_net_fees_in_gbp) as waiver_net_fees from intermediate.int_mtd_vs_previous_year_metrics where date in ('2024-01-31') group by 1 order by 1 ``` Production: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/2743/attachments/image.png) vs. Local: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/2743/attachments/image%20%282%29.png) Keep in mind that still Global dimension can be greater than any other dimension aggregated since not all users have a deal. Mismatches between the other 2 dimensions might be linked to the dump. Commits are meaningful and help navigate in the changes. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20823
2024-09-05 09:53:16 +00:00
- name: main_billing_country_name_per_deal
data_type: string
description: |
Name of the main country in which the Deal is billed.
It's a simplification of the billing country that is common to all users
that share the same Deal. It can be null.
- name: main_billing_country_iso_2_per_deal
data_type: string
description: |
ISO 3166-1 alpha-2 main country code in which the Deal is billed.
It's a simplification of the billing country that is common to all users
that share the same Deal. It can be 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.
It's a simplification of the billing country that is common to all users
that share the same Deal. It can be null.
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- name: joined_at_utc
data_type: timestamp
description: |
Timestamp of when the Host user joined Superhog.
- name: joined_date_utc
data_type: date
description: |
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Date of when the Host user joined Superhog.
Merged PR 3909: Fixes created_date_utc and updated_date_utc in SH User and its dependencies # Description The model `stg_core__superhog_user` contained the fields `created_date_utc` and `updated_date_utc`, which were actually timestamps, not dates. This created issues a while ago in KPIs that were fixed by forcing a date conversion at `int_kpis` level, but the source issue remained unfixed. This PR just creates the proper fields in staging, meaning: * `created_at_utc` and `created_date_utc` * `updated_at_utc` and `updated_date_utc` And propagates the changes through all dependencies. On KPIs, it also removes the hardcoded date conversion since it's no longer needed. It also adds the different schema entries on which these fields were already defined. Note I didn't update the staging entry since there's no entry for the rest of the fields. I recommend checking this PR in the commits order. What I've tested: * Unified User and User Host have plenty of dependencies that I've checked one by one, at each dependency layer by using dbt docs. * Run `core__unified_user` and the full execution of +`mtd_aggregated_metrics` What clearly will fail: * There's the famous `Users_dashboard` PBI report that shouldn't exist that has a dependency with `core__unified_user`. This report will fail. But it does not exist. I'd like to drop it once and forever # Checklist - [X] The edited models and dependants run properly with production data. **See above** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **The staging model is incremental!** Related work items: #23703
2024-12-31 08:04:03 +00:00
- name: created_at_utc
data_type: timestamp
description: The timestamp when the user was created.
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- name: created_date_utc
data_type: date
Merged PR 3909: Fixes created_date_utc and updated_date_utc in SH User and its dependencies # Description The model `stg_core__superhog_user` contained the fields `created_date_utc` and `updated_date_utc`, which were actually timestamps, not dates. This created issues a while ago in KPIs that were fixed by forcing a date conversion at `int_kpis` level, but the source issue remained unfixed. This PR just creates the proper fields in staging, meaning: * `created_at_utc` and `created_date_utc` * `updated_at_utc` and `updated_date_utc` And propagates the changes through all dependencies. On KPIs, it also removes the hardcoded date conversion since it's no longer needed. It also adds the different schema entries on which these fields were already defined. Note I didn't update the staging entry since there's no entry for the rest of the fields. I recommend checking this PR in the commits order. What I've tested: * Unified User and User Host have plenty of dependencies that I've checked one by one, at each dependency layer by using dbt docs. * Run `core__unified_user` and the full execution of +`mtd_aggregated_metrics` What clearly will fail: * There's the famous `Users_dashboard` PBI report that shouldn't exist that has a dependency with `core__unified_user`. This report will fail. But it does not exist. I'd like to drop it once and forever # Checklist - [X] The edited models and dependants run properly with production data. **See above** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **The staging model is incremental!** Related work items: #23703
2024-12-31 08:04:03 +00:00
description: The date when the user was created.
- name: updated_at_utc
data_type: timestamp
description: The timestamp when the user was updated.
Merged PR 2516: Create host_user and user_role in intermediate # Description Adds 2 new tables: - `int_core__user_role`: contains the relationship of a given user has a role. - `int_core__user_host`: based on the previous table, it selects the users and main information from those users that are considered as hosts according to the role they have. Note: I needed to change the test in stg. A user, generally, can have no role, one role, or multiple roles. Thus we cannot propagate this information in the unified_user model. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19513
2024-08-07 14:28:34 +00:00
- name: updated_date_utc
data_type: date
Merged PR 3909: Fixes created_date_utc and updated_date_utc in SH User and its dependencies # Description The model `stg_core__superhog_user` contained the fields `created_date_utc` and `updated_date_utc`, which were actually timestamps, not dates. This created issues a while ago in KPIs that were fixed by forcing a date conversion at `int_kpis` level, but the source issue remained unfixed. This PR just creates the proper fields in staging, meaning: * `created_at_utc` and `created_date_utc` * `updated_at_utc` and `updated_date_utc` And propagates the changes through all dependencies. On KPIs, it also removes the hardcoded date conversion since it's no longer needed. It also adds the different schema entries on which these fields were already defined. Note I didn't update the staging entry since there's no entry for the rest of the fields. I recommend checking this PR in the commits order. What I've tested: * Unified User and User Host have plenty of dependencies that I've checked one by one, at each dependency layer by using dbt docs. * Run `core__unified_user` and the full execution of +`mtd_aggregated_metrics` What clearly will fail: * There's the famous `Users_dashboard` PBI report that shouldn't exist that has a dependency with `core__unified_user`. This report will fail. But it does not exist. I'd like to drop it once and forever # Checklist - [X] The edited models and dependants run properly with production data. **See above** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **The staging model is incremental!** Related work items: #23703
2024-12-31 08:04:03 +00:00
description: The date when the user was updated.
Merged PR 3625: Excludes new dash users without id deal # Description This PR has 2 commits: - The first one handles the removal from the computation any user that has not an id deal properly set. I just created a boolean field in int_core__user_host that identifies if the host has no id_deal. Then apply the new condition in the 2 main usages of New Dash info. - The second one cleans New Dash KPIs. Since we do not have anymore users without deals, it means that the identification of the host/account is going to be exactly the same if done by id_user_host or id_deal. I hated having id_user_host in KPIs so I've removed it :) Lastly, this should speed up massively the execution. Not because there's improvements on the code but rather the reduction of data. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-21 16:30:47 +00:00
- name: is_missing_id_deal
data_type: boolean
description: |
Flag to identify if a user is missing the id_deal (true) or
not (false).
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
- name: is_user_in_new_dash
Merged PR 2629: Integrates logic to detect New Dashboard users within DWH # Description First step towards reporting New Dash is to be able within DWH to know which hosts have been migrated. In order to do so, and anticipating that there's going to be new phases in the future, I've created a `int_core__user_migration` model that reads from a configuration macro `get_new_dash_migration_phases_config` that will allow semi-automatic user retrieval in the future. This avoids nasty hardcoding within the model itself. The information of whether a user is migrated, in which phase and when the phase was deployed is available at user level in the `int_core__user_host` table. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **-> I selected a view for this model since I don't believe we should materialse this data other than the user host table** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-22 12:10:25 +00:00
data_type: boolean
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
Flag to determine if this user host is in New Dash or not.
- name: has_user_moved_from_old_dash
data_type: boolean
description: |
Flag to determine if this user host is in New Dash and has
been moved from the old dash.
- name: new_dash_version
Merged PR 2629: Integrates logic to detect New Dashboard users within DWH # Description First step towards reporting New Dash is to be able within DWH to know which hosts have been migrated. In order to do so, and anticipating that there's going to be new phases in the future, I've created a `int_core__user_migration` model that reads from a configuration macro `get_new_dash_migration_phases_config` that will allow semi-automatic user retrieval in the future. This avoids nasty hardcoding within the model itself. The information of whether a user is migrated, in which phase and when the phase was deployed is available at user level in the `int_core__user_host` table. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **-> I selected a view for this model since I don't believe we should materialse this data other than the user host table** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-22 12:10:25 +00:00
data_type: string
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
For users that are in New Dash, specifies the New Dash Version
in which these users were moved or joined.
- name: new_dash_move_date_utc
Merged PR 2629: Integrates logic to detect New Dashboard users within DWH # Description First step towards reporting New Dash is to be able within DWH to know which hosts have been migrated. In order to do so, and anticipating that there's going to be new phases in the future, I've created a `int_core__user_migration` model that reads from a configuration macro `get_new_dash_migration_phases_config` that will allow semi-automatic user retrieval in the future. This avoids nasty hardcoding within the model itself. The information of whether a user is migrated, in which phase and when the phase was deployed is available at user level in the `int_core__user_host` table. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **-> I selected a view for this model since I don't believe we should materialse this data other than the user host table** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-22 12:10:25 +00:00
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
For users that are in New Dash and have been moved from
Old Dash, specifies the date in which users switched.
- name: new_dash_move_at_utc
data_type: timestamp
description: |
For users that are in New Dash and have been moved from
Old Dash, specifies the timestamp in which users switched.
This is an estimate since we don't know for sure the exact
timestamp. Currently defaulting to 00:00:00h of given move
date.
- name: user_in_new_dash_since_date_utc
data_type: date
description: |
For users that are in New Dash, the effective date since
these users can be considered in New Dash. It the user
has moved from Old Dash, it will be the new_dash_move_date_utc.
If not, it will correspond to the joined_date_utc.
- name: user_in_new_dash_since_timestamp_at_utc
data_type: timestamp
description: |
For users that are in New Dash, the effective date since
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
these users can be considered in New Dash. If the user
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
has moved from Old Dash, it will be the new_dash_move_at_utc.
If not, it will correspond to the joined_at_utc.
Merged PR 2629: Integrates logic to detect New Dashboard users within DWH # Description First step towards reporting New Dash is to be able within DWH to know which hosts have been migrated. In order to do so, and anticipating that there's going to be new phases in the future, I've created a `int_core__user_migration` model that reads from a configuration macro `get_new_dash_migration_phases_config` that will allow semi-automatic user retrieval in the future. This avoids nasty hardcoding within the model itself. The information of whether a user is migrated, in which phase and when the phase was deployed is available at user level in the `int_core__user_host` table. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **-> I selected a view for this model since I don't believe we should materialse this data other than the user host table** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-22 12:10:25 +00:00
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
- name: int_core__new_dash_users
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
This table provides information of the host users that are in New Dash.
Users can be in New Dash because 1) have moved (migrated) from Old Dash
or 2) have been directly created within New Dash.
Merged PR 2629: Integrates logic to detect New Dashboard users within DWH # Description First step towards reporting New Dash is to be able within DWH to know which hosts have been migrated. In order to do so, and anticipating that there's going to be new phases in the future, I've created a `int_core__user_migration` model that reads from a configuration macro `get_new_dash_migration_phases_config` that will allow semi-automatic user retrieval in the future. This avoids nasty hardcoding within the model itself. The information of whether a user is migrated, in which phase and when the phase was deployed is available at user level in the `int_core__user_host` table. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **-> I selected a view for this model since I don't believe we should materialse this data other than the user host table** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-22 12:10:25 +00:00
columns:
- name: id_user_host
data_type: character varying
description: The unique user ID for the Host.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2629: Integrates logic to detect New Dashboard users within DWH # Description First step towards reporting New Dash is to be able within DWH to know which hosts have been migrated. In order to do so, and anticipating that there's going to be new phases in the future, I've created a `int_core__user_migration` model that reads from a configuration macro `get_new_dash_migration_phases_config` that will allow semi-automatic user retrieval in the future. This avoids nasty hardcoding within the model itself. The information of whether a user is migrated, in which phase and when the phase was deployed is available at user level in the `int_core__user_host` table. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **-> I selected a view for this model since I don't believe we should materialse this data other than the user host table** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-22 12:10:25 +00:00
- not_null
- unique
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
- name: new_dash_version
Merged PR 2629: Integrates logic to detect New Dashboard users within DWH # Description First step towards reporting New Dash is to be able within DWH to know which hosts have been migrated. In order to do so, and anticipating that there's going to be new phases in the future, I've created a `int_core__user_migration` model that reads from a configuration macro `get_new_dash_migration_phases_config` that will allow semi-automatic user retrieval in the future. This avoids nasty hardcoding within the model itself. The information of whether a user is migrated, in which phase and when the phase was deployed is available at user level in the `int_core__user_host` table. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **-> I selected a view for this model since I don't believe we should materialse this data other than the user host table** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-22 12:10:25 +00:00
data_type: string
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
The name of the New Dash version this user appeared firstly.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2629: Integrates logic to detect New Dashboard users within DWH # Description First step towards reporting New Dash is to be able within DWH to know which hosts have been migrated. In order to do so, and anticipating that there's going to be new phases in the future, I've created a `int_core__user_migration` model that reads from a configuration macro `get_new_dash_migration_phases_config` that will allow semi-automatic user retrieval in the future. This avoids nasty hardcoding within the model itself. The information of whether a user is migrated, in which phase and when the phase was deployed is available at user level in the `int_core__user_host` table. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **-> I selected a view for this model since I don't believe we should materialse this data other than the user host table** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-22 12:10:25 +00:00
- not_null
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
- name: has_user_moved_from_old_dash
data_type: boolean
description: |
Flag to determine if this user host is in New Dash and has
been moved from the old dash.
- name: new_dash_move_date_utc
Merged PR 2629: Integrates logic to detect New Dashboard users within DWH # Description First step towards reporting New Dash is to be able within DWH to know which hosts have been migrated. In order to do so, and anticipating that there's going to be new phases in the future, I've created a `int_core__user_migration` model that reads from a configuration macro `get_new_dash_migration_phases_config` that will allow semi-automatic user retrieval in the future. This avoids nasty hardcoding within the model itself. The information of whether a user is migrated, in which phase and when the phase was deployed is available at user level in the `int_core__user_host` table. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **-> I selected a view for this model since I don't believe we should materialse this data other than the user host table** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-22 12:10:25 +00:00
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
For users that are in New Dash and have been moved from
Old Dash, specifies the date in which users switched.
- name: new_dash_move_at_utc
data_type: timestamp
Merged PR 3047: Override migration date with join date if join date is after migration date # Description Quick fix to make lower_limit_migration_date_utc more robust for new dash reporting purposes. I noticed some cases in which users were actually created after the migration date. In these cases, I just keep joined date. # Checklist - [X] The edited models and dependants run properly 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: #22331
2024-10-04 07:16:52 +00:00
description: |
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
For users that are in New Dash and have been moved from
Old Dash, specifies the timestamp in which users switched.
This is an estimate since we don't know for sure the exact
timestamp. Currently defaulting to 00:00:00h of given move
date.
- name: user_in_new_dash_since_date_utc
data_type: date
description: |
For users that are in New Dash, the effective date since
these users can be considered in New Dash. It the user
has moved from Old Dash, it will be the new_dash_move_date_utc.
If not, it will correspond to the joined_date_utc.
- name: user_in_new_dash_since_timestamp_at_utc
data_type: timestamp
Merged PR 3047: Override migration date with join date if join date is after migration date # Description Quick fix to make lower_limit_migration_date_utc more robust for new dash reporting purposes. I noticed some cases in which users were actually created after the migration date. In these cases, I just keep joined date. # Checklist - [X] The edited models and dependants run properly 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: #22331
2024-10-04 07:16:52 +00:00
description: |
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
For users that are in New Dash, the effective date since
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
these users can be considered in New Dash. If the user
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
has moved from Old Dash, it will be the new_dash_move_at_utc.
If not, it will correspond to the joined_at_utc.
Created address_validations in intermediate
2024-08-19 11:43:54 +02:00
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
- name: int_core__user_product_bundle
description: |
This model contains the relationship of a User has a Product Bundle. It contains
both the active Product Bundles as well as inactive, past ones, for each user,
with the dates in which it was active. If a Product Bundle is active, then the
end date is null.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
In the initiatives of "new pricing" and "new dashboard" (2024), a User that
has been migrated into this setup can have one or many Product Bundles active.
This table won't display Product Bundles from users that have not been migrated.
A Product Bundle is a bundle of one or many Product Services. In other words,
different combinations of Product Services (Basic Screening, Id Verification,
Screening Plus, Basic Damage Deposit, Damage Deposit Plus, Waiver Pro, etc)
) would result into different Product Bundles.
For instance, for the New Dashboard MVP, we only have 2 Product Bundles:
- Basic Screening: only contains one service, which is Basic Screening
- Basic Program: contains 2 services, which are Basic Screening and
Waiver Pro.
Important:
A User having an active Product Bundle does NOT mean that the bundle is in use.
Merged PR 2647: Adding accommodation_to_product_bundle to stg # Description Adds accommodation to product bundle table from sync_core to staging. Note that this table still has no data because so far no listing has an associated product bundle. Small change: removed in schema pending confirmation comments from Lou now that we've got an answer confirming it. # Checklist - [ ] The edited models and dependants run properly with production data: **N/A - there's no data :(** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A - there's no data :(** - [X] I have checked for DRY opportunities with other models and docs. - [ ] I've picked the right materialization for the affected models. **N/A - there's no data :(** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 08:57:23 +00:00
In order to be in use, the Product Bundle needs to be applied to a Listing.
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
Thus, the relationship in this table only shows, from user point of view, what
Product Bundles she/he can apply into a Listing.
columns:
- name: id_user_product_bundle
data_type: bigint
description: |
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
The unique identifier of this table.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
- not_null
- unique
- name: id_user_host
data_type: string
description: |
The identifier of the User. Can be duplicated if it has many Product Bundles.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
- not_null
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
- name: id_product_bundle
data_type: int
description: |
The identifier of the Product Bundle associated to the user. The same Product
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
Bundle can be applied into many users. Can be null if the bundle is custom.
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
- name: id_protection_plan
data_type: int
description: |
The identifier of the Protection Plan. There's a 1 to 1 relationship between
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
a Product Bundle and a Protection Plan.
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
- name: product_bundle_name
data_type: string
description: |
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
The name of the Product Bundle.
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
- name: product_bundle_display_name
data_type: string
description: |
The name of the Product Bundle, better fit for visualisations.
Documenting protection name fields in user_product_bundle
2024-10-07 17:21:52 +02:00
- name: protection_name
data_type: string
description: |
The name of the Protection Plan associated to the Product Bundle.
- name: protection_display_name
data_type: string
description: |
The name of the Protection Plan, better fit for visualisations.
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
- name: display_on_front_end
data_type: boolean
description: |
Flag that accounts for the capacity of a Host being able to modify the Product Bundle.
- name: chosen_product_services
data_type: int
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
Identifier of the combination of Services that apply to a Product Bundle. In essence,
the sum of Service Ids applied return the number displayed in this column. For example,
a chosen_product_services = 257 means it has the services 1 + 256, which are the
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Basic Screening and the Waiver Pro.
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
- name: original_starts_at_utc
data_type: timestamp
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
Timestamp of when this User has Product Bundle was active for the first time, according to
the Backend.
Keep in mind that this timestamp can be before the migration of the user, thus
effective_start_date_utc might be better for reporting and analysis purposes.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
- not_null
- name: original_ends_at_utc
data_type: timestamp
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
Timestamp of when this User has Product Bundle was active for the last time, according to
the Backend. If null it means that it's currently active.
Keep in mind that this timestamp can be before the migration of the user, thus
effective_end_date_utc might be better for reporting and analysis purposes.
- name: effective_start_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
Effective date of when this User has Product Bundle was active for the first time.
It takes into account the fact that a User needs to be migrated in order for
the Product Bundle to be active. In case of doubt, use this date.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
- not_null
- name: effective_end_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
Effective date of when this User has Product Bundle was active for the last time.
If null it means that it's currently active.
It takes into account the fact that a User needs to be migrated in order for
the Product Bundle to be active. In case of doubt, use this date.
- name: has_no_end_date
data_type: boolean
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
Flag to determine if the end date is filled or not.
- name: created_at_utc
data_type: timestamp
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
Timestamp of when this User has Product Bundle was created in the Backend.
- name: created_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
Date of when this User has Product Bundle was created in the Backend.
- name: updated_at_utc
data_type: timestamp
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
Timestamp of when this User has Product Bundle was last updated in the Backend.
- name: updated_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2636: First version of User Product Bundle # Description Working version of User Product Bundle in intermediate. I tried to be quite explicit in the documentation of the model and the choices made (both in the code itself and in the schema). There's some opinionated choices so feel free to challenge them. There's a small change on the user_migration model, in which I didn't properly set a field into a date. Note that there's some schema comments pending from Lou's validation. Up to you if we prefer to wait until resolved or we move forward - to me, it's not blocking. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-26 09:18:56 +00:00
Date of when this User has Product Bundle was last updated in the Backend.
- name: dwh_extracted_at
data_type: timestamp
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Timestamp of when this record was ingested from the Backend to the DWH.
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
- name: int_core__booking_to_product_bundle
description: |
This model contains the information of which booking is linked to a
specific product bundle. It's a subset of all bookings since it only
applies to bookings that come from hosts that have been migrated into
Keep latest booking to product bundle state
2024-10-04 10:32:15 +02:00
the New Dash. Only the latest product bundle associated to the booking
is shown.
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
Note: at this moment, it's not straight-forward to know which product service
is applied in the booking. We only know that a booking is linked to a product
bundle, but not the service that applies from those available within the
product bundle. Likely this is not an issue for the MVP since there's only 2
bundles and 2 services, and the only bundle that has a paid service is Basic
Program.
Note: to improve data quality, there's an inner join with
int_core__user_product_bundle to ensure that bookings need to 1) come from
hosts that appear in the table and 2) be created after the user's effective
start of the product bundle. This is because there's some previous booking
data that it's before the New Dash MVP start date.
columns:
- name: id_booking_to_product_bundle
data_type: bigint
description: |
The unique identifier of this table.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
- not_null
- unique
- name: id_booking
data_type: bigint
description: |
The identifier of the booking that has a product bundle.
A booking appearing here would mean it's under the New Dash &
the New Pricing structure. It is expected that bookings are
unique within this model.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
- not_null
- unique
- name: id_user_product_bundle
data_type: bigint
description: |
The identifier of the user product bundle. This allows the retrieval
of the information of the product bundle associated at the user level.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
- not_null
- name: id_user_host
data_type: string
description: |
The identifier of the user that acts as a host. Only Hosts that have
New Pricing in the New Dash structure that have had bookings will
appear in this model.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
- not_null
- name: product_bundle_name
data_type: string
description: |
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
The name of the Product Bundle.
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
- name: created_at_utc
data_type: timestamp
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Timestamp of when this Booking to Product Bundle record was created in the Backend.
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
- name: created_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Date of when this Booking to Product Bundle record was created in the Backend.
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
- name: updated_at_utc
data_type: timestamp
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Timestamp of when this Booking to Product Bundle record was last updated in the Backend.
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
- name: updated_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Date of when this Booking to Product Bundle record was last updated in the Backend.
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- name: dwh_extracted_at
data_type: timestamp with timezone
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Timestamp of when this record was ingested from the Backend to the DWH.
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- name: int_core__accommodation_to_product_bundle
description: |
This model contains the information of which product bundle is assigned
into an accommodation, also known as listing.
It's a subset of all accommodations since it only applies to listings that
come from hosts that have been migrated into the New Dash.
Note: to improve data quality, there's an inner join with
int_core__user_product_bundle to ensure that accommodations need to be linked
to hosts that appear in the table.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
Important note: the lack of entries in this table does NOT mean that the
users do not have Product Bundles in an Accommodation. A migrated user in New
Dash have by default the Product Bundle "Basic Screening", which only contains
the Product Service "Basic Screening". This is a free, default service at the
moment of creating this model, but according to Dash Product Manager, it is
likely that this service will at some point be charged - though likely 2025.
In the meantime, it's possible an quite frequent that users that have been
migrated have Bookings without the respective Accommodation appearing in this
table. For these cases, keep in mind that this Basic Screening has this default
behavior, so it has to be modelised differently.
columns:
- name: id_accommodation_to_product_bundle
data_type: bigint
description: |
The unique identifier of this table.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- not_null
- unique
- name: id_accommodation
data_type: bigint
description: |
The identifier of the accommodation that has a product bundle.
An accommodation appearing here would mean it's under the New Dash &
the New Pricing structure; as well as having a product bundle different
than the default "Basic Screening".
Accommodations can have several entries in this table for each time
there's a change on the bundle assigned into it.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- not_null
- name: id_user_product_bundle
data_type: bigint
description: |
The identifier of the user product bundle. This allows the retrieval
of the information of the product bundle associated at the user level.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- not_null
- name: id_user_host
data_type: string
description: |
The identifier of the user that acts as a host. Only Hosts that have
New Pricing in the New Dash structure that have an accommodation with
a product bundle different than the default "Basic Screening" assigned
into it will appear in this model.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- not_null
- name: product_bundle_name
data_type: string
description: |
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
The name of the Product Bundle.
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- name: original_starts_at_utc
data_type: timestamp
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
Timestamp of when this Product Bundle is assigned into an Accommodation was
active for the first time, according to the Backend.
Keep in mind that this timestamp can be before the migration of the user, thus
effective_start_date_utc might be better for reporting and analysis purposes.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- not_null
- name: original_ends_at_utc
data_type: timestamp
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
Timestamp of when this Product Bundle is assigned into an Accommodation was
active for the last time, according to the Backend. If null it means that
it's currently active.
Keep in mind that this timestamp can be before the migration of the user, thus
effective_end_date_utc might be better for reporting and analysis purposes.
- name: effective_start_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
Effective date of when this Product Bundle is assigned into an Accommodation was
active for the first time.
It takes into account the fact that a User needs to be migrated in order for
the Product Bundle to be active in the Accommodation. In case of doubt, use this date.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- not_null
- name: effective_end_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
Effective date of when this Product Bundle is assigned into an Accommodation was
active for the last time. If null it means that it's currently active.
It takes into account the fact that a User needs to be migrated in order for
the Product Bundle to be active in the Accommodation. In case of doubt, use this date.
- name: has_no_end_date
data_type: boolean
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
Flag to determine if the end date is filled or not.
- name: created_at_utc
data_type: timestamp
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Timestamp of when this Accommodation to Product Bundle record was created in the Backend.
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- name: created_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Date of when this Accommodation to Product Bundle record was created in the Backend.
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- name: updated_at_utc
data_type: timestamp
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Timestamp of when this Accommodation to Product Bundle record was last updated in the Backend.
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
- name: updated_date_utc
data_type: date
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Date of when this Accommodation to Product Bundle record was last updated in the Backend.
Merged PR 2652: Adds accommodation to product bundle in intermediate # Description Adds accommodation to product bundle in intermediate. The source table is currently empty, because there's no product bundle different to Basic Screening applied into a listing yet. Thus, it's possible that this modelisation needs to change in the future since not having data forces us to trust the business logic without a proper technical documentation. # Checklist - [ ] The edited models and dependants run properly with production data. **N/A no data** - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. **N/A no data** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. **N/A no data - but view should make the trick for the time being** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 14:05:24 +00:00
Merged PR 2650: Added int_core__booking_to_product_bundle in intermediate # Description Creates a new view with the bookings that come from New Dash, linked to the Product Bundles. Extensive documentation added, please check it out and if something is not clear I'll modify 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. - [ ] I've picked the right materialization for the affected models. To be discussed. There's not huge data still so view looks ok to me. I guess, maybe, in the future, we will have a flag or similar in int_core__bookings to detect if a bookings comes from New Dash/New Pricing or not, but it's still early to decide. In any case this model is needed for immediate New Dash MVP reporting so I propose to keep it like this as a view and afterwards we can decide if it makes more sense to materialise it differently. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-27 12:51:55 +00:00
- name: dwh_extracted_at
data_type: timestamp with timezone
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Timestamp of when this record was ingested from the Backend to the DWH.
Merged PR 2662: New Dash MVP - with. fix on production issue # Description Same PR as before, just adds a new commit that fixes my silly issue in prod. I owe some drinks :D # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-28 10:09:08 +00:00
- name: int_core__new_dash_user_overview
description: |
This model allows for minimum tracking of how the new dash initative is
performing in the different migrations.
It's a user-centric model in which, for each user, we retrieve some
basic performance indicators in the form of listings and bookings.
columns:
- name: id_user_host
data_type: string
description: |
The unique identifier of this table. It corresponds to the host users
that have been migrated to the New Dashboard.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2662: New Dash MVP - with. fix on production issue # Description Same PR as before, just adds a new commit that fixes my silly issue in prod. I owe some drinks :D # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-28 10:09:08 +00:00
- not_null
- unique
addressed comments
2024-11-12 17:10:42 +01:00
- name: id_deal
data_type: character varying
description: The ID for the Deal.
Merged PR 2662: New Dash MVP - with. fix on production issue # Description Same PR as before, just adds a new commit that fixes my silly issue in prod. I owe some drinks :D # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-28 10:09:08 +00:00
- name: user_migration_phase
data_type: string
description: |
The migration phase in which this user was migrated, for informative
purposes.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2662: New Dash MVP - with. fix on production issue # Description Same PR as before, just adds a new commit that fixes my silly issue in prod. I owe some drinks :D # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-28 10:09:08 +00:00
- not_null
Added the has_user_moved_from_old_dash field
2024-12-13 10:56:56 +01:00
- name: has_user_moved_from_old_dash
data_type: boolean
description: |
Flag to determine if this user host is in New Dash and has
been moved from the old dash.
Merged PR 2662: New Dash MVP - with. fix on production issue # Description Same PR as before, just adds a new commit that fixes my silly issue in prod. I owe some drinks :D # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-28 10:09:08 +00:00
- name: user_estimated_migration_date_utc
data_type: date
description: |
The estimated date in which this user was migrated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2662: New Dash MVP - with. fix on production issue # Description Same PR as before, just adds a new commit that fixes my silly issue in prod. I owe some drinks :D # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-28 10:09:08 +00:00
- not_null
Added PMS info
2025-01-20 14:26:37 +01:00
- name: has_active_pms
data_type: boolean
description: |
Addressed comments
2025-01-20 17:18:39 +01:00
Does the host have an active associated PMS.
Added PMS info
2025-01-20 14:26:37 +01:00
data_tests:
- not_null
- name: active_pms_list
data_type: string
description: |
Addressed comments
2025-01-20 17:18:39 +01:00
Name of the active PMS associated with the host. It can have more than
Added PMS info
2025-01-20 14:26:37 +01:00
one PMS associated with it. It can be null if it doesn't have any PMS associated.
Merged PR 2662: New Dash MVP - with. fix on production issue # Description Same PR as before, just adds a new commit that fixes my silly issue in prod. I owe some drinks :D # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-28 10:09:08 +00:00
- name: company_name
data_type: string
description: |
Information about the host user.
- name: first_name
data_type: string
description: |
Information about the host user.
- name: last_name
data_type: string
description: |
Information about the host user.
new dash new data
2024-11-12 16:33:55 +01:00
- name: email
data_type: string
description: |
Information about the host user.
Merged PR 2662: New Dash MVP - with. fix on production issue # Description Same PR as before, just adds a new commit that fixes my silly issue in prod. I owe some drinks :D # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-28 10:09:08 +00:00
- name: account_currency
data_type: string
description: |
Currency associated to the host user.
- name: total_user_product_bundles
data_type: integer
description: |
Count of product bundles that this user has or has had.
It contains both active and historic cases.
- name: total_active_user_product_bundles
data_type: integer
description: |
Count of product bundles that this user currently has.
It contains only currently active cases.
- name: total_listings
data_type: integer
description: |
Count of listings that the user owns or has owned.
- name: total_active_listings
data_type: integer
description: |
Count of listings that the user owns.
It contains only those that can accept bookings (hard
activation - not to be confused with activity-based
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
segmentation).
Merged PR 2662: New Dash MVP - with. fix on production issue # Description Same PR as before, just adds a new commit that fixes my silly issue in prod. I owe some drinks :D # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-28 10:09:08 +00:00
- name: total_listings_with_product_bundle_with_paid_service
data_type: integer
description: |
Count of listings that have, or have had, a paid service
product bundle activated.
- name: total_listings_with_active_product_bundle_with_paid_service
data_type: integer
description: |
Count of listings that currently have an active paid service
product bundle.
- name: has_active_listings
data_type: integer
description: |
Integer-based flag version of total_active_listings.
- name: has_listings_with_paid_service_applied
data_type: integer
description: |
Integer-based flag version of total_listings_with_product_bundle_with_paid_service.
- name: has_listings_with_active_paid_service_applied
data_type: integer
description: |
Integer-based flag version of total_listings_with_active_product_bundle_with_paid_service.
- name: total_bookings_with_product_bundle
data_type: integer
description: |
Count of bookings that have a product bundle associated.
- name: total_bookings_with_product_bundle_with_paid_service
data_type: integer
description: |
Count of bookings that have a product bundle associated that contain
a paid service.
- name: has_bookings_with_product_bundle
data_type: integer
description: |
Integer-based flag version of total_bookings_with_product_bundle.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2662: New Dash MVP - with. fix on production issue # Description Same PR as before, just adds a new commit that fixes my silly issue in prod. I owe some drinks :D # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #19570
2024-08-28 10:09:08 +00:00
- name: has_bookings_with_product_bundle_with_paid_service
data_type: integer
description: |
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
Integer-based flag version of total_bookings_with_product_bundle_with_paid_service.
- name: int_core__invoicing_price_plans_per_month
description: |
This model contains the price plans that were considered as active
for the invoicing process each month. This is, given that more than
one plan coexist within the same month, we take the price plan that
was active at the end of the month. This price plan is the one that
should apply for the invoicing of that month, indisctintly of the
fact that there was other plans active before.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- id_user_host
- id_price_plan
- active_in_month_start_date_utc
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
columns:
- name: id_price_plan
data_type: bigint
description: |
The unique identifier of this table, representing
the identifier of the price plan.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- not_null
- name: id_user_host
data_type: string
description: |
The unique identifier of the user host that has
a price plan.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- not_null
- name: price_plan_charged_by_type
data_type: string
description: |
Type of price plan that determines that will affect
the billing logic applied.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- not_null
- name: price_plan_start_at_utc
data_type: timestamp
description: |
Original timestamp of when a given price plan
started to be active.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- not_null
- name: price_plan_end_at_utc
data_type: timestamp
description: |
Original timestamp of when a given price plan
ended to be active. If it's currently active,
a default end date on 2099 will apply.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- not_null
- name: price_plan_created_at_utc
data_type: timestamp
description: |
Original timestamp of when a given price plan
was created.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
- not_null
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- name: active_in_month_start_date_utc
data_type: date
description: |
Date that refers to the first day of the
month on which we will consider a price plan
as active.
If we're interested in retrieving the information from
June, this date will be the 1st of June.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
- not_null
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- name: active_in_month_end_date_utc
data_type: date
description: |
Date that refers to the last day of the
month on which we will consider a price plan
as active.
If we're interested in retrieving the information from
June, this date will be the 30th of June.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
- not_null
Merged PR 2642: Booking Charge Events to have a similar logic as invoicing # Description Based on the Notion page [here](https://www.notion.so/knowyourguest-superhog/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03), this PR mainly adds: - Charge at verification depends on when the Guest joined or the VR was updated (depending on if the verification request associated exists does not exists or it does, respectively) - Add the logic to retrieve the last plan that is available at the beginning of each month. - Additional where conditions, relatively documented, to imitate was is available in the invoicing process. This includes removal of duplicated bookings, guest verification and guest user existing. Additional changes: - Remove select star :) - Added dbt tests that didn't exist before - Add informative fields on 1) how many price plans were active in a given month, even though we just keep the last one and 2) cases in which bookings are created after the booking is supposed to be charged. Data quality:´ - I have mixed feelings. This does not correspond 100% to the volumes provided by the exporter, though are quite close. For April, May and June 2024, this logic has more than 95% of accuracy. Still, the fact of using the guest joined, and especially the updated date, I feel like this will make past data "disappear" if the guest has another journey. I don't know for sure since we do not store incremental updates of user information. I'd propose to move forward to have an estimated metric available anyway - with this or a similar logic, even the previous one based on the used link at but fixing the cases in which there's no VR associated. Let's discuss 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: #18111
2024-09-03 13:15:40 +00:00
- name: price_plans_active_in_month
data_type: integer
description: |
Integer that refers to how many price plans
have been active in a given month for a user
host. The price plan retrieved will be the
last one that was active, so this is just an
informative field of how many changes of price
plans happened during that month.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
- not_null
model and docs+tests
2024-09-17 15:47:45 +02:00
- name: int_core__payaway_per_month_user
description: |
This model contains the payaway plans that were considered as active
for the invoicing process each month. This is, given that more than
one plan coexist within the same month, we take the one plan that
was active at the end of the month. This is the one that should apply for
the invoicing of that month, indisctintly of the fact that there was other
plans active before.
The time scope of the model is limited to the current month. This means
that, even though some plans will end in future dates or have no planned
missing text
2024-09-17 16:12:38 +02:00
end date, this table will only reflect activeness within months up to the
current month.
model and docs+tests
2024-09-17 15:47:45 +02:00
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
model and docs+tests
2024-09-17 15:47:45 +02:00
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- id_user_host
- id_payaway_plan
- active_in_month_start_date_utc
columns:
- name: id_payaway_plan
data_type: bigint
description: |
The unique identifier of this table, representing
the identifier of the payaway plan.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
model and docs+tests
2024-09-17 15:47:45 +02:00
- not_null
- name: id_user_host
data_type: string
description: |
The unique identifier of the user host that has
a price plan.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
model and docs+tests
2024-09-17 15:47:45 +02:00
- not_null
- name: start_at_utc
data_type: timestamp
description: |
Original timestamp of when a given plan started to be active.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
model and docs+tests
2024-09-17 15:47:45 +02:00
- not_null
- name: end_at_utc
data_type: timestamp
description: |
Original timestamp of when a given plan stopped being active. If it's
null, it means the plan is open ended (has no planned end date yet).
- name: created_at_utc
data_type: timestamp
description: |
Original timestamp of when a given plan was created.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
model and docs+tests
2024-09-17 15:47:45 +02:00
- not_null
- name: active_in_month_start_date_utc
data_type: date
description: |
Date that refers to the first day of the month on which we will
consider a plan as active. If we're interested in retrieving the
information from June, this date will be the 1st of June.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
model and docs+tests
2024-09-17 15:47:45 +02:00
- not_null
- name: active_in_month_end_date_utc
data_type: date
description: |
Date that refers to the last day of the month on which we will
consider a plan as active. If we're interested in retrieving the
information from June, this date will be the 30th of June.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
model and docs+tests
2024-09-17 15:47:45 +02:00
- not_null
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
Merged PR 2742: Creation of int_core__deal # Description Creates a new master table containing the Deals. At this stage, the information is quite limited - I only included those fields that are useful for fixing the KPIs issues. To be enriched later on. # Checklist - [ ] The edited models and dependants run properly with production data. **Question here. Do I need to have the models materialised in local to see the dependants on DBT Docs? I didn't see any uses of the previous model int_core__deal_id_master_list.** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20822
2024-09-04 16:03:36 +00:00
- name: int_core__deal
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
This table provides information about the unique entity that identifies a
client, which is a Deal.
A Deal is a common way to match information between Core, Xero and Hubspot
data sources. It's different from the typical User Host in the sense that
a Deal can have multiple User accounts (usually referred to as Platform
accounts). This is because in the past, different Host configurations could
only be done if multiple users were created.
It can happen that a Deal has 1 or multiple hosts, as mentioned above. At
the same time, not all users that act as hosts have a deal associated. One
example is Know Your Guest (KYG) Lite accounts. However, there's also historical
cases that for whatever reason there's no Deal associated.
For this model, the billing country and the deal name are estimated based on
the information available in int_core__unified_user.
First version of name unification for a deal
2024-09-06 17:08:50 +02:00
Merged PR 2742: Creation of int_core__deal # Description Creates a new master table containing the Deals. At this stage, the information is quite limited - I only included those fields that are useful for fixing the KPIs issues. To be enriched later on. # Checklist - [ ] The edited models and dependants run properly with production data. **Question here. Do I need to have the models materialised in local to see the dependants on DBT Docs? I didn't see any uses of the previous model int_core__deal_id_master_list.** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20822
2024-09-04 16:03:36 +00:00
columns:
- name: id_deal
data_type: character varying
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
description: The unique ID for the Deal. One record per id_deal.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 2742: Creation of int_core__deal # Description Creates a new master table containing the Deals. At this stage, the information is quite limited - I only included those fields that are useful for fixing the KPIs issues. To be enriched later on. # Checklist - [ ] The edited models and dependants run properly with production data. **Question here. Do I need to have the models materialised in local to see the dependants on DBT Docs? I didn't see any uses of the previous model int_core__deal_id_master_list.** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20822
2024-09-04 16:03:36 +00:00
- not_null
- unique
First version of name unification for a deal
2024-09-06 17:08:50 +02:00
- name: main_deal_name
data_type: string
description: |
Main name for this ID deal. 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.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
First version of name unification for a deal
2024-09-06 17:08:50 +02:00
- not_null
Merged PR 2742: Creation of int_core__deal # Description Creates a new master table containing the Deals. At this stage, the information is quite limited - I only included those fields that are useful for fixing the KPIs issues. To be enriched later on. # Checklist - [ ] The edited models and dependants run properly with production data. **Question here. Do I need to have the models materialised in local to see the dependants on DBT Docs? I didn't see any uses of the previous model int_core__deal_id_master_list.** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20822
2024-09-04 16:03:36 +00:00
- name: main_id_billing_country_per_deal
data_type: integer
description: |
ID of the main country in which the Deal is billed.
It's an estimation since in some cases, a Deal can have
different User Hosts and these are not forced to be billed
within the same country. However, the volume of these cases
is very low, thus we proceed with this estimation.
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
In some cases it's null.
Merged PR 2742: Creation of int_core__deal # Description Creates a new master table containing the Deals. At this stage, the information is quite limited - I only included those fields that are useful for fixing the KPIs issues. To be enriched later on. # Checklist - [ ] The edited models and dependants run properly with production data. **Question here. Do I need to have the models materialised in local to see the dependants on DBT Docs? I didn't see any uses of the previous model int_core__deal_id_master_list.** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20822
2024-09-04 16:03:36 +00:00
- name: main_billing_country_name_per_deal
data_type: string
description: |
Name of the main country in which the Deal is billed.
In some cases it's null.
- name: main_billing_country_iso_2_per_deal
data_type: string
description: |
ISO 3166-1 alpha-2 main country code in which the Deal is billed.
In some cases it's 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.
modified host/deal logic
2025-01-20 16:35:43 +01:00
- name: has_active_pms
data_type: boolean
description: |
Does the deal have an active associated PMS.
data_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.
Merged PR 2742: Creation of int_core__deal # Description Creates a new master table containing the Deals. At this stage, the information is quite limited - I only included those fields that are useful for fixing the KPIs issues. To be enriched later on. # Checklist - [ ] The edited models and dependants run properly with production data. **Question here. Do I need to have the models materialised in local to see the dependants on DBT Docs? I didn't see any uses of the previous model int_core__deal_id_master_list.** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20822
2024-09-04 16:03:36 +00:00
- name: users_with_this_id_deal
data_type: integer
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2742: Creation of int_core__deal # Description Creates a new master table containing the Deals. At this stage, the information is quite limited - I only included those fields that are useful for fixing the KPIs issues. To be enriched later on. # Checklist - [ ] The edited models and dependants run properly with production data. **Question here. Do I need to have the models materialised in local to see the dependants on DBT Docs? I didn't see any uses of the previous model int_core__deal_id_master_list.** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20822
2024-09-04 16:03:36 +00:00
Informative field of how many Users have this same Deal associated.
- name: billing_countries_for_this_id_deal
data_type: integer
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
description: |
Merged PR 2742: Creation of int_core__deal # Description Creates a new master table containing the Deals. At this stage, the information is quite limited - I only included those fields that are useful for fixing the KPIs issues. To be enriched later on. # Checklist - [ ] The edited models and dependants run properly with production data. **Question here. Do I need to have the models materialised in local to see the dependants on DBT Docs? I didn't see any uses of the previous model int_core__deal_id_master_list.** - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20822
2024-09-04 16:03:36 +00:00
Informative field of how many different billing countries are
fix schemas in intermediate
2024-09-12 15:38:50 +02:00
associated to this Deal based on the user account configuration.
Merged PR 3914: Include Hubspot deals for KPIs # Description Context: I'm intending to work on Account Managers reporting, that mostly will include reporting at Deal level the Resolutions Payouts as well as the new Retained metrics. While checking the great increase on Resolutions Payouts for October 2024: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image%20%282%29.png) I decided to take a quick look into the main players... and surprise surprise we have Guesty: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3914/attachments/image.png) So Guesty represents 37k over the 73K of October. 50%. Not bad. The main issue is that we've been aware for months now (since Churn efforts, mostly) that we're not reporting in KPIs those deals that are NOT created in Core. Most notably, API deals which includes... well, Guesty. So creating this kind of in-depth Account Managers improvement without reporting Guesty I think it would be very misleading. Note that the overall figures (Global dimension) are still accurate, though. What's new: * A new model named `int_kpis__dimension_deals` that basically retrieves Deals from both Core (as before) and Hubspot. It combines information from both and mostly assumes Hubspot as a better source of information than Core - although we do not have the Main Billing Country there afaik. * Propagates changes, mostly in the monthly by deal view of Main KPIs. Here I confirm that now Guesty appears, and it only has metrics that come from Xero (APIs Revenue, Total Revenue, Resolutions, etc) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25829
2024-12-31 15:12:38 +00:00
- name: first_created_date_utc
data_type: date
description: |
First date corresponding to the user creation date for the users
that have this Deal associated.
model and docs
2024-09-17 12:16:52 +02:00
- name: int_core__payaway
description: |
Contains all the PayAway plans, which are basically the settings for
host-takes-waiver plans with our host customers. All plans have a start
and end point in time, which means that any waivers that happen during
the range of plan should use the settings of this plan as a reference.
Plans can be open ended, as in not having a specified end in time. This
just means they are indefinitely active until someone changes it.
Plans can also have a planned end time which sits in the future.
columns:
- name: id_payaway_plan
data_type: bigint
description: "The unique id for this plan."
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
model and docs
2024-09-17 12:16:52 +02:00
- not_null
- unique
- name: id_user_host
data_type: character varying
description: "The Superhog ID of the host user this record applies to."
- name: start_at_utc
data_type: timestamp without time zone
description:
The point in time in which this plan became active. It can never be
null.
- name: end_at_utc
data_type: timestamp without time zone
description:
The point in time in which this plan will stop being active. It can
be null, which means the plan has no planned end date yet. Should this
column have a value, it should always be after the start time of the
plan.
- name: has_no_end_date
data_type: boolean
description: Syntactic sugar for checking if the plan has a specified end date.
- name: payaway_percentage
data_type: numeric
description: |
The percentage of the Waiver payments that Superhog will keep as a
a fee. Should be between 0% and a 100%. 0% is a valid amount.
This means that the Superhog fee is computed as:
Waiver Amount * payaway_percentage.
If the amount that comes out of this calculation is smaller than the
amount in column payaway_minimum_commission_local_curr, then the
Superhog fee becomes payaway_minimum_commission_local_curr instead.
So, the final logic becomes:
MAX(
Waiver Amount * payaway_percentage,
payaway_minimum_commission_local_curr
)
- name: payaway_minimum_commission_local_curr
data_type: numeric
description:
The minimum fee that we take from each waiver payment, specified in
the currency of the guest payment (so if this record is in dollars, it
means it applies to guest payments made in dollars). We will never
charge less than this. This can be 0.
- name: currency
data_type: character varying
description:
The ISO 4217 code for the currency of this record. Must always be
filled, otherwise the records is meaningless.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
model and docs
2024-09-17 12:16:52 +02:00
- not_null
- name: created_at_utc
data_type: timestamp without time zone
description: Timestamp of when the pay away plan was created.
- name: updated_at_utc
data_type: timestamp without time zone
description: Timestamp of when the pay away plan to currency was last updated
- name: dwh_extracted_at_utc
data_type: timestamp with time zone
description: Timestamp of when this data was extracted into DWH.
Merged PR 3028: Adding int_core__user_product_bundle_contains_services # Description This PR adds a new table named `user_product_bundle_contains_services` in intermediate core. Mainly, this table serves as a bridge between `user_product_bundle` and `product_services`. A `product_bundle` within `user_product_bundle` can contain 1 or several services, and this was stated in the field `contains_product_services`. The value of this field corresponds to the sum of `product_service_binary_tier` from the services that apply within that bundle. Even though the information is quite concise using this format, it adds extra complexity for analytical purposes, so this new table just duplicates the `user_product_bundle` main attributes as many times as services are contained. For example: `id_user_product_bundle` = 383 contains one unique bundle named Basic Program. This bundle has the `chosen_product_services` = 257, which can only be decomposed in power of 2 as of the sum of 256 + 1. This bundle therefore contains 2 services, Basic Screening (`product_service_binary_tier` = 1) and Waiver Pro (`product_service_binary_tier` = 256). Thus, in the new table, we will have 2 records and remove all this logic to something more standard, as seen in this screenshot: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3028/attachments/image%20%282%29.png) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. *N/A - there's no PK in this table, but the combination of columns that should be unique is tested* - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-02 14:54:03 +00:00
- name: int_core__user_product_bundle_contains_services
description: |
This table contains the information of "this user has a certain product bundle which
contains these services."
It's a denormalised relationship to break the power of 2 link between chosen_product_services
and product_service_binary_tier, which allows standard joins using the ids.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3028: Adding int_core__user_product_bundle_contains_services # Description This PR adds a new table named `user_product_bundle_contains_services` in intermediate core. Mainly, this table serves as a bridge between `user_product_bundle` and `product_services`. A `product_bundle` within `user_product_bundle` can contain 1 or several services, and this was stated in the field `contains_product_services`. The value of this field corresponds to the sum of `product_service_binary_tier` from the services that apply within that bundle. Even though the information is quite concise using this format, it adds extra complexity for analytical purposes, so this new table just duplicates the `user_product_bundle` main attributes as many times as services are contained. For example: `id_user_product_bundle` = 383 contains one unique bundle named Basic Program. This bundle has the `chosen_product_services` = 257, which can only be decomposed in power of 2 as of the sum of 256 + 1. This bundle therefore contains 2 services, Basic Screening (`product_service_binary_tier` = 1) and Waiver Pro (`product_service_binary_tier` = 256). Thus, in the new table, we will have 2 records and remove all this logic to something more standard, as seen in this screenshot: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3028/attachments/image%20%282%29.png) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. *N/A - there's no PK in this table, but the combination of columns that should be unique is tested* - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-02 14:54:03 +00:00
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- id_user_product_bundle
- id_product_service
columns:
- name: id_user_product_bundle
data_type: bigint
description: |
The identifier of the record for a user having a product bundle. It's the foreign key
pointing to user_product_bundle.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3028: Adding int_core__user_product_bundle_contains_services # Description This PR adds a new table named `user_product_bundle_contains_services` in intermediate core. Mainly, this table serves as a bridge between `user_product_bundle` and `product_services`. A `product_bundle` within `user_product_bundle` can contain 1 or several services, and this was stated in the field `contains_product_services`. The value of this field corresponds to the sum of `product_service_binary_tier` from the services that apply within that bundle. Even though the information is quite concise using this format, it adds extra complexity for analytical purposes, so this new table just duplicates the `user_product_bundle` main attributes as many times as services are contained. For example: `id_user_product_bundle` = 383 contains one unique bundle named Basic Program. This bundle has the `chosen_product_services` = 257, which can only be decomposed in power of 2 as of the sum of 256 + 1. This bundle therefore contains 2 services, Basic Screening (`product_service_binary_tier` = 1) and Waiver Pro (`product_service_binary_tier` = 256). Thus, in the new table, we will have 2 records and remove all this logic to something more standard, as seen in this screenshot: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3028/attachments/image%20%282%29.png) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. *N/A - there's no PK in this table, but the combination of columns that should be unique is tested* - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-02 14:54:03 +00:00
- not_null
- name: id_user_host
data_type: string
description: |
The Superhog ID of the host user this record applies to.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3028: Adding int_core__user_product_bundle_contains_services # Description This PR adds a new table named `user_product_bundle_contains_services` in intermediate core. Mainly, this table serves as a bridge between `user_product_bundle` and `product_services`. A `product_bundle` within `user_product_bundle` can contain 1 or several services, and this was stated in the field `contains_product_services`. The value of this field corresponds to the sum of `product_service_binary_tier` from the services that apply within that bundle. Even though the information is quite concise using this format, it adds extra complexity for analytical purposes, so this new table just duplicates the `user_product_bundle` main attributes as many times as services are contained. For example: `id_user_product_bundle` = 383 contains one unique bundle named Basic Program. This bundle has the `chosen_product_services` = 257, which can only be decomposed in power of 2 as of the sum of 256 + 1. This bundle therefore contains 2 services, Basic Screening (`product_service_binary_tier` = 1) and Waiver Pro (`product_service_binary_tier` = 256). Thus, in the new table, we will have 2 records and remove all this logic to something more standard, as seen in this screenshot: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3028/attachments/image%20%282%29.png) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. *N/A - there's no PK in this table, but the combination of columns that should be unique is tested* - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-02 14:54:03 +00:00
- not_null
- name: id_product_bundle
data_type: bigint
description: |
Merged PR 3396: Changes claims and logic to consider user is in new dash # Description Considers the 2 Claims NewDashVersion and NewDashMoveDate as sources of truth, removing the previous (crazy) logic. If a user has the claim NewDashVersion, then it's in New Dash. The claim value will also provide the version in which the user appeared (MVP, V2, etc) If a user has the NewDashMoveDate, it means it has moved from Old Dash. If not, but still has NewDashVersion, it means the user was directly created in New Dash. The models now provide logic to handle these cases, and it's propagated downstream will ensuring reporting will still work. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [NOT AT ALL] The edited models contain PK tests, and I've ran and passed them. **MANY ISSUES ON PRODUCTION CURRENTLY** - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Changes claims and logic to consider user is in new dash. Downstream propagation included Related work items: #23457
2024-10-31 15:45:28 +00:00
The identifier of the product bundle. Can be null if it's a custom bundle.
Merged PR 3028: Adding int_core__user_product_bundle_contains_services # Description This PR adds a new table named `user_product_bundle_contains_services` in intermediate core. Mainly, this table serves as a bridge between `user_product_bundle` and `product_services`. A `product_bundle` within `user_product_bundle` can contain 1 or several services, and this was stated in the field `contains_product_services`. The value of this field corresponds to the sum of `product_service_binary_tier` from the services that apply within that bundle. Even though the information is quite concise using this format, it adds extra complexity for analytical purposes, so this new table just duplicates the `user_product_bundle` main attributes as many times as services are contained. For example: `id_user_product_bundle` = 383 contains one unique bundle named Basic Program. This bundle has the `chosen_product_services` = 257, which can only be decomposed in power of 2 as of the sum of 256 + 1. This bundle therefore contains 2 services, Basic Screening (`product_service_binary_tier` = 1) and Waiver Pro (`product_service_binary_tier` = 256). Thus, in the new table, we will have 2 records and remove all this logic to something more standard, as seen in this screenshot: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3028/attachments/image%20%282%29.png) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. *N/A - there's no PK in this table, but the combination of columns that should be unique is tested* - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-02 14:54:03 +00:00
- name: id_product_service
data_type: bigint
description: |
The identifier of the product service.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3028: Adding int_core__user_product_bundle_contains_services # Description This PR adds a new table named `user_product_bundle_contains_services` in intermediate core. Mainly, this table serves as a bridge between `user_product_bundle` and `product_services`. A `product_bundle` within `user_product_bundle` can contain 1 or several services, and this was stated in the field `contains_product_services`. The value of this field corresponds to the sum of `product_service_binary_tier` from the services that apply within that bundle. Even though the information is quite concise using this format, it adds extra complexity for analytical purposes, so this new table just duplicates the `user_product_bundle` main attributes as many times as services are contained. For example: `id_user_product_bundle` = 383 contains one unique bundle named Basic Program. This bundle has the `chosen_product_services` = 257, which can only be decomposed in power of 2 as of the sum of 256 + 1. This bundle therefore contains 2 services, Basic Screening (`product_service_binary_tier` = 1) and Waiver Pro (`product_service_binary_tier` = 256). Thus, in the new table, we will have 2 records and remove all this logic to something more standard, as seen in this screenshot: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3028/attachments/image%20%282%29.png) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. *N/A - there's no PK in this table, but the combination of columns that should be unique is tested* - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-02 14:54:03 +00:00
- not_null
- name: product_bundle_name
data_type: string
description: |
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
The name of the product bundle.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3028: Adding int_core__user_product_bundle_contains_services # Description This PR adds a new table named `user_product_bundle_contains_services` in intermediate core. Mainly, this table serves as a bridge between `user_product_bundle` and `product_services`. A `product_bundle` within `user_product_bundle` can contain 1 or several services, and this was stated in the field `contains_product_services`. The value of this field corresponds to the sum of `product_service_binary_tier` from the services that apply within that bundle. Even though the information is quite concise using this format, it adds extra complexity for analytical purposes, so this new table just duplicates the `user_product_bundle` main attributes as many times as services are contained. For example: `id_user_product_bundle` = 383 contains one unique bundle named Basic Program. This bundle has the `chosen_product_services` = 257, which can only be decomposed in power of 2 as of the sum of 256 + 1. This bundle therefore contains 2 services, Basic Screening (`product_service_binary_tier` = 1) and Waiver Pro (`product_service_binary_tier` = 256). Thus, in the new table, we will have 2 records and remove all this logic to something more standard, as seen in this screenshot: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3028/attachments/image%20%282%29.png) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. *N/A - there's no PK in this table, but the combination of columns that should be unique is tested* - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-02 14:54:03 +00:00
- not_null
- name: product_service_name
data_type: string
description: |
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
The name of the product service.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3028: Adding int_core__user_product_bundle_contains_services # Description This PR adds a new table named `user_product_bundle_contains_services` in intermediate core. Mainly, this table serves as a bridge between `user_product_bundle` and `product_services`. A `product_bundle` within `user_product_bundle` can contain 1 or several services, and this was stated in the field `contains_product_services`. The value of this field corresponds to the sum of `product_service_binary_tier` from the services that apply within that bundle. Even though the information is quite concise using this format, it adds extra complexity for analytical purposes, so this new table just duplicates the `user_product_bundle` main attributes as many times as services are contained. For example: `id_user_product_bundle` = 383 contains one unique bundle named Basic Program. This bundle has the `chosen_product_services` = 257, which can only be decomposed in power of 2 as of the sum of 256 + 1. This bundle therefore contains 2 services, Basic Screening (`product_service_binary_tier` = 1) and Waiver Pro (`product_service_binary_tier` = 256). Thus, in the new table, we will have 2 records and remove all this logic to something more standard, as seen in this screenshot: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3028/attachments/image%20%282%29.png) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. *N/A - there's no PK in this table, but the combination of columns that should be unique is tested* - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-02 14:54:03 +00:00
- not_null
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
Addressed comments
2025-02-07 15:15:17 +01:00
- name: product_service_display_name
data_type: string
description: |
The display name of the product service.
data_tests:
- not_null
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- name: int_core__product_service_to_price
description: |
This model provides the information related to the prices of the different
product services in the scope of New Pricing. Each product service can have
prices in different currencies. Each price is storified and applies in the range
of starts to end. If the end date is null, then the price is currently active.
There is no possibility to allow custom pricing at user level.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
column_A: ends_at_utc
column_B: starts_at_utc
or_equal: True
columns:
- name: id_product_service_to_price
data_type: integer
description: |
Identifier of the product service to price. Acts as the primary key for this table.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- unique
- not_null
- name: id_product_service
data_type: integer
description: |
Identifier of the product service.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- not_null
- name: payment_type
data_type: string
description: |
Type of the payment, namely if the price represents a
percentage or an amount.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- not_null
- accepted_values:
values:
- "AMOUNT"
- "PERCENTAGE"
- name: price_base_unit
data_type: string
description: |
Represents how the price value should be taken into account, either
if the price is representing the total amount at booking level or
it's a nightly fee.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- not_null
- accepted_values:
values:
- "PER BOOKING"
- "PER NIGHT"
- name: invoicing_trigger
data_type: string
description: |
Represents at which moment in time this service should be invoiced.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- not_null
- accepted_values:
values:
- "PRE-BOOKING"
- "POST-CHECKOUT"
- "AT WAIVER PAYMENT"
- "AT DEPOSIT PAYMENT"
- "N/A"
- name: currency_code
data_type: string
description:
Currency iso4217 code. It identifies the currency for the amount stated in
amount_local_curr.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- not_null
- name: amount_local_curr
data_type: decimal
description: |
Price amount of a given product service in the currency stated in id_currency.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- not_null
- name: product_service_price_name
data_type: string
description: |
The name given to a product service to price, for example "Waiver Pro Default Price".
- name: product_service_name
data_type: string
description: |
The name of the product service, for example "Waiver Pro".
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: is_default_service
data_type: boolean
description: |
Flag that determines if the service is a default one (True)
or an upgraded service (False).
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- name: starts_at_utc
data_type: timestamp
description: |
Timestamp of when this product service to price starts to be active.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- not_null
- name: ends_at_utc
data_type: timestamp
description: |
Timestamp of when this product service to price ends to be active.
It can be null, thus meaning it's currently active.
- name: has_no_end_date
data_type: boolean
description: |
True when ends_at_utc is not set, false otherwise.
- name: created_at_utc
data_type: timestamp
description: |
Timestamp of when this product service to price was created.
- name: created_date_utc
data_type: date
description: |
Date of when this product service to price was created.
- name: updated_at_utc
data_type: timestamp
description: |
Timestamp of when this product service to price was last updated.
- name: updated_date_utc
data_type: date
description: |
Date of when this product service to price was last updated.
- name: dwh_extracted_at_utc
data_type: timestamp
description: |
Timestamp of when this data was extracted into DWH.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3087: Adding int_core__product_service_to_price # Description Adds int_core__product_service_to_price. This model is the equivalent of staging but just adding currency code, product service name and a few boolean fields to identify if the product service to price is currently active and if it's the default price or not. Currently it's a view since it has 16 records, likely it can be transformed into a table in the future. The idea will be to create a similar table for protection_plan. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [NA] I've picked the right materialization for the affected models. -> We will see in the future if needs to be adapted # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:39:34 +00:00
- not_null
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- name: int_core__protection_plan_to_price
description: |
This model provides the information related to the prices of the different
protection plans in the scope of New Pricing. It does not contain the amounts being
protected, just how much it costs to purchase a given protection.
Each protection plan can have prices in different currencies. Each price is
storified and applies in the range of starts to end. If the end date is null,
then the price is currently active.
There is no possibility to allow custom pricing at user level.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
column_A: ends_at_utc
column_B: starts_at_utc
or_equal: True
columns:
- name: id_protection_plan_to_price
data_type: integer
description: |
Identifier of the protection plan to price. Acts as the primary key for this table.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- unique
- not_null
- name: id_protection_plan
data_type: integer
description: |
Identifier of the protection plan.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- name: payment_type
data_type: string
description: |
Type of the payment, namely if the price represents a
percentage or an amount.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- accepted_values:
values:
- "AMOUNT"
- "PERCENTAGE"
- name: price_base_unit
data_type: string
description: |
Represents how the price value should be taken into account, either
if the price is representing the total amount at booking level or
it's a nightly fee.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- accepted_values:
values:
- "PER BOOKING"
- "PER NIGHT"
- name: invoicing_trigger
data_type: string
description: |
Represents at which moment in time this service should be invoiced.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- accepted_values:
values:
- "PRE-BOOKING"
- "POST-CHECKOUT"
- "AT WAIVER PAYMENT"
- "AT DEPOSIT PAYMENT"
- "N/A"
- name: currency_code
data_type: string
description:
Currency iso4217 code. It identifies the currency for the amount stated in
amount_local_curr.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- name: amount_local_curr
data_type: decimal
description: |
Price amount of a given protection plan in the currency stated in id_currency.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- name: protection_plan_price_name
data_type: string
description: |
The name given to a protection plan to price, for example "ProtectionPlus Default Price".
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: protection_plan_name
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
data_type: string
description: |
The name of the protection plan, for example "ProtectionPlus".
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: is_default_service
data_type: boolean
description: |
Flag that determines if the service is a default one (True)
or an upgraded service (False).
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- name: starts_at_utc
data_type: timestamp
description: |
Timestamp of when this protection plan to price starts to be active.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- name: ends_at_utc
data_type: timestamp
description: |
Timestamp of when this protection plan to price ends to be active.
It can be null, thus meaning it's currently active.
- name: has_no_end_date
data_type: boolean
description: |
True when ends_at_utc is not set, false otherwise.
- name: created_at_utc
data_type: timestamp
description: |
Timestamp of when this protection plan to price was created.
- name: created_date_utc
data_type: date
description: |
Date of when this protection plan to price was created.
- name: updated_at_utc
data_type: timestamp
description: |
Timestamp of when this protection plan to price was last updated.
- name: updated_date_utc
data_type: date
description: |
Date of when this protection plan to price was last updated.
- name: dwh_extracted_at_utc
data_type: timestamp
description: |
Timestamp of when this data was extracted into DWH.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- name: int_core__protection_plan_cover
description: |
This model provides the information related to the cover, or amount protected,
of the different protection plans in the scope of New Pricing.
Each protection plan can have amounts protected in different currencies.
There is no possibility to allow custom protection amounts at user level.
columns:
- name: id_protection_plan_cover
data_type: integer
description: |
Identifier of the protection plan cover. Acts as the primary key for this table.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- unique
- not_null
- name: id_protection_plan
data_type: integer
description: |
Identifier of the protection plan.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- name: currency_code
data_type: string
description: Currency iso4217 code. It identifies the currency for the different protection covers.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- name: baseline_protection_cover_local_curr
data_type: decimal
description: |
Baseline cover amount of a given protection plan in the currency stated in currency_code.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- name: lower_protection_cover_local_curr
data_type: decimal
description: |
Lower cover amount of a given protection plan in the currency stated in currency_code.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- name: maximum_protection_cover_local_curr
data_type: decimal
description: |
Maximum cover amount of a given protection plan in the currency stated in currency_code.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
- name: protection_plan_cover_name
data_type: string
description: |
The name given to a protection plan cover, for example "Basic Protection £50K".
- name: protection_plan_name
data_type: string
description: |
The name given to a protection plan, for example "Basic Protection".
- name: created_at_utc
data_type: timestamp
description: |
Timestamp of when this protection plan cover was created.
- name: created_date_utc
data_type: date
description: |
Date of when this protection plan cover was created.
- name: updated_at_utc
data_type: timestamp
description: |
Timestamp of when this protection plan cover was last updated.
- name: updated_date_utc
data_type: date
description: |
Date of when this protection plan cover was last updated.
- name: dwh_extracted_at_utc
data_type: timestamp
description: |
Timestamp of when this data was extracted into DWH.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3090: Propagates Protection Plan to intermediate, for price and cover # Description Propagates Protection Plan to price and cover to intermediate. Ideally I wanted to have a single table that contained prices + covers, but it is not straight forward to assume: * if a modification of the amount covered by a protection plan will create a new protection plan id, or not * if a modification of the price a protection costs will create a new protection plan id, or not So I keep it split for the time being. Besides, use cases might be different, ex: I want to see all prices of services (product + protection plan, but no need for cover). # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-10-08 11:44:52 +00:00
- not_null
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- name: int_core__booking_to_service
description: |
This model contains the information of which booking has a certain
service applied. 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 or New Pricing.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
column_A: booking_check_out_at_utc
column_B: booking_check_in_at_utc
or_equal: True
- dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
column_A: service_detail_created_at_utc
column_B: booking_created_at_utc
or_equal: True
- dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
column_A: service_detail_updated_at_utc
column_B: service_detail_created_at_utc
or_equal: True
columns:
- name: id_booking
data_type: bigint
description: |
The identifier of the booking. Acts as Foreign Key to Booking table.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- not_null
- name: id_booking_service_detail
data_type: bigint
description: |
The identifier of the booking that has a certain service applied.
The same booking can have multiple services applied and would
have distinct id_booking_service_detail.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- not_null
- unique
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- name: id_verification_request
data_type: bigint
description:
The identifier of the verification request. It acts as Foreign Key to
Verification Request table. It can be null.
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: id_accommodation
data_type: bigint
description:
The identifier of the accommodation or listing. It acts as Foreign Key
to the Accommodation table. It cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
- name: id_user_product_bundle
data_type: bigint
description:
The identifier of the Product Bundle, or program, that a User has applied
to the Booking. It acts as Foreign Key to the User Product Bundle table.
It cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- name: id_verification
data_type: bigint
description: |
The identifier of the verification. It acts as Foreign Key to Verification
table. It can be null.
- name: id_product_service
data_type: bigint
description: |
The identifier of the product service. It acts as Foreign Key to Product
Service table. It can be null.
- name: id_protection_plan
data_type: bigint
description: |
The identifier of the protection plan, aka protection service. It acts as
Foreign Key to Product Plan table. It can be null.
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- name: id_deal
data_type: string
description: |
Unique identifier of the account. It can be null.
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: id_user_host
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
data_type: string
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Unique identifier of the user that acts as a Host.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- not_null
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: id_user_guest
data_type: string
description: |
Unique identifier of the user that acts as a Guest.
Can be null if Superhog does not interact with the Guest.
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: program_name
data_type: string
description: |
The name of the program, or product bundle, applied to the booking.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- name: service_name
data_type: string
description: |
The name of the service applied within the booking. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- not_null
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: service_status
data_type: string
description: |
The status of the service applied within the booking. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: booking_status
data_type: string
description: |
The status of the overall booking. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- name: service_protection_amount
data_type: string
description: |
The amount protected given for the service applied within the booking.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- not_null
- name: service_detail_created_at_utc
data_type: timestamp
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Timestamp of when this Service record was created in the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- not_null
- name: service_detail_updated_at_utc
data_type: timestamp
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Timestamp of when this Service record was last updated in the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- not_null
- name: booking_created_at_utc
data_type: timestamp
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Timestamp of when the Booking record was created in the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: booking_created_date_utc
data_type: date
description: |
Date of when the Booking record was created in the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: booking_updated_at_utc
data_type: timestamp
description: |
Timestamp of when the Booking record was last updated in the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- not_null
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: booking_updated_date_utc
data_type: date
description: |
Date of when the Booking record was last updated in the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- name: booking_check_in_at_utc
data_type: timestamp
description: |
Timestamp of the Check-in of the Booking.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- not_null
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: booking_check_in_date_utc
data_type: timestamp
description: |
Date of the Check-in of the Booking.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- name: booking_check_out_at_utc
data_type: timestamp
description: |
Timestamp of the Check-out of the Booking.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- not_null
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: booking_check_out_date_utc
data_type: date
description: |
Date of the Check-out of the Booking.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
- name: booking_number_of_nights
data_type: integer
description: |
Number of nights between Check-in date and Check-out date.
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: host_currency_code
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
data_type: string
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Iso 4217 currency code for the account of the Host.
It can be null.
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
- name: is_missing_id_deal
data_type: boolean
description: |
Flag to identify if the Host for this booking is missing
the Id Deal or not.
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- name: is_user_in_new_dash
data_type: boolean
description: |
Flag to determine if this user host is in New Dash or not.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
- name: new_dash_version
data_type: string
description: |
For users that are in New Dash, specifies the New Dash Version
in which these users were moved or joined. It can be null if
the user is not in new dash.
- name: user_in_new_dash_since_timestamp_at_utc
data_type: timestamp
description: |
For users that are in New Dash, the effective date since
these users can be considered in New Dash. If the user
has moved from Old Dash, it will be the new_dash_move_at_utc.
If not, it will correspond to the joined_at_utc. It can be null
if the user is not in new dash.
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: is_missing_host_currency_code
data_type: boolean
description: |
Flag to identify if the host is missing the currency code.
- name: is_booking_cancelled
data_type: boolean
description: |
Flag to identify if the booking has been cancelled or not.
- name: int_core__booking_service_detail
description: |
This model contains enriched information of the services that are applied within
a Booking. Specifically, contains both Booking and Services attributes, as well
as the unit and total prices at this specific moment in time. In other words,
it's the snapshot of the current status of the services applied to a 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 or New Pricing.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
column_A: booking_check_out_at_utc
column_B: booking_check_in_at_utc
or_equal: True
- dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
column_A: service_detail_created_at_utc
column_B: booking_created_at_utc
or_equal: True
- dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
column_A: service_detail_updated_at_utc
column_B: service_detail_created_at_utc
or_equal: True
columns:
- name: id_booking
data_type: bigint
description: |
The identifier of the booking. Acts as Foreign Key to Booking table.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
- not_null
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: id_booking_service_detail
data_type: bigint
description: |
The identifier of the booking that has a certain service applied.
The same booking can have multiple services applied and would
have distinct id_booking_service_detail.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- unique
- name: service_detail_created_at_utc
data_type: timestamp
description: |
Timestamp of when this Service record was created in the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: service_detail_updated_at_utc
data_type: timestamp
description: |
Timestamp of when this Service record was last updated in the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: booking_created_at_utc
data_type: timestamp
description: |
Timestamp of when the Booking record was created in the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: booking_updated_at_utc
data_type: timestamp
description: |
Timestamp of when the Booking record was last updated in the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: booking_check_in_at_utc
data_type: timestamp
description: |
Timestamp of the Check-in of the Booking.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: booking_check_out_at_utc
data_type: timestamp
description: |
Timestamp of the Check-out of the Booking.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: service_business_scope
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
data_type: string
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Identifies the main business scope (Platform, Guest Products, APIs)
according to New Pricing documentation. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- accepted_values:
values:
- PLATFORM
- name: service_business_type
data_type: string
description: |
Identifies the service type (Screening, Deposit Management, Protection)
according to New Pricing documentation.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- accepted_values:
values:
- SCREENING
- PROTECTION
- DEPOSIT_MANAGEMENT
- UNKNOWN
- name: service_source
data_type: string
description: |
Identifies the source of the information used (Product or Protection
based on how backend is modelled).
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- accepted_values:
values:
- PRODUCT
- PROTECTION
- UNKNOWN
- name: service_status
data_type: string
description: |
The status of the service applied within the booking. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: booking_status
data_type: string
description: |
The status of the overall booking. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: program_name
data_type: string
description: |
The name of the program, or product bundle, applied to the booking.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: service_name
data_type: string
description: |
The name of the service applied within the booking. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: payment_type
data_type: string
description: |
Identifies if the service price unit is an actual amount or a percentage
of another value. It can be null if the host currency is not populated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- accepted_values:
values:
- "AMOUNT"
- "PERCENTAGE"
- "UNKNOWN"
- name: price_base_unit
data_type: string
description: |
Identifies if the service price unit needs to be applied per booking or
per number of nights between check-in and check-out.
It can be null if the host currency is not populated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- accepted_values:
values:
- "PER BOOKING"
- "PER NIGHT"
- "UNKNOWN"
- name: invoicing_trigger
data_type: string
description: |
Identifies the moment in time in which this service needs to be charged.
It can be null if the host currency is not populated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- accepted_values:
values:
- "PRE-BOOKING"
- "POST-CHECKOUT"
- "AT WAIVER PAYMENT"
- "AT DEPOSIT PAYMENT"
- "N/A"
- "UNKNOWN"
- name: currency_code
data_type: string
description: |
Iso 4217 currency code that applies to the Service within the Booking.
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
It can be null.
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: service_unit_price_local_curr
data_type: decimal
description: |
Identifies the service unit price in the local currency. Can be null.
- name: service_unit_price_in_gbp
data_type: decimal
description: |
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
This is an informative field, use at your own risk.
Identifies the service unit price converted to GBP. If the date of
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
the chargeable exists, it will use the latest chargeable date for the exchange
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
rate computation. If not, it will use the moment this service detail line
was created. It can be null. It can vary over time due to the currency rate
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
estimation in the future for chargeable dates, and can vary also because of
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
changes in the date used.
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: service_total_price_in_gbp
data_type: decimal
description: |
Identifies the current total price of that service in a given
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
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
time until the chargeable date due to the currency rate estimation in
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
the future.
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
- name: service_first_chargeable_date_utc
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
data_type: date
description: |
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
Identifies the first date in which the billing item for this service
Merged PR 4423: Logic for Billable Bookings in New Dash Bookings # Description Changes: * Tags services to be billed (invoiced to host) in the staging models of product_service and protection_plan * Propagates into booking_service_detail master table. This also computes billable dates. * Propagates into booking_summary master table. This has the final determination of a booking being billable or not, and when the first and last billing should occur. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27619
2025-02-17 15:01:44 +00:00
is supposed to be charged or when the guest payment happens.
It can be null if no service supposed to be charged is available.
If there's only one chargeable service, this field will contain
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
the same value as service_last_chargeable_date_utc.
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
- name: service_last_chargeable_date_utc
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
data_type: date
description: |
Identifies the last date in which the billing item for this service
Merged PR 4423: Logic for Billable Bookings in New Dash Bookings # Description Changes: * Tags services to be billed (invoiced to host) in the staging models of product_service and protection_plan * Propagates into booking_service_detail master table. This also computes billable dates. * Propagates into booking_summary master table. This has the final determination of a booking being billable or not, and when the first and last billing should occur. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27619
2025-02-17 15:01:44 +00:00
is supposed to be charged or when the guest payment happens.
It can be null if no service supposed to be charged is available.
If there's only one chargeable service, this field will contain
the same value as service_first_chargeable_date_utc.
- name: service_first_billable_date_utc
data_type: date
description: |
Identifies the first date in which the billing item for this service
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
is supposed to be charged. It can be null if no billing item is
available. If there's only one billing item, this field will contain
Merged PR 4423: Logic for Billable Bookings in New Dash Bookings # Description Changes: * Tags services to be billed (invoiced to host) in the staging models of product_service and protection_plan * Propagates into booking_service_detail master table. This also computes billable dates. * Propagates into booking_summary master table. This has the final determination of a booking being billable or not, and when the first and last billing should occur. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27619
2025-02-17 15:01:44 +00:00
the same value as service_last_billable_date_utc.
It's similar to Chargeable Services logic but it only considers
Billable Services to the Host (excluding Guest Payments and free services).
- name: service_last_billable_date_utc
data_type: date
description: |
Identifies the last date in which the billing item for this service
is supposed to be charged. It can be null if no billing item is
available. If there's only one billing item, this field will contain
the same value as service_first_billable_date_utc.
It's similar to Chargeable Services logic but it only considers
Billable Services to the Host (excluding Guest Payments and free services).
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- name: is_missing_currency_code
Merged PR 3539: Normalise service names and create booking to service table # Description Goal of the PR is start modelising the Services and Revenue for New Dash/New Pricing. Be aware that this is a first model and it's not by all means the definitive nor complete version. Changes: * Services name normalisation: It's a bit painful because we usually had two names: 'MyService' and 'My Service'. The initial setup I built was considering the first, but in some new integrated tables it only has the second. So I just standardised everything to be in upper case and with spaces such as 'MY SERVICE'. Might make more sense later on. This affects many existing models. * Compute a new Service Business Type field in `stg_core__product_service`: Main reason is that effectively Platform scope in New Pricing have business differences in the services types but this does not exist in the backend. I do it at staging level with a dedicated accepted values test to ensure any new update is captured and notified. You can read more about the business logic in this [Notion page](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f). * Create a new model `int_core__booking_to_service`: this model joins the information of BookingViewToService with BookingView and Booking tables to retrieve a more consolidated version of what we will needed downstream for the future table of Booking Service Detail and the Aggregated version (not included in this PR). This table likely can be enriched in future PRs. At the moment it just contains the bare minimum fields needed for the lines/aggregated versions. (NB: Booking information is needed, for instance, for the services which unit price need to be applied for the number of nights of the booking) # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [X] Check if a full-refresh is required after this PR is merged. **stg_core__booking_view_to_service needs full refresh** Related work items: #20809
2024-11-15 10:04:02 +00:00
data_type: boolean
description: |
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
Flag to identify if the applied service is missing the currency code.
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: is_booking_cancelled
data_type: boolean
description: |
Flag to identify if the booking has been cancelled or not.
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: is_paid_service
data_type: boolean
description: |
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
Flag to identify it the service unit price is strictly
greater than 0 or not. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
- name: is_upgraded_service
data_type: boolean
description: |
Flag to identify if the service is an upgraded version,
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
meaning, it's not a Basic Screening. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
- not_null
Merged PR 4423: Logic for Billable Bookings in New Dash Bookings # Description Changes: * Tags services to be billed (invoiced to host) in the staging models of product_service and protection_plan * Propagates into booking_service_detail master table. This also computes billable dates. * Propagates into booking_summary master table. This has the final determination of a booking being billable or not, and when the first and last billing should occur. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27619
2025-02-17 15:01:44 +00:00
- name: is_billable_service
data_type: boolean
description: |
Flag that determines if the service is billable or not.
If the service is billable, it is supposed to be included in the
invoice to the host.
data_tests:
- not_null
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
- name: is_missing_chargeable_date
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
data_type: boolean
description: |
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
Flag to identify if the service has no chargeable date.
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3578: First version of int_core__booking_service_detail # Description Minor Changes: * Computation in staging of `is_default_service` column for Basic Screening. This includes `stg_core__product_service`, `stg_core__protection_plan` and the schema entry. * Propagation of `is_default_service` to intermediate. This includes `int_core__protection_plan_to_price`, `int_core__product_service_to_price` and the schema entry. * Adapting a small data test to include a new case in `stg_core__booking_view_to_service` schema entry. Main Changes: * New fields and re-order existing ones on `int_core__booking_to_service`. * Changed materialisation of `int_core__booking_to_service` to a view, since the new model `int_core__booking_service_detail` is materialised as table. New Model: * First version of `int_core__booking_service_detail`. This model includes the current state of a Service that is applied within a Booking. It includes many Booking attributes, Service attributes as well as some meta data fields regarding the business scope and type, according to the [New Pricing](https://www.notion.so/knowyourguest-superhog/All-Services-Definitions-333fba1fbed54715b6b1c3b5133f0d4f) documentation. * This is one of the 3 Booking models that I propose to create for New Pricing. You can read about the others [here](https://www.notion.so/knowyourguest-superhog/Services-and-Revenue-modelling-1420446ff9c980118e0cfffa7c41f369), although I'll probably won't do them until New Dash is finalised on tech side. * This current model should suffice to be able to understand which services are applied within a Booking. Notably you will see that this is not enough to compute revenue, as there's some placeholders in place. This is expected. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 08:24:32 +00:00
- not_null
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
- name: is_service_chargeable_in_a_single_date
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
data_type: boolean
description: |
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
Flag to identify if the service is chargeable in a single date.
If True, it means that service_first_chargeable_date_utc contains
the same date as service_last_chargeable_date_utc. If False, these
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
fields will contain different dates. It can be null, thus meaning
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
there's no chargeable date at all.
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- name: int_core__booking_summary
description: |
This model contains enriched information aggregated at Booking level regarding
the services that are applied within a Booking.
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 or New Pricing.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
column_A: booking_check_out_at_utc
column_B: booking_check_in_at_utc
or_equal: True
- dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
column_A: number_of_applied_services
column_B: number_of_applied_paid_services
or_equal: True
- dbt_expectations.expect_column_pair_values_A_to_be_greater_than_B:
column_A: number_of_applied_services
column_B: number_of_applied_upgraded_services
or_equal: True
columns:
- name: id_booking
data_type: bigint
description: |
The identifier of the booking. Acts as Primary Key to this table.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
- unique
- name: id_verification_request
data_type: bigint
description:
The identifier of the verification request. It acts as Foreign Key to
Verification Request table. It can be null.
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: id_accommodation
data_type: bigint
description:
The identifier of the accommodation or listing. It acts as Foreign Key
to the Accommodation table. It cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
- name: id_user_product_bundle
data_type: bigint
description:
The identifier of the Product Bundle, or program, that a User has applied
to the Booking. It acts as Foreign Key to the User Product Bundle table.
It cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- name: id_deal
data_type: string
description: |
Unique identifier of the account. It can be null.
- name: id_user_host
data_type: string
description: |
Unique identifier of the user that acts as a Host. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
- name: id_user_guest
data_type: string
description: |
Unique identifier of the user that acts as a Guest.
Can be null if Superhog does not interact with the Guest.
- name: booking_status
data_type: string
description: |
The current status of the booking. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: program_name
data_type: string
description: |
The name of the program, or product bundle, applied to the booking.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- name: booking_created_at_utc
data_type: timestamp
description: |
Timestamp of when the Booking record was created in the Backend.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: booking_created_date_utc
data_type: date
description: |
Date of when the Booking record was created in the Backend.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- name: booking_updated_at_utc
data_type: timestamp
description: |
Timestamp of when the Booking record was last updated in the Backend.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: booking_updated_date_utc
data_type: date
description: |
Date of when the Booking record was last updated in the Backend.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- name: booking_check_in_at_utc
data_type: timestamp
description: |
Timestamp of the Check-in of the Booking.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: booking_check_in_date_utc
data_type: timestamp
description: |
Date of the Check-in of the Booking.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- name: booking_check_out_at_utc
data_type: timestamp
description: |
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
Timestamp of the Check-out of the Booking.
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- name: booking_check_out_date_utc
data_type: date
description: |
Date of the Check-out of the Booking.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3646: Adding informative fields in booking tables for New Pricing # Description Adds informative fields to New Pricing booking-related tables. These are added into booking_to_service which is a view, and propagated and materialised as table in the `booking_service_detail` and `booking_summary`. The new fields are: - Date versions for relevant booking timestamps (Created, Updated, Check-in, Check-out) - Booking Number of nights - Ids for the Accommodation and UserProductBundle - Program Name (aka Product Bundle Name). I dislike the fact that it's named "Product" because you can have Protection Plans in the Program as well... so I opted for a more conventional business-oriented naming, which is Program. Added a bunch of tests + documentation. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-25 15:03:38 +00:00
- not_null
- name: booking_number_of_nights
data_type: integer
description: |
Number of nights between Check-in date and Check-out date.
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- name: host_currency_code
data_type: string
description: |
Iso 4217 currency code for the account of the Host.
It can be null.
- name: is_user_in_new_dash
data_type: boolean
description: |
Flag to determine if this user host is in New Dash or not.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
- name: new_dash_version
data_type: string
description: |
For users that are in New Dash, specifies the New Dash Version
in which these users were moved or joined. It can be null if
the user is not in new dash.
- name: user_in_new_dash_since_timestamp_at_utc
data_type: timestamp
description: |
For users that are in New Dash, the effective date since
these users can be considered in New Dash. If the user
has moved from Old Dash, it will be the new_dash_move_at_utc.
If not, it will correspond to the joined_at_utc. It can be null
if the user is not in new dash.
- 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,
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
payments, etc, as well as it can vary over time until the chargeable
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
date due to the currency rate estimation in the future.
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
- name: service_first_chargeable_date_utc
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
data_type: date
description: |
Identifies the first moment in time in which the first
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
service applied to this booking is supposed to be charged.
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
- name: service_last_chargeable_date_utc
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
data_type: date
description: |
Identifies the last moment in time in which the last
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
service applied to this booking is supposed to be charged.
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
Merged PR 4423: Logic for Billable Bookings in New Dash Bookings # Description Changes: * Tags services to be billed (invoiced to host) in the staging models of product_service and protection_plan * Propagates into booking_service_detail master table. This also computes billable dates. * Propagates into booking_summary master table. This has the final determination of a booking being billable or not, and when the first and last billing should occur. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27619
2025-02-17 15:01:44 +00:00
- name: service_first_billable_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 billed.
This excludes Guest Payments, and only includes services to
be invoiced to the Host.
- name: service_last_billable_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 billed.
This excludes Guest Payments, and only includes services to
be invoiced to the Host.
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
- name: service_first_created_at_utc
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
data_type: timestamp
description: |
Timestamp corresponding to the first creation of a Service
record applied to this Booking, according to the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
- name: service_last_created_at_utc
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
data_type: timestamp
description: |
Timestamp corresponding to the latest creation of a Service
record applied to this Booking, according to the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
- name: service_last_updated_at_utc
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
data_type: timestamp
description: |
Timestamp corresponding to the latest update on any Service
record applied to this Booking, according to the Backend.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- not_null
- name: number_of_applied_services
data_type: integer
description: |
Total number of Services applied to this Booking.
- name: number_of_applied_paid_services
data_type: integer
description: |
Total number of Services that require a monetary
income to Superhog 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.
Merged PR 4423: Logic for Billable Bookings in New Dash Bookings # Description Changes: * Tags services to be billed (invoiced to host) in the staging models of product_service and protection_plan * Propagates into booking_service_detail master table. This also computes billable dates. * Propagates into booking_summary master table. This has the final determination of a booking being billable or not, and when the first and last billing should occur. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27619
2025-02-17 15:01:44 +00:00
- name: number_of_applied_billable_services
data_type: integer
description: |
Total number of Services that require an invoice to the Host
to the Host, that are applied to this Booking.
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
- name: is_booking_chargeable
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
data_type: boolean
description: |
Merged PR 3654: New Dash KPIs - Chargeable Services (Revenue) # Description This PR aims to do 2 things: 1. Create the first metric daily model for New Dash - Chargeable Services * PK at Booking, Date and Service. I added a few more dimensions such as Accommodation and Business Type. The idea is that while Daily Unique Bookings/Accommodations Charged will be close (if not the same) as Charged Services, by having the ID we can compute Monthly/Weekly Unique Bookings/Accommodations Charged in a proper manner. Besides this, we would still compute additive metrics in the future such as the sum of Charged Services and the sum of Service Total Price in GBP. * `IMPORTANT`: as discussed in the daily, I changed New Pricing models containing "Charged" columns to "Chargeable". This affects the new model for New Dash KPIs, but also `int_core__booking_summary` and `int_core__booking_service_detail`. 2. Small fixes on New Dash - Created Services. * Mainly, there were some inconsistencies with what was actually written (and really applied) in the schema entry as for what was the PK of the model vs. what was stated in the model. I just re-ordered the columns and re-specified correctly the PK. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-26 10:14:37 +00:00
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.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
- not_null
Merged PR 4423: Logic for Billable Bookings in New Dash Bookings # Description Changes: * Tags services to be billed (invoiced to host) in the staging models of product_service and protection_plan * Propagates into booking_service_detail master table. This also computes billable dates. * Propagates into booking_summary master table. This has the final determination of a booking being billable or not, and when the first and last billing should occur. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27619
2025-02-17 15:01:44 +00:00
- name: is_booking_billable
data_type: boolean
description: |
Flag to identify it the Booking is billable or not.
In essence, it solves the question: are we supposed to invoice
a certain amount to the host to get money out of this booking, or not?
To be considered as billable, a billable date needs to exist
as well as the total price of billable services, converted to GBP,
need to be strictly greater than 0.
The fact that a booking is not billable does not necessarily mean that
it won't be in the future.
The fact that a booking is not billable does not necessarily mean that
it's not chargeable, since Guest Payments could still apply.
Similarly, if the booking is billable it does not necessarily mean that
is actually billed.
It cannot be null.
data_tests:
- not_null
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- name: is_missing_currency_code_in_service_detail
data_type: boolean
description: |
Flag to identify if the currency code is missing in any
Booking Service Detail record for this Booking.
- name: is_booking_cancelled
data_type: boolean
description: |
Flag to identify if the booking has been cancelled or not.
- name: has_paid_services
data_type: boolean
description: |
Flag to identify if the booking has any paid service 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.
Merged PR 4423: Logic for Billable Bookings in New Dash Bookings # Description Changes: * Tags services to be billed (invoiced to host) in the staging models of product_service and protection_plan * Propagates into booking_service_detail master table. This also computes billable dates. * Propagates into booking_summary master table. This has the final determination of a booking being billable or not, and when the first and last billing should occur. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27619
2025-02-17 15:01:44 +00:00
- name: has_billable_services
data_type: boolean
description: |
Flag to identify if the booking has any billable service or not.
Merged PR 3588: First version of booking summary # Description This table provides the Booking that are under New Pricing. Some of them might also be under New Dashboard. Changes on existing models: * Added a few informative fields in the view `int_core__booking_to_service` that enables feeding Booking Service Detail and Booking Summary. These are: `id_verification_request`, `id_deal`, `is_user_in_new_dash`, `new_dash_version`, `user_in_new_dash_since_timestamp_at_utc`. New models: * Created a first version of `int_core__booking_summary`. This model mainly retrieves Booking attributes from `int_core__booking_to_service` and aggregates service information (paid services, upgraded services, types of services applied, total price, etc) from the detailed version of this table which is `int_core__booking_service_detail`. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-19 16:42:34 +00:00
- 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: is_missing_id_deal
data_type: boolean
description: |
Flag to identify if the Host for this booking is missing
the Id Deal or not.
- name: is_missing_host_currency_code
data_type: boolean
description: |
Flag to identify if the Host for this booking is missing
the currency code or not.
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- name: int_core__product_service_billing_item
description: |
Provides the Billing Items for Product Services in the scope of
New Dashboard and New Pricing initiative.
columns:
- name: id_product_service_billing_item
data_type: integer
description: |
Identifier of the Product Service Billing Item. Acts as the primary key for this table.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- unique
- not_null
- name: id_booking
data_type: integer
description: |
Identifier of the booking. Acts as foreign key for the Booking table.
A Booking can have multiple Billing Items applied. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: id_product_service_to_price
data_type: integer
description: |
Identifier of the product service to price. Acts as foreign key for the
Product Service To Price table. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: id_product_service
data_type: integer
description: |
Identifier of the product service. Acts as foreign key for the
Product Service table. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: service_name
data_type: string
description: |
The name of the service billed for this booking. Cannot be null.
For example: WAIVER PRO.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: service_price_name
data_type: string
description: |
The name given to the price for the service billed for this booking.
For example: WAIVER PRO DEFAULT PRICE.
- name: booking_status
data_type: string
description: |
The current status of the booking. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: currency_code
data_type: string
description:
Currency iso4217 code. It identifies the currency for the amount stated in
amount_local_curr. It cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: amount_local_curr
data_type: decimal
description: |
Price of the Billing Item, in local currency. It can be positive or negative,
depending on if the line aims to add or remove a previously created amount.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
- name: amount_in_gbp
data_type: decimal
description: |
Price of the Billing Item, in GBP. It uses the exchange rate according to
chargeable date. It can be positive or negative, depending on if the
line aims to add or remove a previously created amount.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
- not_null
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- name: chargeable_at_utc
data_type: timestamp
description: |
Timestamp of when this Product Service Billing Item can be charged.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: chargeable_date_utc
data_type: date
description: |
Date of when this Product Service Billing Item can be charged.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: created_at_utc
data_type: timestamp
description: |
Timestamp of when this Product Service Billing Item record was created.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: created_date_utc
data_type: date
description: |
Date of when this Product Service Billing Item record was created.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: updated_at_utc
data_type: timestamp
description: |
Timestamp of when this Product Service Billing Item record was last updated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: updated_date_utc
data_type: date
description: |
Date of when this Product Service Billing Item record was last updated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: int_core__protection_plan_billing_item
description: |
Provides the Billing Items for Protection Plans in the scope of
New Dashboard and New Pricing initiative.
columns:
- name: id_protection_plan_billing_item
data_type: integer
description: |
Identifier of the Protection Plan Billing Item. Acts as the primary key for this table.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- unique
- not_null
- name: id_booking
data_type: integer
description: |
Identifier of the booking. Acts as foreign key for the Booking table.
A Booking can have multiple Billing Items applied. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: id_protection_plan_to_price
data_type: integer
description: |
Identifier of the protection plan to price. Acts as foreign key for the
Protection Plan To Price table. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: id_protection_plan
data_type: integer
description: |
Identifier of the protection plan. Acts as foreign key for the
Protection Plan table. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: service_name
data_type: string
description: |
The name of the service billed for this booking. Cannot be null.
For example: BASIC PROTECTION.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: service_price_name
data_type: string
description: |
The name given to the price for the service billed for this booking.
For example: BASIC PROTECTION DEFAULT PRICE.
- name: booking_status
data_type: string
description: |
The current status of the booking. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: currency_code
data_type: string
description:
Currency iso4217 code. It identifies the currency for the amount stated in
amount_local_curr. It cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: amount_local_curr
data_type: decimal
description: |
Price of the Billing Item, in local currency. It can be positive or negative,
depending on if the line aims to add or remove a previously created amount.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
- name: amount_in_gbp
data_type: decimal
description: |
Price of the Billing Item, in GBP. It uses the exchange rate according to
chargeable date. It can be positive or negative, depending on if the
line aims to add or remove a previously created amount.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3638: Propagates billing info to booking service detail and booking summary # Description Changes: * Handles conversion to GBP directly in the models `int_core__product_service_billing_item` and `int_core__protection_plan_billing_item` . * Adds the newly created field of `is_missing_id_deal` in `int_core__booking_to_service`, to avoid manually computing downstream. * Computes total price per service in `int_core__booking_service_detail`. Since, technically, the same service can have different billing lines, I also retrieve some min/max charge dates and some booleans to help the identification. * Computes total price per booking in `int_core__booking_summary`. Since, technically, the same booking can have different services charged in different moments in time, I also retrieve some min/max charge dates. I also computed a very necessary `is_booking_charged` to understand if we're making money or not out of it. This PR should provide the necessary fields to start computing Revenue for New Dash. HOWEVER: 1) I still need to handle Guest Payments computation for Waiver/Deposit services. I'll do it in a separated PR. 2) while doing this exercise I noticed that the current data is not good / consistent with what I was expecting in terms of New Pricing documentation. I will check with Dash Squad so it's correctly filled, before reporting fake numbers... # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 13:50:30 +00:00
- not_null
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- name: chargeable_at_utc
data_type: timestamp
description: |
Timestamp of when this Protection Plan Billing Item can be charged.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: chargeable_date_utc
data_type: date
description: |
Date of when this Protection Plan Billing Item can be charged.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: created_at_utc
data_type: timestamp
description: |
Timestamp of when this Protection Plane Billing Item record was created.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: created_date_utc
data_type: date
description: |
Date of when this Protection Plan Billing Item record was created.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: updated_at_utc
data_type: timestamp
description: |
Timestamp of when this Protection Plan Billing Item record was last updated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
- name: updated_date_utc
data_type: date
description: |
Date of when this Protection Plan Billing Item record was last updated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3633: Creates billing models in intermediate # Description Adds Billing models in intermediate. It's mostly the similar content as for the staging counterparts, but providing useful information such as the currency code and service that this billing line refers to. Same as before, two separate models for Protection Plan and Product Service. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #20809
2024-11-22 10:28:42 +00:00
- not_null
Merged PR 3766: First version of ab_test_tracking_guest_journey # Description A very simple, clean table to get the records needed for A/B test tracking on GJ side. The table already removes weird cases that are somehow usual within A/B test configurations, to ensure that the monitoring is as clean (and less biased) as possible. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25145
2024-12-04 07:58:14 +00:00
- name: int_core__ab_test_tracking_guest_journey
description: |
Provides the A/B test tracking of a given Verification Request, aka Guest Journey.
For those Guest Journeys that are subject to A/B testing through Feature Flagging,
this table will provide the id of the verification request, the A/B test name in
which is in and the variation, as well as additional metadata.
This table already contains cleaning of multi-variant guest journeys and disablement
of the feature flag (A/B test) itself, so should be quite ready to use.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3766: First version of ab_test_tracking_guest_journey # Description A very simple, clean table to get the records needed for A/B test tracking on GJ side. The table already removes weird cases that are somehow usual within A/B test configurations, to ensure that the monitoring is as clean (and less biased) as possible. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25145
2024-12-04 07:58:14 +00:00
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- id_verification_request
- ab_test_name
columns:
- name: id_verification_request
data_type: integer
description: |
Identifier of the Verification Request. Acts as foreign key to the Verification Request table.
It can be duplicated across different Feature Flags - meaning the same verification request
can be part of none, one, or several A/B tests.
In this table, a Verification Request or Guest Journey can only appear once per A/B test.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3766: First version of ab_test_tracking_guest_journey # Description A very simple, clean table to get the records needed for A/B test tracking on GJ side. The table already removes weird cases that are somehow usual within A/B test configurations, to ensure that the monitoring is as clean (and less biased) as possible. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25145
2024-12-04 07:58:14 +00:00
- not_null
- name: ab_test_name
data_type: string
description: |
Name of the Guest Journey A/B test. It corresponds to the Feature Flag Name in the
backend. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3766: First version of ab_test_tracking_guest_journey # Description A very simple, clean table to get the records needed for A/B test tracking on GJ side. The table already removes weird cases that are somehow usual within A/B test configurations, to ensure that the monitoring is as clean (and less biased) as possible. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25145
2024-12-04 07:58:14 +00:00
- not_null
- name: variation
data_type: string
description: |
Identifier of the variation a given Verification Request is in, within a
given Guest Journey A/B test. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3766: First version of ab_test_tracking_guest_journey # Description A very simple, clean table to get the records needed for A/B test tracking on GJ side. The table already removes weird cases that are somehow usual within A/B test configurations, to ensure that the monitoring is as clean (and less biased) as possible. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25145
2024-12-04 07:58:14 +00:00
- not_null
- name: first_appearance_at_utc
data_type: timestamp
description: |
Timestamp of the first Verification Request Feature Flag record created
with the same verification request and A/B test name. Mostly for information
purposes. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3766: First version of ab_test_tracking_guest_journey # Description A very simple, clean table to get the records needed for A/B test tracking on GJ side. The table already removes weird cases that are somehow usual within A/B test configurations, to ensure that the monitoring is as clean (and less biased) as possible. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25145
2024-12-04 07:58:14 +00:00
- not_null
- name: last_appearance_at_utc
data_type: timestamp
description: |
Timestamp of the last Verification Request Feature Flag record created
with the same verification request and A/B test name. Mostly for information
purposes. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3766: First version of ab_test_tracking_guest_journey # Description A very simple, clean table to get the records needed for A/B test tracking on GJ side. The table already removes weird cases that are somehow usual within A/B test configurations, to ensure that the monitoring is as clean (and less biased) as possible. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25145
2024-12-04 07:58:14 +00:00
- not_null
Merged PR 3769: Adds int_core__ab_test_monitoring_guest_journey # Description Adds a table that contain the main information needed for metric computation at verification request level that is part of an A/B test. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25146
2024-12-04 09:45:09 +00:00
- name: int_core__ab_test_monitoring_guest_journey
description: |
Provides the Guest Journey A/B test key information to build metric monitoring on top.
The purpose of this table is not to compute the metrics themselves, but rather leave
a bit of open possibilities for whenever we're analysing results later on. This is
already materialised to avoid running long queries in the notebooks.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3769: Adds int_core__ab_test_monitoring_guest_journey # Description Adds a table that contain the main information needed for metric computation at verification request level that is part of an A/B test. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25146
2024-12-04 09:45:09 +00:00
- dbt_utils.unique_combination_of_columns:
combination_of_columns:
- id_verification_request
- ab_test_name
columns:
- name: id_verification_request
data_type: integer
description: |
Identifier of the Verification Request. Acts as foreign key to the Verification Request table.
It can be duplicated across different Feature Flags - meaning the same verification request
can be part of none, one, or several A/B tests.
In this table, a Verification Request or Guest Journey can only appear once per A/B test.
Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3769: Adds int_core__ab_test_monitoring_guest_journey # Description Adds a table that contain the main information needed for metric computation at verification request level that is part of an A/B test. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25146
2024-12-04 09:45:09 +00:00
- not_null
- name: ab_test_name
data_type: string
description: |
Name of the Guest Journey A/B test. It corresponds to the Feature Flag Name in the
backend. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3769: Adds int_core__ab_test_monitoring_guest_journey # Description Adds a table that contain the main information needed for metric computation at verification request level that is part of an A/B test. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25146
2024-12-04 09:45:09 +00:00
- not_null
- name: variation
data_type: string
description: |
Identifier of the variation a given Verification Request is in, within a
given Guest Journey A/B test. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3769: Adds int_core__ab_test_monitoring_guest_journey # Description Adds a table that contain the main information needed for metric computation at verification request level that is part of an A/B test. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25146
2024-12-04 09:45:09 +00:00
- not_null
- name: first_appearance_date_utc
data_type: date
description: |
Date of the first Verification Request Feature Flag record created
with the same verification request and A/B test name. Mostly for information
purposes. Cannot be null.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Merged PR 3769: Adds int_core__ab_test_monitoring_guest_journey # Description Adds a table that contain the main information needed for metric computation at verification request level that is part of an A/B test. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #25146
2024-12-04 09:45:09 +00:00
- not_null
- name: verification_started_date_utc
data_type: date
description: |
Date of when the Guest Journey was started. Can be null.
- name: verification_completed_date_utc
data_type: date
description: |
Date of when the Guest Journey was completed. Can be null.
- name: experience_rating
data_type: integer
description: |
CSAT score value for the Guest Journey. Can be null.
- name: last_payment_paid_date_utc
data_type: date
description: |
Date of when the last paid payment on this Guest Journey
happened. Can be null.
- name: guest_revenue_without_taxes_in_gbp
data_type: float
description: |
Total guest revenue paid without taxes in GBP, including Deposit
Fees, Waiver Fees and Check-In Cover fees. Can be null.
- name: deposit_fees_without_taxes_in_gbp
data_type: float
description: |
Deposit fees revenue paid without taxes in GBP.
Can be null.
- name: waiver_fees_without_taxes_in_gbp
data_type: float
description: |
Waiver fees revenue paid without taxes in GBP.
Can be null.
- name: check_in_cover_fees_without_taxes_in_gbp
data_type: float
description: |
Check-in Cover fees revenue paid without taxes in GBP.
Can be null.
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- name: int_core__screen_and_protect_users
description: |
"Contains information about Screen & Protect API users.
It includes all user details related with the service."
columns:
- name: id_apim_user
data_type: character varying
description: "Identifier of the User. Acts as primary
key for this table."
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- not_null
- unique
- name: id_apim_user_type
data_type: bigint
description: "Identifier of the type of user."
Simplify PR
2024-12-20 14:03:58 +01:00
- name: id_currency
data_type: bigint
description: "Id of the currency, works as a foreign key to the
currency table"
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Simplify PR
2024-12-20 14:03:58 +01:00
- not_null
- relationships:
to: ref('stg_core__currency')
field: id_currency
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- name: id_deal
data_type: text
description: ""
- name: account_type
data_type: text
description: ""
- name: client_markup
data_type: text
description: ""
- name: tech_email_address
data_type: text
description: ""
- name: invoicing_email_address
data_type: text
description: ""
- name: is_protected
data_type: boolean
description: |
Indicates if the user's bookings are protected or not.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- not_null
Invoice model completed
2024-12-23 15:25:38 +01:00
- name: price_increase_percentage
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
data_type: numeric
description: The percentage or value of the price increase
applied to the user's account.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: true
- name: price_increase_start_date_utc
data_type: date
description: The date when the price increase becomes effective.
This is the first day of the month.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- is_first_day_of_month
Invoice model completed
2024-12-23 15:25:38 +01:00
- name: monthly_volume_discount_percentage
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
data_type: numeric
description: The discount percentage or value offered based on the
volume of bookings achieved within a month.
No user can have more than one discount per month.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
max_value: 100
strictly: true
Invoice model completed
2024-12-23 15:25:38 +01:00
- name: threshold_approved_or_flagged_booking_volume
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
data_type: numeric
description: The minimum number of bookings required to qualify for
the monthly volume discount.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
strictly: true
- name: monthly_volume_discount_start_date_utc
data_type: date
description: The date when the monthly volume discount period begins.
This is the first day of the month.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- is_first_day_of_month
- name: monthly_volume_discount_end_date_utc
data_type: date
description: The date when the monthly volume discount period ends.
This is the last day of the month.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- is_last_day_of_month
Invoice model completed
2024-12-23 15:25:38 +01:00
- name: monthly_general_discount_percentage
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
data_type: numeric
description: The general discount percentage or value applied to all
bookings within the applicable period.
No user can have more than one discount per month.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
max_value: 100
strictly: true
- name: monthly_general_discount_start_date_utc
data_type: date
description: The date when the general discount period begins.
This is the first day of the month.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- is_first_day_of_month
- name: monthly_general_discount_end_date_utc
data_type: date
description: The date when the general discount period ends.
This is the last day of the month.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- is_last_day_of_month
- name: created_at_utc
data_type: timestamp
description: |
Timestamp of when this user was created.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- not_null
- name: created_date_utc
data_type: date
description: |
Date of when this user was created.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- not_null
- name: updated_at_utc
data_type: timestamp
description: |
Timestamp of when this user was last updated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- not_null
- name: updated_date_utc
data_type: date
description: |
Date of when this user was last updated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
new approach for S&P users data extraction
2024-12-18 11:46:54 +01:00
- not_null
Check in Hero users table
2024-12-20 15:36:00 +01:00
- name: int_core__check_in_hero_users
description: |
"Contains information about CheckIn Hero API users.
It includes all user details related with the service."
columns:
- name: id_apim_user
data_type: character varying
description: "Identifier of the User. Acts as primary
key for this table."
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Check in Hero users table
2024-12-20 15:36:00 +01:00
- not_null
- unique
- name: id_apim_user_type
data_type: bigint
description: "Identifier of the type of user."
- name: id_currency
data_type: bigint
description: "Id of the currency, works as a foreign key to the
currency table"
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Check in Hero users table
2024-12-20 15:36:00 +01:00
- not_null
- relationships:
to: ref('stg_core__currency')
field: id_currency
Added booking fee and currency to model
2025-01-15 09:00:36 +01:00
- name: currency_code
data_type: character varying
description: Currency ISO 4217 code used by user.
data_tests:
- not_null
Check in Hero users table
2024-12-20 15:36:00 +01:00
- name: id_deal
data_type: text
description: ""
- name: account_type
data_type: text
description: ""
- name: client_markup
data_type: text
description: ""
- name: booking_fee_in_local_currency
data_type: numeric
description: "Fee charged to the user for each booking in the local currency."
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Check in Hero users table
2024-12-20 15:36:00 +01:00
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
max_value: 1000
strictly: true
- name: company_name
data_type: text
description: Company name of partner user.
- name: created_at_utc
data_type: timestamp
description: |
Timestamp of when this user was created.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Check in Hero users table
2024-12-20 15:36:00 +01:00
- not_null
- name: created_date_utc
data_type: date
description: |
Date of when this user was created.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Check in Hero users table
2024-12-20 15:36:00 +01:00
- not_null
- name: updated_at_utc
data_type: timestamp
description: |
Timestamp of when this user was last updated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Check in Hero users table
2024-12-20 15:36:00 +01:00
- not_null
- name: updated_date_utc
data_type: date
description: |
Date of when this user was last updated.
change "tests:" to "data_tests:"
2025-01-13 16:00:35 +01:00
data_tests:
Check in Hero users table
2024-12-20 15:36:00 +01:00
- not_null
Listings report model
2025-02-03 10:37:25 +01:00
- name: int_core__accommodations_activity
description: |
This model provides a detailed information on listings, including their hosts,
and related booking activity. It contains identifiers, geographic information,
host details, and booking counts categorized by status.
columns:
- name: id_accommodation
data_type: bigint
description: "The unique identifier of the listing."
data_tests:
- unique
- not_null
- name: id_user_host
data_type: text
description: "The unique identifier of the host associated with the listing."
- name: id_deal
data_type: character varying
description: |
The primary identifier of the B2B client (deal). A deal can be linked to multiple hosts,
while a host can have at most one deal or none. This field can be null if there is no deal.
- name: company_name
data_type: character varying
description: |
The name of the company associated with the host. This value may sometimes match
the host's first name, last name, a combination of both, or be entirely different.
It can also be null or empty.
- name: email
data_type: character varying
description: "The email address of the host."
- name: first_name
data_type: character varying
description: "The first name of the host."
- name: last_name
data_type: character varying
description: "The last name of the host."
- name: is_active
data_type: boolean
description: |
Indicates whether the listing is currently active.
- name: friendly_name
data_type: character varying
description: "A user-friendly name assigned to the listing."
- name: country_name
data_type: character varying
description: "The full name of the country where the listing is located."
- name: town
data_type: character varying
description: "The town or city where the listing is located."
- name: address_line_1
data_type: character varying
description: "The first line of the listing's address."
- name: address_line_2
data_type: character varying
description: "The second line of the listing's address, if applicable."
- name: country_iso_2
data_type: character varying
description: "The two-letter ISO 3166-1 country code representing the listing's country."
- name: postcode
data_type: character varying
description: "The postal code of the listing's location."
- name: currency_iso4217
data_type: character varying
description: "The three-letter ISO 4217 currency code for transactions related to the listing."
- name: created_date_utc
data_type: date
description: "The date when the listing was first created."
- name: approved_bookings
data_type: bigint
description: "The total number of bookings with status approved for this accommodation."
- name: cancelled_bookings
data_type: bigint
description: "The total number of bookings with status cancelled for this accommodation."
- name: flagged_bookings
data_type: bigint
description: "The total number of bookings with status flagged for this accommodation."
- name: incomplete_information_bookings
data_type: bigint
description: "The total number of bookings with status incomplete information for this accommodation."
- name: no_flags_bookings
data_type: bigint
description: "The total number of bookings with status no flags for this accommodation."
- name: not_approved_bookings
data_type: bigint
description: "The total number of bookings with status not approved for this accommodation."
- name: rejected_bookings
data_type: bigint
description: "The total number of bookings with status rejected for this accommodation."
- name: total_bookings
data_type: bigint
description: "The total number of bookings for this accommodation."
Model for Bookings report in Legacy
2025-02-05 11:53:28 +01:00
- name: int_core__booking_details
description: |
"Contains detailed information about each booking, including host
and guest details, accommodation, and verification request data."
columns:
- name: id_booking
data_type: bigint
description: "The unique, Superhog generated id for this booking."
data_tests:
- unique
- not_null
- name: id_user_host
data_type: text
description: "The unique user ID for the Host."
data_tests:
- not_null
- name: id_deal
data_type: character varying
description:
"The ID of the deal of the user. It only applies to client accounts.
Can be null."
- name: id_user_guest
data_type: text
description: "The unique, Superhog generated id for the guest"
- name: id_accommodation
data_type: bigint
description: "Id of the accommodation or listing."
- name: id_verification_request
data_type: bigint
description: |
The identifier of the verification request. It acts as Foreign Key to
Verification Request table. It can be null.
- name: booking_state
data_type: character varying
description:
"State in which the booking is, could be either of the following:
- Approved
- NotApproved
- Cancelled
- Rejected
- NoFlags
- Flagged
- IncompleteInformation"
data_tests:
- accepted_values:
values:
- "Approved"
- "NotApproved"
- "Cancelled"
- "Rejected"
- "NoFlags"
- "Flagged"
- "IncompleteInformation"
- name: is_accommodation_active
data_type: boolean
description: "Boolean value indicating if the accommodation is active."
- name: checkin_date_utc
data_type: date
description: "Date of check-in of the booking."
- name: checkout_date_utc
data_type: date
description: "Date of check-out of the booking."
- name: booking_nights
data_type: integer
description: "Number of nights of the booking."
- name: created_date_utc
data_type: timestamp without time zone
description: "Date when the booking was created."
- name: host_first_name
data_type: character varying
description: "First name of the host."
- name: host_last_name
data_type: character varying
description: "Last name of the host."
- name: host_email
data_type: character varying
description: "Email of the host."
- name: company_name
data_type: character varying
description: "The company name."
- name: guest_first_name
data_type: character varying
description: "First name of the guest."
- name: guest_last_name
data_type: character varying
description: "Last name of the guest."
- name: guest_email
data_type: character varying
description: "Email of the guest."
- name: guest_billing_country
data_type: character varying
description: "Billing country of the guest."
- name: guest_billing_town
data_type: character varying
description: "Billing town of the guest."
added friendly name
2025-02-05 12:41:30 +01:00
- name: friendly_name
data_type: character varying
description: "Name of the listing."
Model for Bookings report in Legacy
2025-02-05 11:53:28 +01:00
- name: accommodation_country
data_type: character varying
description: "Country of the listing"
- name: accommodation_address
data_type: character varying
description: "Address of the listing"
- name: is_verification_request_complete
data_type: boolean
description: "True if the verification request is considered complete,
AKA the guest has finished the full guest journey."
- name: verification_estimated_started_date_utc
data_type: date
description: "The estimated date on which the guest started the guest journey."
- name: verification_estimated_completed_date_utc
data_type: date
description: "The estimated date on which the guest finished the guest journey."
renamed
2025-02-05 16:06:29 +01:00
- name: days_to_complete_verification
adding number of days to complete verification
2025-02-05 15:31:42 +01:00
data_type: numeric
description: "Number of days it took to complete the verification."
Model for Bookings report in Legacy
2025-02-05 11:53:28 +01:00
- name: link_used_date_utc
data_type: date
description: "The date on which the guest used the link for the verification."
- name: verification_request_booking_source
data_type: text
description: Source type of host of the booking, this could be either;
- PMS
- OSL
- API/MANUAL
data_tests:
- accepted_values:
values:
- "PMS"
- "OSL"
- "API/MANUAL"
- name: chose_deposit
data_type: boolean
description: "Boolean value indicating if the guest chose Deposit payment validation."
- name: chose_fee
data_type: boolean
description: "Boolean value indicating if the guest chose Fee payment validation."
- name: chose_waiver
data_type: boolean
description: "Boolean value indicating if the guest chose Waiver payment validation."
- name: chose_no_cover
data_type: boolean
description: "Boolean value indicating if the guest chose No Cover payment validation."
- name: chose_checkin_cover
data_type: boolean
description: "Boolean value indicating if the guest chose CheckIn Cover."
New dash service usage model
2025-02-07 12:37:32 +01:00
Addressed comments
2025-02-07 15:15:17 +01:00
- name: int_core__new_dash_services_offered
description: "This model contains the the services offered in New Dash.
finished schema
2025-02-10 08:18:11 +01:00
These offers are displayed by different measures, such as the number of users,
New dash service usage model
2025-02-07 12:37:32 +01:00
accommodations and bookings."
columns:
Addressed comments
2025-02-10 08:09:22 +01:00
- name: service_display_name
New dash service usage model
2025-02-07 12:37:32 +01:00
data_type: text
Addressed comments
2025-02-10 08:09:22 +01:00
description: "The name of the New Dash service."
New dash service usage model
2025-02-07 12:37:32 +01:00
data_tests:
- not_null
- name: number_users
data_type: bigint
description:
"Number of user accounts that have a bundle that considers this service.
The fact that a user has a bundle with the service included does not mean
that the service is active or used. Each user can associate any of their
bundles with any of their accommodations."
changed naming
2025-02-12 15:16:41 +01:00
- name: number_users_with_service_applied_in_accommodation
new active_users data
2025-02-12 15:00:31 +01:00
data_type: bigint
description:
"Number of user accounts that have a bundle that considers this service
and that bundle is active in at least one active accommodation.
In other words there is at least one active accommodation that offers
this service for this number of users."
Format schema
2025-02-12 15:03:17 +01:00
changed naming
2025-02-12 15:16:41 +01:00
- name: number_users_without_service_applied_in_accommodation
new active_users data
2025-02-12 15:00:31 +01:00
data_type: bigint
description:
"Number of user accounts that have a bundle that considers this service
but none of those bundle with the service is active in any active
accommodation.
fixed schema
2025-02-12 15:35:03 +01:00
It is basically the difference between number_users and
number_users_with_service_applied_in_accommodation."
new active_users data
2025-02-12 15:00:31 +01:00
New dash service usage model
2025-02-07 12:37:32 +01:00
- name: number_accommodations
data_type: bigint
description:
"Number of accommodations or listings that have a bundle that considers
this service."
- name: number_active_accommodations
data_type: bigint
description:
"Number of accommodations or listings that have a bundle that considers
this service and are active."
- name: number_inactive_accommodations
data_type: bigint
description:
"Number of accommodations or listings that have a bundle that considers
this service and are inactive."
- name: number_bookings
data_type: bigint
description: "Number of bookings that have a bundle that considers this service."
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_protected
New dash service usage model
2025-02-07 12:37:32 +01:00
data_type: bigint
Updated model
2025-02-13 17:13:05 +01:00
description: "Number of bookings with status PROTECTED for this service."
New dash service usage model
2025-02-07 12:37:32 +01:00
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_rejected
New dash service usage model
2025-02-07 12:37:32 +01:00
data_type: bigint
Updated model
2025-02-13 17:13:05 +01:00
description: "Number of bookings with status REJECTED for this service."
New dash service usage model
2025-02-07 12:37:32 +01:00
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_no_checks
New dash service usage model
2025-02-07 12:37:32 +01:00
data_type: bigint
Updated model
2025-02-13 17:13:05 +01:00
description: "Number of bookings with status NO CHECKS for this service."
added all booking states
2025-02-12 09:09:16 +01:00
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_no_flags
added all booking states
2025-02-12 09:09:16 +01:00
data_type: bigint
Updated model
2025-02-13 17:13:05 +01:00
description: "Number of bookings with status NO FLAGS for this service."
added all booking states
2025-02-12 09:09:16 +01:00
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_paid
added all booking states
2025-02-12 09:09:16 +01:00
data_type: bigint
Updated model
2025-02-13 17:13:05 +01:00
description: "Number of bookings with status PAID for this service."
added all booking states
2025-02-12 09:09:16 +01:00
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_pending
added all booking states
2025-02-12 09:09:16 +01:00
data_type: bigint
Updated model
2025-02-13 17:13:05 +01:00
description: "Number of bookings with status PENDING for this service."
added all booking states
2025-02-12 09:09:16 +01:00
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_unknown
added all booking states
2025-02-12 09:09:16 +01:00
data_type: bigint
Updated model
2025-02-13 17:13:05 +01:00
description: "Number of bookings with unknown status for this service."
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_partially_protected
Updated model
2025-02-13 17:13:05 +01:00
data_type: bigint
description: "Number of bookings with status PARTIALLY PROTECTED for this service."
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_not_protected
Updated model
2025-02-13 17:13:05 +01:00
data_type: bigint
description: "Number of bookings with status NOT PROTECTED for this service."
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_not_paid
Updated model
2025-02-13 17:13:05 +01:00
data_type: bigint
description: "Number of bookings with status NOT PAID for this service."
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_confirmed
Updated model
2025-02-13 17:13:05 +01:00
data_type: bigint
description: "Number of bookings with status CONFIRMED for this service."
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_for_review
Updated model
2025-02-13 17:13:05 +01:00
data_type: bigint
description: "Number of bookings with status FOR REVIEW for this service."
Addressed comments
2025-02-14 08:35:51 +01:00
- name: number_bookings_with_service_status_flagged
Updated model
2025-02-13 17:13:05 +01:00
data_type: bigint
description: "Number of bookings with status FLAGGED for this service."
added all booking states
2025-02-12 09:09:16 +01:00
Payments model for legacy report
2025-02-04 11:24:46 +01:00
- name: int_core__payments
description: |
A table holding payment details for guest journeys, including amounts in both
transaction currency and GBP, host and guest information, and payment status.
Currency conversions are done using using data from xexe.com.
columns:
- name: id_payment
data_type: bigint
description: Unique identifier for the payment.
data_tests:
- not_null
- name: payment_reference
data_type: character varying
description: Unique reference code associated with the payment.
- name: verification_payment_type
data_type: character varying
description: Type of payment verification, categorizing the transaction.
data_tests:
- accepted_values:
values:
- "Waiver"
- "Deposit"
- "CheckInCover"
- "Fee"
Fixed waiver payment logic
2025-02-04 14:14:00 +01:00
- name: is_host_taking_waiver_risk
data_type: boolean
description: Boolean indicating whether the host is taking the risk
- name: payaway_percentage
data_type: numeric
description: Percentage of the payment that goes to Superhog.
- name: payaway_minimum_commission_local_curr
data_type: numeric
description: Minimum commission amount in local currency.
Payments model for legacy report
2025-02-04 11:24:46 +01:00
- name: payment_status
data_type: character varying
description: Current status of the payment (e.g., pending, paid, refunded).
- name: payment_due_date_utc
data_type: date
description: The due date for the payment, in UTC.
- name: payment_paid_date_utc
data_type: date
description: The date when the payment was successfully made, in UTC.
commit wip
2025-02-06 12:20:33 +01:00
- name: refund_payment_reference
data_type: date
description: The reference code associated with the refund payment.
- name: refund_due_date_utc
data_type: date
description: The due date for the refund payment, in UTC.
- name: payment_refunded_date_utc
data_type: date
description: The date when the payment was refunded, in UTC.
Payments model for legacy report
2025-02-04 11:24:46 +01:00
- name: total_amount_in_txn_currency
data_type: numeric
description: |
The total amount of the payment in local currency.
This includes taxes if applicable.
data_tests:
- not_null
- name: total_amount_in_gbp
data_type: numeric
description: |
The total amount of the payment in GBP.
This includes taxes if applicable.
data_tests:
- not_null
- name: amount_without_taxes_in_txn_currency
data_type: numeric
description: |
The net amount of the payment without taxes, in local currency.
data_tests:
- not_null
- name: amount_without_taxes_in_gbp
data_type: numeric
description: |
The net amount of the payment without taxes, in GBP.
data_tests:
- not_null
- name: tax_amount_in_txn_currency
data_type: numeric
description: |
The tax portion of the payment, in local currency.
Will be 0 if no taxes apply.
data_tests:
- not_null
- name: tax_amount_in_gbp
data_type: numeric
description: |
The tax portion of the payment, in GBP. Will be 0 if no
taxes apply.
data_tests:
- not_null
- name: amount_due_to_host_in_txn_currency
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The amount payable to the host with taxes, in local currency.
Payments model for legacy report
2025-02-04 11:24:46 +01:00
- name: amount_due_to_host_in_gbp
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The amount payable to the host with taxes, in GBP.
- name: amount_due_to_host_without_taxes_in_txn_currency
data_type: numeric
description: |
The amount payable to the host without taxes, in local currency.
- name: amount_due_to_host_without_taxes_in_gbp
data_type: numeric
description: |
The amount payable to the host without taxes, in GBP.
Payments model for legacy report
2025-02-04 11:24:46 +01:00
- name: superhog_fee_in_txn_currency
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The service fee charged by Superhog with taxes, in local currency.
Payments model for legacy report
2025-02-04 11:24:46 +01:00
- name: superhog_fee_in_gbp
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The service fee charged by Superhog with taxes, in GBP.
- name: superhog_fee_without_taxes_in_txn_currency
data_type: numeric
description: |
The service fee charged by Superhog without taxes, in local currency.
- name: superhog_fee_without_taxes_in_gbp
data_type: numeric
description: |
The service fee charged by Superhog without taxes, in GBP.
Payments model for legacy report
2025-02-04 11:24:46 +01:00
- name: currency
data_type: text
description: |
The ISO 4217 currency code (e.g., GBP, USD, EUR) in which the payment
was originally made.
Fixed waiver payment logic
2025-02-04 14:14:00 +01:00
- name: exchange_rate_to_gbp
data_type: numeric
description: |
The exchange rate used to convert the payment amount from local currency
to GBP.
Added booking id to payments model
2025-02-19 11:53:19 +01:00
- name: id_booking
data_type: bigint
description: The unique, Superhog generated id for this booking.
Can be null for verification request not related to a booking.
new booking fields
2025-02-19 15:29:05 +01:00
- name: booking_state
data_type: character varying
description: "State in which the booking is"
- name: is_verification_request_complete
data_type: boolean
description: "True if the verification request is considered
complete, AKA the guest has finished the full guest journey."
Fixed waiver payment logic
2025-02-04 14:14:00 +01:00
- name: id_user_host
data_type: character varying
description: |
The unique identifier of the host receiving the payment.
- name: id_deal
data_type: character varying
description: |
Main identifier of the B2B clients. A Deal can have multiple Hosts.
A Host can have only 1 Deal or no Deal at all. This field can be null.
commit wip
2025-02-06 12:20:33 +01:00
- name: host_first_name
Payments model for legacy report
2025-02-04 11:24:46 +01:00
data_type: character varying
description: First name of the host receiving the payment.
commit wip
2025-02-06 12:20:33 +01:00
- name: host_last_name
Payments model for legacy report
2025-02-04 11:24:46 +01:00
data_type: character varying
description: Last name of the host receiving the payment.
commit wip
2025-02-06 12:20:33 +01:00
- name: host_email
Payments model for legacy report
2025-02-04 11:24:46 +01:00
data_type: character varying
description: Email address of the host receiving the payment.
- name: company_name
data_type: character varying
description: |
The company name of the host.
Fixed waiver payment logic
2025-02-04 14:14:00 +01:00
- name: host_country
data_type: character varying
description: |
The country name of the host.
Payments model for legacy report
2025-02-04 11:24:46 +01:00
- name: guest_first_name
data_type: character varying
description: First name of the guest making the payment.
- name: guest_last_name
data_type: character varying
description: Last name of the guest making the payment.
- name: guest_email
data_type: character varying
description: Email address of the guest making the payment.
commit wip
2025-02-06 12:20:33 +01:00
- name: guest_billing_country
data_type: text
description: |
The country name of the guest's billing address.
- name: guest_billing_town
data_type: text
description: |
The town or city name of the guest's billing address.
Added listings data
2025-02-19 14:57:44 +01:00
- name: id_accommodation
data_type: character varying
description: |
"Id of the accommodation or listing."
- name: accommodation_name
Payments model for legacy report
2025-02-04 11:24:46 +01:00
data_type: character varying
description: |
A user-friendly name for the booking or transaction, often used for
display purposes.
Added listings data
2025-02-19 14:57:44 +01:00
- name: accommodation_country
data_type: text
description: |
The country name of the accommodation.
- name: accommodation_town
data_type: text
description: |
The town or city name of the accommodation.
- name: accommodation_address
Payments model for legacy report
2025-02-04 11:24:46 +01:00
data_type: character varying
description: |
The first line of the property address associated with the payment.
Added listings data
2025-02-19 14:57:44 +01:00
- name: accommodation_postcode
data_type: character varying
description: |
The postal code of the property address associated with the payment
for the booking.
Payments model for legacy report
2025-02-04 11:24:46 +01:00
- name: check_in_date_utc
data_type: date
description: The scheduled check-in date of the guest, in UTC.
- name: check_out_date_utc
data_type: date
description: The scheduled check-out date of the guest, in UTC.
- name: host_currency
data_type: character varying
description: |
The currency in which the host receives their payment (may differ from
the transaction currency).
New waiver fees model
2025-02-10 18:42:15 +01:00
- name: int_core__waiver_fees
description: |
"This model contains the fees charged for the Waiver service. It includes
the percentage of the payment that goes to Superhog, the minimum fee around
the amount charged in both local currency and GBP"
columns:
- name: id_payment
data_type: bigint
description: Unique identifier for the payment.
data_tests:
- not_null
- name: payaway_percentage
data_type: numeric
description: Percentage of the payment that goes to Superhog.
data_tests:
- dbt_expectations.expect_column_values_to_be_between:
min_value: 0
max_value: 0.99
strictly: false
- name: payaway_minimum_commission_local_curr
data_type: numeric
description: Minimum commission amount in local currency.
- name: is_host_taking_waiver_risk
data_type: boolean
description: Boolean indicating whether the host is taking the risk
- name: amount_due_to_host_in_txn_currency
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The amount payable to the host with taxes, in local currency.
New waiver fees model
2025-02-10 18:42:15 +01:00
- name: amount_due_to_host_in_gbp
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The amount payable to the host with taxes, in GBP.
New waiver fees model
2025-02-10 18:42:15 +01:00
- name: superhog_fee_in_txn_currency
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The service fee charged by Superhog with taxes, in local currency.
New waiver fees model
2025-02-10 18:42:15 +01:00
- name: superhog_fee_in_gbp
data_type: numeric
description: |
Updated model
2025-02-11 10:44:19 +01:00
The service fee charged by Superhog with taxes, in GBP.
Merged PR 4349: Xero metrics by Business Scope # Description Changes: * Creation of a deal-based model that contains when a "deal has appeared in new dash". This is tricky because a Deal can still have multiple users, thus it needs to be attributed to a date. I've chosen the first user appearance for the rest of the metrics. * Adaptation of dimension deals in KPIs to include a client type, that indicates if the deal is from APIs or not (Platform, i.e., Dashboard). * Xero metrics by Business Scope. This is the previous "dash source" that I need to change in the previously worked models. I decided to include APIs in the segmentation since in most cases we distinguish old dash from new dash by just "anything that is not in new dash". This is very wrong for invoicing metrics, in which we have APIs. So this actually properly computes a client segmentation by scope. Note that I'll need to handle the monthly/mtd metrics/agg for these 2 metric models (Resolutions + Invoiced revenue) separately. # Checklist - [X] The edited models and dependants run properly with production data. - [X] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [X] I have checked for DRY opportunities with other models and docs. - [X] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #27356
2025-02-11 15:13:42 +00:00
- name: int_core__new_dash_deal_since_date
description: |
This model contains the deals that correspond to user hosts in New Dash.
While not the usual case, it's possible that a deal has more than one user
host. Thus this model aims to aggregate the first and last migration or
appearances dates for each deal. This is specially useful for KPIs purposes.
columns:
- name: id_deal
data_type: character varying
description: |
The unique identifier of the deal that is in New Dash.
data_tests:
- unique
- not_null
- name: min_user_in_new_dash_since_date_utc
data_type: date
description: |
The date when the first user host appeared in New Dash for this deal.
- name: max_user_in_new_dash_since_date_utc
data_type: date
description: |
The date when the last user host appeared in New Dash for this deal.
- name: total_new_dash_users
data_type: bigint
description: |
The total number of user hosts that have appeared in New Dash for this deal.
New PMS model
2025-02-19 08:59:49 +01:00
Renamed
2025-02-19 10:56:43 +01:00
- name: int_core__active_property_managers_system
New PMS model
2025-02-19 08:59:49 +01:00
description: |
This model contains information about active property managers systems (PMS)
and their associated hosts.
It includes details about the host, their account type, company,
billing information, and the number of accommodations they manage.
columns:
renamed field
2025-02-19 11:57:58 +01:00
- name: active_pms_name
New PMS model
2025-02-19 08:59:49 +01:00
data_type: text
description: |
renamed field
2025-02-19 11:57:58 +01:00
The name of the active property management system.
New PMS model
2025-02-19 08:59:49 +01:00
data_tests:
- not_null
- name: id_user_host
data_type: character varying
description: |
Updated tests
2025-02-19 09:08:21 +01:00
The unique ID for the host.
data_tests:
- not_null
- unique
New PMS model
2025-02-19 08:59:49 +01:00
- name: id_deal
data_type: character varying
description: |
Main identifier of the B2B clients. A Deal can have multiple Hosts.
A Host can have only 1 Deal or no Deal at all. This field can be null.
- name: account_type
data_type: character varying
description: |
Name of the account type. Can be null and might be not up-to-date.
- name: first_name
data_type: character varying
description: |
First name of the Host.
- name: last_name
data_type: character varying
description: |
Last name of the Host.
- name: company_name
data_type: character varying
description: |
Name of the company. In some cases, it's the same as the first_name,
the last_name, a concatenation of both, or something different.
Can be null and empty.
- name: email
data_type: character varying
description: |
Email of the Host.
- name: billing_country_name
data_type: character varying
description: |
Name of the country in which the Host is billed.
In some cases it's null.
- name: billing_country_iso_3
data_type: character varying
description: |
ISO 3166-1 alpha-3 country code in which the Host is billed.
In some cases it's null.
- name: joined_date_utc
data_type: date
description: |
Date of when the Host user joined Superhog.
- name: booking_count
data_type: bigint
description: |
The number of bookings from the host made through the PMS.
- name: accommodation_count
data_type: bigint
description: |
The number of accommodations managed by the host.
Reference in a new issue Copy permalink