First step on refactor of kpis:
- Remove relative incremental vs. previous year computation from the source model (`mtd_booking_metrics`, in this case)
- Aggregate the source mtd global metrics models into a single model: `int_mtd_vs_previous_year_metrics` (to enable multi-source weighted metric computation) and compute previous year value and relative increment. Now this logic is encapsulated into a macro `calculate_safe_relative_increment`, easing readability and providing a bit more robustness.
- End-to-end continuity to not break the existing dashboard display in `int_core__mtd_aggregated_metrics`
This is a substep of the global change. All info can be found in the documentation [here](https://www.notion.so/knowyourguest-superhog/Refactoring-Business-KPIs-5deb6aadddb34884ae90339402ac16e3)
Related work items: #18202
This PR implements a denormalized view of Xero invoice and credit notes data.
This is done because this shaped of data will both enable very simple reporting on some accounting reports, as well as easier modeling in some of the KPIs effort.
I also included a tiny change on dates and times in the invoice models.
Related work items: #17550
IMPORTANT: this PR was merged and reverted. The division by 0 error has been fixed in the last commit
Adds the following metrics:
- Guest Revenue
by both visions (global and by deal id)
It creates 2 new models:
- int_mtd_guest_revenue_metrics
- int_monthly_guest_revenue_history_by_deal
the approaches are similar in the sense that we retrieve the information from the int_core__verification_payments and a filter by a PAID status. I checked and the aggregated volumes of the figures correspond to the decimal as what is reported to the guest_payments dashboard (aggregating the information from the currency tab)
Same as last PR, this one does not exposes the data since a refactor of how the code is structured will follow shortly.
Related work items: #18107
Adds the following metrics:
- Guest Revenue
by both visions (global and by deal id)
It creates 2 new models:
- int_core__mtd_guest_revenue_metrics
- int_core__monthly_guest_revenue_history_by_deal
the approaches are similar in the sense that we retrieve the information from the int_core__verification_payments and a filter by a PAID status. I checked and the aggregated volumes of the figures correspond to the decimal as what is reported to the guest_payments dashboard (aggregating the information from the currency tab)
Same as last PR, this one does not exposes the data since a refactor of how the code is structured will follow shortly.
Reverts !2199
Related work items: #18107
Adds the following metrics:
- Guest Revenue
by both visions (global and by deal id)
It creates 2 new models:
- int_core__mtd_guest_revenue_metrics
- int_core__monthly_guest_revenue_history_by_deal
the approaches are similar in the sense that we retrieve the information from the int_core__verification_payments and a filter by a PAID status. I checked and the aggregated volumes of the figures correspond to the decimal as what is reported to the guest_payments dashboard (aggregating the information from the currency tab)
Same as last PR, this one does not exposes the data since a refactor of how the code is structured will follow shortly.
Related work items: #18107
New model for guests satisfaction report, I included columns to check what is the guest paying for that might be helpful for analysis as well
Related work items: #16947
Adds the following metrics:
- Guest Journey with Payment
- Guest Journey Payment Rate
by both visions (global and by deal id)
**Important**: it does not expose these metrics to the dashboard, this will be done after we have feedback from Ben R. on the paid GJ without GJ completeness. Missing steps to make them appear is to adapt `int_core__mtd_aggregated_metrics` and `int_core__monthly_aggregated_metrics_history_by_deal` and the respective reporting counterparts.
It adapts:
- `int_core__mtd_guest_journey_metrics`
- `int_core__monthly_guest_journey_history_by_deal`
the approaches are similar in the sense that we join with `int_core__verification_payments` and filter by a PAID status, that has been defined in the `dbt_project.yml` in a similar manner as we did with cancelled bookings. It can happen that the same verification request has multiple payments (see screenshot), which in this case we keep the first date in which the paid payment happens. The volume is quite low anyway.
code for the screenshot:
```
with pre as (
select
id_verification_request,
count(distinct icvp.id_payment) as total_paid_payments
from intermediate.int_core__verification_payments icvp
where icvp.payment_status = 'Paid'
group by 1
)
select
case when total_paid_payments > 2 then 'more than 2'
when total_paid_payments = 2 then '2'
when total_paid_payments = 1 then '1'
end as payment_volume_category,
count(1) as vr_volume
from pre
group by 1
order by 2 desc
```
I also added a missing reference in `schema.yaml` int about `int_core__mtd_guest_journey_metrics`
Related work items: #18105
This PR creates 2 new models:
- `int_core__monthly_aggregated_metrics_history_by_deal`, which just gathers the information of the previously created models that compute the kpis by deal id.
- `core__monthly_aggregated_metrics_history_by_deal`, effectively a copy from intermediate to reporting
It also includes documentation of these 2 models, differences between these and the `mtd_aggregated_metrics` equivalents and references it to exposures. I took the opportunity to update the documentation of the `core__mtd_aggregated_metrics` now that it's a bit more mature.
This should be the last PR for the first draft of 'by deal' metrics.
Related work items: #17689
Adding accommodation metrics by deal id with the model `int_core__monthly_accommodation_history_by_deal`.
With this PR, we have the full set of batch 1 metrics by deal id completed, although separated in different tables. Aggregation will come in a separated PR.
Similarly as the previous PR, this one it's a mix between the logic of `int_core__mtd_accommodation_metrics` and the logic existing for the `int_core__monthly_X_history_by_deal` . It also adds the tests in schema.
Related work items: #17689
Adding the 6 Guest Journey metrics by deal id by creating the model `int_core__monthly_guest_journey_history_by_deal`
The structure for the deal id detail follows yesterday's approach on bookings, namely `int_core__monthly_booking_history_by_deal`, but considering the metric computation of the guest journey, namely `int_core__mtd_guest_journey_metrics`.
It also adds the dbt tests ensuring that date and id_deal are not null and that the combination of both is unique.
Related work items: #17689
This is a first approach to compute some easy metrics for the "deal" based business kpis. At this stage, it contains the information of bookings (created, checkout, cancelled) per deal and month, including both historic months as well as the current one. This do not contain MTD computation because it's overkill to do a MTD at deal level (+ we have 1k deals, so scalability can become a problem in the future)
Models:
- **int_dates_by_deal**: simple model that reads from **int_dates** and just joins it with **unified_users** to retrieve the deals. It will be used as the 'source of truth' for which deals should be considered in a given month, basically, since the first host associated to a deal is created (not necessarily booked)
- **int_core__monthly_booking_history_by_deal**: it contains the history of bookings per deal id in a monthly basis. It should be easy enough to integrate here, in the future and if needed, B2B macro segmentation.
In terms of performance, comparing the model **int_core__monthly_booking_history_by_deal** and **int_core__mtd_booking_metrics** you'll see that I removed the joined with the **int_dates_xxx** in the CTEs. This is because I want to avoid a double join of date & deal that I tried and I stopped after 5 min running. Since this computation is in a monthly basis - no MTD - it's easy enough to just apply the **int_dates_by_deal** on the last part of the query. With this approach, it runs in 7 seconds.
Related work items: #17689
The bank transactions table coming from Xero has positive amounts for all transactions by default.
Nevertheless, some transactions are receiving and some are sending.
This PR implements sign for transactions amounts throughout the DWH so that aggregations work properly.
I've also left the transaction sign column in some spots since it might be useful for some aggregation wizardry (ie cancel out receiving transactions in resolutions so that counts are more accurate).
Related work items: #17551
