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
- Main purpose is to bring the Bank Transactions table from sync to stg.
- Along the way:
- I created a couple of new generic tests.
- I reviewed docs and tests for a couple of other Xero models that were not in the best shape.
Related work items: #17551
There's a couple of broken tests for Stripe data in production for some `accepted_values` one, but it's just because our test is too strict and doesn't really account for all values.
This PR fixes plus drops a small comment on the funky sources table which won't hurt for future modelers.
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
Adding cancelled bookings metric based on the feedback of the tech team. Mainly, the date of a cancelled booking can be considered as the `updated_date_utc` for those bookings with status cancelled, as it's a terminal state and no additional steps should follow.
I also took the opportunity to update:
- The order on the `int_core__mtd_aggregated_metrics`, so it matches the one in the Notion page for the 1st batch, freeing already the space for the order_by numbers for missing metrics
- Make acronyms of alias in the `main_kpi` subquery in `int_core__mtd_booking_metrics` slightly more clear
- Remove empty line at the end of the file in `int_core__mtd_booking_metrics`
Keep in mind that the cancelled bookings metric will be directly available in the dashboard once this PR is approved and DWH re-runs.
Related work items: #17310
The CTEs that project currency rates backwards have a few mistakes that introduce additional dates in the period where we do have actual, factual rates. This PR fixes the errors that cause this.
Implements the following metrics:
- Guest Journey Created
- Guest Journey Started
- Guest Journey Completed
- Guest Journey Start Rate
- Guest Journey Completion Rate
- Guest Journey Incompletion Rate
A new model, namely int_core__mtd_guest_journey_metrics have been created, that mainly reads from int_core__verification_requests and the estimated start and complete dates logic.
Metrics are integrated into the already existing mtd_aggregated_metrics. Small changes here to allow multi-source via macro.
Finally, increased documentation regarding the aggregated model and added a exposure for the main_kpis dashboard.
I also took the opportunity to include the git ignore of the new package integrated in the previous PR.
To keep in mind: no change on the dashboard applies, the metrics should appear automatically at the moment this PR is merged & production is updated with the changes
Related work items: #17311
- Creates an intermediate rates table that both uses real rates from xe.com and also make some assumptions about future and past dates.
- Also took the chance to place all orphan int models into a `cross` folder.
Related work items: #17212
