counterweight/data-dwh-dbt-project
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
data-dwh-dbt-project/models/intermediate/cross/int_mtd_aggregated_metrics.sql

853 lines
35 KiB
MySQL
Raw Normal View History

Merged PR 2003: Business KPIs first draft This PR aims to provide a first draft for business KPIs, at this stage **quite minimal**. It mostly contains a MTD and Monthly display approach. No dimensions are created. The models created are: - **int_dates_mtd**: mainly it reads from int_dates to retrieve those days needed for a MTD/monthly display - **int_core__mtd_booking_metrics**: it contains the booking metrics, ending in a format of date|value|value last year|increment --> here we could add, in the future, additional metrics from other sources (ex: guest journey, etc) - **int_core__mtd_aggregated_metrics**: it transforms the data coming from the different mtd intermediate sources to be easily displayed in the dashboard. This is a good candidate for macros :) - **core__mtd_aggregated_metrics**: copy-paste of the its int_core version, including a bit of model documentation The dashboard is functional but in another PR. I can show you how it looks like at the moment you are going to check the PR Related work items: #17214
2024-06-11 15:45:57 +00:00
{% set metrics = [
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
{
"order_by": 1,
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"metric": "Total Created Bookings",
"value": "created_bookings",
"previous_year_value": "previous_year_created_bookings",
"relative_increment": "relative_increment_created_bookings",
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"number_format": "integer",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
},
{
"order_by": 2,
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"metric": "Total Check Out Bookings",
"value": "check_out_bookings",
"previous_year_value": "previous_year_check_out_bookings",
"relative_increment": "relative_increment_check_out_bookings",
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"number_format": "integer",
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
},
{
"order_by": 3,
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"metric": "Billable Bookings",
"value": "billable_bookings",
"previous_year_value": "previous_year_billable_bookings",
"relative_increment": "relative_increment_billable_bookings",
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
{
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"order_by": 4,
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"metric": "Billable Check Out Bookings",
"value": "billable_check_out_bookings",
"previous_year_value": "previous_year_billable_check_out_bookings",
"relative_increment": "relative_increment_billable_check_out_bookings",
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"number_format": "integer",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
},
{
"order_by": 5,
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"metric": "Created Bookings (Excl. Cancelled)",
"value": "not_cancelled_created_bookings",
"previous_year_value": "previous_year_not_cancelled_created_bookings",
"relative_increment": "relative_increment_not_cancelled_created_bookings",
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"number_format": "integer",
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
{
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"order_by": 6,
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"metric": "Cancelled Created Bookings",
"value": "cancelled_created_bookings",
"previous_year_value": "previous_year_cancelled_created_bookings",
"relative_increment": "relative_increment_cancelled_created_bookings",
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"number_format": "integer",
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
Merged PR 4425: Reworks Billable Bookings metrics # Description Changes: * On Est. Billable Bookings, keeps previous logic for Old Dash while assuming the first billable service for New Dash * Adds a Billable Check Out Bookings in Check Out bookings, as defined in the requirements. # 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: #27619
2025-02-17 15:59:21 +00:00
{
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"order_by": 7,
"metric": "Check Out Bookings (Excl. Cancelled)",
"value": "not_cancelled_check_out_bookings",
"previous_year_value": "previous_year_not_cancelled_check_out_bookings",
"relative_increment": "relative_increment_not_cancelled_check_out_bookings",
Merged PR 4425: Reworks Billable Bookings metrics # Description Changes: * On Est. Billable Bookings, keeps previous logic for Old Dash while assuming the first billable service for New Dash * Adds a Billable Check Out Bookings in Check Out bookings, as defined in the requirements. # 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: #27619
2025-02-17 15:59:21 +00:00
"number_format": "integer",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4425: Reworks Billable Bookings metrics # Description Changes: * On Est. Billable Bookings, keeps previous logic for Old Dash while assuming the first billable service for New Dash * Adds a Billable Check Out Bookings in Check Out bookings, as defined in the requirements. # 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: #27619
2025-02-17 15:59:21 +00:00
},
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
{
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"order_by": 8,
"metric": "Cancelled Check Out Bookings",
"value": "cancelled_check_out_bookings",
"previous_year_value": "previous_year_cancelled_check_out_bookings",
"relative_increment": "relative_increment_cancelled_check_out_bookings",
Merged PR 2730: Exposing Billable Bookings metric for KPIs # Description Exposes Billable Bookings metric for KPIs, both in the "global+dimension" view and in the "deal" view. Metrics have already been created for a while. Exposing them now after the changes carried out in the model `int_core__booking_charge_events`. Based on the current quality of the data, I opted for "Est. Billable Bookings" to account for the fact that this is an estimation. If you don't feel comfortable with it, let's remove the "Est. ". # 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: #18111
2024-09-04 08:15:37 +00:00
"number_format": "integer",
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2730: Exposing Billable Bookings metric for KPIs # Description Exposes Billable Bookings metric for KPIs, both in the "global+dimension" view and in the "deal" view. Metrics have already been created for a while. Exposing them now after the changes carried out in the model `int_core__booking_charge_events`. Based on the current quality of the data, I opted for "Est. Billable Bookings" to account for the fact that this is an estimation. If you don't feel comfortable with it, let's remove the "Est. ". # 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: #18111
2024-09-04 08:15:37 +00:00
},
{
"order_by": 10,
Merged PR 2068: Adding cancelled bookings metric 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
2024-06-18 14:58:55 +00:00
"metric": "Guest Journey Created",
"value": "created_guest_journeys",
"previous_year_value": "previous_year_created_guest_journeys",
"relative_increment": "relative_increment_created_guest_journeys",
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 11,
Merged PR 2068: Adding cancelled bookings metric 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
2024-06-18 14:58:55 +00:00
"metric": "Guest Journey Started",
"value": "started_guest_journeys",
"previous_year_value": "previous_year_started_guest_journeys",
"relative_increment": "relative_increment_started_guest_journeys",
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 12,
Merged PR 2068: Adding cancelled bookings metric 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
2024-06-18 14:58:55 +00:00
"metric": "Guest Journey Completed",
"value": "completed_guest_journeys",
"previous_year_value": "previous_year_completed_guest_journeys",
"relative_increment": "relative_increment_completed_guest_journeys",
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2068: Adding cancelled bookings metric 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
2024-06-18 14:58:55 +00:00
},
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 13,
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
"metric": "Guest Journey with Payment",
"value": "paid_guest_journeys",
"previous_year_value": "previous_year_paid_guest_journeys",
"relative_increment": "relative_increment_paid_guest_journeys",
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
},
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 20,
Merged PR 4418: New metric - Live Deals # Description Adds new metric - live deals # 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: #27712
2025-02-17 07:48:11 +00:00
"metric": "Live Deals",
"value": "live_deals",
"previous_year_value": "previous_year_live_deals",
"relative_increment": "relative_increment_live_deals",
"number_format": "integer",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Merged PR 4418: New metric - Live Deals # Description Adds new metric - live deals # 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: #27712
2025-02-17 07:48:11 +00:00
},
{
"order_by": 21,
Merged PR 2107: Adds host lifecycle metrics into biz kpis This PR closes the first draft of the first batch of business kpis. Host logic has changed to be applied at deal id level. It's mostly an adapted copy-paste from the accommodation counterpart, specifically: - `int_core__mtd_deal_lifecycle`: computes the historic deal lifecycle. One line for each deal and MTD date. **Important**: _Not all hosts have a deal set. This will need a data quality report for business teams to fix_ - `int_core__mtd_deal_metrics`: computes the aggregation at MTD date level of the metrics per lifecycle state and activity state Additionally, this PR changes: - `int_core__mtd_aggregated_metrics`: it includes the new 3 deal metrics and changes the source of the already existing 3 deal metrics from `mtd_booking_metrics` to the new `mtd_deal_metrics` - `int_core__mtd_booking_metrics`: removes all code needed to compute the remaining deal metrics, speeding it up considerably. After this PR, the mtd models run (locally) at the following speed: - `int_core__mtd_accommodation_lifecycle`: 47 sec - `int_core__mtd_deal_lifecycle`: 3 sec - `int_core__mtd_accommodation_metrics`: 5 sec - `int_core__mtd_deal_metrics`: < 1 sec - `int_core__mtd_booking_metrics`: 8 sec (quite a reduction) - `int_core__mtd_guest_journey_metrics`: 5 sec - `int_core__mtd_aggregated_metrics` and `core__mtd_aggregated_metrics`: < 1 sec Related work items: #17312
2024-06-25 12:20:59 +00:00
"metric": "New Deals",
"value": "new_deals",
"previous_year_value": "previous_year_new_deals",
"relative_increment": "relative_increment_new_deals",
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Merged PR 2107: Adds host lifecycle metrics into biz kpis This PR closes the first draft of the first batch of business kpis. Host logic has changed to be applied at deal id level. It's mostly an adapted copy-paste from the accommodation counterpart, specifically: - `int_core__mtd_deal_lifecycle`: computes the historic deal lifecycle. One line for each deal and MTD date. **Important**: _Not all hosts have a deal set. This will need a data quality report for business teams to fix_ - `int_core__mtd_deal_metrics`: computes the aggregation at MTD date level of the metrics per lifecycle state and activity state Additionally, this PR changes: - `int_core__mtd_aggregated_metrics`: it includes the new 3 deal metrics and changes the source of the already existing 3 deal metrics from `mtd_booking_metrics` to the new `mtd_deal_metrics` - `int_core__mtd_booking_metrics`: removes all code needed to compute the remaining deal metrics, speeding it up considerably. After this PR, the mtd models run (locally) at the following speed: - `int_core__mtd_accommodation_lifecycle`: 47 sec - `int_core__mtd_deal_lifecycle`: 3 sec - `int_core__mtd_accommodation_metrics`: 5 sec - `int_core__mtd_deal_metrics`: < 1 sec - `int_core__mtd_booking_metrics`: 8 sec (quite a reduction) - `int_core__mtd_guest_journey_metrics`: 5 sec - `int_core__mtd_aggregated_metrics` and `core__mtd_aggregated_metrics`: < 1 sec Related work items: #17312
2024-06-25 12:20:59 +00:00
},
{
Merged PR 4418: New metric - Live Deals # Description Adds new metric - live deals # 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: #27712
2025-02-17 07:48:11 +00:00
"order_by": 22,
Merged PR 2107: Adds host lifecycle metrics into biz kpis This PR closes the first draft of the first batch of business kpis. Host logic has changed to be applied at deal id level. It's mostly an adapted copy-paste from the accommodation counterpart, specifically: - `int_core__mtd_deal_lifecycle`: computes the historic deal lifecycle. One line for each deal and MTD date. **Important**: _Not all hosts have a deal set. This will need a data quality report for business teams to fix_ - `int_core__mtd_deal_metrics`: computes the aggregation at MTD date level of the metrics per lifecycle state and activity state Additionally, this PR changes: - `int_core__mtd_aggregated_metrics`: it includes the new 3 deal metrics and changes the source of the already existing 3 deal metrics from `mtd_booking_metrics` to the new `mtd_deal_metrics` - `int_core__mtd_booking_metrics`: removes all code needed to compute the remaining deal metrics, speeding it up considerably. After this PR, the mtd models run (locally) at the following speed: - `int_core__mtd_accommodation_lifecycle`: 47 sec - `int_core__mtd_deal_lifecycle`: 3 sec - `int_core__mtd_accommodation_metrics`: 5 sec - `int_core__mtd_deal_metrics`: < 1 sec - `int_core__mtd_booking_metrics`: 8 sec (quite a reduction) - `int_core__mtd_guest_journey_metrics`: 5 sec - `int_core__mtd_aggregated_metrics` and `core__mtd_aggregated_metrics`: < 1 sec Related work items: #17312
2024-06-25 12:20:59 +00:00
"metric": "Deals Booked in Month",
"value": "deals_booked_in_month",
"previous_year_value": "previous_year_deals_booked_in_month",
"relative_increment": "relative_increment_deals_booked_in_month",
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
{
Merged PR 4418: New metric - Live Deals # Description Adds new metric - live deals # 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: #27712
2025-02-17 07:48:11 +00:00
"order_by": 23,
Merged PR 2107: Adds host lifecycle metrics into biz kpis This PR closes the first draft of the first batch of business kpis. Host logic has changed to be applied at deal id level. It's mostly an adapted copy-paste from the accommodation counterpart, specifically: - `int_core__mtd_deal_lifecycle`: computes the historic deal lifecycle. One line for each deal and MTD date. **Important**: _Not all hosts have a deal set. This will need a data quality report for business teams to fix_ - `int_core__mtd_deal_metrics`: computes the aggregation at MTD date level of the metrics per lifecycle state and activity state Additionally, this PR changes: - `int_core__mtd_aggregated_metrics`: it includes the new 3 deal metrics and changes the source of the already existing 3 deal metrics from `mtd_booking_metrics` to the new `mtd_deal_metrics` - `int_core__mtd_booking_metrics`: removes all code needed to compute the remaining deal metrics, speeding it up considerably. After this PR, the mtd models run (locally) at the following speed: - `int_core__mtd_accommodation_lifecycle`: 47 sec - `int_core__mtd_deal_lifecycle`: 3 sec - `int_core__mtd_accommodation_metrics`: 5 sec - `int_core__mtd_deal_metrics`: < 1 sec - `int_core__mtd_booking_metrics`: 8 sec (quite a reduction) - `int_core__mtd_guest_journey_metrics`: 5 sec - `int_core__mtd_aggregated_metrics` and `core__mtd_aggregated_metrics`: < 1 sec Related work items: #17312
2024-06-25 12:20:59 +00:00
"metric": "Deals Booked in 6 Months",
"value": "deals_booked_in_6_months",
"previous_year_value": "previous_year_deals_booked_in_6_months",
"relative_increment": "relative_increment_deals_booked_in_6_months",
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
{
Merged PR 4418: New metric - Live Deals # Description Adds new metric - live deals # 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: #27712
2025-02-17 07:48:11 +00:00
"order_by": 24,
Merged PR 2107: Adds host lifecycle metrics into biz kpis This PR closes the first draft of the first batch of business kpis. Host logic has changed to be applied at deal id level. It's mostly an adapted copy-paste from the accommodation counterpart, specifically: - `int_core__mtd_deal_lifecycle`: computes the historic deal lifecycle. One line for each deal and MTD date. **Important**: _Not all hosts have a deal set. This will need a data quality report for business teams to fix_ - `int_core__mtd_deal_metrics`: computes the aggregation at MTD date level of the metrics per lifecycle state and activity state Additionally, this PR changes: - `int_core__mtd_aggregated_metrics`: it includes the new 3 deal metrics and changes the source of the already existing 3 deal metrics from `mtd_booking_metrics` to the new `mtd_deal_metrics` - `int_core__mtd_booking_metrics`: removes all code needed to compute the remaining deal metrics, speeding it up considerably. After this PR, the mtd models run (locally) at the following speed: - `int_core__mtd_accommodation_lifecycle`: 47 sec - `int_core__mtd_deal_lifecycle`: 3 sec - `int_core__mtd_accommodation_metrics`: 5 sec - `int_core__mtd_deal_metrics`: < 1 sec - `int_core__mtd_booking_metrics`: 8 sec (quite a reduction) - `int_core__mtd_guest_journey_metrics`: 5 sec - `int_core__mtd_aggregated_metrics` and `core__mtd_aggregated_metrics`: < 1 sec Related work items: #17312
2024-06-25 12:20:59 +00:00
"metric": "Deals Booked in 12 Months",
"value": "deals_booked_in_12_months",
"previous_year_value": "previous_year_deals_booked_in_12_months",
"relative_increment": "relative_increment_deals_booked_in_12_months",
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Merged PR 2107: Adds host lifecycle metrics into biz kpis This PR closes the first draft of the first batch of business kpis. Host logic has changed to be applied at deal id level. It's mostly an adapted copy-paste from the accommodation counterpart, specifically: - `int_core__mtd_deal_lifecycle`: computes the historic deal lifecycle. One line for each deal and MTD date. **Important**: _Not all hosts have a deal set. This will need a data quality report for business teams to fix_ - `int_core__mtd_deal_metrics`: computes the aggregation at MTD date level of the metrics per lifecycle state and activity state Additionally, this PR changes: - `int_core__mtd_aggregated_metrics`: it includes the new 3 deal metrics and changes the source of the already existing 3 deal metrics from `mtd_booking_metrics` to the new `mtd_deal_metrics` - `int_core__mtd_booking_metrics`: removes all code needed to compute the remaining deal metrics, speeding it up considerably. After this PR, the mtd models run (locally) at the following speed: - `int_core__mtd_accommodation_lifecycle`: 47 sec - `int_core__mtd_deal_lifecycle`: 3 sec - `int_core__mtd_accommodation_metrics`: 5 sec - `int_core__mtd_deal_metrics`: < 1 sec - `int_core__mtd_booking_metrics`: 8 sec (quite a reduction) - `int_core__mtd_guest_journey_metrics`: 5 sec - `int_core__mtd_aggregated_metrics` and `core__mtd_aggregated_metrics`: < 1 sec Related work items: #17312
2024-06-25 12:20:59 +00:00
},
{
Merged PR 4418: New metric - Live Deals # Description Adds new metric - live deals # 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: #27712
2025-02-17 07:48:11 +00:00
"order_by": 25,
Merged PR 2107: Adds host lifecycle metrics into biz kpis This PR closes the first draft of the first batch of business kpis. Host logic has changed to be applied at deal id level. It's mostly an adapted copy-paste from the accommodation counterpart, specifically: - `int_core__mtd_deal_lifecycle`: computes the historic deal lifecycle. One line for each deal and MTD date. **Important**: _Not all hosts have a deal set. This will need a data quality report for business teams to fix_ - `int_core__mtd_deal_metrics`: computes the aggregation at MTD date level of the metrics per lifecycle state and activity state Additionally, this PR changes: - `int_core__mtd_aggregated_metrics`: it includes the new 3 deal metrics and changes the source of the already existing 3 deal metrics from `mtd_booking_metrics` to the new `mtd_deal_metrics` - `int_core__mtd_booking_metrics`: removes all code needed to compute the remaining deal metrics, speeding it up considerably. After this PR, the mtd models run (locally) at the following speed: - `int_core__mtd_accommodation_lifecycle`: 47 sec - `int_core__mtd_deal_lifecycle`: 3 sec - `int_core__mtd_accommodation_metrics`: 5 sec - `int_core__mtd_deal_metrics`: < 1 sec - `int_core__mtd_booking_metrics`: 8 sec (quite a reduction) - `int_core__mtd_guest_journey_metrics`: 5 sec - `int_core__mtd_aggregated_metrics` and `core__mtd_aggregated_metrics`: < 1 sec Related work items: #17312
2024-06-25 12:20:59 +00:00
"metric": "Churning Deals",
"value": "churning_deals",
"previous_year_value": "previous_year_churning_deals",
"relative_increment": "relative_increment_churning_deals",
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 30,
Merged PR 2105: Adding listing lifecycle metrics into business KPIs This PR will compute the listing metrics in an aggregated manner to be displayed in the Main KPIs dashboard, specifically: - New Listings - First Time Booked Listings - Churning Listings - It also adapts the computation for the already existing metrics of Listings Booked in X months At code level, it contains the following: - Adds `int_core__mtd_accommodation_metrics`, which computes the aggregation of the lifecycle of listings at date level (unique), being date the corresponding date from `int_dates_mtd` - Changes `int_core__mtd_aggregated_metrics` to take the accommodation metrics from the new model. Those 3 already existing (Listings booked in X month) now read from the new model as well. - Changes `int_core__mtd_booking_metrics` to remove unused computation, making it lighter. Specifically, it removes 1) listing related metrics, since now we have a dedicated model and 2) number of guests booked, since it's not used at all. The resulting values in local are consistent with what is already reported in the staging report. Related work items: #17312
2024-06-25 08:14:23 +00:00
"metric": "New Listings",
"value": "new_listings",
"previous_year_value": "previous_year_new_listings",
"relative_increment": "relative_increment_new_listings",
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2105: Adding listing lifecycle metrics into business KPIs This PR will compute the listing metrics in an aggregated manner to be displayed in the Main KPIs dashboard, specifically: - New Listings - First Time Booked Listings - Churning Listings - It also adapts the computation for the already existing metrics of Listings Booked in X months At code level, it contains the following: - Adds `int_core__mtd_accommodation_metrics`, which computes the aggregation of the lifecycle of listings at date level (unique), being date the corresponding date from `int_dates_mtd` - Changes `int_core__mtd_aggregated_metrics` to take the accommodation metrics from the new model. Those 3 already existing (Listings booked in X month) now read from the new model as well. - Changes `int_core__mtd_booking_metrics` to remove unused computation, making it lighter. Specifically, it removes 1) listing related metrics, since now we have a dedicated model and 2) number of guests booked, since it's not used at all. The resulting values in local are consistent with what is already reported in the staging report. Related work items: #17312
2024-06-25 08:14:23 +00:00
},
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 31,
Merged PR 2105: Adding listing lifecycle metrics into business KPIs This PR will compute the listing metrics in an aggregated manner to be displayed in the Main KPIs dashboard, specifically: - New Listings - First Time Booked Listings - Churning Listings - It also adapts the computation for the already existing metrics of Listings Booked in X months At code level, it contains the following: - Adds `int_core__mtd_accommodation_metrics`, which computes the aggregation of the lifecycle of listings at date level (unique), being date the corresponding date from `int_dates_mtd` - Changes `int_core__mtd_aggregated_metrics` to take the accommodation metrics from the new model. Those 3 already existing (Listings booked in X month) now read from the new model as well. - Changes `int_core__mtd_booking_metrics` to remove unused computation, making it lighter. Specifically, it removes 1) listing related metrics, since now we have a dedicated model and 2) number of guests booked, since it's not used at all. The resulting values in local are consistent with what is already reported in the staging report. Related work items: #17312
2024-06-25 08:14:23 +00:00
"metric": "First Time Booked Listings",
"value": "first_time_booked_listings",
"previous_year_value": "previous_year_first_time_booked_listings",
"relative_increment": "relative_increment_first_time_booked_listings",
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2105: Adding listing lifecycle metrics into business KPIs This PR will compute the listing metrics in an aggregated manner to be displayed in the Main KPIs dashboard, specifically: - New Listings - First Time Booked Listings - Churning Listings - It also adapts the computation for the already existing metrics of Listings Booked in X months At code level, it contains the following: - Adds `int_core__mtd_accommodation_metrics`, which computes the aggregation of the lifecycle of listings at date level (unique), being date the corresponding date from `int_dates_mtd` - Changes `int_core__mtd_aggregated_metrics` to take the accommodation metrics from the new model. Those 3 already existing (Listings booked in X month) now read from the new model as well. - Changes `int_core__mtd_booking_metrics` to remove unused computation, making it lighter. Specifically, it removes 1) listing related metrics, since now we have a dedicated model and 2) number of guests booked, since it's not used at all. The resulting values in local are consistent with what is already reported in the staging report. Related work items: #17312
2024-06-25 08:14:23 +00:00
},
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 32,
Merged PR 2068: Adding cancelled bookings metric 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
2024-06-18 14:58:55 +00:00
"metric": "Listings Booked in Month",
"value": "listings_booked_in_month",
"previous_year_value": "previous_year_listings_booked_in_month",
"relative_increment": "relative_increment_listings_booked_in_month",
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 33,
Merged PR 2068: Adding cancelled bookings metric 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
2024-06-18 14:58:55 +00:00
"metric": "Listings Booked in 6 Months",
"value": "listings_booked_in_6_months",
"previous_year_value": "previous_year_listings_booked_in_6_months",
"relative_increment": "relative_increment_listings_booked_in_6_months",
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 34,
Merged PR 2068: Adding cancelled bookings metric 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
2024-06-18 14:58:55 +00:00
"metric": "Listings Booked in 12 Months",
"value": "listings_booked_in_12_months",
"previous_year_value": "previous_year_listings_booked_in_12_months",
"relative_increment": "relative_increment_listings_booked_in_12_months",
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
Merged PR 2105: Adding listing lifecycle metrics into business KPIs This PR will compute the listing metrics in an aggregated manner to be displayed in the Main KPIs dashboard, specifically: - New Listings - First Time Booked Listings - Churning Listings - It also adapts the computation for the already existing metrics of Listings Booked in X months At code level, it contains the following: - Adds `int_core__mtd_accommodation_metrics`, which computes the aggregation of the lifecycle of listings at date level (unique), being date the corresponding date from `int_dates_mtd` - Changes `int_core__mtd_aggregated_metrics` to take the accommodation metrics from the new model. Those 3 already existing (Listings booked in X month) now read from the new model as well. - Changes `int_core__mtd_booking_metrics` to remove unused computation, making it lighter. Specifically, it removes 1) listing related metrics, since now we have a dedicated model and 2) number of guests booked, since it's not used at all. The resulting values in local are consistent with what is already reported in the staging report. Related work items: #17312
2024-06-25 08:14:23 +00:00
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 35,
Merged PR 2105: Adding listing lifecycle metrics into business KPIs This PR will compute the listing metrics in an aggregated manner to be displayed in the Main KPIs dashboard, specifically: - New Listings - First Time Booked Listings - Churning Listings - It also adapts the computation for the already existing metrics of Listings Booked in X months At code level, it contains the following: - Adds `int_core__mtd_accommodation_metrics`, which computes the aggregation of the lifecycle of listings at date level (unique), being date the corresponding date from `int_dates_mtd` - Changes `int_core__mtd_aggregated_metrics` to take the accommodation metrics from the new model. Those 3 already existing (Listings booked in X month) now read from the new model as well. - Changes `int_core__mtd_booking_metrics` to remove unused computation, making it lighter. Specifically, it removes 1) listing related metrics, since now we have a dedicated model and 2) number of guests booked, since it's not used at all. The resulting values in local are consistent with what is already reported in the staging report. Related work items: #17312
2024-06-25 08:14:23 +00:00
"metric": "Churning Listings",
"value": "churning_listings",
"previous_year_value": "previous_year_churning_listings",
"relative_increment": "relative_increment_churning_listings",
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2105: Adding listing lifecycle metrics into business KPIs This PR will compute the listing metrics in an aggregated manner to be displayed in the Main KPIs dashboard, specifically: - New Listings - First Time Booked Listings - Churning Listings - It also adapts the computation for the already existing metrics of Listings Booked in X months At code level, it contains the following: - Adds `int_core__mtd_accommodation_metrics`, which computes the aggregation of the lifecycle of listings at date level (unique), being date the corresponding date from `int_dates_mtd` - Changes `int_core__mtd_aggregated_metrics` to take the accommodation metrics from the new model. Those 3 already existing (Listings booked in X month) now read from the new model as well. - Changes `int_core__mtd_booking_metrics` to remove unused computation, making it lighter. Specifically, it removes 1) listing related metrics, since now we have a dedicated model and 2) number of guests booked, since it's not used at all. The resulting values in local are consistent with what is already reported in the staging report. Related work items: #17312
2024-06-25 08:14:23 +00:00
},
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
{
"order_by": 40,
"metric": "Host Resolutions Payment Count",
"value": "xero_host_resolution_payment_count",
"previous_year_value": "previous_year_xero_host_resolution_payment_count",
"relative_increment": "relative_increment_xero_host_resolution_payment_count",
"number_format": "integer",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
},
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
{
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
"order_by": 100,
New KPI rates for Main KPIs
2025-01-23 17:14:36 +01:00
"metric": "Revenue Retained Rate",
"value": "revenue_retained_ratio",
"previous_year_value": "previous_year_revenue_retained_ratio",
"relative_increment": "relative_increment_revenue_retained_ratio",
"number_format": "percentage",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
New KPI rates for Main KPIs
2025-01-23 17:14:36 +01:00
},
{
"order_by": 101,
"metric": "Revenue Retained Post-Resolutions Rate",
"value": "revenue_retained_post_resolutions_ratio",
"previous_year_value": "previous_year_revenue_retained_post_resolutions_ratio",
"relative_increment": "relative_increment_revenue_retained_post_resolutions_ratio",
"number_format": "percentage",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
New KPI rates for Main KPIs
2025-01-23 17:14:36 +01:00
},
{
"order_by": 102,
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"metric": "Host Resolutions Payment Count per Created Booking Rate",
changed names
2025-01-24 08:30:05 +01:00
"value": "host_resolution_payment_per_created_booking_ratio",
"previous_year_value": "previous_year_host_resolution_payment_per_created_booking_ratio",
"relative_increment": "relative_increment_host_resolution_payment_per_created_booking_ratio",
New KPI rates for Main KPIs
2025-01-23 17:14:36 +01:00
"number_format": "percentage",
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
New KPI rates for Main KPIs
2025-01-23 17:14:36 +01:00
},
{
"order_by": 110,
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"metric": "Created Booking Cancellation Rate",
"value": "cancelled_created_bookings_rate",
"previous_year_value": "previous_year_cancelled_created_bookings_rate",
"relative_increment": "relative_increment_cancelled_created_bookings_rate",
"number_format": "percentage",
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
},
{
"order_by": 111,
"metric": "Check Out Booking Cancellation Rate",
"value": "cancelled_check_out_bookings_rate",
"previous_year_value": "previous_year_cancelled_check_out_bookings_rate",
"relative_increment": "relative_increment_cancelled_check_out_bookings_rate",
"number_format": "percentage",
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
},
{
"order_by": 120,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"metric": "Guest Journey Start Rate",
"value": "start_rate_guest_journey",
"previous_year_value": "previous_year_start_rate_guest_journey",
"relative_increment": "relative_increment_start_rate_guest_journey",
"number_format": "percentage",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
{
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"order_by": 121,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"metric": "Guest Journey Completion Rate",
"value": "completion_rate_guest_journey",
"previous_year_value": "previous_year_completion_rate_guest_journey",
"relative_increment": "relative_increment_completion_rate_guest_journey",
"number_format": "percentage",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
{
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"order_by": 122,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
"metric": "Guest Journey Incompletion Rate",
"value": "incompletion_rate_guest_journey",
"previous_year_value": "previous_year_incompletion_rate_guest_journey",
"relative_increment": "relative_increment_incompletion_rate_guest_journey",
"number_format": "percentage",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
},
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
{
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"order_by": 123,
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
"metric": "Guest Journey Payment Rate",
"value": "payment_rate_guest_journey",
"previous_year_value": "previous_year_payment_rate_guest_journey",
"relative_increment": "relative_increment_payment_rate_guest_journey",
"number_format": "percentage",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
},
Merged PR 3272: Expose Churn Rates into Main KPIs # Description Exposes Churn Rates into Main KPIs, specifically Revenue Churn Rate, Bookings Churn Rate and Listings Churn Rate. This is based on the average approach. Additionally, it adds these 3 metrics in the kpis_additive_metrics_per_dimension_are_consistent test. Additionally, it removes from int_mtd_vs_previous_year_metrics the computation of the additive Churn Rates. The removal of further unused code will be handled in a separated PR. # 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. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22691
2024-10-22 08:08:03 +00:00
{
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"order_by": 130,
Merged PR 3272: Expose Churn Rates into Main KPIs # Description Exposes Churn Rates into Main KPIs, specifically Revenue Churn Rate, Bookings Churn Rate and Listings Churn Rate. This is based on the average approach. Additionally, it adds these 3 metrics in the kpis_additive_metrics_per_dimension_are_consistent test. Additionally, it removes from int_mtd_vs_previous_year_metrics the computation of the additive Churn Rates. The removal of further unused code will be handled in a separated PR. # 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. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22691
2024-10-22 08:08:03 +00:00
"metric": "Revenue Churn Rate",
"value": "total_revenue_churn_average_contribution",
"previous_year_value": "previous_year_total_revenue_churn_average_contribution",
"relative_increment": "relative_increment_total_revenue_churn_average_contribution",
"number_format": "percentage",
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "ONGOING_MONTH",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Merged PR 3272: Expose Churn Rates into Main KPIs # Description Exposes Churn Rates into Main KPIs, specifically Revenue Churn Rate, Bookings Churn Rate and Listings Churn Rate. This is based on the average approach. Additionally, it adds these 3 metrics in the kpis_additive_metrics_per_dimension_are_consistent test. Additionally, it removes from int_mtd_vs_previous_year_metrics the computation of the additive Churn Rates. The removal of further unused code will be handled in a separated PR. # 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. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22691
2024-10-22 08:08:03 +00:00
},
{
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"order_by": 131,
Merged PR 3272: Expose Churn Rates into Main KPIs # Description Exposes Churn Rates into Main KPIs, specifically Revenue Churn Rate, Bookings Churn Rate and Listings Churn Rate. This is based on the average approach. Additionally, it adds these 3 metrics in the kpis_additive_metrics_per_dimension_are_consistent test. Additionally, it removes from int_mtd_vs_previous_year_metrics the computation of the additive Churn Rates. The removal of further unused code will be handled in a separated PR. # 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. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22691
2024-10-22 08:08:03 +00:00
"metric": "Bookings Churn Rate",
"value": "created_bookings_churn_average_contribution",
"previous_year_value": "previous_year_created_bookings_churn_average_contribution",
"relative_increment": "relative_increment_created_bookings_churn_average_contribution",
"number_format": "percentage",
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "ONGOING_MONTH",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Merged PR 3272: Expose Churn Rates into Main KPIs # Description Exposes Churn Rates into Main KPIs, specifically Revenue Churn Rate, Bookings Churn Rate and Listings Churn Rate. This is based on the average approach. Additionally, it adds these 3 metrics in the kpis_additive_metrics_per_dimension_are_consistent test. Additionally, it removes from int_mtd_vs_previous_year_metrics the computation of the additive Churn Rates. The removal of further unused code will be handled in a separated PR. # 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. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22691
2024-10-22 08:08:03 +00:00
},
{
Merged PR 4309: Cancelled Bookings KPIs rework # Description Exposes new metrics: * Created Bookings (Excl. Cancelled) * Cancelled Created Bookings * Check Out Bookings (Excl. Cancelled) * Cancelled Check Out Bookings Re-naming of existing metrics: * Created Bookings -> Total Created Bookings * Checkout Bookings -> Total Check Out Bookings Removes exposure of previous Cancelled Bookings. In the monthly by deal model, it's hardcoded still - need to change PBI to remove safely. This will be done later on once we remove the Cancelled Bookings models. Adapts the existing tests on KPIs to accommodate for the changes by including new metrics. Also, I've set the detector to 5 (from 8) since it's been a while this has not triggered thus might be worth the effort to have more detection capabilities. # 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: #24637
2025-02-06 15:12:35 +00:00
"order_by": 132,
Merged PR 3272: Expose Churn Rates into Main KPIs # Description Exposes Churn Rates into Main KPIs, specifically Revenue Churn Rate, Bookings Churn Rate and Listings Churn Rate. This is based on the average approach. Additionally, it adds these 3 metrics in the kpis_additive_metrics_per_dimension_are_consistent test. Additionally, it removes from int_mtd_vs_previous_year_metrics the computation of the additive Churn Rates. The removal of further unused code will be handled in a separated PR. # 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. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22691
2024-10-22 08:08:03 +00:00
"metric": "Listings Churn Rate",
"value": "listings_booked_in_month_churn_average_contribution",
"previous_year_value": "previous_year_listings_booked_in_month_churn_average_contribution",
"relative_increment": "relative_increment_listings_booked_in_month_churn_average_contribution",
"number_format": "percentage",
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "ONGOING_MONTH",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Merged PR 3272: Expose Churn Rates into Main KPIs # Description Exposes Churn Rates into Main KPIs, specifically Revenue Churn Rate, Bookings Churn Rate and Listings Churn Rate. This is based on the average approach. Additionally, it adds these 3 metrics in the kpis_additive_metrics_per_dimension_are_consistent test. Additionally, it removes from int_mtd_vs_previous_year_metrics the computation of the additive Churn Rates. The removal of further unused code will be handled in a separated PR. # 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. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22691
2024-10-22 08:08:03 +00:00
},
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
{
"order_by": 200,
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"metric": "Total Revenue",
"value": "total_revenue_in_gbp",
"previous_year_value": "previous_year_total_revenue_in_gbp",
"relative_increment": "relative_increment_total_revenue_in_gbp",
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
},
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
{
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
"order_by": 201,
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with this. # 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
"metric": "Revenue Retained",
"value": "revenue_retained_in_gbp",
"previous_year_value": "previous_year_revenue_retained_in_gbp",
"relative_increment": "relative_increment_revenue_retained_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with this. # 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
},
{
"order_by": 202,
Merged PR 4020: Expose new KPIs # Description Exposes 2 New KPIs on Revenue Retained. Work was already done, I just removed the temporary filter and adapted the name of the metric. # Checklist - [ ] The edited models and dependants run properly with production data. - [ ] The edited models are sufficiently documented. - [ ] The edited models contain PK tests, and I've ran and passed them. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] I've picked the right materialization for the affected models. # Other - [ ] Check if a full-refresh is required after this PR is merged. Expose new KPIs Related work items: #25804
2025-01-10 10:07:00 +00:00
"metric": "Revenue Retained Post-Resolutions",
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with this. # 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
"value": "revenue_retained_post_resolutions_in_gbp",
"previous_year_value": "previous_year_revenue_retained_post_resolutions_in_gbp",
"relative_increment": "relative_increment_revenue_retained_post_resolutions_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with this. # 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
},
Added expected_mrr to int_mtd_aggregated_metrics
2025-01-16 15:32:32 +01:00
{
"order_by": 203,
created new model to get all mrr metrics
2025-01-28 12:26:53 +01:00
"metric": "Expected Onboarding MRR per New Deal",
"value": "expected_mrr_per_deal",
"previous_year_value": "previous_year_expected_mrr_per_deal",
"relative_increment": "relative_increment_expected_mrr_per_deal",
New expected MRR metric
2025-01-27 18:26:19 +01:00
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "ONGOING_MONTH",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
New expected MRR metric
2025-01-27 18:26:19 +01:00
},
{
"order_by": 204,
"metric": "Expected Onboarding MRR",
Added expected_mrr to int_mtd_aggregated_metrics
2025-01-16 15:32:32 +01:00
"value": "expected_mrr",
"previous_year_value": "previous_year_expected_mrr",
"relative_increment": "relative_increment_expected_mrr",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "ONGOING_MONTH",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Added expected_mrr to int_mtd_aggregated_metrics
2025-01-16 15:32:32 +01:00
},
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with this. # 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
{
"order_by": 211,
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"metric": "Total Revenue per Booking Created",
"value": "total_revenue_per_created_booking",
"previous_year_value": "previous_year_total_revenue_per_created_booking",
"relative_increment": "relative_increment_total_revenue_per_created_booking",
Financial rate metrics
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
},
{
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with this. # 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
"order_by": 212,
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"metric": "Total Revenue per Guest Journey Created",
"value": "total_revenue_per_created_guest_journey",
"previous_year_value": "previous_year_total_revenue_per_created_guest_journey",
"relative_increment": "relative_increment_total_revenue_per_created_guest_journey",
Financial rate metrics
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
},
{
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with this. # 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
"order_by": 213,
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"metric": "Total Revenue per Deals Booked in Month",
"value": "total_revenue_per_deals_booked_in_month",
"previous_year_value": "previous_year_total_revenue_per_deals_booked_in_month",
"relative_increment": "relative_increment_total_revenue_per_deals_booked_in_month",
Financial rate metrics
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
},
{
Merged PR 3906: Adds 2 new retained income metrics # Description It adds 2 new metrics in Main KPIs, both for Global/per Dimension and By Deal. If merged, metrics will NOT appear automatically in the Global/per Dimension nor in the By Deal. These two new metrics are: * Income Retained: Total Revenue - Waiver Paid Back to Host * Income Retained Post Resolutions: Total Revenue - Waiver Paid Back to Host - Host Resolutions Amount Paid Why these are important: ![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image.png) Even though we grow considerably in terms of Revenue, the gap of Waivers that we pay back to host is also increasing. Thus the "real" increment is actually lower. However, what I find more interesting is the heavy decrease in Income Retained Post Resolutions. Here's the Year-by-Year comparison: ![image (2).png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/image%20%282%29.png) In November 2024, we're back to the figures of 2023 (-0.4%) and this should be alarming considering we're growing in Total Revenue by 27% and in Retained Income by 41% vs. Nov 23. In terms of business impact, I'd opt for having these 2 metrics computed as these capture a reality that otherwise we keep hidden. Happy to discuss renames and how/if we move forward with this. # 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. Attached working excel with the extraction [20241227_retained_revenue_global.xlsx](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/3906/attachments/20241227_retained_revenue_global.xlsx) Related work items: #25804
2024-12-31 12:10:12 +00:00
"order_by": 214,
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"metric": "Total Revenue per Listings Booked in Month",
"value": "total_revenue_per_listings_booked_in_month",
"previous_year_value": "previous_year_total_revenue_per_listings_booked_in_month",
"relative_increment": "relative_increment_total_revenue_per_listings_booked_in_month",
Financial rate metrics
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
},
{
"order_by": 220,
"metric": "Invoiced Operator Revenue",
"value": "xero_operator_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_operator_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_operator_net_fees_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
},
Merged PR 4757: Creates a Total Booking Fees metric (Old dash + New dash) # Description Main Changes: * Computes the total booking fees in `int_kpis__metric_daily_invoiced_revenue` * Propagates within KPIs, including schema and tests * Propagates within cross in both "by deal" and "by dimension/global" * Propagates to main kpis tests Small fix: * In `int_mtd_vs_previous_year_metrics`, manual formatting because sqlfmt is broken on this model... # 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: #28560
2025-03-20 13:45:44 +00:00
{
"order_by": 224,
"metric": "Invoiced Total Booking Fees Revenue",
"value": "xero_booking_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_booking_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_booking_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4757: Creates a Total Booking Fees metric (Old dash + New dash) # Description Main Changes: * Computes the total booking fees in `int_kpis__metric_daily_invoiced_revenue` * Propagates within KPIs, including schema and tests * Propagates within cross in both "by deal" and "by dimension/global" * Propagates to main kpis tests Small fix: * In `int_mtd_vs_previous_year_metrics`, manual formatting because sqlfmt is broken on this model... # 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: #28560
2025-03-20 13:45:44 +00:00
},
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
{
"order_by": 225,
Merged PR 4727: Bookings fees are now Old Dashboard Booking Fees in Main KPIs # Description Booking fees is widely used with different meanings, for old dash, for new dash, for both, etc. This is painful. First step to align on a proper naming is ensure that what we report in Main KPIs is clearly stated, which in this case, Booking Fees are now called Old Dashboard Booking Fees. Changes: * Modify `stg_seed__accounting_aggregations` seed to rename Booking Fees to Old Dashboard Booking Fees. This is for us to clarify. This is only applied for KPIs compute. I also added an empty space that I mistakenly forgot in the past for `financial_l3_aggregation`. * Modify KPIs source, i.e., `int_kpis__metric_daily_invoiced_revenue`. Here I forcefully modify the name of the field to `xero_old_dashboard_booking_net_fees_in_gbp`. * Propagate changes of downstream usages of `xero_booking_net_fees_in_gbp` to `xero_old_dashboard_booking_net_fees_in_gbp`. This affects all models, including the reporting model. On this one we still have both names to avoid breaking it. I will need to modify the data glossary in PBI anyway so I'll do this change as well. * Modify displayed metric name from Booking Fees Revenue to Old Dashboard Booking Fees Revenue. * Modify schema so it reflects the proper names, descriptions, and tests. * Ensure outlier and completion tests still work after this change. I confirm the field `xero_booking_net_fees_in_gbp` does not exist anymore in the rest of DWH after these changes, except for the abovementioned comment on the reporting line. # 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: #28560
2025-03-18 14:55:32 +00:00
"metric": "Invoiced Old Dashboard Booking Fees Revenue",
"value": "xero_old_dashboard_booking_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_old_dashboard_booking_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_old_dashboard_booking_net_fees_in_gbp",
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
},
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
{
"order_by": 226,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Invoiced Listing Fees Revenue",
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
"value": "xero_listing_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_listing_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_listing_net_fees_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
},
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
{
"order_by": 227,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Invoiced Verification Fees Revenue",
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
"value": "xero_verification_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_verification_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_verification_net_fees_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
},
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
{
Merged PR 4118: New Dash services Invoiced Revenue # Description Adds new metrics on Revenue for New Dash services: invoiced_revenue.xero_basic_protection_net_fees_in_gbp, invoiced_revenue.xero_waiver_pro_net_fees_in_gbp, invoiced_revenue.xero_id_verification_net_fees_in_gbp, invoiced_revenue.xero_protection_plus_net_fees_in_gbp, invoiced_revenue.xero_screening_plus_net_fees_in_gbp, invoiced_revenue.xero_sex_offenders_check_net_fees_in_gbp, invoiced_revenue.xero_protection_pro_net_fees_in_gbp Note that it does not add Basic Screening. This is because so far this is a free service, even though the kpis models already consider such a possibility. First data appears for December so this will be available starting 1st February # 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. New Dash services Invoiced Revenue Related work items: #26680
2025-01-20 16:23:20 +00:00
"order_by": 231,
"metric": "Invoiced Screening Plus Revenue",
"value": "xero_screening_plus_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_screening_plus_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_screening_plus_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4118: New Dash services Invoiced Revenue # Description Adds new metrics on Revenue for New Dash services: invoiced_revenue.xero_basic_protection_net_fees_in_gbp, invoiced_revenue.xero_waiver_pro_net_fees_in_gbp, invoiced_revenue.xero_id_verification_net_fees_in_gbp, invoiced_revenue.xero_protection_plus_net_fees_in_gbp, invoiced_revenue.xero_screening_plus_net_fees_in_gbp, invoiced_revenue.xero_sex_offenders_check_net_fees_in_gbp, invoiced_revenue.xero_protection_pro_net_fees_in_gbp Note that it does not add Basic Screening. This is because so far this is a free service, even though the kpis models already consider such a possibility. First data appears for December so this will be available starting 1st February # 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. New Dash services Invoiced Revenue Related work items: #26680
2025-01-20 16:23:20 +00:00
},
{
"order_by": 232,
"metric": "Invoiced ID Verification Revenue",
"value": "xero_id_verification_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_id_verification_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_id_verification_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4118: New Dash services Invoiced Revenue # Description Adds new metrics on Revenue for New Dash services: invoiced_revenue.xero_basic_protection_net_fees_in_gbp, invoiced_revenue.xero_waiver_pro_net_fees_in_gbp, invoiced_revenue.xero_id_verification_net_fees_in_gbp, invoiced_revenue.xero_protection_plus_net_fees_in_gbp, invoiced_revenue.xero_screening_plus_net_fees_in_gbp, invoiced_revenue.xero_sex_offenders_check_net_fees_in_gbp, invoiced_revenue.xero_protection_pro_net_fees_in_gbp Note that it does not add Basic Screening. This is because so far this is a free service, even though the kpis models already consider such a possibility. First data appears for December so this will be available starting 1st February # 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. New Dash services Invoiced Revenue Related work items: #26680
2025-01-20 16:23:20 +00:00
},
{
"order_by": 233,
"metric": "Invoiced Sex Offenders Check Revenue",
"value": "xero_sex_offenders_check_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_sex_offenders_check_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_sex_offenders_check_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4118: New Dash services Invoiced Revenue # Description Adds new metrics on Revenue for New Dash services: invoiced_revenue.xero_basic_protection_net_fees_in_gbp, invoiced_revenue.xero_waiver_pro_net_fees_in_gbp, invoiced_revenue.xero_id_verification_net_fees_in_gbp, invoiced_revenue.xero_protection_plus_net_fees_in_gbp, invoiced_revenue.xero_screening_plus_net_fees_in_gbp, invoiced_revenue.xero_sex_offenders_check_net_fees_in_gbp, invoiced_revenue.xero_protection_pro_net_fees_in_gbp Note that it does not add Basic Screening. This is because so far this is a free service, even though the kpis models already consider such a possibility. First data appears for December so this will be available starting 1st February # 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. New Dash services Invoiced Revenue Related work items: #26680
2025-01-20 16:23:20 +00:00
},
{
"order_by": 234,
"metric": "Invoiced Waiver Pro Revenue",
"value": "xero_waiver_pro_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_waiver_pro_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_waiver_pro_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4118: New Dash services Invoiced Revenue # Description Adds new metrics on Revenue for New Dash services: invoiced_revenue.xero_basic_protection_net_fees_in_gbp, invoiced_revenue.xero_waiver_pro_net_fees_in_gbp, invoiced_revenue.xero_id_verification_net_fees_in_gbp, invoiced_revenue.xero_protection_plus_net_fees_in_gbp, invoiced_revenue.xero_screening_plus_net_fees_in_gbp, invoiced_revenue.xero_sex_offenders_check_net_fees_in_gbp, invoiced_revenue.xero_protection_pro_net_fees_in_gbp Note that it does not add Basic Screening. This is because so far this is a free service, even though the kpis models already consider such a possibility. First data appears for December so this will be available starting 1st February # 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. New Dash services Invoiced Revenue Related work items: #26680
2025-01-20 16:23:20 +00:00
},
{
"order_by": 235,
"metric": "Invoiced Basic Protection Revenue",
"value": "xero_basic_protection_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_basic_protection_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_basic_protection_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4118: New Dash services Invoiced Revenue # Description Adds new metrics on Revenue for New Dash services: invoiced_revenue.xero_basic_protection_net_fees_in_gbp, invoiced_revenue.xero_waiver_pro_net_fees_in_gbp, invoiced_revenue.xero_id_verification_net_fees_in_gbp, invoiced_revenue.xero_protection_plus_net_fees_in_gbp, invoiced_revenue.xero_screening_plus_net_fees_in_gbp, invoiced_revenue.xero_sex_offenders_check_net_fees_in_gbp, invoiced_revenue.xero_protection_pro_net_fees_in_gbp Note that it does not add Basic Screening. This is because so far this is a free service, even though the kpis models already consider such a possibility. First data appears for December so this will be available starting 1st February # 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. New Dash services Invoiced Revenue Related work items: #26680
2025-01-20 16:23:20 +00:00
},
{
"order_by": 236,
"metric": "Invoiced Protection Plus Revenue",
"value": "xero_protection_plus_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_protection_plus_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_protection_plus_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4118: New Dash services Invoiced Revenue # Description Adds new metrics on Revenue for New Dash services: invoiced_revenue.xero_basic_protection_net_fees_in_gbp, invoiced_revenue.xero_waiver_pro_net_fees_in_gbp, invoiced_revenue.xero_id_verification_net_fees_in_gbp, invoiced_revenue.xero_protection_plus_net_fees_in_gbp, invoiced_revenue.xero_screening_plus_net_fees_in_gbp, invoiced_revenue.xero_sex_offenders_check_net_fees_in_gbp, invoiced_revenue.xero_protection_pro_net_fees_in_gbp Note that it does not add Basic Screening. This is because so far this is a free service, even though the kpis models already consider such a possibility. First data appears for December so this will be available starting 1st February # 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. New Dash services Invoiced Revenue Related work items: #26680
2025-01-20 16:23:20 +00:00
},
{
"order_by": 237,
"metric": "Invoiced Protection Pro Revenue",
"value": "xero_protection_pro_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_protection_pro_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_protection_pro_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 4118: New Dash services Invoiced Revenue # Description Adds new metrics on Revenue for New Dash services: invoiced_revenue.xero_basic_protection_net_fees_in_gbp, invoiced_revenue.xero_waiver_pro_net_fees_in_gbp, invoiced_revenue.xero_id_verification_net_fees_in_gbp, invoiced_revenue.xero_protection_plus_net_fees_in_gbp, invoiced_revenue.xero_screening_plus_net_fees_in_gbp, invoiced_revenue.xero_sex_offenders_check_net_fees_in_gbp, invoiced_revenue.xero_protection_pro_net_fees_in_gbp Note that it does not add Basic Screening. This is because so far this is a free service, even though the kpis models already consider such a possibility. First data appears for December so this will be available starting 1st February # 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. New Dash services Invoiced Revenue Related work items: #26680
2025-01-20 16:23:20 +00:00
},
{
"order_by": 240,
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"metric": "Invoiced APIs Revenue",
"value": "xero_apis_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_apis_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_apis_net_fees_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
},
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
{
Merged PR 4118: New Dash services Invoiced Revenue # Description Adds new metrics on Revenue for New Dash services: invoiced_revenue.xero_basic_protection_net_fees_in_gbp, invoiced_revenue.xero_waiver_pro_net_fees_in_gbp, invoiced_revenue.xero_id_verification_net_fees_in_gbp, invoiced_revenue.xero_protection_plus_net_fees_in_gbp, invoiced_revenue.xero_screening_plus_net_fees_in_gbp, invoiced_revenue.xero_sex_offenders_check_net_fees_in_gbp, invoiced_revenue.xero_protection_pro_net_fees_in_gbp Note that it does not add Basic Screening. This is because so far this is a free service, even though the kpis models already consider such a possibility. First data appears for December so this will be available starting 1st February # 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. New Dash services Invoiced Revenue Related work items: #26680
2025-01-20 16:23:20 +00:00
"order_by": 245,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Invoiced Athena Revenue",
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
"value": "xero_guesty_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_guesty_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_guesty_net_fees_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
},
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
{
Merged PR 4118: New Dash services Invoiced Revenue # Description Adds new metrics on Revenue for New Dash services: invoiced_revenue.xero_basic_protection_net_fees_in_gbp, invoiced_revenue.xero_waiver_pro_net_fees_in_gbp, invoiced_revenue.xero_id_verification_net_fees_in_gbp, invoiced_revenue.xero_protection_plus_net_fees_in_gbp, invoiced_revenue.xero_screening_plus_net_fees_in_gbp, invoiced_revenue.xero_sex_offenders_check_net_fees_in_gbp, invoiced_revenue.xero_protection_pro_net_fees_in_gbp Note that it does not add Basic Screening. This is because so far this is a free service, even though the kpis models already consider such a possibility. First data appears for December so this will be available starting 1st February # 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. New Dash services Invoiced Revenue Related work items: #26680
2025-01-20 16:23:20 +00:00
"order_by": 246,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Invoiced E-Deposit Revenue",
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
"value": "xero_e_deposit_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_e_deposit_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_e_deposit_net_fees_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
New API invoices
2025-04-16 14:27:23 +02:00
"display_exclusion": "INVOICING",
"include_in_account_reporting": false,
},
{
"order_by": 247,
"metric": "Invoiced Check In Hero API Revenue",
"value": "xero_check_in_hero_api_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_check_in_hero_api_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_check_in_hero_api_net_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
"display_exclusion": "INVOICING",
"include_in_account_reporting": false,
},
{
"order_by": 248,
Addressed comments
2025-04-16 16:18:14 +02:00
"metric": "Invoiced Screen & Protect Revenue",
"value": "xero_screen_and_protect_net_fees_in_gbp",
"previous_year_value": "previous_year_xero_screen_and_protect_net_fees_in_gbp",
"relative_increment": "relative_increment_xero_screen_and_protect_net_fees_in_gbp",
New API invoices
2025-04-16 14:27:23 +02:00
"number_format": "currency_gbp",
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": false,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
},
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
{
"order_by": 250,
Merged PR 2264: Remove (GBP) from metric name Remove (GBP) from metric name Related work items: #18107
2024-07-10 16:10:07 +00:00
"metric": "Guest Revenue",
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22688
2024-10-10 13:46:59 +00:00
"value": "total_guest_payments_in_gbp",
"previous_year_value": "previous_year_total_guest_payments_in_gbp",
"relative_increment": "relative_increment_total_guest_payments_in_gbp",
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
},
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 251,
Merged PR 2264: Remove (GBP) from metric name Remove (GBP) from metric name Related work items: #18107
2024-07-10 16:10:07 +00:00
"metric": "Guest Revenue per Guest Journey Completed",
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22688
2024-10-10 13:46:59 +00:00
"value": "guest_payments_per_completed_guest_journey",
"previous_year_value": "previous_year_guest_payments_per_completed_guest_journey",
"relative_increment": "relative_increment_guest_payments_per_completed_guest_journey",
Financial rate metrics
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2257: Expose guest revenue and guest journey payment metrics This PR aims to expose the new metrics to the business KPIs report. The new metrics exposed are, for the global and the by deal view: - Guest Revenue - Guest Revenue per Guest Journey Completed - Guest Revenue per Guest Journey with Payment - Guest Payments - Guest Payments per Guest Journey Completed - Guest Payments per Guest Journey with Payment - Guest Journey with Payment - Guest Journey Payment Rate Changes: - Silly change on the naming in the by deal view of `payment_rate_guest_journey` to be consistent with the global view. - Silly change that I miss some GJ payment metric for the view by deal id. - Added a new number format called `currency_gbp` - only for monetary metrics, available in the schema files - Usual procedure to publish metrics: for global metrics, add them in the `int_mtd_aggregated_metrics`. I also changed the order of display. - **Important**: to avoid displaying revenue figures until Xero invoicing is handled, I created a macro called `is_date_before_previous_month` that is called in the reporting equivalent models: `mtd_aggregated_metrics` in the where section and in the `monthly_aggregated_metrics_history_by_deal` as a case-when. This should allow to expose all new metrics, and enable the publishing of a new update of the business kpis! Related work items: #18107
2024-07-10 14:17:05 +00:00
},
{
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"order_by": 252,
Merged PR 2264: Remove (GBP) from metric name Remove (GBP) from metric name Related work items: #18107
2024-07-10 16:10:07 +00:00
"metric": "Guest Revenue per Guest Journey with Payment",
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22688
2024-10-10 13:46:59 +00:00
"value": "guest_payments_per_paid_guest_journey",
"previous_year_value": "previous_year_guest_payments_per_paid_guest_journey",
"relative_increment": "relative_increment_guest_payments_per_paid_guest_journey",
Financial rate metrics
2024-09-20 14:53:43 +02:00
"number_format": "converted_metric_currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
},
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
{
"order_by": 260,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Deposit Fees Revenue",
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
"value": "deposit_fees_in_gbp",
"previous_year_value": "previous_year_deposit_fees_in_gbp",
"relative_increment": "relative_increment_deposit_fees_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
},
{
"order_by": 262,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Waiver Revenue",
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
"value": "waiver_payments_in_gbp",
"previous_year_value": "previous_year_waiver_payments_in_gbp",
"relative_increment": "relative_increment_waiver_payments_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
},
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
{
"order_by": 263,
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"metric": "Damage Waiver Payouts",
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
"value": "xero_waiver_paid_back_to_host_in_gbp",
"previous_year_value": "previous_year_xero_waiver_paid_back_to_host_in_gbp",
"relative_increment": "relative_increment_xero_waiver_paid_back_to_host_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
},
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
{
"order_by": 264,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Waiver Retained",
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
"value": "waiver_net_fees_in_gbp",
"previous_year_value": "previous_year_waiver_net_fees_in_gbp",
"relative_increment": "relative_increment_waiver_net_fees_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "INVOICING",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
},
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
{
"order_by": 265,
Merged PR 3124: 1/3 - Revenue renaming Main KPIs - MTD scope # Description Adapts revenue figures in Main KPIs - MTD scope or global view. This includes MTD, Monthly Overview, Global Evolution over Time, Detail by Category. In essence, everything that is not by deal. The changes are mainly 2: * Remove the line that deducts the `Waiver Amount Paid Back to Hosts` in all metrics except the `Waiver Net Fees`. This effectively means that the previous `Guest Revenue` = `Guest Payments`, thus I dropped all 3 `Guest Payments` metrics. * Do a renaming at metric display level, but not in the code. This means that I remove the computation of `guest_revenue_in_gbp` for instance and keep `guest_payments_in_gbp`, and apply the renaming later on, since the modelisation already accounts for defining metric names differently from those of the fields. For the rest of metrics, I revised all metrics name and did changes based on the [whiteboard](https://whiteboard.office.com/me/whiteboards/p/c3BvOmh0dHBzOi8vZ3VhcmRob2ctbXkuc2hhcmVwb2ludC5jb20vcGVyc29uYWwvcGFibG9fbWFydGluX3N1cGVyaG9nX2NvbQ%3d%3d/b!T2D3opQuBECSDnhuFZrUacFu3TxvSvdIsnI4Dxsh2IuaB1AigbciRqkqte61I4wz/01H5SI4J4L7HTPJGUT7JGYKTOSQYYWACXU). I also changed the dedicated data tests in Main KPIs to ensure it's working. I also changed the exclusion logic in reporting based on the name of the metric to not display metrics that depend on the invoicing cycle unless it's 2 months ago or before. To keep in mind: * Merging this will automatically display the new figures/naming in production. Might be wise to communicate to stakeholders since some key metrics (namely, Guest Revenue / Total Revenue) will change the meaning. * We also need to do these changes in the metrics by deal part of the computation. I'd do first the removal of these fields in the PBI report (and take the opportunity to change the Data Catalogue) and then do the PR in DWH to change the logic. Before that though let's check that the names included in this PR are the correct ones :) # Checklist - [X] The edited models and dependants run properly with production data. - [NA] The edited models are sufficiently documented. - [X] The edited models contain PK tests, and I've ran and passed them. - [NA] I have checked for DRY opportunities with other models and docs. - [NA] 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: #22688
2024-10-10 13:46:59 +00:00
"metric": "Check-In Hero Revenue",
Merged PR 2429: Business KPIs - Revenue details Exposes the following metrics: 1. Invoiced Booking Fees 1. Invoiced Listing Fees 1. Invoiced Verification Fees 1. Invoiced Guesty Fees 1. Invoiced E-Deposit Fees 1. Deposit Fees 1. Waiver Amount Paid by Guests 1. Waiver Amount Paid back to Hosts 1. Check-In Hero Amount Paid by Guests This PR is only for Global metrics, the one by deal id will follow separately. Keep in mind that merging this PR will make the data appear in the report. Related work items: #18914
2024-07-29 13:16:19 +00:00
"value": "checkin_cover_fees_in_gbp",
"previous_year_value": "previous_year_checkin_cover_fees_in_gbp",
"relative_increment": "relative_increment_checkin_cover_fees_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "positive",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
},
Merged PR 5311: Adds Confident Stay Revenue as a Main KPIs and Account Performance metric # Description Creates a new metric: Confident Stay Revenue. This includes: * Setting the computation in `int_mtd_vs_previous_year_metrics` * Configuring the metric behavior in `int_mtd_aggregated_metrics`. It follows the same as CIH. * Adding the metric in the completion test. I didn't add it in the outlier test in purpose as any new value would trigger the outlier since there's no history to compare against. Few notes: * I confirm it displays no value, as the product has not been launched. * Note that the inclusion of Confident Stay in Guest Revenue was already handled in the previous PR. Next steps to complete the ticket: * Add in the Data Glossary of Main KPIs the definition of Confident Stay Revenue * Add in the Data Glossary of Account Performance the definition of Confident Stay Revenue # 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. - [N/A] I have checked for DRY opportunities with other models and docs. - [N/A] 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: #30278
2025-05-26 09:22:15 +00:00
{
"order_by": 266,
"metric": "Confident Stay Revenue",
"value": "stay_disrupt_fees_in_gbp",
"previous_year_value": "previous_year_stay_disrupt_fees_in_gbp",
"relative_increment": "relative_increment_stay_disrupt_fees_in_gbp",
"number_format": "currency_gbp",
"increment_sign_format": "positive",
"display_exclusion": "NONE",
"include_in_account_reporting": true,
},
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
{
"order_by": 270,
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"metric": "Host Resolutions Payouts",
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
"value": "xero_host_resolution_amount_paid_in_gbp",
"previous_year_value": "previous_year_xero_host_resolution_amount_paid_in_gbp",
"relative_increment": "relative_increment_xero_host_resolution_amount_paid_in_gbp",
"number_format": "currency_gbp",
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
Merged PR 2354: Main KPIs batch 2 exposure 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
2024-07-19 09:14:30 +00:00
},
New KPI rates for Main KPIs
2025-01-23 17:14:36 +01:00
{
"order_by": 271,
Merged PR 4763: Align metrics within KPIs report # Description There's misalignment in the different areas in the business, but even within our own report... **I'm not saying this is perfect** - but at least it forces a common Data Glossary within Main KPIs. I'd suggest later on reviewing naming - same as we need to do for revenue anyway -, but for the meantime, at least have consistency on our side. Changes: * Est. Billable Bookings -> Billable Bookings. We have other metrics stated as Estimated in the Data Glossary. * Waiver and Resolutions payments to host are now called Payouts. This is not perfect but at least is clear we're paying out, so it's a cost. * Host Resolutions Payment Rate is now explicitly mentioning how it's being computed to avoid confusion with the Payout Rate, that does not appear here yet, but appears in the YTD. Additional Changes: * Tests are also aligned with new names. * Re-order booking display, so Cancelled Bookings (inclusion and exclusion) are shown below. Having them the first is weird. # 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. - [ ] I have checked for DRY opportunities with other models and docs. - [ ] 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: #28560
2025-03-20 17:00:36 +00:00
"metric": "Host Resolutions Payouts per Booking Created",
changed names
2025-01-24 08:30:05 +01:00
"value": "host_resolution_amount_paid_per_created_booking",
"previous_year_value": "previous_year_host_resolution_amount_paid_per_created_booking",
"relative_increment": "relative_increment_host_resolution_amount_paid_per_created_booking",
New KPI rates for Main KPIs
2025-01-23 17:14:36 +01:00
"number_format": "currency_gbp",
"increment_sign_format": "negative",
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
"display_exclusion": "NONE",
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
"include_in_account_reporting": true,
New KPI rates for Main KPIs
2025-01-23 17:14:36 +01:00
},
Adding guest journey KPIs. Updating gitignore
2024-06-17 11:10:13 +02:00
] %}
Merged PR 2003: Business KPIs first draft This PR aims to provide a first draft for business KPIs, at this stage **quite minimal**. It mostly contains a MTD and Monthly display approach. No dimensions are created. The models created are: - **int_dates_mtd**: mainly it reads from int_dates to retrieve those days needed for a MTD/monthly display - **int_core__mtd_booking_metrics**: it contains the booking metrics, ending in a format of date|value|value last year|increment --> here we could add, in the future, additional metrics from other sources (ex: guest journey, etc) - **int_core__mtd_aggregated_metrics**: it transforms the data coming from the different mtd intermediate sources to be easily displayed in the dashboard. This is a good candidate for macros :) - **core__mtd_aggregated_metrics**: copy-paste of the its int_core version, including a bit of model documentation The dashboard is functional but in another PR. I can show you how it looks like at the moment you are going to check the PR Related work items: #17214
2024-06-11 15:45:57 +00:00
with
Merged PR 2232: KPI refactor - 1st step, bookings 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
2024-07-08 15:58:36 +00:00
int_mtd_vs_previous_year_metrics as (
select * from {{ ref("int_mtd_vs_previous_year_metrics") }}
Merged PR 2003: Business KPIs first draft This PR aims to provide a first draft for business KPIs, at this stage **quite minimal**. It mostly contains a MTD and Monthly display approach. No dimensions are created. The models created are: - **int_dates_mtd**: mainly it reads from int_dates to retrieve those days needed for a MTD/monthly display - **int_core__mtd_booking_metrics**: it contains the booking metrics, ending in a format of date|value|value last year|increment --> here we could add, in the future, additional metrics from other sources (ex: guest journey, etc) - **int_core__mtd_aggregated_metrics**: it transforms the data coming from the different mtd intermediate sources to be easily displayed in the dashboard. This is a good candidate for macros :) - **core__mtd_aggregated_metrics**: copy-paste of the its int_core version, including a bit of model documentation The dashboard is functional but in another PR. I can show you how it looks like at the moment you are going to check the PR Related work items: #17214
2024-06-11 15:45:57 +00:00
)
{% for metric in metrics %}
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
select
year,
month,
day,
is_end_of_month,
is_current_month,
Merged PR 3810: Adds is_end_of_month_or_yesterday for Main KPIs # Description Adds `is_end_of_month_or_yesterday` for Main KPIs. Apparently, the fact that we do not show the ongoing value of the month on some tabs of Main KPIs is the main blocker for Ben C to consistently use Main KPIs, which he actually retrieves from the SH legacy reporting. Since I'm sceptical about the data shown there, I want to remove this blocker. It will require a small PR on PBI as well. # 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. - [NA] 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: #25342
2024-12-09 16:13:52 +00:00
is_end_of_month_or_yesterday,
Merged PR 2317: Exposing first_day_month for business kpis This PR exposes the field first_day_month in the business KPIs, for the Global view. It's just to be able to properly display graphs, since it's quite confusing doing it so by last_day_month (see screenshot)![image.png](https://guardhog.visualstudio.com/4148d95f-4b6d-4205-bcff-e9c8e0d2ca65/_apis/git/repositories/54ac356f-aad7-46d2-b62c-e8c5b3bb8ebf/pullRequests/2317/attachments/image.png) Related work items: #18580
2024-07-16 09:14:38 +00:00
first_day_month,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
date,
Merged PR 2607: Propagates and exposes multiple dimension handling for KPIs # Description This PR ensures the propagation of the dimensions for KPIs across the key aggregating and exposing models. Additionally, provides these 2 new fields in reporting while **not affecting the current data display**, thus it's safe to work in the PBI report without needing to work in 2 PRs in parallel. **Changes:** **1 - Intermediate, `int_mtd_vs_previous_year_metrics`:** * Removes the temporary filter on `where dimension in ({{ production_dimensions }})`. This will be applied directly to reporting later. This ensures that the new dimension on customer segmentation is fully available only within intermediate. * Adds `dimension` and `dimension_value` granularity. This includes: 1) adding these fields, 2) joining by these fields with all the source CTEs containing the source models with metrics - which in turn needs the change of the dates model - and 3) joining by these fields in the self-join to compute the incremental vs. previous year. * Changes on the schema file **2 - Intermediate, `int_mtd_aggregated_metrics`:** * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields. * Changes on the schema file **3 - Reporting, `mtd_aggregated_metrics`:** * Adds the filter removed on `int_mtd_vs_previous_year_metrics`. This ensures that only the Global dimension is available for the reporting, thus **no changes from user POV**. * Adds `dimension` and `dimension_value` granularity. This includes only adding these fields * Changes on the schema file # 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: #19325
2024-08-20 15:42:27 +00:00
dimension,
dimension_value,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
previous_year_date,
{{ metric.order_by }} as order_by,
Merged PR 4948: Reporting model for mtd aggregated metrics by deal # Description Creates a new model for reporting. It includes any relevant metric at Deal level in a similar format as we do for `mtd_aggregated_metrics`. Additionally, there's few Deal attributes - from Hubspot, segmentations, lifecycles, etc. In order to dynamically choose which metrics are relevant on a Deal level, I modified the configuration in `int_mtd_aggregated_metrics` so the extraction is under control. # 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. **Worth discussing the possibilities to include indexes in the future** # Other - [ ] Check if a full-refresh is required after this PR is merged. Related work items: #28998
2025-04-08 10:04:11 +00:00
{{ metric.include_in_account_reporting }} as include_in_account_reporting,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
-- quotation marks added because text format
'{{ metric.number_format }}' as number_format,
Merged PR 4769: Refactors display exclusion in main metrics # Description I noticed this morning that after the name changes some exclusions have been messed up. I think is about time we handle this properly. Following what we did for `ytd_mtd_aggregated_main_metrics_overview`, I apply the same logic: the metric display configuration is handled for each metric in the configuration rather than by some crazy-complex-name-logic. I also took the opportunity to make Host Resolutions timely after a discussion with Chloe yesterday. Finance handles resolutions payments twice a week, and the "delay" in time is mostly coming from Resolutions accepting to pay someone vs. Finance handling the payment. In any case we're talking about a few days maximum difference, which I believe it's 1) process-related freshness, rather than data-related and 2) much better to have visibility in a timely manner rather than waiting for the 20th on next month. # 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. - [ ] I have checked for DRY opportunities with other models and docs. **Logic is common among YTD and MTD models. At some moment this can be improved** - [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: #28560
2025-03-21 09:40:20 +00:00
'{{ metric.display_exclusion }}' as display_exclusion,
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
'{{ metric.metric }}' as metric,
{{ metric.value }} as value,
{{ metric.previous_year_value }} as previous_year_value,
Fixed models for mtd_aggregated_metrics
2024-08-08 17:06:11 +02:00
{{ metric.relative_increment }} as relative_increment,
case
when '{{ metric.increment_sign_format }}' = 'negative'
then {{ metric.relative_increment }} * -1
else {{ metric.relative_increment }}
end as relative_increment_with_sign_format
Merged PR 2236: Refactor of already exposed metrics: listings, deals and guest journeys 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
2024-07-09 13:00:43 +00:00
from int_mtd_vs_previous_year_metrics
Merged PR 2053: Added number_format category in mtd_aggregated_metrics Added number_format category in mtd_aggregated_metrics Related work items: #17458
2024-06-17 14:59:01 +00:00
{% if not loop.last %}
union all
{% endif %}
Merged PR 2003: Business KPIs first draft This PR aims to provide a first draft for business KPIs, at this stage **quite minimal**. It mostly contains a MTD and Monthly display approach. No dimensions are created. The models created are: - **int_dates_mtd**: mainly it reads from int_dates to retrieve those days needed for a MTD/monthly display - **int_core__mtd_booking_metrics**: it contains the booking metrics, ending in a format of date|value|value last year|increment --> here we could add, in the future, additional metrics from other sources (ex: guest journey, etc) - **int_core__mtd_aggregated_metrics**: it transforms the data coming from the different mtd intermediate sources to be easily displayed in the dashboard. This is a good candidate for macros :) - **core__mtd_aggregated_metrics**: copy-paste of the its int_core version, including a bit of model documentation The dashboard is functional but in another PR. I can show you how it looks like at the moment you are going to check the PR Related work items: #17214
2024-06-11 15:45:57 +00:00
{% endfor %}
Reference in a new issue Copy permalink