data-dwh-dbt-project/models/intermediate/kpis/int_kpis__agg_dates_main_kpis.sql
Oriol Roqué Paniagua 0d7b5ac88a 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

56 lines
1.9 KiB
SQL

{% set dimensions = get_kpi_dimensions_per_model("") %}
{{ config(materialized="table", unique_key=["date", "dimension", "dimension_value"]) }}
with
daily_dim as (
select distinct
ikdd.year,
ikdd.month,
ikdd.day,
ikdd.date,
-- Dimensions --
coalesce(ikd_deals.id_deal, 'UNSET') as id_deal,
coalesce(
ikd_deals.main_billing_country_iso_3_per_deal, 'UNSET'
) as main_billing_country_iso_3_per_deal,
coalesce(
icmas.active_accommodations_per_deal_segmentation, 'UNSET'
) as active_accommodations_per_deal_segmentation,
ikdd.first_day_month,
ikdd.last_day_month,
ikdd.is_end_of_month,
ikdd.is_current_month,
case
when ikdd.is_yesterday or ikdd.is_end_of_month then true else false
end as is_end_of_month_or_yesterday
from {{ ref("int_kpis__dimension_dates") }} as ikdd
left join
{{ ref("int_kpis__dimension_deals") }} as ikd_deals
on ikdd.date >= ikd_deals.effective_deal_start_date_utc
left join
{{ ref("int_kpis__dimension_daily_accommodation") }} as icmas
on ikd_deals.id_deal = icmas.id_deal
and ikdd.date = icmas.date
where (ikdd.is_month_to_date = true or ikdd.is_end_of_month)
)
{% for dimension in dimensions %}
select distinct
year,
month,
day,
date,
{{ dimension.dimension }} as dimension,
{{ dimension.dimension_value }} as dimension_value,
first_day_month,
last_day_month,
is_end_of_month,
is_current_month,
is_end_of_month_or_yesterday
from daily_dim
where {{ dimension.dimension_value }} <> 'UNSET'
{% if not loop.last %}
union all
{% endif %}
{% endfor %}