84 lines
No EOL
9.4 KiB
Markdown
84 lines
No EOL
9.4 KiB
Markdown
# 2024-10-02 - Integrating New Dashboard & New Pricing into DWH
|
||
|
||
List of Core tables linked to New Pricing (NP) / New Dashboard (ND)
|
||
|
||
| Table Name | Description | Main fields | Status | DWH usages | Uri’s comments |
|
||
| --- | --- | --- | --- | --- | --- |
|
||
| Claim | Not exclusively for NP/ND, but used to know which users have been switched in different stages from Old Dashboard to New Dashboard | - UserId
|
||
- ClaimType
|
||
- ClaimValue | Fully integrated, might need updates | We apply a macro based on the content of this table:
|
||
- [user_migration_configuration](https://guardhog.visualstudio.com/Data/_git/data-dwh-dbt-project?path=/macros/user_migration_configuration.sql)
|
||
This is later used in the [user_migration](https://guardhog.visualstudio.com/Data/_git/data-dwh-dbt-project?path=/models/intermediate/core/int_core__user_migration.sql) model to identify migrated users from old to new dash. This is later added into the main table of [user_host](https://guardhog.visualstudio.com/Data/_git/data-dwh-dbt-project?path=/models/intermediate/core/int_core__user_host.sql) | Likely we’ll need updates as new versions of the dashboard are launched. Should be covered already for MVP and V2.
|
||
|
||
Not clear how to tag “new dash users” for those cases that the user gets directly created into the new dash (instead of switched). To be confirmed
|
||
- Quick discussion with Daga: what if we take 1) Claim to know which user is in New Dash and 2) Claim to know which user has been switched and when. Then 1)-2) is new users in new dash, and the creation date of the user is the new “start date”. |
|
||
| ProductBundle | Basic information of a product bundle | - Id (ProductBundleId)
|
||
- ProtectionPlanId | Not integrated, will not integrate | | Not needed for the moment since UserProductBundle already contains denormalised information of the product bundle (ex: name, protection plan id) |
|
||
| ProductBundleDescription | Description of the product bundle | - ProductBundleId | Not integrated, will not integrate | | Not needed for the moment since it only contains an explanation of what the product bundle means for client point of view |
|
||
| UserProductBundle | It’s the main table: it states that the user has, or has had, the capacity to apply product bundles into a listing. This does not mean however that these are/were actually applied. A bundle contains one or more product services and has a certain protection plan. | - Id (UserProductBundleId)
|
||
- SuperhogUserId
|
||
- ProductBundleId
|
||
- ProtectionPlanId
|
||
- ChosenProductServices
|
||
- StartDate
|
||
- EndDate | Fully integrated, might need updates | Main usage in the model:
|
||
- [user_product_bundle](https://guardhog.visualstudio.com/Data/_git/data-dwh-dbt-project?path=/models/intermediate/core/int_core__user_product_bundle.sql) | Not all users in this table are in New Dashboard. Thus, specifically for New Dash reporting, we force users to exist in the user_migration model. Also, we create an effective start date of a product bundle so this start date is not before the user switched from old to new dash. |
|
||
| AccommodationToProductBundle | Another main table: it states that a listing has, or has had, a product bundled applied; thus affecting the bookings of that listing with the specific product bundle. | - Id (AccommodationToProductBundleId)
|
||
- UserProductBundleId
|
||
- AccommodationId
|
||
- StartDate
|
||
- EndDate | Fully integrated, no need to update | Main usage in the model:
|
||
- [accommodation_to_product_bundle](https://guardhog.visualstudio.com/Data/_git/data-dwh-dbt-project?path=/models/intermediate/core/int_core__accommodation_to_product_bundle.sql) | Important - this table will NOT contain basic screening product bundle. This is because this bundle is by default. Thus only product bundles different to the basic screening can be applied. Also, we create an effective start date of a product bundle so this start date is not before the user configured the bundle (see UserProductBundle comment) |
|
||
| BookingToProductBundle | States that a booking has had a product bundle (well, a user product bundle) applied. Thus this can be used to know the product and protection services that were offered (not necessarily those that finally applied). | - Id
|
||
- UserProductBundleId
|
||
- BookingId | Fully integrated, no need to update | Main usage in the model:
|
||
- [booking_to_product_bundle](https://guardhog.visualstudio.com/Data/_git/data-dwh-dbt-project?path=/models/intermediate/core/int_core__booking_to_product_bundle.sql&version=GBmaster&_a=contents) | Unsure of why we have StartDate and EndDate in this table. Not using it 😀
|
||
|
||
We also enforce that the user needs to have had the product bundle configured before the booking was created (effectively meaning that we exclude bookings from migrated users that were created before the migration date). |
|
||
| ProductService | Basic information of the product service | - Id (ProductServiceId)
|
||
- ProductServiceFlag | Integrated in staging, needs further modelisation | Integrated into staging:
|
||
- [product_service](https://guardhog.visualstudio.com/Data/_git/data-dwh-dbt-project?path=/models/staging/core/stg_core__product_service.sql) | |
|
||
| ProductServiceToPrice | Basic information of product services and their prices. It states that a given product service will have a certain price for a given currency, with a given price base unit, with a certain invoicing trigger and a specific payment type. Additionally, it will state if this price is a default one or a dedicated one for a given user, in case UserProductBundleId is set. | - Id (ProductServiceToPriceId)
|
||
- ProductServiceId
|
||
- CurrencyId
|
||
- UserProductBundleId
|
||
- BillingMethodId
|
||
- InvoicingMethodId
|
||
- PaymentTypeId
|
||
- StartDate
|
||
- EndDate
|
||
- Amount | Integrated in staging, needs further modelisation | Integrated into staging:
|
||
- [product_service_to_price](https://guardhog.visualstudio.com/Data/_git/data-dwh-dbt-project?path=/models/staging/core/stg_core__product_service_to_price.sql) | We do directly the denormalisation of the attributes BillingMethodId, InvoicingMethodId and PaymentTypeId at the staging layer. Also, there’s the following rename:
|
||
- BillingMethod = price_base_unit
|
||
- InvoicingMethod = invoicing_trigger
|
||
- PaymentType remains the same |
|
||
| BillingMethod | Whether the price of the ProductServiceToPrice is at Booking level or per number of nights | - Id (BillingMethodId) | Fully integrated, no need to update | Integrated directly into the ProductServiceToPrice staging layer as price_base_unit | |
|
||
| InvoicingMethod | When the service needs to be invoiced, at which moment of time | - Id (InvoicingMethodId) | Fully integrated, no need to update | Integrated directly into the ProductServiceToPrice staging layer as invoicing_trigger | |
|
||
| PaymentType | Whether the price is stated as an Amount or as Percentage | - Id (PaymentTypeId) | Fully integrated, no need to update | Integrated directly into the ProductServiceToPrice staging layer as payment_type | |
|
||
| Protection | Basic information of the Protection Services | - Id (ProtectionId)
|
||
- RequiredProductServices | Integrated in staging, needs further modelisation | | Seems a 1 to 1 relation with ProtectionPlan. If so, I’ll just add everything into a single protection_plan table |
|
||
| ProtectionPlan | Historification in case there’s changes on any Protection | - Id (ProtectionPlanId)
|
||
- ProtectionId
|
||
- StartDate
|
||
- EndDate | Integrated in staging, needs further modelisation | | |
|
||
| ProtectionPlanToPrice | Similar contents as ProductServiceToPrice, but for Protection. In essence, how much it costs to have a dedicated protection (for a given currency, price base unit, invoicing trigger, payment type). Also if it’s a default price or a dedicated one for a given user, in case UserProductBundleId is set | - Id (ProtectionPlanToPriceId)
|
||
- ProtectionPlanId
|
||
- CurrencyId
|
||
- UserProductBundleId
|
||
- BillingMethodId
|
||
- InvoicingMethodId
|
||
- PaymentTypeId
|
||
- StartDate
|
||
- EndDate
|
||
- Amount | Integrated in staging, needs further modelisation | | We should follow a similar strategy as for ProductServiceToPrice
|
||
|
||
Maybe rename internally as ProtectionServiceToPrice? Avoid confusion with ProtectionPlanToCurrency |
|
||
| AppliedProductService | Key table to know “this Booking has these Product Services applied”. Currently WIP in backend side, necessary for Revenue computation and Service usage | - TBD | To be integrated, waiting for backend | TBD | We asked for additional id fields so we can link the information with other main tables easily. Also, see if we can follow an insert only approach to keep the history. |
|
||
| AppliedProtectionService | Similar as AppliedProductService but for Protection. Does not exist yet | - TBD | To be integrated, waiting for backend | TBD | We asked to have this table created so we can have a similar strategy as we will do for AppliedProductService |
|
||
| ProtectionPlanToCurrency | How much we protect per Protection Service and Currency. This contains protections itself, rather than prices for the protections, thus can wait for later. | - Id (ProtectionPlanToCurrencyId)
|
||
- ProtectionPlanId | Integrated in staging, needs further modelisation | | I think I will add a different name to avoid confusions with ProtectionPlanToPrice. |
|
||
| DepositManagement | | | ? | | Deposit management is the nomenclature used for Waivers/Deposits services, but these exist in ProductServices and I’m not sure the following tables have a direct link or are strictly needed for our reporting. |
|
||
| DepositManagementItem | | | ? | | |
|
||
| DepositManagementItemToProtection | | | ? | | |
|
||
| DepositManagementItemToProtectionAmount | | | ? | | |
|
||
| | | | | | | |