Adding submetrics of guest revenue:
- deposit fees
- checkin cover fees
- waiver payments
all of this adds up to
- guest income
and the revenue is computed by subtracting waivers paid to hosts
Related work items: #18787
This PR exposes the following metrics to the Main KPIs business overview report, for both Global + By Deal view:
- Total Revenue
- Total Revenue per Booking Created
- Total Revenue per Guest Journey Created
- Total Revenue per Deals Booked in Month (does not apply on the by deal view)
- Total Revenue per Listings Booked in Month
- Invoiced Operator Revenue
- Host Resolution Payment Count
- Host Resolution Amount Paid
Keep in mind Global view will be displaying these metrics once this is merged. I also changed a bit the order of the metric display.
Note that Billable Bookings are not included.
I recommend to review by 1) checking the first commit. This is almost the same as the previous abandoned PR that @<Joaquin Ossa> you already checked on Tuesday. I added a second commit, to be checked later, which basically fixes some stupid issues that if one of the source of revenue is null, then total revenue is null. This is specially critical for the view by deal, since most of them do not have revenue from APIs - thus all total revenue figures were null...
Related work items: #18108, #18109, #18110, #18719
Computing and propagating APIs revenue metrics.
I retrieved the revenues linked to Guesty and e-deposits. The sum of those are considered the total API revenue at this stage.
These 3 metrics are available in upper layers (not exposed yet to the report), just to fix the total revenue computation, which now includes APIs revenue
Related work items: #18719
Propagates billable bookings kpis in intermediate. Does not expose any metric to the report.
Changes:
- Retrieval and computation of previous_year and relative_increment for global view (mtd models)
- Retrieval as is for deal view
Related work items: #18111
This PR aims to propagate the invoicing metrics through the DWH. It does not expose them to users, yet.
This PR effectively computes the following metrics, for both the "global" view (MTD) and the "by deal" view (by_deal):
- Invoiced Operator Revenue
- Host Resolution Count of Payments
- Host Resolution Amount Paid
With these 3 new metrics, we're able to combine them with the existing ones to compute:
- Total Revenue
- Total Revenue per Booking Created
- Total Revenue per Guest Journey Created
- Total Revenue per Deal Booked in Month
- Total Revenue per Listings Booked in Month
You'll also note that I've included standalone metrics for booking fees, listing fees, verification fees and waiver payments. This will not be exposed in this batch 2, but based on the conversation with Finance, will clearly make it for batch 3. I just find it easier to add it now, since it's straight forward.
Main changes:
- `int_mtd_vs_previous_year_metrics` now computes all the above mentioned metrics
- `int_monthly_aggregated_metrics_history_by_deal` now computes all the above mentioned metrics, except Total Revenue per Deal Booked in Month since it does not make sense for the deal view. Additionally, I took the opportunity to include the missing metrics from listings (accommodations). The goal is not necessarily to display them, but at least compute it on our side.
Additional changes:
- In `int_xero__mtd_invoicing_metrics` and `int_xero__monthly_invoicing_history_by_deal`, there's a very silly name change to keep the same convention for fees: from `xero_operator_net_fees` to `xero_operator_net_fees_in_gbp`
- I applied additional changes in `int_monthly_aggregated_metrics_history_by_deal` with the goal to keep the same format as we have in `int_mtd_vs_previous_year_metrics`, this meaning:
1 - explicit alias naming (from `gj` to `guest_journeys`)
2 - keep a similar arrangement of metrics, and clearly separate scopes depending on the metric type
3 - Re-apply autoformatting
Related work items: #18108, #18109, #18110
This PR aims to propagate the computation of guest revenue model into the aggregated models.
Changes:
- I changed the logic on `int_mtd_guest_revenue_metrics` since it was still using the old computation of the relative increment within the same model. Basically, I removed it (last part of the query). The rest of changes in this model are just formatting.
- I also applied the formatting in the int_mtd_vs_previous_year_metrics, mainly changing the macro calls from **'**xyz**'** to **"**xyz**"**.
What's new:
- `int_mtd_guest_revenue_metrics` into `int_mtd_vs_previous_year_metrics`, by adding `total_guest_revenue_in_gbp` and `total_guest_payments_in_gbp`. Additionally, with the new logic, for the first time we're able to compute **weighted metrics** coming from different sources. Specifically, it computes the weighted measures per guest journey completed and guest journey with payment.
- Similar behavior on the 'by deal', adding `int_monthly_guest_revenue_history_by_deal` into `int_monthly_aggregated_metrics` and similar computation
This model does not affect the exposing logic still, meaning these metrics won't be exposed in the report. This will come in a separated PR.
Related work items: #18107
Following yesterday's refactor of booking metrics, this PR provides a refactor of already exposed metrics: listings, deals and guest journeys.
-> Data is consistent with values already exposed.
Changes:
- for `int_core__mtd_listing_metrics`, `int_core__mtd_deal_metrics` and `int_core__mtd_guest_journey_metrics`:
1. remove the computation of the previous year metric value and the relative increment (last part of the query)
2. re-apply the formatting
- for `int_mtd_vs_previous_year_metrics`:
1. Reference listings, deals and GJ models
2. Include the metrics for these types in the `plain_kpi_combination` CTE
3. Add the computation of previous year and relative increment using the macro
- for `int_core__mtd_aggregated_metrics`
1. Remove and "hardcode" sources since all metrics now depend exclusively of `int_mtd_vs_previous_year_metrics`
This PR does not alter the exposed metrics in the production report. It does not aim to change the name of the reporting/intermediate models that expose the information, it will be done in a separated PR.
Documentation: https://www.notion.so/knowyourguest-superhog/Refactoring-Business-KPIs-5deb6aadddb34884ae90339402ac16e3
Related work items: #18202
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
