# Data News A place to communicate progress, achievements, updates and generally any new thing from the Data Team. Come regularly to stay updated. # 2025-07-07 ## Pablo leaves the team Pablo here. Most of you should know by now, but in case you’ve been hiding under a rock, I’m one week away from leaving Truvi. After a very sweet tenure where I got to start and grow the Data team, I’ve decided to give it a shot to a position in a wildly different company. It’s been a tough decision, because I’ve had (and I’m still having) a great time at Truvi. But sometimes you need to sacrifice something great to see if you can score something even better. My final day will be 14/07. In the meanwhile, feel free to reach out for both work related stuff or just a simply goodbye coffee. And rest assured, Data team will continue forward as usual: Uri and Joaquín will continue the work and keep delivering, just as always. ## What drives resolution incidents? It’s been a while since our latest Data News entry… because we’ve been busy carrying out in-depth analysis on what causes resolution incidents, in the scope of the Data-Driven Risk Assessment project (or just DDRA). In these past few weeks, the three members of the Data Team have analysed independently data around New Dash Protected Bookings and how these have turned out to generate (or not) a Resolution Incident: from characteristics of the Booking, the Booking Services, the Listing, the Guest and Guest Journey, Occupancy Rates… and so on. After a consolidation effort, we’re happy to announce that we have a new Data Paper available! Here are some highlights from the analysis: - Longer stays are about 3x more likely to result in a resolution incident than shorter ones. - Screening and Deposit Management services - while protective - are associated with a 2-3x higher likelihood of incidents. - Larger listings (more bedrooms or bathrooms) show a 3-5x increase in incident likelihood. - Lower expected occupancy at check-in time makes bookings 2x more likely to run into trouble. - Younger guests (on average) carry a 2-5x higher risk of a resolution incident. But we didn’t stop there. We trained two Machine Learning models (AI) using the most predictive features we found, and compared them to our current flagging system. The result? A contactless ML model that we estimate it performs up to 10x better than our existing process. For additional, in-depth detail, we encourage you to take a look at the Data Paper: [2025-07-07 Understanding what causes Resolution Incidents and how to predict them](https://www.notion.so/2025-07-07-Understanding-what-causes-Resolution-Incidents-and-how-to-predict-them-2250446ff9c980649761d9ded927a023?pvs=21) ## Revenue Churn targets have been updated Among the different targets we track in Main KPIs, we recently noticed that the target for Revenue Churn Rate was supposed to be of 1%, and not the 3% we were showing. A quick update has been released to capture the correct targets. This has affected both Revenue Churn Rate and Revenue Churn (in GBP) metrics. ![Yep that was easy… once we found it…](Data%20News%207dc6ee1465974e17b0898b41a353b461/image.png) Yep that was easy… once we found it… ## More informative data alerts The Data team regularly monitors most of the tables we have in the DWH with automatic data tests. These tests review the data in our DWH regularly to ensure they comply with what we expect and to avoid data quality issues that could affect our reporting. Until recently, our alerts simply *raised* the alert, but didn’t provide much detail into what was exactly wrong. But since some recent work we’ve done, we’re now receiving very detailed reports via Slack any time one of these alerts gets triggered. With this, the team can identify the issue and the root cause much faster and conveniently, and we’re avoiding having to read through some terribly formatted log files in a server. With this, we will be able to continue catching issues before they hit you and your reports. ## First invoicing cycle after the Guest Products release On July 1st, Data team delivered the invoicing exports for the finance team as usual. But this occasion was a bit special, since it was the first cycle after the release of Guest Products by the Guest Squad. This new release offers a lot of possibilities for our dashboard guest journey, but came with the price of many of our foundation code being changed. This impacted the invoicing process. During May and June, Data team worked hard to ensure that all our DWH, reporting and invoicing related code and tables were ready for the delivery of this new release. And finally, on June 1st, we made the first exports with the new version of data. So far things have been smooth, so it seems we’ve overcome the challenge. Now it’s time for the Guest Squad to come up with great ideas and keep leveraging the possibilities that come with the new changes they’ve made. # 2025-06-13 ## Categorising New Dash users for alerting purposes This week we’ve also worked on tagging New Dash accounts for alerting purposes. The idea behind this is to be able to: - Quickly identify which accounts needs reviewing and what potential action needs to be done. - Understand the impact in terms of Listings & Bookings per each category This is a long entry, but please read carefully as it’s very relevant. ### User categories definition We have created 11 user categories, which are: - **00 - No Alert**: Users have all their active listings with upgraded programs and these have generated upgraded bookings. Also, these users have not churned. All is good! - **01 - No Listings**: The user has not churned and does not have any listings. We should check if there’s a problem on the integration or the listing setup. - **02 - No Active Listings**: The user has not churned and does not have any active listings. We should check if there’s a problem on the integration or the listing setup. - **03 - No Bookings - No Upgraded Program in Listings**: The user has not churned, has active listings but these only contain Basic Screening. It has not generated Bookings so far. We should check why there’s no upgraded programs applied to listings. - **04 - No Bookings - Has Upgraded Program in Listings**: The user has not churned, has active listings with upgraded programs, but there’s no bookings. It’s possible that the user is recently onboarded or migrated. However, if it’s not the case, we should understand why there’s no bookings. - **05 - Only Basic Screening Bookings - No Upgraded Program in Listings**: The user has not churned, has active listings and has bookings - but everything is at Basic Screening! This is an upsell opportunity or showcasing a problem with the migration/onboarding of the account. - **06 - Only Basic Screening Bookings - Has Upgraded Program in Listings**: The user has not churned, has active listings with upgraded programs but all bookings are Basic Screening. It’s possible that these listings were upgraded recently and we’re waiting for the bookings. However if the problem persists, we should understand why the upgraded listings are not generated upgraded bookings. - **07 - Has Upgraded Bookings - No Upgraded Program in Listings**: The user has not churned, has had upgraded bookings in the past but currently it can only generate Basic Screening bookings! This is an important point to understand why has moved to free services, and a good upselling opportunity. - **08 - Has Upgraded Bookings - Not all Listings have Upgraded Program Applied**: The user has not churned, has some upgraded bookings and has some active listings with upgraded programs. Seems ok, right? No - because a few bookings are still Basic Screening, due to the fact that there’s some active listings that do NOT have upgraded programs. - **98 - Has Churned:** User has churned, recommended to exclude if wanting to understand the current business snapshot. - **99 - Has Data Quality Issues**: A few edge cases such as the account not having a live date in HubSpot or having the MVP launch as the initial date in New Dash. For more techy profiles to check what’s going on. Recommended to exclude for business audiences. ### How are these user categories being used? The user category it’s only available in **New Dashboard Reporting** → **New Dashboard Overview**, in Power BI. [Link is available here](https://app.powerbi.com/groups/me/apps/d6a99cb6-fad1-4e92-bce1-254dcff0d9a2/reports/44d8eee3-e1e6-474a-9626-868a5756ba83/915f40519c0a301c209c?ctid=862842df-2998-4826-bea9-b726bc01d3a7&experience=power-bi). There’s 2 main areas in which this categorisation is available in the report: - New tab **User Alerts**, as a summary or overview - Existing tab **User Detail**, as a dedicated filter and field in the table Let’s start with the new tab called User Alerts, which looks like this: ![New tab User Alerts](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%201.png) New tab User Alerts As rows we can observe the 11 distinct user categories, including a total row. These are split in columns between users migrated from Old Dash and New Business users; and it also includes a totals column. In here we represent 5 different measures: - **Users**: count of users that are under a certain category - **Active Listings**: count of listings that are active - that can generate bookings. - **Active Listings with Upgraded Program**: count of listings that are active and that can generate upgraded bookings; meaning, bookings beyond Basic Screening - **Total Bookings**: total count of bookings, including Upgraded bookings + Basic Screening bookings - **Upgraded Bookings**: count of bookings that are not Basic Screening bookings. → Note that Basic Screening Bookings would be Total Bookings minus Upgraded Bookings. A simple coloured flag system is in place to identify the severity of each alert: Red = very bad, Yellow = bad, Green = good and Black = edge cases. It’s worth mentioning that even if an alert is yellow, if tons of users/listings/bookings are affected might increase the necessity to act! Let’s continue with User Detail. We’ve added the new filter User Categorisation which can be used to select one or many alerts at the same time. You can combine this with additional filters, as well. For instance, if selecting the alert #03 - No Bookings - No Upgraded Program in Listings: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%202.png) The table and the callouts will update accordingly. You’ll also notice that the User Categorisation is available as the 3rd field in the table. In order to make this tab more complete, we’ve also explicitly added the count of Active Listings that are Basic Screening, or just Active Basic Screening Bookings, as well as the % over the total. Lastly, and similarly to Bookings, we’ve added an Upgraded Listings Rate which just shows the % of Active Upgraded Listings vs. all Active Listings per account. Let’s deep dive into the alert #08 - Has Upgraded Bookings - Not all Listings Have Upgraded Program Applied. We’ve just selected this User Categorisation and sorted by Upgraded Listings Rate: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%203.png) Let’s focus on the first row: this user has 19 active listings, from which 1 has an Upgraded Program and the rest, 18, have Basic Screening. This results into an Upgraded Listings Rate of 5.3% (1 divided by 19). This user has generated a total of 584 bookings, from which 80 have an upgraded program. However, the remaining 504 bookings are Basic Screening-only, which results into an Upgraded Booking Rate of 13.7%. To put it simply, these are 504 bookings from which we missed the opportunity to generate any kind of revenue. Worth noting that these can be extended to 14,815 bookings if considering all users in this alert. ### Early conclusions Early because we also need time to deep-dive... But there’s few interesting cases in which we can already act upon. I’ll be only including accounts that have been in New Dash before June, to remove slight time delays: 2 weeks should be sufficient. I’ll also exclude churned and data quality alerts from the totals, to have a clean picture. Here’s the highlights: - On Migrated accounts from Old Dash: - 43% of the migrated accounts have Medium or High Priority alerts (yellow and red). This corresponds to 307 accounts. - **7.3% of the migrated accounts have High Priority alerts**. This corresponds to 53 accounts, a few having No Listings (11), not Active Listings (19), or not Upgraded Programs in Listings (9 without Bookings, 14 with Basic Screening Bookings). - 17% of the Bookings are Basic Screening, the main gap being - On the onboarding of New business accounts - i.e. not migrated: - 48% of the new business accounts have Medium or High Priority alerts (yellow and red). This corresponds to 196 accounts. - **20% of the new business accounts have High Priority alerts**. This corresponds to 83 accounts, the majority having No Listings (48), not Active Listings (18), or not Upgraded Programs in Listings (5 without Bookings, 12 with Basic Screening Bookings) - On Upgraded Bookings - i.e., that we can generate revenue vs. Basic Screening Bookings (free) - 61% of the Total Bookings come from users tagged as 08 - Has Upgraded Bookings - Not all Listings have Upgraded Program Applied vs. just a 30% that comes from 00 - No Alert. - However, **the impact of the alert #08 is huge in terms of Basic Screening-only Bookings: around ~15K, which explains 3/4 of all Basic Screening Bookings.** - At this stage it’s worth mentioning that part of these bookings might come from automatic listing activation + automatic booking pulling that should be resolved in the coming weeks, as part of the Basic Screening iterations. This just highlights how relevant this piece of work is. There’s many more insights to reveal with this new categorisation and hopefully we all get more used to it on time! ## Updates on Invoicing & Crediting Report This week, we worked on updating the Invoicing & Crediting Report. This update aligns with recent conversations we've had with the Finance and Resolutions teams, aiming to help them reduce the time spent searching for specific data or determining which tasks should be prioritized. With that in mind, we've added two new tabs to the report: - **Accounts Due Amount:** This tab highlights the accounts with the highest pending payments to Truvi, as well as the accounts with the highest pending payments from Truvi. The goal is to give the Finance team a clearer view of which accounts should be prioritized for follow-up and payment actions. ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%204.png) - **Due Amount Details:** This tab provides a more detailed view of both pending invoices and credit notes. It includes all relevant information for each document, allowing users to dive deeper into the data related to each outstanding payment. It also includes a secondary view called *Financial View*, which offers a simplified version of the General View for financial analysis. ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%205.png) ## Screen & Protect API pricing and reporting Over the past few weeks, internal discussions have focused on the evolving pricing structure of the **Screen & Protect API** and its implications for existing invoicing reports. Given the product's early stage and ongoing changes in pricing, it has been agreed that automating the invoicing process via a new Power BI report is not currently a priority. As the product continues to develop, and with client volume still relatively low, the decision has been made to **maintain manual invoicing** for now. This allows flexibility while we refine the pricing strategy and gather insights on usage patterns and client demand. Looking ahead, when **Screen & Protect API** scales enough, with a more stable pricing model and growing adoption. At that point, we’ll revisit the reporting needs and adapt the invoicing report to support the Finance and Product teams accordingly. This approach is expected to serve as a model for invoicing processes for future early-stage products as well. # 2025-06-06 ## Test accounts are now excluded from Power BI reports Good news! Thanks to a piece of work carried out by Dash Squad, we now have a proper way to identify which accounts are for testing purposes in the production backend of Truvi. At the moment of writing this, 535 accounts have been identified as test accounts. A few of these accounts have had activity in terms of Bookings, Listings, Guest Journeys, etc. This was bad because it was affecting many critical reports such as Main KPIs. However, these impacts were mostly localised in the historical years of 2022, and a bit of 2023. Impact on 2024 is reduced, and 2025 almost not existent. A huge amount of these accounts didn’t have any activity at all but were still appearing in reports such as Account Management reports, that are account based, and in this case we can observe how much of these have been cleaned out. The work carried out on Data side is to directly exclude these test accounts from the major entities within DWH; meaning we apply this exclusion by default. This will save us precious time since any report we built would already contain the logic to exclude these test accounts. Lastly, we’re aware that there’s a few additional accounts that look like test accounts that need to be tagged accordingly. We’ll continue raising and flagging these cases to improve our data quality. ## Host Resolutions overrepresentation bug now fixed A data bug led to Host Resolutions Payments being overrepresented across various reports. This inflated values for related KPIs and metrics, particularly affecting: - **Business Overview:** Overstated Host Resolution Payouts, understated revenue retained post-resolutions. - **Accounting Reports:** Overstated Host Resolution Payments. - **Account Management Reports:** Skewed margins and growth data. The bug caused a **net overstatement of ~£7.2K**, with the majority of the impact (~£6.5K) occurring in the first five days of June. The issue was fixed on June 5th. For additional details on the incident, please check the Incident Report below: [20250605-01 - Overrepresentation of Host Resolutions Payments](https://www.notion.so/20250605-01-Overrepresentation-of-Host-Resolutions-Payments-2090446ff9c9804ca74be8bfae70fa64?pvs=21) ## Finance reporting updates For the past few weeks we have been closely collaborating with the finance team and there have been some conversations about updating some reports like Invoicing & Crediting Report to better accommodate the needs of the finance team as well as creating some new reports like the budget report. During the past week we focused on both of this tasks, doing some work on the current reports, which are under review and will soon be live with the newest changes, as well as dedicating efforts into researching and identifying all necessary data points from Xero, our accounting software, which will form the foundation of these new reports. We look forward to sharing more detailed news about these ongoing reporting developments as they progress. # 2025-05-30 ## New Confident Stay Report is now live & important changes on Check In Hero reporting This week we’ve progressed with Confident Stay modelling within DWH. One of the outputs has been the creation of a dedicated Power BI report to track Confident Stay once the product goes live. ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%206.png) The new Confident Stay - Overview report is accessible through the Guest Insights Power BI app. Importantly, we’ve also moved to Guest Insights all 3 already existing reports of Check-In Hero. Please, use the reports on this new location as at some point in the future we will decommission the dedicated Check In Hero app. Now, coming back to Confident Stay: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%207.png) At the moment, the report holds no data on Confident Stay being offered or purchased until the product goes live. As such, it’s possible that when we go live we might need to some tweaks. In any case, we’ve already implemented a Guest Journey based conversion funnel, a Host Adoption tracking and last but not least a dedicated tab for Revenue monitoring. It’s a minimalistic report but should allow to track the very basics. ## New Dashboard Reporting: Booking Check-In and Improvements This week we’ve also done a few improvements on the New Dashboard Overview report in Power BI. The main upgrade has been the creation of a new tab called Check In Bookings. This tab allows to understand the composition of Bookings that Check In in a given month in terms of when were these Created in our systems. Let’s see an example: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%208.png) In this case, I’m filtering for Check-Ins happening between May and December 2025; and I’m only considering Bookings with Upgraded Programs (note that the filter “Has Upgraded Services” equals to True). This indicates the bookings that are potentially going to have at least 1 paid service, assuming these don’t get cancelled. This includes both Billable Services and Guest Payment Services, or both. As we can see in the snapshot, we have 10.1K Bookings with an Upgraded Service in May. Interestingly, 5.5K were actually created within May, while the rest were created in previous months. It’s also interesting to note that in June, 4K bookings were created in May. This is quite close to the 5.5K same-month creation & check-in. This new tab should allow better comprehension on when revenue linked to bookings can potentially happen, as well as provide a proper tracking on Creation vs. Check In bookings. Now, moving to more updates! We’ve conducted a large amount of small improvements across the report. The most relevant aspects have been: - Booking Detail now allows to filter by "Check In Date". It also explicitly displays both Bookings with Upgraded Programs vs. Chargeable Bookings. - User Detail now allows to filter by "In New Dash Since" and displays different measures. At the end of the table we now have an explicit count of Basic Screening Bookings (Bookings - Bookings w. Upgraded Program). We’ve also added an Upgraded Bookings Rate that computes for each account the % of Upgraded Bookings vs. the total Bookings. Those accounts that are not close to 100% are worrying, as it means we’re mostly having free bookings. For those interested in the full list of changes, you can find it in this list: - **Full list of improvements** Readme: - Added HubSpot as source. Overview: - Funnel now displays full integer value - Global Indicator New Dash users now shows the thousand separator - Moved Global Indicator "Total Listings" above "Active Listings" - Global Indicator "Bookings with a Program containing Upgraded Services" renamed to "Bookings with Upgraded Programs" - Global Indicator "Total Active Listings with an Active Program" renamed to "Active Listings with Active Program" - Global Indicator "Total Active Listings with an Active Program containing Upgraded Services" renamed to "Active Listings with Active Upgraded Programs" - Smaller filters, rearrangement, visualisation updates User Detail: - Renamed any "w. Upgraded Services" to "w. Upgraded Program" - Added between filter "In New Dash Since" - Smaller filters, rearrangement, visualisation updates - Added Callouts to easily identify main totals on filtering - Added new columns Basic Screening Bookings, Basic Screening Bookings (%) and Upgraded Bookings Rate Booking Detail: - Added between filter "Check In Date" - Added dropdown filter "Booking Id" - Smaller filters, rearrangement, visualisation updates - Added callout "Bookings w. Upgraded Program". This helps identify the difference vs. Chargeable Bookings i.e., those that have already a chargeable invoicing line or a Guest purchase - Added a note to explain difference between Chargeable Bookings and Bookings w. Upgraded Program. Services Adoption: - Smaller filters, rearrangement, visualisation updates Created Services: - Smaller filters, rearrangement, visualisation updates Chargeable Services - Smaller filters, rearrangement, visualisation updates - Excluded Dimension "Has Upgraded Services" since it's the same as "Global" - Forced that values represented in both graphs have chargeable amounts strictly greater than 0, to exclude "null" amounts per dimension value. This fixes the Guest Agreement appearing here. ## Data-Driven Risk Assessment Project resumes After some weeks working on most priority subjects, this week we’ve resumed the work on the Data-Driven Risk Assessment project (also known as just “data-driven flagging”). The idea for this project is to understand and build a process that flags bookings based on factors that are purely based on data, with the aim to reduce the amount of resolution incidents and provide a better informed coverage of screening and protection for our hosts. This is a very exciting yet challenging project, as for a proper process we need to have 1) huge amounts of data 2) with high quality and 3) available at the moment of screening. This forces us to focus on New Dash Bookings and incidents that appear in the Resolution Center, and in both cases we don’t have a massive history. Despite this challenge, we’ve been analysing the current performance for several weeks now and we’re resuming with the phase 2 of the project: Data Team will invest a bit of time experimenting with Machine Learning models and analysing trends with the aim to have a predictive system from which we can measure the performance before deciding if we aim to implement this in production. While the output of such a project is unknown and there’s a risk we don’t reach a good model, it’s very likely that in the process we study and obtain insights that will increase Truvi’s knowledge on the relationship of Screening, Protection and Resolution Outcome - the heart of our business model. ## SQL Training in Full Swing for Our Domain Analysts! Over the past few weeks, our domain analysts have been making great strides in strengthening their data skills. After completing a series of training sessions focused on Excel—where they've become nothing short of masters—we’ve now shifted our focus to SQL. The team has been actively studying the SQL learning materials we've shared with them, and we’re already seeing strong motivation. To support their growth, we’ve been preparing new practical challenges that will help them better understand how to query data and get familiar with the structure and contents of our data warehouse (DWH). This hands-on approach is designed to build both confidence and capability, empowering analysts to dive deeper into our data and unlock more insights independently. # 2025-05-23 ## New Dashboard Onboarding report now live Following [last week investigation on Billable Bookings](Data%20News%207dc6ee1465974e17b0898b41a353b461.md), this week we have released a new report within New Dashboard Reporting application in Power BI: New Dash Onboarding. This report focuses exclusively on accounts that have not been migrated from Old Dash. The idea behind is to capture the different steps that each new account needs to complete in order to be considered successfully onboarded: from the moment the contract is signed until this account is finally invoiced. For instance, let’s focus on accounts that have had a contract signed on March 2025: ![New Dash Onboarding - Overview; for contracts signed on March 2025. Snapshot as of 26th May.](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%209.png) New Dash Onboarding - Overview; for contracts signed on March 2025. Snapshot as of 26th May. We can observe we had 60 contracts signed in March 2025, but only 19 of these have been already invoiced. We’re aware that a natural delay exists due to the invoicing process being a monthly process. However, only 37 out of 60 contracts have generated Bookings with Paid Services, thus it indicates the need to act upon certain accounts to activate and speed up the revenue generation. Additionally we can see two additional tables. The first one highlights accounts that ONLY have free bookings, and that have not churned. This can be sorted by the Total Bookings or the Avg. Bookings/Day to track the magnitude of the missed opportunity. For instance, `34922353025-Opulent Stays inc` has had 143 Bookings since it was onboarded, all of them with free services. Let’s deep dive on this account in the tab Account Detail: ![New Dash Onboarding - Account Detail, for 34922353025-Opulent Stays inc. Snapshot as of 26th May.](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2010.png) New Dash Onboarding - Account Detail, for 34922353025-Opulent Stays inc. Snapshot as of 26th May. We can see that this account has Upgraded Programs (which contain Paid Services) in 9 listings, and that the first Upgraded Program was set on the 27th March, so 10 days after the contract was signed. However, it still has no Bookings with Paid Services. This account currently has as active services the Basic Damage Deposit and the Waiver Plus, so it’s possible that still these Guest-facing products need to be purchased in order for a Booking to be considered as having Paid Services. A quick look in the other report of New Dashboard Overview - Booking Detail would help determining which Programs are actually applied to upcoming Bookings. Additionally, we can observe that this account expressed interest on ID Verification during sales calls, but that this service is not currently active in any active listing. A potential upselling opportunity! Getting back to the Overview tab, we also have the second table that highlights accounts that have had Paid Bookings in the past but that at this moment, there’s no Active & Upgraded Program at Listing Level. The interesting example in this case is `34610311272-Hipstay Ltd` as it still has 4 active listings. Looking into Account Detail for this account: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2011.png) We can easily observe that the Program and Listing Funnels miss the latest - and most important - step. It had 25 Paid Bookings, but moving forward it only has the capacity to generate Free Bookings with Basic Screening. This highlights an interesting case to understand why a client has decided to go for free services when it was not even yet invoiced! There’s additional functionalities in the report which we encourage client-facing teams to explore by themselves. Keep in mind that data is updated once a day, thus small delays might happen when checking vs. the actual Dashboard configuration. ## Confident Stay revenue now captured in KPIs This week we’ve modified the Guest Payments related flow in KPIs to ensure to capture Confident Stay revenue once it’s live. The change affects Guest Revenue, which now includes Confident Stay payments alongside Check In Hero, Deposit Fees and Waiver Fees. This is also affecting Guest Revenue dependants, such as Total Revenue or Revenue Retained Post-Resolutions. Additionally, we’ve created a new metric called Confident Stay Revenue as a standalone revenue tracking for this new Guest Product. Keep in mind that at the moment this is still zero as the product has not been released yet. ## Guest Journey A/B test: London Wallpaper results It’s been over a month since we’ve been monitoring the A/B test on the Welcome Page with London background. Due to the changes only applying for guests that travel to London or Great London areas, the sample size we got in this time period is much lower than usual (around 400 Guest Journeys). Seeing that results are still not significant, meaning we cannot really conclude anything from this A/B test, the A/B test has been stopped on 27th May 2025. There’s an interesting possibility to re-do this A/B test with additional destinations so we increase the sample size and the possibilities to reach to meaningful conclusions. However, this will come later down the line. The detailed results of the London Wallpaper A/B test are available here: [2025-05-27 Guest Journey - London Wallpaper A/B Test - Results](https://www.notion.so/2025-05-27-Guest-Journey-London-Wallpaper-A-B-Test-Results-2000446ff9c9800d86f2d3bcfdbbec42?pvs=21) ## Guest Journey A/B test: Your Trip Questionaire has been launched The next A/B test is called Your Trip Questionaire and is being launched right after the London Wallpaper one, on May 27th 2025. The Your Trip Questionaire aims to investigate if asking additional questions to the Guest during the Guest Journey process has an effect in the Guest behaviour - in terms of conversion, payments and/or CSAT score. Since adding additional steps in the Guest Journey might add friction, the A/B test will not have a 50-50% distribution but rather a reduced amount of 10% in the study variation. This will reduce the potential risk while still ensuring that the hypothesis gets studied properly. Data Team will take a close look in the coming days to ensure that any risk is managed accordingly. In the meantime, here’s the technical details for this brand new A/B test: [2025-Q2 - 2 - Your Trip Questionaire - Guest Journey A/B test](https://www.notion.so/2025-Q2-2-Your-Trip-Questionaire-Guest-Journey-A-B-test-1f90446ff9c980a296b9ecb47cad21ef?pvs=21) ## Our Domain Analysts are SQL-ing up Great news! Our current batch of Domain Analysts have done a great job going through some Excel challenges and training and we’re now happy with their skills with it. This means we now move on to a tougher (but also more juicy) bone: learning SQL. SQL is the language we use to query data from the DWH, so learning it will allow our colleagues to pull all sorts of great stuff out of the DWH. We expect to spend a few weeks with them both upskilling them in SQL and guiding them through navigating and leveraging the contents of our DWH. Wish them luck: as with all language learning, picking up SQL is going to burn some serious brain calories! ## New currency (AED) in Exchange Rates data We recently received a request from Ant to cover some features in the Resolution Center: we need to included the United Arabs Dirham (AED) to our database of currency rates. Since this has been the first time since inception that we had to add a brand new currency to our rates database, we needed to upgrade some parts of our tool `xexe`, which is the code that brings the rates from [XE.com](http://XE.com) into our DWH. Those are now done and the AED rates history (starting from 2025-01-01) is now present in both the DWH and the Billing DB. And remember, if you need to add another currency to this list, just let us know! # 2025-05-16 ## Preparing DWH for Confident Stay This week we’ve resumed the necessary work to properly track and enable future reporting around Guest Products. We already started to capture the necessary tables [a few weeks ago](Data%20News%207dc6ee1465974e17b0898b41a353b461.md), but now with the coming launch of Stay Disrupt it was about time to continue with the work. This week we’ve handled a big internal refactor regarding Guest Payments, which it’s the main source of data for key areas such as A/B testing or Guest Revenue computation. In essence, we’ve split the logic to differentiate between Guest Products (Check-In Hero, Stay Disrupt) and what we call Verification Products (Waivers, Deposits, Fees). This split enables us to capture and transform the data according to the different logic each type of product has, while enabling a cleaner environment within DWH. Lastly, everything gets aggregated together to Guest Journey Payments; which includes any payment done by the Guest within the Guest Journey. Besides combining Verification Products and Guest Products, we apply the conversion of the amounts to without taxes for revenue computation purposes. This was the biggest challenge on Data side to prepare for Stay Disrupt: mainly, ensuring nothing critical would break! Next step will be ensuring that Check-in Hero reporting is prepared for the incoming changes, before jumping into discussing dedicated Stay Disrupt reporting. ## On New Dash and Billable Bookings This week we’ve also dedicated quite a bit of effort to understand why April billable bookings have had a lower volume than expected. This is important since we rely on Billable Bookings as for the go-to metric on bookings side as a precursor to invoiced revenue. After the first investigations, there’s no obvious, single explanation that covers this observed decline. Rather, the decline it’s a combination of small factors; some of which are actual issues that need fixing, others suggest that we need better business methodology in place and others are just because of the different logic to determine when a booking is billable in New Dash, with respect to Old Dash. This exercise is still in progress. At the moment, in Data side, we’re focusing on providing dedicated account onboarding reporting for those accounts in New Dash that have not been migrated from Old Dash - so that are “new business” directly in New Dash. # 2025-05-02 ## Account Growth report is now live [Last week](Data%20News%207dc6ee1465974e17b0898b41a353b461.md) we explained that we were working on an improved version of the report Account Managers Overview. This week, we’re happy to announce that the new report Account Growth is live! As a summary, here’s the main key improvements: - **Growth is now based on Billable Items** (Bookings for Platform, Verifications for APIs). - **We forecast the current month**, updating daily - making the report much more timely. - **Growth compares the forecast vs. the past 3 months**, focusing on recent trends and reducing seasonality noise. - **Impact score now uses Revenue Retained Post-Resolutions**, better aligned with profitability goals. In terms of visualisation, we kept a similar display as the existing one in the tab Monthly Growth - but now it allows to select the ongoing month and has the different logic and metrics in place. Importantly, we’ve also added 2 new additional tabs: - **Ongoing Month Overview**: it specifically focus on the ongoing month and highlights any account that is tagged as Major Decline, as well as the top 10 accounts in Revenue Retained Post-Resolutions. ![Double click-me!](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2012.png) Double click-me! - **Account Growth Detail**: it allows to deep-dive into a single account. It displays the historical evolution of the account in terms of growth and revenue metrics, as well as it provides specific context of why the account is labelled with a certain category on the ongoing month. ![Double click-me!](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2013.png) Double click-me! With this new report up and running, we’ll proceed to delete the previous Account Managers Overview on May 23rd. Please, if you have any question or concern, contact the Data Team before May 23rd! ## Exploratory Data Analysis on Resolution Incidents This week we’ve also advanced in the scope of the [Data-Driven Flagging Project](Data%20News%207dc6ee1465974e17b0898b41a353b461.md). We’re waiting for more data to reach significant conclusions on the booking status vs. resolution outcome methodology, as we’re only focusing on New Dash protected bookings. However, in the meantime, we’ve conducted a high-level analysis on any Resolution Incident that appears in Resolution Center, indistinctly if it’s New or Old Dash. This gives us a bit more data (though not an incredible amount) so we’re able to start exploring main trends. We’ve focused into 3 areas: - How does the booking duration (number of nights) affect resolution incident occurrence? - How does international/national travellers affect resolution incident occurrence? - How does the lead time from booking creation to check-in affect resolution incident occurrence? These areas are high-level enough for us to retrieve first trends without falling into low sample inconclusiveness. So! Time for you, reader, to make a guess. ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2014.png) Ready? Here’s the actual insights obtained from the data analysis! - **Longer bookings** are more likely to result into incidents. - **National and especially same-town travellers** are associated with higher incident rates than international guests. - **The time between booking creation and check-in** does **not** significantly influence the likelihood of incidents or payouts. - Across all explored factors, **no clear trend** explains when a payout is likely once an incident has been raised - suggesting that a payout resolution depends on other factors. How many correct guesses? Any surprise? Let us know through slack! The in-depth analysis is available in this Data paper: [2025-05-02 Exploratory Data Analysis on Resolution Incidents](https://www.notion.so/2025-05-02-Exploratory-Data-Analysis-on-Resolution-Incidents-1e70446ff9c98043b263e3b2eadb79fb?pvs=21) ## Milestone: Live Deals in New Dash surpass those from Old Dash! On April 29th 2025, and according to Main KPIs data, New Dash surpassed Old Dash in terms of number of accounts that are live. This is a great milestone! Since the first release of the MVP at the end of July 2024 to the current date, many initiatives and projects have been circulating around New Dash impacting the wider business. ![Source: Business Overview - Main KPIs - Detail by Category, on 29th April 2025. ](Data%20News%207dc6ee1465974e17b0898b41a353b461/image_(9).png) Source: Business Overview - Main KPIs - Detail by Category, on 29th April 2025. Congrats to everyone for this big step forward, we win as a team! ## Update on Host Resolutions Payments Report Following last week's update from the Finance team, we’ve completed key improvements to the **Host Resolutions Payments Report**. The report now includes **all Host Resolutions Payments**, regardless of whether they were originally recorded as **bank transactions** or as **credit notes**. This ensures a complete and unified view of all resolution-related payouts. In addition to the data update, we’ve made the report **more user-friendly** and **insightful**: - Added new metrics like **Average Payment Amount** and its **evolution over time** - Introduced a new **Top Accounts tab**, showing: - The **top 10 accounts by total resolution amount paid** - Accounts with the **most resolution claims** - Those with the **highest average amount per claim** ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2015.png) These changes aim to provide more visibility and value for both the **Resolutions** and **Finance** teams. # 2025-04-25 ## Account growth limitations and how to improve it It’s been several months since we first released the report of Account Managers Overview, back in Q4 2024. The main idea behind this report is to quickly categorise the different accounts between Major Gain, Gain, Flat, Decay and Major Decay in terms of how the account growth is impacting our business. While this has been helpful in these past few months, we’ve also been aware that there’s some limitations with how the growth and impact scores are being computed: - Computation is based on Total Revenue, Created Bookings and Listings Booked in Month. This works relatively well for Platform deals, in which the 3 metrics make sense. However, for API deals we do not track Bookings nor Listings, thus we only rely on Revenue. This can reduce the balance of the score. - Computation is mostly based on Year-on-Year (YoY) and MoM (Month-on-Month) evolution of the abovementioned 3 metrics, and it gets averaged. This results in a simple average of a total of 6 evolutions. This has shown some limitations if the account has been live for a bit more than a year or less, in which an actual MoM decrease is hidden by the fact that we might be comparing the current growth versus an initial start of the account. - Information is not very timely… We’re aware that Revenue metrics have an intrinsic delay due to the invoicing cycle. However, Bookings are technically available with a 1 day difference in DWH, while in the report we currently only use the Bookings from the previous month, thus we could provide a greater degree of awareness. - Impact score is weighted by Total Revenue, while now we have the ability to use a more margin-related metric: Revenue Retained Post-Resolutions. While Total Revenue is a good indicator, switching to RRPR would provide a better comprehension of how an account would impact directly to our Truvi goals of reaching profitability. It’s also worth noting that this account growth computation is, by nature, complex. For instance, focusing exclusively on MoM evolution could falsely flag accounts as decay while this effect might just be because of seasonality. ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2016.png) At this moment we’re exploring a more advanced, refined version of the account growth and impact to the business at account level. In essence, what the new version is providing is: - We only base the growth on Billable Items. These refer to Billable Bookings for Platform Deals, and to Billable Verifications for API Deals. - Billable Items are forecasted at the end of the current month. This means that we’re not only providing information up to yesterday, but rather aiming to predict the monthly Billable Items of the current month. This forecast would change every day and become more accurate as the month progresses. This is critical to be able to detect drastic changes of an account while in the month! - The growth is computed only by comparing the current month forecasted Billable Items vs. the actual Billable Items of the past 3 months. This takes into account both the absolute values (for instance, 100 Billable Items vs. 120) as well as the relative share of Billable Items of a given account vs the total (for instance, 0.5% vs. 0.3%). This ensures that we’re able to only base the growth on recent data while ensuring that potential seasonal effects are diluted by taking the relative share. - The impact score is based on Revenue Retained Post-Resolutions, rather than Total Revenue. So far the first tests look successful! The accounts that we flag as Major Decay indeed seem to be having a clear decay which is followed by a posterior negative impact in Revenue metrics when deep-diving into the metrics in the Account Performance report. And… probably the best thing is that now information is as timely as we can get! This next week we will finalise the tests, do small tweaks here and there and start working on a Power BI report. ## Finance Team Updates How Host Resolution Payments Are Processed The Finance team is making an important change to how **Host Resolution Payments** are recorded in our systems. This update affects where the information is stored and how it appears in reports, helping us manage and track these payments more accurately. Until now, Host Resolution Payments were recorded as regular **bank transactions**. Starting from **March 31, 2025**, they will instead be recorded as **credit notes**. This shift brings better alignment with our financial processes and improves how we categorize and report these payments. While the categorization of payments remains mostly the same, there are a few updates, including a new account code to capture certain types of resolutions more precisely. To make this transition smooth: - A **new table** will be created in the DWH to combine both the old and new data sources. - Our **reporting models** will be reviewed and updated to make sure the change is properly reflected. - Key reports like the **Main KPIs Report** and the **Host Resolutions Report** will be updated accordingly. Our teams are working closely with Finance to ensure there’s no double counting, that all necessary data fields are captured, and that everything is fully tested before going live. ## Update on A/B Tests: New Illustration and Destination Welcome Page After almost six weeks, the A/B test for the **New Illustration** has been completed. While no significant positive impact was observed, there were also no negative effects — the main goal of the study. The final decision on whether to roll out the New Illustration now rests with the Guest team. You can review the full test results [here: [2025-04-15 Guest Journey - New Illustration A/B Test - Results](https://www.notion.so/2025-04-15-Guest-Journey-New-Illustration-A-B-Test-Results-1ba0446ff9c980f2893ede0970611156?pvs=21) ]. ### Next steps We’re launching a new A/B test focused on the **Destination Welcome Page and Message**. In this test, guests will see a **custom wallpaper image and welcome message** tailored to the town where they have booked their stay. - The initial rollout will target bookings in **London and Greater London**. - Based on the results, we may expand the test to include more cities in the future. You can find all the details about this new A/B test [here: [2025-Q2 - London Wallpaper - Guest Journey A/B test](https://www.notion.so/2025-Q2-London-Wallpaper-Guest-Journey-A-B-test-1d80446ff9c980319eb2c0e97e41be1e?pvs=21) ]. # 2025-04-11 ## KPIs refactor finished Following [last week’s update](Data%20News%207dc6ee1465974e17b0898b41a353b461.md), early this week we’ve finished the refactor on the internal KPIs modelling. This should enable us to provide more flexibility and address further needs on any reporting that requires this information. At the moment, this KPIs flow is being used mostly for Main KPIs, Account Management and New Dash reporting - so quite central. Unfortunately, we faced a data quality issue linked to a wrong computation that was released with this refactor. The incident has now been resolved, but for further details you can check the incident page here: [20250409-01 - Wrong computation on Revenue Retained metrics](https://www.notion.so/20250409-01-Wrong-computation-on-Revenue-Retained-metrics-1d10446ff9c980e0b6d3e52b40879b68?pvs=21) Thanks again to Kayla for spotting and raising it! ## Account Performance reporting now live The first interesting piece of work after the [KPIs modelling refactor](Data%20News%207dc6ee1465974e17b0898b41a353b461.md) has been the implementation of the Account Performance report, which sits in Account Management Power BI app. In short, this is an improved version of the previously existing tabs of Detail by Deal and Deal Comparison in the Main KPIs report. These were not very good in terms of usability and, at the same time, were not providing timely data. With the new report and thanks to the refactor, we’re now able to deep-dive into several tabs to get insights, see below a few examples: Display the performance of several metrics of a single account, in a monthly or month-to-date level: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2017.png) Display several metrics over time for a single account: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2018.png) Display a single metric for a single account year-on-year: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2019.png) Compare how different deals perform over time and the % share on a single metric: and here we can select multiple filters, such as Account Manager, Deal Lifecycle State, Billing Country, Business Scope (API/New Dash/Old Dash), Listing Segmentation… even filter by the value of the metric itself: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2020.png) … and even check the size and trend of accounts linked to Account Managers, for instance, for New Dash: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2021.png) This is a quite significant change and there’s tons of information hidden here. We highly encourage to take a look at the Data Glossary tab for further information. We expect that it will take a bit of time to get to the full potential, so reach out to us if you want a demo! Last but not least, we aim to remove the old tabs in Main KPIs on Detail by Deal and Deal Comparison on April 25th, as these will become obsolete. ## Keeping our reports updated Last week, we rolled out several exciting updates across our Power BI reports to make data exploration smoother, faster, and more insightful. Here’s a quick overview of what’s new: ### New Dash Overview: *Adoption Services Tab Added* The **New Dash Overview** report now includes a brand-new **Adoption Services** tab! Users can now monitor how adoption rates for different services in New Dash are evolving — whether by **users**, **listings**, or **bookings**. This update makes it easier to track service engagement over time and identify trends or drops in usage. ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2022.png) ### Churn Report: Multi-Month Selection Enabled We heard your feedback! The **Churn Report** now supports **multi-month selection**, allowing users to analyze data over broader time periods with just a few clicks. This change helps speed up long-range trend analysis and simplifies comparisons across months. ### API Reports: Fresh Look & More Filters We’ve also made improvements to a few of our **API-related reports**: - Cleaned up the design to match our latest visual standards. - Added new **filtering options** to give users more flexibility and control over the data they explore. # 2025-04-04 ## **Data Alerts: Keeping Our Data Strong and Reliable** Over time, the Data team has implemented a system of **data alerts** across all our models to help ensure the accuracy and consistency of the information we provide. These alerts work quietly in the background, constantly monitoring for anomalies, missing data, or unexpected changes. Their goal is simple: **to make sure our data remains trustworthy and actionable**. ### Why It Matters In the past few weeks, these alerts have proven especially valuable. We've seen a rise in the number of issues detected, and thanks to the alert system, we've been able to: - **Identify problems early** - **Raise awareness quickly** - **Ensure that the data in our reports remains reliable** This proactive approach helps us maintain confidence in the numbers we use every day. ### A More Resilient Data Ecosystem Our alert system is a key part of maintaining a resilient and transparent data layer. It allows us to catch and address issues before they impact decision-making—ensuring the data you see is as accurate and up-to-date as possible. ## KPIs refactor in progress Following the several data needs in the past weeks in terms of KPIs, we ended up building quite a few models within DWH, which has become a quite complex ecosystem. In order to keep our flow as scalable as possible, we’re conducting a small refactor that will not have any impact on the business users; but that will enable us to maintain and provide new initiatives in the future much easier. The scope of this refactor is double: - Ensure that any metric, even if complex, is computed within our KPIs folder, following the Data Team conventions. This was not the case for heavy logic metrics in the scope of Churn Rates and Onboarding MRR. - Remove the strict dependency on Account Management reporting from the monthly by deal KPIs. This has served as well for the past months but being realistic, we need more timely data regarding Account performance. Conducting this decoupling enables us to freely adapt the Account Management data flow without impacting other reports. Additionally, we’re testing a new framework called dbt audit helper that is very helpful to identify changes between model outcomes. This enables us, for instance, to validate that the previous output of a production model is exactly the same as the new proposed refactored model - and if it’s not the same, it will identify which rows have differences. Combining this audit tool with a few other tricks, we’re able to easily - and rapidly - try code while ensuring the output remains the same; even for tables with tens of columns and millions of rows. ## Data-driven flagging project gets a green light In Truvi, we have visibility on the details of bookings and the incidents that happen in them. For hundreds of thousands of bookings per year. This puts Truvi in a unique position to *know* (not guess, but actually know) what characteristics of a booking, listings and guests can be early signs of damage risks. Building data-driven, automatic, risk-assessing models would enable us to deliver great value to our customers and much more performant risk-management policies for our company. Succeeding in this area would boost the P&L by improving our products (more sales, less churn) and by helping us reduce our resolutions payouts (save in protection costs). This is an idea that has been wandering around the company for some time. Together with Matt, we decided to shape this a bit more seriously and discuss it. The Data team’s proposal (which you can find here: [20250331 - Actuarial Screening Project Proposal](https://www.notion.so/20250331-Actuarial-Screening-Project-Proposal-1c70446ff9c9809f8285eba86ddcbdb2?pvs=21) ) was born, and we’ve agreed to give phase 1 of this project a go. Our goal for phase 1 is to simply measure the performance of our current flagging system in terms of spotting risk, and running some numbers in terms of how would improvements in flagging drive results for Truvi and our customers. We are committed to complete phase 1, but will decide if we pursue the rest of the project depending on what we find during this first phase. # 2025-03-28 ## Business Targets is now live As presented recently in the Town Hall, we have been working on a big piece of work to be able to track performance against targets. This target exercise has been going on for a while, and has finally been materialised in several updates in Main KPIs to be able to track in far more depth the main metrics. In essence, Main KPIs now actually contains KPIs, while before it was mostly containing tons of metrics. Probably the biggest impact of this piece of work is a simple yet informative Power BI tab in Main KPIs called **Business Targets:** ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2023.png) In this report we will be able to see the latest status of the main timely drivers of performance for our business, always updated up to yesterday (included). The main drivers are the following: - **New Deals**: how many new clients are going live? - **Churning Deals**: how many existing clients are offboarding? - **Live Deals**: how many clients are currently live? - **Host Resolutions Payouts**: how much are we paying out in terms of resolutions? - **Billable Bookings**: how many bookings can be billed? Each of these drivers has a target, displayed in pink in the gauges. For these drivers, we have both a Monthly tracker as well as Year-To-Date (YTD) tracker: the monthly reflects on how much we should achieve (or avoid reaching) in a given month, while the YTD aggregates all prior monthly targets to the current month. It’s important to state that the year considered is the financial year, and not the calendar year. This means that the financial year 2025 ranges from 1st April 2024 to 31st March 2025. We can also see that there’s an Actual and Projected value. The Actual value is the value observed in the Month-To-Date or Year-To-Date up to the Last Update date. The Projected, on the other hand, is a forecasted value at the end of the month. So, if we focus on New Deals as an example: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2024.png) We see that we achieved 69 New Deals from the 1st of March to the 27th of March. We’re aiming to reach to at least 86 by the 31st of March. If we keep the same rate of New Deals constant in the 4 remaining days, how many New Deals would we have by the end of March? So that would be: 69 New Deals divided by 27 days ~2.6 New Deals per day. If we multiply this by 31 days we would get the ~79 New Deals that we’re projecting by the end of the month. In other words, we’re projecting that there’s 10 New Deals that we might potentially bring at this rate. Since this figure of 79 Projected New Deals is below the target of 86, figures are displayed in red, indicating that we’re at risk of not achieving this objective. This can also be observe by noticing that the grey sector does not surpass the pink target line. For YTD, the idea is the same. The 982 Actual contains all New Deals brought from 1st of April 2024 to the 27th of March 2025. If adding up the Actual the 10 projected New Deals of this month, we will get the 992 Projected New Deals in terms of YTD. It’s worth noting that a metric being below target can be good in some cases, such as Churning Deals (the less clients that offboard, the better!) or even Host Resolutions Payouts: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2025.png) In this case, we observe that in a Monthly level we’re far below the target so figures are green. However, in YTD this figure actually surpasses the target thus being bad. Effectively this means that in the past months we didn’t achieve the targets, as the current one is going very well so far. For Live Deals however, things are a bit differently. Both the Monthly and YTD is the same value, and we only display the Actual value (we only count clients that are currently live). We cannot directly influence Live Deals, but rather, capture new clients and ensuring the existing ones do not offboard. Last but not least - we will be sending weekly emails to all Truvi employees for you to have this figures in mind! First delivery is expected for Friday 4th of April. ## New Dash Migration project: automating data extraction Back in the beginning of the year we supported our AMs colleagues by providing pricing estimates when a user would transition from Old Dash to New Dash, effectively getting the new services and pricing. Now… this has been outdated for a while, and we were in need to do another update. Since the exercise carried out back in the day was quite complex in terms of Excel formulas, we decided to automate as much as possible the data extraction so we would be able to provide faster updates in the future. This mostly includes computing a big part of the logic directly in SQL, while previously it was found in Excel. A couple of versions have already gone out and we’re finalising some additional requirements in order to reduce manual workload from AM teams in charge of the migration. ## New Dash reporting updates As the migration of clients from the old to the new dashboard progresses significantly, our focus has shifted toward **enhancing data depth** and **improving reporting capabilities**. This week, we've been developing new models to **analyse the adoption and usage of New Dash services** across: **Account users** – Percentage of users offering the service. **Listings** – Share of active listings with the service enabled. **Bookings** – Percentage of bookings where the service has been applied. By implementing these metrics, we’ll be able to track **historical trends** and answer more questions like: - *Are more of our customers adopting this service over time?* - *Is there any decline in usage that we need to address?* To complement these insights, we're also introducing **deal lifecycle states** in the **Overview** and **User Details** tabs. This segmentation will allow users to: - Analyse service adoption based on different deal lifecycle stages. - Exclude **churned deals** for cleaner metric numbers. With these updates, the **New Dashboard Report** is becoming an even more relevant tool for tracking customer engagement and service adoption trends. ## dbt CI pipelines are now protecting your reports As the Truvi data needs grow and evolve, our DWH keeps on growing more and more complex. With close to 400 tables and a few thousands of columns, working on it is not faint of heart. Because of this, complexity, the risk of making mistakes when developing our DWH is increasing, which can lead to side effects like reports not displaying what it should, or anything at all. To unload some of this burden from the Data team member shoulders, we’ve recently set up Continuous Integration (CI) pipelines in our code repository. These pipelines are a series of automatic steps that get executed every time a team member wants to modify the code in the DWH. They check several possible mistakes that might be introduced, and act as a traffic light of sorts: if everything is ok, we can go ahead and use the code. If we identify any issue in the pipeline… that’s great! One bug that didn’t slip through. ![Our CI pipeline letting Uri know he hasn’t broken main KPIs… this time.](Data%20News%207dc6ee1465974e17b0898b41a353b461/continuousintegrationdronepr-build-is.jpg) Our CI pipeline letting Uri know he hasn’t broken main KPIs… this time. As many other technicalities, you probably won’t *see* this much… but remember, that everyday you wake up and your report is there, working as always, it’s because of tools like this! # 2025-03-14 ## New Dash reporting small improvements This week we’ve also continued on the small improvements on New Dashboard reporting in Power BI. We’ve added a small display in the Overview page to show the amount of distinct Deal Ids we have in addition to the existing New Dash User count. ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2026.png) In theory, in New Dash, a Deal should only be represented by a single User. However, we’re noticing during the migration that this is not always the case, and sometimes, we even get some alerts due to the duplicity of Deals among different users. This small change should provide better overview on data quality for New Dash. Additionally, we’ve taken the opportunity to do some minor changes such as adding the share of chargeable amount in the Chargeable Services summary table: ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2027.png) Lastly, we also took the opportunity to update the report with the new Truvi style. ## New Guest Products tables ingested into DWH This week we’ve also started a new line of work to be able to capture Guest Products in DWH. At the moment, the following new backend tables are in sync: - guestProduct.DisplayDetail - guestProduct.Configuration - guestProduct.ConfigurationLevel - guestProduct.ConfigurationPricePlan - guestProduct.ConfigurationStatus - guestProduct.Product - dbo.VerificationRequestToGuestProduct - dbo.VerificationRequestGuestProductToPayment The first step into DWH modelling which is staging has also been completed for all the abovementioned tables, and we’re currently deep-diving into the intermediate side. There’s still work to do here, so keep tuned for further updates. ## Anticipating account behaviour: First steps towards account-based created bookings forecasting It is well known that different metrics have different time availabilities. For instance, within DWH we’re able to provide the amount of bookings created up to yesterday, but we’re not able to do so for total revenue as this depends on the invoicing. Rather, on Main KPIs, we will have the February total revenue figures available on the 20th of March. However, for Account Managers reporting, this will be available on the 1st of April. While this is important to ensure a certain level of data quality within the reported metrics, we are also in need to anticipate account behaviour, specially to understand potential upcoming impacts and prevent churn. Ideally, we would like to forecast revenue-related metrics for each account, as this is the most insightful measure on account performance. However, forecasting revenue is… well, complicated. We have different client types, from APIs to Platform, with different dashboards, different applied services and price plans and these can change in different moments in time, etc. So to start with we have started by doing something far more simpler: aiming to predict how many bookings an account would have created at the end of the current month. In many cases, the amount of bookings created is a good indicator of the performance - despite not being perfect - and can help understanding in almost real-time if there’s any change in behaviour at account level. While account-based forecasting is a clear use-case, keep in mind that we predict this for any category/dimension, since this depends on our KPIs models. For instance: ![Snapshot of the top 12 categories that, as of 17th of March, have had the most created bookings in the current month of March. With the actual figures we’re able to estimate a end of month figure as shown in current_month_projected_created_bookings. How good is this projection? Well, it depends, as shown in the relative_error. As of 17th of March, it seems that Old Dash (1.3%) and Global (3.7%) projected bookings are quite stable, while for instance in New Dash (34%) we’re less certain of how the month will end. This is normal since New Dash is having more and more clients migrated, thus generating more bookings, thus more difficult to predict.](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2028.png) Snapshot of the top 12 categories that, as of 17th of March, have had the most created bookings in the current month of March. With the actual figures we’re able to estimate a end of month figure as shown in current_month_projected_created_bookings. How good is this projection? Well, it depends, as shown in the relative_error. As of 17th of March, it seems that Old Dash (1.3%) and Global (3.7%) projected bookings are quite stable, while for instance in New Dash (34%) we’re less certain of how the month will end. This is normal since New Dash is having more and more clients migrated, thus generating more bookings, thus more difficult to predict. In order to have a forecast at account level, we currently have a very simple model within DWH that aims to project the amount of bookings created at the end of the month by using: - The average amount of bookings created in the past 7 days, and - The average amount of bookings created in the current month-to-date Intuitively, at the beginning of the month, this projected figure is likely going to be quite inaccurate. However, as the month advances, it’s going to get closer and closer to the final, real figure. In order to provide an estimated measure of by how much we can trust this projection for the current month, we do a simple exercise: we apply the same projection logic for the past 3 months, and compare these previous months forecast vs. the actual end of month figures. From these we are able to get a simple projection error that we can attribute to the current month projection. This is also very important if at some point we want to try other forecasting methods, so we’re able to choose the one that gives the best results. We’ve also compared a few cases of projected booking decay with actual data and input from our Account Managers colleagues and it seems to work well within reasonable limits - at the end, trying to predict the future is a complex task. For the time being, this projection logic is still sitting in DWH waiting to be leveraged to the business teams. Keep tuned for further updates! ## Deals lifecycle alignment with HubSpot We recently identified a discrepancy between the data used in our financial model for Live Deals and the data available in Power BI. The difference became evident when comparing our reporting approach with Alex Anderson's methodology for retrieving and structuring deal data. To resolve this, we decided to align our entire deal lifecycle with HubSpot, ensuring consistency with the reporting structure Alex has been using. This transition has significantly improved accuracy, bringing reported amounts much closer together. While this is a step forward, we are still working on filling in some missing data within HubSpot. Additionally, some deals do not exist in HubSpot at all. These will now appear in our reports under the label **"99-NOT IN HUBSPOT"** to clearly indicate their status. ## Successful Excel tips & Tricks Session Our recent **Excel Tips & Tricks** session was a great success! 🚀 You can find the recording of the session here https://guardhog-my.sharepoint.com/personal/joaquin_ossa_superhog_com/_layouts/15/stream.aspx?id=%2Fpersonal%2Fjoaquin%5Fossa%5Fsuperhog%5Fcom%2FDocuments%2FRecordings%2FExcel%20useful%20tips%20session%2D20250312%5F150535%2DMeeting%20Recording%2Emp4&referrer=StreamWebApp%2EWeb&referrerScenario=AddressBarCopied%2Eview%2E75aed233%2D08f6%2D4ff2%2D8d21%2D6de356fd5450 and the documentation [Excel Tips and Tricks](https://www.notion.so/Excel-Tips-and-Tricks-15e0446ff9c980b59831df76c4d41567?pvs=21) ### **What we covered:** ✅ Most-used shortcut keys for faster navigation ✅ Basic and advanced formulas to boost efficiency ✅ Best practices for cleaner and more effective spreadsheets We’re also available for more personalized sessions tailored to your team’s needs! If you'd like a **closed session**, we can work through practical problems together to help your team get more comfortable with Excel. **Hands-on learning is the best way to master it!** 📊 # 2025-03-07 ## Detecting Hyperline invoices in Xero This week we’ve carried out a small improvement in our accounting DWH models of Xero to be able to discern which invoices and credit notes come from Hyperline and which are not. The main benefit around this is to ensure that invoices and credit notes are correctly attributed to a month in the same manner as we do for the old documents in Xero. In other words, ensuring that our reporting is consistent. While at some point in the future we’ll much certainly read invoicing information from Hyperline itself, we will still need to be able to exclude those are copied over to Xero to avoid duplicity on the invoices. Also this ensures that during this transition period in which both Hyperline and Xero are used for invoicing purposes, we have control on DWH to ensure proper reporting capabilities. ## Platform or API deal type now available in Account Managers reporting A small improvement has been released this past week concerning Account Managers reporting, both for the AM Overview and the AM Margin: now we’re informing whether the Deal is an API client or a Platform client. ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2029.png) While this is not a massive change from user point of view, it has enabled us to identify these deals in the modelled structure within DWH. This will likely be of massive help in the future when improving KPIs and Account Managers reporting capabilities, as having this distinction means we can implement different logic if needed. ## Truvi rebranding on Power BI ongoing This week we’ve also started on the Power BI rebranding, which effectively means modifying the background, logo and some colour displays around Power BI to fit with Truvi’s brand. ![The new template in place for Main KPIs](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2030.png) The new template in place for Main KPIs At the moment these reports have already been rebranded: - Main KPIs - Account Managers (all reports) - Miscellaneous Reports (Currency exchange and Deal consolidation) - Truvi Reporting (previously Superhog Reporting) - API reporting (all reports) While we still have many reports to update, we will do so either when we need to work on them for another reason or when we have a few minutes to spare. Massive thanks to Pedro and Sergio for creating the new Truvi templates for Power BI! ## New Churn Report is now live We’re excited to announce the release of a new Churn Report in the Account Managers reporting app! Previously, account managers had to extract this data manually from HubSpot, resulting in only basic and essential insights. This new report automates the process and includes additional valuable data to better support the team. It provides insights into the number of accounts that have churned throughout Truvi's history, including their performance and reasons for offboarding. ![image.png](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2031.png) We hope this helps account managers better understand the impact of churned accounts and identify ways to enhance support for our current clients. [Churn Report - Power BI](https://app.powerbi.com/groups/me/apps/bb1a782f-cccc-4427-ab1a-efc207d49b62/reports/d4955aad-1550-46c7-9549-2bdeebb99286/ReportSectionddc493aece54c925670a?ctid=862842df-2998-4826-bea9-b726bc01d3a7&experience=power-bi) ## New Dash fixes and improvements Last week, we made several updates and fixes to the New Dash Overview report. We introduced the new Guest Agreement service, a free offering for some client bookings as part of their program. Additionally, we fixed a couple of bugs—special thanks to Alex’s sharp eye for spotting these! One issue involved displaying inactive PMS accounts, while another affected the correct computation of bookings with guest services. A big shout-out to Alex for helping us catch these! We encourage everyone to stay vigilant and report any potential errors in our reports. While we strive to minimize mistakes through thorough reviews within the data team, occasional slips can happen, and your feedback is invaluable in ensuring accuracy. # 2025-02-28 ## Resolutions Incidents Report Now that we have access to Resolution's data, we’re excited to introduce a new report designed to generate valuable insights from this information. Our first delivery will be the Resolution Incidents Report, which provides a comprehensive overview of incidents reported by hosts. This report will include agent performance metrics (insights into case handling and decision-making) host incident trends (number of incidents, claims, and resolutions) and detailed incident breakdown with a complete view of each case, including compensation amounts and resolution processes. This report will help us better understand trends, improve decision-making, and optimize our resolution process. ## Upcoming Excel Training Session Are you ready to take your Excel skills to the next level? Join us for an upcoming **Excel training session** next Wednesday March 12th where we'll cover key practices to improve efficiency, essential **shortcut keys**, and powerful **formulas** to make your work easier and more effective. ### **What will we see?** - **Time-Saving Shortcuts** – Master the most useful keyboard shortcuts for faster navigation and data handling. - **Essential Formulas** – Discover formulas that simplify complex calculations and analysis. - **Recommended Best Practices** – Learn how to structure and manage your data efficiently. Whether you’re a beginner looking to improve your workflow or an experienced user wanting to refine your skills, this session will provide valuable insights to **work smarter, not harder** in Excel. Stay tuned for the session details—we look forward to seeing you there! ## Towards FY2026: Main KPIs update Tracking metric performance against targets is crucial as we approach the start of the new financial year 2026, in April 2025. To support this, we have updated the Power BI report **Main KPIs**, incorporating three new tabs designed to enhance visibility and analysis of key business metrics. ![New tabs available in Business Overview - Main KPIs report](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2032.png) New tabs available in Business Overview - Main KPIs report The **Main KPIs** report now features: - **Main KPIs Overview** – A revenue and payouts-focused tab, providing insights into the evolution, contribution, and impacts of these figures on Month-to-Date (MTD) and Year-to-Date (YTD) performance. This high-level view ensures a quick grasp of financial health. - **KPIs Tracking** – A holistic snapshot of performance against targets for all metrics within a single month. This tab enables a comprehensive understanding of where we stand across different key indicators. - **KPI Detail** – A deep-dive view for individual metrics, comparing performance against targets (both MTD and YTD), as well as achievement rates relative to End-of-Financial-Year (EOFY) goals. Additionally, this tab features a graphical display that visualizes trends over time. With these enhancements, teams will now be able to track and analyze performance with greater clarity and precision. Whether assessing overall revenue impact, evaluating specific KPI progress, or identifying trends over time, the new tabs on **Main KPIs** report serves as a powerful tool for data-driven decision-making. # 2025-02-21 ## Resolutions Data ingested into DWH This week we’ve reached a new milestone: Resolution Center data is now ingested in DWH. We have a new integration with the Incidents container on CosmosDB that contains Resolutions data, which will enable us in the future to gain further understanding on Claims and enrich our reporting. After a few days, we confirm that the integration between CosmosDB and DWH for this Resolutions stream is working nicely. At this stage the information is mostly stored in a raw manner, as it comes from Cosmos DB. In the following days we’ll start modelling the data internally to enable reporting and analytical use-cases. ## Screen & Protect Invoice Report Over the past few weeks, we have been developing new models to streamline the invoicing process for our latest API products, such as Screen & Protect and Check-in Hero. These models are designed to improve efficiency and accuracy in our billing system. Now we have finished working on the **Screen & Protect API invoice report, t**his report provides a detailed breakdown of all API transactions, ensuring transparency and accuracy in billing. It captures key data points such as transaction counts, associated costs (depending on the protection plan for each client), making it easier to validate and reconcile invoices. ## New Active PMS Report As part of our ongoing efforts to enhance Superhog reporting in Power BI, we have now completed the final update—**the Active PMS Report**. This report provides **detailed insights into active Property Management Systems (PMS) within Truvi**, including: **Accounts with Active PMS** – A clear overview of all accounts using a PMS **Number of Listings** – Tracking the number of properties associated with each PMS **Bookings Generated** – Insights into the volume of bookings coming from each system The **Active PMS Report** is a valuable tool for monitoring partner activity and understanding the impact of different PMS platforms on our business. ## Billable Bookings metric adaptations Following the inclusion of the [new Business Scope category](Data%20News%207dc6ee1465974e17b0898b41a353b461.md) in Main KPIs, we’ve reworked how Billable Bookings are considered depending on the business scope - Old Dash, New Dash & APIs. We have now 2 metrics: - Est. Billable Bookings: this is mostly a continuation of our previous metric. This takes into account in an estimated manner WHEN a booking is supposed to be Billed. For Old Dash, this follows the previous logic that depends on the Price Plan of the user. For New Dash, this is assumed to be on the first date that any billable service of that booking can be billed. This means that if a New Dash booking has several billable services that are billed in different timeframes, we will assume the booking to be billed within the first billable date. This metric is timely, but might not be 100% accurate depending on the use-case, since attributing bookings to a billable time is opinionated. - Billable Check Out Bookings: while it’s complex to say when a Booking is billable, it’s much easier to assess if a Booking is Billable or not. This is why we can attribute the concept of a Booking being billable once all possible services have been billed; this is, at the end of the lifecycle of the booking: at check out date. This is exactly what this metric on Billable Check Out Bookings does, in the sense that it only captures Billable Bookings at a given Check Out date. This metric is more accurate, but it’s not timely. For APIs so far we don’t have any content on Bookings since we still need to work out internally the implementation. For further information, we encourage you to check the Data Glossary which contains the definitions of both metrics. # 2025-02-14 ## Data News update: previous history moved to a separate Notion page After several entries in the Data News, we reached a point in which opening the Notion page or adding new content has become painfully slow - this is how busy we are in the Data Team to deliver new content! In short, we’ve cleaned the Data News page. The previous content, from the 1st of December 2023 to the 7th of February 2025, is available in this separated Notion if ever you need to get back to it: → [Data News - From 1st Dec 2023 to 7th Feb 2025](Data%20News%207dc6ee1465974e17b0898b41a353b461/Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) ![What a milestone!](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2033.png) What a milestone! ## Main KPIs new category: By Business Scope We’ve been busy [these past few days](Data%20News%207dc6ee1465974e17b0898b41a353b461/Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) in order to deliver a very insightful feature: allowing the possibility to split most of the metrics in Main KPIs by Old Dash, New Dash or APIs. This feature is now live and is accessible as a new Category, named Business Scope. The possible values for this category are the following: - **Old Dash:** platform clients that generate activity (bookings, revenue, etc) under Old Dashboard - **New Dash:** platform clients that generate activity (bookings, revenue, etc) under New Dashboard - **APIs:** APIs clients such as Guesty, E-Deposit, etc. ![Contribution to Total Revenue per Business Scope categories on December 2024.](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2034.png) Contribution to Total Revenue per Business Scope categories on December 2024. The source to categorise between APIs and Platform is based on Hubspot Deals, similarly as we already did for Onboardings/Offboardings/other Hubspot data. However, the split between Old Dashboard and New Dashboard is a bit more complex, because the same Deal can be in both New Dash and Old Dash in different moments in time. For New Dash, we mostly rely either on: - **If a Booking comes from New Dash**: from here we can retrieve many metrics, such as Bookings, Guest Journeys, Guest Payments, etc. This should be relatively accurate. - **The moment in time in which users move from Old Dash to New Dash:** we only rely on this if we do not have any other more accurate way to handle the split. This affects metrics that are Deal-dependant, such as Deal metrics, Listing metrics, etc. and also affects Xero-related metrics such as Invoiced Revenue and Resolution Payments. In these cases, we attribute these as New Dash once the user has moved from Old Dash to New Dash. This might not be 100% accurate specifically on the transition month, since a user can still be invoiced for Old Dash concepts while already in New Dash. Still though it can be seen as a good approximation and as more users distance themselves from such a transition, this split should become more and more accurate. Lastly, there’s also some users that are excluded from this categorisation, such as KYG Lite users. These were originally in Old Dash and now are currently in New Dash, since these were the first to move during the New Dash MVP. However these users have been excluded from a while in New Dash reporting since… well, technically, we do not care about them. Therefore, in order to keep consistency between New Dash reporting and Main KPIs, these KYG Lite users are NOT included in any category. ![Double click me to display properly. Example of some New Dash metrics in the MTD tab up to 16th February 2025](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2035.png) Double click me to display properly. Example of some New Dash metrics in the MTD tab up to 16th February 2025 The majority of the metrics are already available for this new category. The main exceptions are Estimated MRR and Churn metrics, in which we need to deep-dive to understand the feasibilities, and Billable Bookings, in which we have a different definition that needs implementation before making it available. ## Main KPIs new metric: Live Deals [Last week we presented the first Year-To-Date Overview tab](Data%20News%207dc6ee1465974e17b0898b41a353b461/Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), which was stated as a first draft. Currently we have gathered the requirements on what needs to be included and how it is supposed to be presented. While handling this, we discovered we actually needed another metric to define Deals that have been onboarded and that have not churned. This metric is now available under the name of Live Deals. This corresponds to Deals that are New, Never Booked, Active or Reactivated - so, in short, any Deal state that has not churned. ![Example of Live Deals since July 2024 split by Business Scope. The Pink line represents New Dash accounts, and we see how these have been increasing specially since December. Note that at the moment of this screenshot, there’s still remaining days for February so likely the amount of Deals migrated will increase in the following days.](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2036.png) Example of Live Deals since July 2024 split by Business Scope. The Pink line represents New Dash accounts, and we see how these have been increasing specially since December. Note that at the moment of this screenshot, there’s still remaining days for February so likely the amount of Deals migrated will increase in the following days. A very interesting use case for this metric can be to follow the migration of users from Old Dash to New Dash. Linking this metric to the previously announced category “By Business Scope”, we are able to track over time the number of accounts that effectively are in each scope with one day delay. Lastly, a small data quality subject to be considered: currently we do not have a proper way to exclude test accounts, thus is likely that the amount of Live Deals reported is slightly over estimated. A similar thing is happening to the rest of Deal metrics. ## New Dash service adoption is now live This week we’ve also [continued on New Dash reporting improvements](Data%20News%207dc6ee1465974e17b0898b41a353b461/Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), with the goal being to provide more insights on the service adoption on New Dash. We’ve released a new tab in New Dash Reporting Power BI report named Offered Services. This tab allows to understand, for a given service, the amount of users, listings and bookings that have this serviced offered. ![Example of Offered Services tab for the service Protection Pro](Data%20News%207dc6ee1465974e17b0898b41a353b461/image%2037.png) Example of Offered Services tab for the service Protection Pro This is further split by the status: in the case of Bookings, the status of the service itself. In the case of Listings, whether these listings have a program applied containing this service, while not being inactive. Lastly, for users, these are considered active for a given service if at least these have an active listing with a program containing that service. While this is a first step towards understanding the adoption of New Dash services, there’s likely many more possibilities that we can explore in order to improve the coverage. Still this provides a first basic understanding of the general adoption per New Dash service. ## Superhog reporting back alive In the scope of [re-working Superhog reporting](Data%20News%207dc6ee1465974e17b0898b41a353b461/Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), we’re glad to announce that now the reports of Listings, Bookings and Payments have been fully migrated under DWH scope, in which Data team has control. We also re-deployed the PMS report. This one is still reading from the Backend, but conversation is ongoing to see if we can replicate it from DWH similarly as we did for the previous reports. # Prior Data News History Apparently Notion cannot handle well massive pages! If at some point you need to recover the previous Data News history, you can access it through this link: [Data News - From 1st Dec 2023 to 7th Feb 2025](Data%20News%207dc6ee1465974e17b0898b41a353b461/Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md)