2695 lines
No EOL
259 KiB
Markdown
2695 lines
No EOL
259 KiB
Markdown
# Data News - From 1st Dec 2023 to 7th Feb 2025
|
||
|
||
A place to communicate progress, achievements, updates and generally any new thing from the Data Team. Come regularly to stay updated.
|
||
|
||
# 2025-02-07
|
||
|
||
## Booking Fees per Billable Booking decrease analysis
|
||
|
||
Our latest analysis explored the decline in Booking Fees per Billable Booking, which dropped from ~6 ****GBP (mid-2023) to ~3 GBP (late 2024). Initially, this trend raised concerns about a structural decrease in invoiced revenue per booking. However, after a detailed investigation, we identified key factors behind the drop:
|
||
|
||
- **Guardhog Booking Fees removal:** A major portion of the decline was due to the elimination of Guardhog-related fees in June 2024, which previously inflated the metric. Adjusting for this, the perceived downward trend largely disappears.
|
||
- **Temporary invoicing issue:** A billing error in Nov–Dec 2024 resulted in missing fees, later corrected in January 2025. This was an isolated event with no lasting impact.
|
||
|
||
Additionally, we explored a potential impact coming from cancellations. However, these rates remained stable, thus this hypothesis has been discarded.
|
||
|
||
.png)
|
||
|
||
Booking Fees per Billable Booking. The dashed line corresponds to the original observed values, in which we can observe an almost consistent decrease. The solid line corresponds to the corrected values once taking into account Guardhog Booking Fees and the invoicing incident late 2024.
|
||
|
||
Once these factors were accounted for, the initial structural revenue drop is largely minimised. The remaining variations can be, potentially, linked to seasonal trends due to client mix. However, we will continue monitoring trends to ensure a solid understanding of long-term movements.
|
||
|
||
The in-depth analysis can be found in this Data Paper:
|
||
|
||
[2025-02-04 Booking Fees per Billable Booking Decrease ](https://www.notion.so/2025-02-04-Booking-Fees-per-Billable-Booking-Decrease-1840446ff9c980588958c56a8b600d47?pvs=21)
|
||
|
||
## Reworking Cancelled Bookings in Main KPIs
|
||
|
||
There has been quite a bit of misconceptions recently on the impact that Cancellations can have into our business. When a drop in certain metrics is found, a first hypothesis that usually comes into the table is the potential raise of Cancelled Bookings that could explain the situation.
|
||
|
||
The fact that in Main KPIs we computed Cancelled Bookings and were always showing a big increase YoY with an always red label didn’t help either. The reality is that this metric of Cancelled Bookings was not accurate in how it was attributed to a date. Whenever we built it first, we assumed that once a Booking gets Cancelled, the record of that Booking couldn’t have further updates. However, this has proven to not be true, thus the metric was not reliable on time, and there was always chances that Bookings that were already Cancelled a while ago could be re-attributed in the future thus always showing big increases in the recent days of the MTD tab in Main KPIs.
|
||
|
||
When we were doing the analysis of Booking Fees per Billable Booking Decrease, we explored the potential impact on Cancellations on that specific problem. Knowing that we couldn’t purely rely on the metric Cancelled Bookings, but that we were able to rely on the status itself, we created some cancellations rates attributed to the check-out date: and surprise, despite the metric is not completely stable over time, there’s was no real feeling of an increase in cancellations.
|
||
|
||
This is why we’ve decided to rework Cancelled Bookings in Main KPIs following a similar approach. In essence, we have dropped the previous Cancelled Bookings metric and created:
|
||
|
||
- **Cancelled Created Bookings** → Bookings that are cancelled, attributed to when the Booking is created.
|
||
- **Cancelled Check Out Bookings** → Bookings that are cancelled, attributed to when the Booking is completed (check-out date).
|
||
|
||
With this, we’re able to also compute:
|
||
|
||
- **Created Bookings (Excl. Cancelled)** → Total Created Bookings indistinctly of the state minus Cancelled Created Bookings
|
||
- **Check Out Bookings (Excl. Cancelled)** → Total Check Out Bookings indistinctly of the state minus Cancelled Check Out Bookings
|
||
|
||
And with these metrics we can compute effective cancellation rates as:
|
||
|
||
- **Created Booking Cancellation Rate** → Cancelled Created Bookings divided by Total Created Bookings.
|
||
- **Check Out Booking Cancellation Rate** → Cancelled Check Out Bookings divided by Total Created Bookings.
|
||
|
||
|
||
|
||
Check Out Booking Cancellation Rate (as a %) per month, split by year, from Main KPIs - Global Evolution over Time
|
||
|
||
These metrics are definitely much more accurate to follow. However, a very important note: Created Bookings can get cancelled at any point until these have Checked Out. This means that the initial cancellation rates closer to Creation time will always be lower than the final figure once these are completed. So we recommend checking this metric with caution.
|
||
|
||
Lastly, these new metrics have the same categories available as most of the metrics, meaning we can deep-dive into By # of Listings segmentation and By Billing Country. Below a few examples:
|
||
|
||
|
||
|
||
Check Out Booking Cancellation Rate (as a %) over time, by # of Listings segmentation. We see how small clients (01-05) are actually increasing their cancellation rate over time while bigger clients have overall less cancellation rate.
|
||
|
||
|
||
|
||
Check Out Booking Cancellation Rate (as a %) over time, by Billing Country, only considering the 2 most important countries: USA and GBR (UK).
|
||
|
||
## Main KPIs first draft on YTD is now available
|
||
|
||
It’s been a while since we started building Main KPIs back in June 2024. In this period of time, there has been a massive increase in the number of metrics that we’re tracking and, well, it’s starting to be a bit overwhelming to get fast insights if you do not know exactly what you need to look for. Are all metrics important? Is there a few ones that might be representative of the overall business?
|
||
|
||
In this sense, we’ve been preparing internally a first draft of the metrics that we, at Data side, check the most. The idea is to present these in an overview tab so it’s easy to understand and more welcoming. We’ve decided that for the first draft we’d take a look at the evolution of these metrics in a Year To Date, and here’s the result:
|
||
|
||
|
||
|
||
A real example of how the tab looks like for a given segment and year that are not made available. Each metric shows in a callout the YTD value of the selected year. Below, in PY YTD we have the same value observed in YTD for the previous year. Additionally, we have the difference between YTD and PY YTD both in absolute and relative ways. Lastly, depending on the type of the metric and the increment/decrement, figures will show automatically in Green if it’s going well, Red if it’s going bad and Black if there’s no data to compare against.
|
||
|
||
In the top line, we have the 3 main indicators: Total Revenue (income generated), Revenue Retained (deducting Host Takehome amounts, so, Damage Host-Waiver Payments) and Revenue Retained Post-Resolutions (deducting both Waiver Payments and Host Resolutions Payments).
|
||
|
||
These 3 indicators are a direct sum of the second line: Total Revenue is composed by adding Guest Revenue, Invoiced Operator Revenue and Invoiced APIs Revenue. If adding Damage Host-Waiver Payments we get Revenue Retained, and if also adding Host Resolutions Payments we get Revenue Retained Post-Resolutions.
|
||
|
||
The reality though is that many of these metrics are Invoicing-dependant, thus information is not timely. The only exception so far is Guest Revenue, that depends on the Guest Payments from the Backend.
|
||
|
||
This is why we’ve also added a third line, that aims to represent if we should expect more or less growth and sustainability based on purely timely metrics. These are the following:
|
||
|
||
- **Avg. Deals Booked per Month**: in short, average number of clients that are active per month.
|
||
- **Total Churning Deals**: amount of clients that have offboarded in the whole year to date.
|
||
- **Avg. Listings Booked per Month**: average number of listings that are actively generating bookings per month.
|
||
- **Check Out Bookings (Excl. Cancelled)**: Total amount of Bookings that have Checked Out in the whole year to date, that have not been cancelled.
|
||
- **Guest Journeys Completed**: Total amount of verification requests processes that have been completed.
|
||
|
||
Now, while this is already available, we consider this as a first draft. The idea would be to gather your feedback on what should be really important to track and discuss the best way to represent it. So we’re expecting changes in the coming days - don’t take this first snapshot for granted.
|
||
|
||
Lastly, for those that want to follow this in a daily basis, now we have the possibility to get this in a daily (or weekly, or monthly) email by subscribing to this page and setting the Year filter on 2025.
|
||
|
||
|
||
|
||
Example of the e-mail Uri received on Feb 9th with the latest update on this tab.
|
||
|
||
Feel free to contact us to help you setting it up in this regard. Looking forward your feedback!
|
||
|
||
## Work in progress on metric split per Dash source
|
||
|
||
This week we’ve started to work on the allowing the possibility to split the majority of the metrics available in Main KPIs by type of Dashboard. This means, for instance, being able to track the Bookings that are coming from Old Dash and those from New Dash separately.
|
||
|
||
The idea is to have this as a new Category, alongside the By # of Listings segment and By Billing Country categories.
|
||
|
||
This piece of work is currently work in progress and is still not available in Main KPIs. Once we have it it will allow to properly track the New Dash migration and understand any impact due to the migration.
|
||
|
||
## Updating Superhog Production reports
|
||
|
||
Over the past few weeks, some of our reports faced connection issues, preventing them from updating. Surprisingly, no one raised concerns, leading us to believe they were no longer in use. This prompted a discussion about discontinuing all reports in Superhog Production.
|
||
|
||
To test this assumption, we began deleting them one by one—only to discover that several teams still rely on these reports! In response, we shifted our focus to fixing the connection problems and ensuring all reports were up to date.
|
||
|
||
### Progress Update:
|
||
|
||
✅ **Listings Report** – Completed, providing detailed data on all listings.
|
||
|
||
✅ **Bookings Report** – Completed, delivering comprehensive booking insights.
|
||
|
||
🔄 **Payment Report** – Work in progress. After discussing tax and waiver fee calculations with Finance, we are finalizing updates to this last report.
|
||
|
||
We're nearly there—thanks for your patience! 🚀
|
||
|
||
## Work in progress on new features on New Dash services
|
||
|
||
Last week, we began working on improving the visibility of services offered by New Dash users across their listings and bookings. This initiative was driven by requests from several stakeholders seeking greater clarity on service adoption.
|
||
|
||
### **User Adoption per Service**
|
||
|
||
Understanding which users have specific services configured is key. Our goal is to adapt the **User Adoption Funnel**, which currently focuses on “has any upgraded service,” to instead track “has a certain service.”
|
||
|
||
### **Adoption Breakdown:**
|
||
|
||
📌 **Total Users** – All users in the system
|
||
|
||
📌 **Users with a Service in a Program (Bundle)** – Users who have at least one service in a bundle
|
||
|
||
📌 **Users with a Service in a Listing** – Users whose bundle services are applied to their listings
|
||
|
||
📌 **Users with a Service in a Booking** – Users whose services are applied at the booking level
|
||
|
||
With these insights, we aim to provide better tracking and analysis of New Dash services, helping teams make data-driven decisions. Stay tuned for updates!
|
||
|
||
# 2025-01-31
|
||
|
||
## January Invoicing Incident mitigated
|
||
|
||
[Last week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) we explained that one of the first clear insights on the decrease of Booking Fees analysis resulted on discovering that we were missing invoices for some clients on the period of November and December 2024.
|
||
|
||
Early this week we’ve managed to mitigate the incident by implementing a fix and post some late invoices to the affected clients, which results into a 99.1% potential revenue recovery due to the incident.
|
||
|
||
At the moment we’re waiting for the generation of January exports to double check - again - that this fix looks consistent and after a post-mortem we will resolve the incident.
|
||
|
||
For in-depth details of the incident, please refer to the dedicated [incident report](https://www.notion.so/20250124-01-Booking-invoicing-incident-1880446ff9c9803fb830f8de24d97ebb?pvs=21).
|
||
|
||
Lastly, while it’s clear that this incident had an impact on the decrease of Booking Fees, it does not explain the whole story. This is why after the incident resolution this analysis will resume.
|
||
|
||
## How to achieve +4.5% increase in Guest Revenue?
|
||
|
||
A while back, in Q4 2024, we explained in several Data News entries that in collaboration with the Guest Squad we launched and monitored a new A/B test on the Guest Journey to enhance Truvi’s ability to take more informed decisions based on actual results.
|
||
|
||
In this first A/B test we went for a simple approach, just to ensure that the overall process - from actual implementation, to results monitoring - was working as expected. We were not really expecting good nor bad results, since the whole point of the test was understanding the impact of the position of the Continue button on the payment page within the Guest Journey.
|
||
|
||
And… well, after several weeks we’re happy to announce that this A/B test has been successful and - surprisingly - the new version achieved +4.5% increase in Guest Revenue and +3.1% increase in Payment Rate!
|
||
|
||
The detailed results are available in this [Notion page](https://www.notion.so/2025-01-20-Guest-Journey-Floating-Button-A-B-Test-Results-17e0446ff9c9809ca94ecafd79fb6db1?pvs=21).
|
||
|
||
|
||
|
||
The new version was rolled-out to all Guest Journeys on Thursday 23rd of January, and this week we had a retrospective on how we can improve even further the collaboration between Guest Squad and Data in the A/B testing process: because we want to launch many more of them!
|
||
|
||
Congrats to the Guest Squad for these amazing results!
|
||
|
||
## Data Request workflow update
|
||
|
||
This week we noticed that our Data Engineer Pablo was tagged as Data Captain… while he’s still off!
|
||
|
||
We’ve updated the Data Captain workflow so for this period the role is only rotatory between Joaquín and Uri.
|
||
|
||
Additionally, we’ve been doing some small improvements on our Data Request workflow to improve usability and gather the needs more efficiently on our side… as well as better flagging the urgency of the requests.
|
||
|
||
|
||
|
||
Kind reminder that we encourage the use of the Data Request workflow for any request you might have since this helps us better prioritising and working more efficiently with controlled interruptions.
|
||
|
||
## Further Xero reporting automation improvements
|
||
|
||
The [invoicing incident](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) has brought to the surface that we might not be in a strong position to detect invoicing issues in a timely manner. Simultaneously, a few weeks ago we were carrying out an exercise with Finance to improve how we tracked revenue streams from Xero, for KPIs purpose.
|
||
|
||
With both topics quite fresh, we’re currently exploring simple ways to provide more interesting insights around Xero that could help identifying potential issues on invoicing side as well as improve efficiency on Finance side.
|
||
|
||
In the reporting of Invoicing & Crediting, we now have a couple of new tabs.
|
||
|
||
The first one is Revenue Monthly Trends. This allows to aggregate Invoices and Credit Notes per different revenue aggregations in different levels. For instance, Guest Screening and Protection can be seen as an overall category with multiple sub-categories within, such as Booking Fees, Listing Fees, etc. There’s currently 3 levels of aggregations in place.
|
||
|
||
|
||
|
||
Snapshot of Revenue Monthly Trends for December 2024. We can observe that there’s multiple levels of aggregation around Revenue - currently 2 displayed - but these can be further expanded to a 3rd level. For instance, Screening Services and Protection Services that refer to New Dash services can be expanded to have the revenue detail per service, i.e., Screening Plus, Protection Pro, etc.
|
||
|
||
With this information, we’re able to provide a monthly overview of the main revenue lines, and compare it versus the previous month (MoM), the same month but from the previous year (YoY) and even retrieve the cumulative Year-to-Date figures and compare it vs. the Prior YTD. Note though that this YTD is based on the Financial year, meaning it starts on April and finishes on March.
|
||
|
||
Lastly, we’ve also allowed the possibility to filter by Deal in this tab. However, a more interesting tab for account-based use cases might be the Invoiced Revenue per Deal, that compares on a MoM basis the invoiced revenue for that Deal, as well as retrieving how much a certain account contributes to the total invoiced revenue in a given month.
|
||
|
||
|
||
|
||
November 2024 snapshot on Invoiced Revenue per Deal. You see the 3rd and 5th rows, that are blank for Current Month Share (%) and have a -100% in MoM(%)? These are the 2 accounts that raised the alarms for the Invoicing Incident. The main difference is that while before we needed to deep-dive into analytics to reach to this conclusion, with this new report it will be far easier to detect similar issues in the future.
|
||
|
||
This is specially useful to detect any issue on invoicing, as well us further understanding the accounts that contribute more to Invoiced Revenue and based on which revenue lines, since the same aggregation levels exist in this tab.
|
||
|
||
## Update on Main KPIs report
|
||
|
||
This week, we have implemented several important updates to our Main KPIs Report to improve the accuracy and reliability of key business metrics. These changes focus on refining our Expected MRR calculation, updating display rules for invoicing-related metrics, and adjusting the deals lifecycle states to align better with our reporting logic.
|
||
|
||
1. Updated Expected MRR Calculation
|
||
The Expected MRR metrics are now calculated using the total revenue from the previous 12 months, up to the month before the one being displayed.
|
||
This new approach provides a more updated estimate for Expected MRR, particularly for the month prior to the current one. Previously, the estimation method was not as responsive to recent revenue trends. By incorporating the last 12 months of revenue, the metric now reflects a more accurate and timely projection.
|
||
2. Adjusted Display Rules for Invoicing-Related Metrics
|
||
We have modified the display rules for all invoicing-related metrics based on feedback from the Finance Team. Previously, these metrics were not displayed for the current or previous month, leading to some delays in visibility. The Finance Team clarified that the invoicing cycle for the previous month is typically finalized around the 15th of the current month. To ensure data accuracy and avoid premature reporting, we now display these metrics only after the 20th, allowing ample time for the invoicing process to be completed.
|
||
Before the 20th of the current month → Revenue metrics for both the current and previous months are hidden.
|
||
After the 20th of the current month → Revenue metrics for the previous month become visible.
|
||
3. Removal of 'First Time Booked' from Deals Lifecycle States
|
||
The 'First Time Booked' state has been removed from the deals lifecycle states.
|
||
After internal discussions, we found that this lifecycle state was causing issues with MRR metrics calculations, especially for new deals that received bookings within the same month of their creation. To maintain the consistency and reliability of our MRR reporting, we decided to remove this state from the report.
|
||
|
||
These changes were made to improve the usability of the Main KPIs Report, ensuring it better reflects real-time business performance while aligning with our invoicing processes.
|
||
If you have any questions or feedback, please feel free to reach out!
|
||
|
||
# 2025-01-24
|
||
|
||
## From Booking Fees per Billable Booking decrease analysis…
|
||
|
||
This week we’ve invested a bit of brainpower to try to understand the decreasing trend of the Booking Fees per Billable Booking over the past few months. This trend can be observed for several months already and reached the lowest figures around end of 2024.
|
||
|
||
Several hypothesis have been formulated and are being investigated, namely:
|
||
|
||
- Is a potential increase on Cancellations reducing the Booking Fees / Booking Fees per Billable Booking?
|
||
- Is the changes of Price Plans the main reason behind this decrease?
|
||
- Is the churning of clients with high booking fees the potential reason behind this decrease?
|
||
|
||
At this stage, data shows that the overall trend of cancellations is quite stable over time and does not correlate to a decrease on Booking Fees. However, this is at an overall level, so we also investigated at per client basis. At per client basis, we checked the biggest clients in terms of contribution to Booking Fees and correlated it to Cancellations but again, doesn’t seem linked to it.
|
||
|
||
In short, it’s very reasonable to assume that Cancellations are not a cause for decrease on Booking Fees per Billable Booking, nor a decrease to Booking Fees, nor a decrease to Billable Bookings.
|
||
|
||
However, when deep-diving into the per client basis, we’ve noticed that 2 of the main contributors to Booking Fees were not invoiced since October 2024. After confirmation from Finance side, we’ve raised an invoicing incident.
|
||
|
||
While at this stage it’s clear that the incident on the invoices can partially explain the decrease on Booking Fees during the last 2 months, there might be other reasons that need to be investigated to explain the overall decaying trend, specially prior to November 2024. However, the shift in priority at this stage has changed to the invoicing incident - the analysis will resume later on.
|
||
|
||
## … to a new invoicing incident
|
||
|
||
As discussed in the previous entry, the effort on understanding the decrease of Booking Fees per Billable Booking has highlighted that something has been odd in the invoices for the last couple of months. Since the effects seem very localised, it was difficult to spot since only a few clients were affected.
|
||
|
||
In short, the issue seems to be related to an undesired effect from the agreed fix on invoicing from our previous incident, as explained in the Data News entry back to November: [Fixes for invoicing have been agreed](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md)
|
||
|
||
At this stage, the incident is still ongoing. There’s a potential fix being discussed as well as follow up steps on how we can recover the missing revenue from the affected clients. We’re also working on documenting the incident. This is our main priority at the moment at Data side, thus other lines of work might be slowed down until resolved.
|
||
|
||
Lastly, this emphasizes the need for better visualising and alerting on a per-month and per-client invoicing to ensure that any deviation from the usual can be tracked properly. There’s already a few ideas on the table that could help in this regard, mostly on further Xero automated reporting.
|
||
|
||
## New Metrics in Main KPIs
|
||
|
||
To provide deeper insights into our performance and better understand the dynamics of host resolutions and revenue retention, we’ve introduced three new metrics to the Main KPIs report. These metrics are designed to track key aspects of our operations and help us monitor their evolution over time.
|
||
|
||
- **Revenue Retained Rate:** Ratio of Revenue Retained divided by Total Revenue
|
||
- **Revenue Retained Post-Resolutions Rate:** Ratio of Revenue Retained Post-Resolutions payments divided by Total Revenue
|
||
- **Host Resolutions Payment Rate:** Ratio of Resolutions Payment Count divided by Created Bookings
|
||
- **Host Resolutions Amount Paid per Booking Created:** Resolutions Amount Paid divided by Created Bookings
|
||
|
||
By tracking these metrics over time, we expect to better understand changes in guest behaviour, operational processes, or market conditions that impact resolutions and revenue retention.
|
||
|
||
## PMS Data in New Dash & Acc. Manager’s reports
|
||
|
||
As part of our ongoing efforts to improve the quality and usability of our reports, we’ve introduced new information regarding Property Management Systems (PMS) to **both the New Dash and the Account Managers reports**. This addition provides users with enhanced filtering capabilities and greater visibility into PMS associations. Now Account Managers can easily segment their accounts based on PMS usage, enabling more targeted strategies and conversations with clients.
|
||
This new feature reflects our commitment to continually work and improve our data tools and delivering more actionable insights. We’re confident that this update will enhance your ability to make informed decisions and maximize your impact.
|
||
|
||
# 2025-01-17
|
||
|
||
## Pablo goes on paternity leave
|
||
|
||
Pablo here.
|
||
|
||
My little girl will be arriving some time next Monday/Tuesday, and I will be off for some weeks on paternity leave to take here of her and her mother.
|
||
|
||
Don’t despair! You’re in great hands with Uri and Joaquín. We’ve worked hard to make sure my absence is barely noticed, and the guys will do a great job as always (actually, sometimes they’ve done such great things while I’m out on holidays that it makes me wonder if I’m just bothering and dragging them down when I’m around).
|
||
|
||
For any data topics, please keep relying on Uri and Joaquín, or just summon the @data-captain tag on slack and they will come to the rescue.
|
||
|
||
You can expect to see me connected again on mid March.
|
||
|
||
Wishing you the best of luck while I’m out, and see you soon!
|
||
|
||
## New Onboarding MRR metric released in Main KPIs
|
||
|
||
We have added a new metric to our Main KPIs Report: **Expected Onboarding MRR.** The Onboarding MRR is a key metric that estimates the expected monthly revenue from each new deal. It is calculated by taking the total revenue generated by all active accounts over the last 12 months and dividing it by the number of active months for each account. This approach allows for a more accurate and dynamic understanding of revenue expectations during the onboarding phase depending on the amount of listings they have.
|
||
|
||
The addition of the Expected Onboarding MRR metric to our Main KPIs report enables us to do a little forecasting and strategic planning. By understanding the expected revenue from new accounts, we might be able to have more realistic financial goals.
|
||
|
||
All the information regarding this new metric is available in our report [Main KPIs - Power BI](https://app.powerbi.com/groups/me/apps/33e55130-3a65-4fe8-86f2-11979fb2258a/reports/5ceb1ad4-5b87-470b-806d-59ea0b8f2661/cabe954bba6d285c576f?ctid=862842df-2998-4826-bea9-b726bc01d3a7&experience=power-bi)
|
||
|
||
## Revenue metrics improvements in progress
|
||
|
||
After [last week’s inclusion of Revenue Retained metrics](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), this week we’ve been discussing further with Finance in order to understand and minimise the gaps on KPIs Revenue reporting.
|
||
|
||
Long story short, we’re refactoring the way we retrieve invoiced revenue lines, the one that comes from Xero. Historically we’ve been using the Item Codes that are manually tagged in the invoices and credit note line items for Booking, Listing and Verification fees, as well as the Waiver amount that we pay back to the Hosts; while we were using Accounting codes for other metrics, such as the revenue that comes from APIs. After several discussions with Finance, we’ve reached to the conclusion that in order to minimise the gap it’s better to use the Accounting codes - and indeed, an ad-hoc analysis shows that this change should reduce the gap quite a bit.
|
||
|
||
This will allow us during this week to include several improvements, namely:
|
||
|
||
- Reduce the gap between KPIs and the P&L on Listing, Booking, Verification Fees Revenue
|
||
- Reduce the gap between KPIs and the P&L on the Damage Host-Waiver Payments
|
||
- Start tracking New Dash Invoiced Services (Waiver Pro, Protection Pro, Protection Plus, Id Verification, Screening Plus, Sex Offenders Check)
|
||
- Split Guesty Revenue contribution between 1) the Athena API Booking Fees and 2) the Guesty Resolutions revenue line. However, we will still have discrepancies on Guesty due to the accrued revenue that we’re not able to track at the moment.
|
||
- Investigate any other revenue line after the first batch of changes is complete
|
||
|
||
Important note:
|
||
|
||
> **This change will inevitably modify the revenue aggregations, namely Invoiced Operator Revenue, Total Revenue, Revenue Retained, Revenue Retained Post-Resolutions, etc. However, these figures should become more accurate.**
|
||
>
|
||
|
||
This change comes with a drawback, however. Since P&L data starts being available on April 2022, we will need to cut all KPIs start date to that moment in time in order to have consistent and more accurate data. This should not be troublesome - in reality, this historical data is quite inaccurate by nature.
|
||
|
||
We can expect during this week changes on the figures shown in KPIs and Account Managers report. If you have any question or notice anything out of the ordinary, please feel free to reach to us!
|
||
|
||
# 2025-01-10
|
||
|
||
## Support on New Pricing automation
|
||
|
||
This week we’ve been working closely on the New Pricing initiative to help understand which clients can be migrated from old pricing models to a new structure. Our role has focused on providing detailed data analysis to support this transition.
|
||
|
||
By analysing client behavior and the different price structures, we’ve helped by providing expected differences in price as well as segmenting the different clients depending on their impact to the business and the capacity or not to move to the new structure. This is now in the hands of RevOps team to do some data-informed actions.
|
||
|
||
## Account Margin report is now live
|
||
|
||
[Last week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) we explained that we were working to automate the net revenue after the different payouts. Early this week we’ve released a new report in the Account Managers Reporting Power BI app that contains very detailed data per account and time window on the different revenue inputs and outputs, to end up with a kind of client gross margin (without taking into account any operational or fix cost allocation). This is interesting in the sense that it transforms the concept of which accounts are more important from Total Revenue to something more impactful to Truvi’s financial health: we can have very big accounts in terms of Total Revenue, but these can contribute less than smaller accounts depending on the Host takes Waiver payouts and/or Resolutions Payouts. See example below:
|
||
|
||
|
||
|
||
This is a real, handpicked, illustrative (and anonymised) example.
|
||
|
||
We have 3 accounts ordered by the contribution of Total Revenue. At first glance, we could say that the first account is contributing more in Total Revenue - which is true. However, the picture changes if we deduct the Host Takehome (Waiver amount paid back to host). In this case, we see how the huge majority of the first account revenue is actually paid back to the Host, and we only retain 29.7% (Revenue Retained Ratio). Now we would say that it’s the 2nd account that is actually contributing more. But, what if we deduct also the Host Resolutions Payouts? In this case, it’s actually the 3rd account that is contributing to more “net revenue”, as we can observe in Revenue Retained Post-Resolutions. This illustrative example shows the different angles from which we can have different conclusions depending on the business problem we aim to solve.
|
||
|
||
During this week we’ve also included a few improvements, such as the ratio between Resolution Payments per Bookings, to help Resolutions team, as well as the Active PMS for each account.
|
||
|
||
## Revenue Retained metrics now available in Main KPIs
|
||
|
||
Very much [in line with the previous Data News entry](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), we’ve taken the opportunity to propagate 2 new Revenue Retained and Revenue Retained Post-Resolutions metrics into Main KPIs. This will allow for better comprehension in the Global revenue retention, as well as providing the capacity to analyse trends over time and by the different segments we already have in place. Additionally, the metrics have been made available into the detail by Deal tabs to have the month-by-month information in a handy place.
|
||
|
||
|
||
|
||
Example of the MTD tab of how the 2 new metrics compare to the existing Total Revenue. Notice how the growth conception changes: in this example, even though we’re paying Waivers back to Hosts and we have some Resolution Payments, the Revenue Retained Post-Resolutions is increasing more in relative terms than Revenue Retained, and even higher with respect to Total Revenue.
|
||
|
||
In order to improve the look and feel, we’ve also re-arranged the list of metrics so Total Revenue, Revenue Retained Post-Resolutions are the first ones to appear. And we’ve added conditional formatting to easily see if an account is trending up or down in any of the metrics
|
||
|
||
|
||
|
||
It’s not very visible in Notion though so we encourage you to go check Main KPIs!
|
||
|
||
Also - have you noticed the brand new Truvi style Pink for Deal Lifecycle State?
|
||
|
||
## Deals Consolidation Report is now live
|
||
|
||
We have the new Id Deal consolidation report up and running. With the new consolidation report, you can now easily view all deal IDs alongside their associated names from Core, Xero, and Hubspot, whenever they exist in those systems. This consolidated view provides a clear and comprehensive overview, helping to ensure transparency and accuracy in our data.
|
||
|
||
This report is designed to support all teams, so if you need access please reach out to the data team so we can help you with any needed permissions.
|
||
|
||
https://app.powerbi.com/groups/me/apps/10c41ce2-3ca8-4499-a42c-8321a3dce94b/reports/eb744b2d-3f96-41dd-97df-2608daf638f3/3aa7d31cf3fa60fccec5?experience=power-bi
|
||
|
||
We’ve added the new Deals Consolidation Report together with the previously existing Currency Exchange report. These are now located within a Power BI app named Miscellaneous Reports.
|
||
|
||
|
||
|
||
## API Invoice advances
|
||
|
||
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.
|
||
|
||
Once finalized, this work will allow in the future to be integrated seamlessly with the new Hyperline billing platform. This integration aims to automate the entire billing process, making it more reliable and easier for the finance team to manage.
|
||
|
||
# 2025-01-03
|
||
|
||
## APIs Deals now visible in Main KPIs and Account Managers reports
|
||
|
||
This week we’ve been working on increasing KPIs quality. One of the main pain points we have whenever we want to report data is the fact that different sources might contain different levels of completeness. This was the case for Deal Id, for instance, in which a Deal can appear in the backend and not in Hubspot and vice versa. Same story with Xero.
|
||
|
||
Whenever we started creating the Main KPIs reports around June 2024, we only had data ingested from Xero and the backend, and basically the source of truth for KPIs were those Deals that appeared in the backend. However, no API deals are present in the source table we’re using: only platform users with Deal were reported.
|
||
|
||
With the ingestion of Hubspot data, we’ve refined the list of Deals that are considered for KPIs reporting. In essence, we consider either:
|
||
|
||
- Deals from the backend, as we did before
|
||
- Deals from Hubspot that have gone live at any point in time (that are not in Guardhog pipeline)
|
||
|
||
With this change we’re now able to track Main KPIs by Deal for APIs, such as Guesty. This also is propagated towards Account Managers reporting.
|
||
|
||
Lastly, another important change. The name associated to the Deal has also changed and now we’re using as a source of truth the name coming from Hubspot. If and only if the Deal does not appear in Hubspot, the previous crazy-computation-logic to retrieve a name from the backend remains. This also affects Main KPIs and AMs reporting.
|
||
|
||
|
||
|
||
Example of Guesty eDeposit account now appearing in Account Managers reporting
|
||
|
||
> *Keep in mind that Global figures in Main KPIs remain unaffected by this change.*
|
||
>
|
||
|
||
This small line of work should improve the quality on the KPIs. We’re still aware that there’s many fake Deals that need to be removed at some point, lacking a proper source of truth. One step at a time!
|
||
|
||
## Automating client “net” revenue post-payouts
|
||
|
||
> Disclaimer: we might switch to a better, proper naming.
|
||
>
|
||
|
||
Long story short, it’s been several months since we’re able to report Total Revenue at account level. We’re also able to track the Waiver amount paid back to hosts. And we know from Xero the amount on Host Resolutions that we pay out per client so… let’s combine it all together to have some monetary metrics of the “”“real””” monetary value each client represents for Truvi.
|
||
|
||
That’s a bit the idea behind this initiative! And also the main reason why we prioritised including API deals in the KPIs flow as [mentioned before](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md).
|
||
|
||
|
||
|
||
Based on a true story
|
||
|
||
We’re currently finalising a new report to enrich the monitoring of our accounts for RevOps teams to use it, and hopefully bring further data-driven decision making on their day-to-day responsibilities. Pending naming alignment, these metrics will also be made available soon in Main KPIs - we’d just need to wait a bit.
|
||
|
||
## Deal consolidation report
|
||
|
||
At Superhog, our deal information comes from three different sources: Core, Xero, and Hubspot. Each of these systems provides valuable data, but it can be challenging to verify where each deal ID originates, especially when information overlaps across sources.
|
||
|
||
To streamline this process, we are currently working on a consolidated report that will display all deal IDs along with their associated names from each of these sources—Core, Xero, and Hubspot—whenever they exist in the respective system. This report will provide a clear and quick overview of where each deal's information comes from, ensuring transparency and accuracy.
|
||
|
||
The primary aim of this report is to support teams, particularly the finance team, by allowing them to quickly access and verify deal data from the relevant source. This will not only save time but also improve the accuracy of financial and operational decision-making.
|
||
|
||
# 2024-12-27
|
||
|
||
## New Dash reporting improvements
|
||
|
||
This week we’ve dedicated a bit of time to improve the reporting on the adoption of Services in the New Dash. Specifically, we’ve finalised the modelling to properly track services that require Guest Payments (Basic Waiver, Waiver Plus and Basic Damage Deposit) and fix the computation of Waiver Pro price by taking into account the booking number of nights. With these 2 improvements, now we’re in a much more accurate spot to track the estimated revenue coming from New Dash in the form of Chargeable Services.
|
||
|
||
Additionally, we’ve created a new tab in the Power BI report to track Booking Details. This includes applied programs, types of services (Screening, Deposit Management, Protection), booking status, check-in, check-out, etc. We’ve also taken the opportunity to revamp the already existing tabs on User Detail to provide more meaningful insights, as well as reworking naming and UX across the reporting.
|
||
|
||
|
||
|
||
The first row that represents 68% of all New Dash bookings, and 86% of the total New Dash bookings with upgraded services (i.e., that are not Basic Screening) corresponds to Home to Host, which is clearly dominating the adoption of New Dash.
|
||
|
||
And it’s nice to see that Chargeable Amounts are increasing quite a bit lately, reaching up to 1.7k GBP in the past week!
|
||
|
||
# 2024-12-20
|
||
|
||
## Data Team wishes you a wonderful holiday season!
|
||
|
||
As we approach the end of the year, we want to share our team's availability over the holiday period. Below is a quick guide to which members of the Data Team will be available in the upcoming days:
|
||
|
||
- Friday 20th Dec: Joaquin & Pablo
|
||
- Monday 23rd Dec: Joaquin & Pablo
|
||
- Tuesday 24th Dec: Joaquin & Pablo
|
||
- Wednesday 25th Dec: National Holidays
|
||
- Thursday 26th Dec: National Holidays
|
||
- Friday 27th Dec: Uri
|
||
- Monday 30th Dec: All team
|
||
- Tuesday 31st Dec: Joaquin & Uri
|
||
- Wednesday 1st Jan: National Holidays
|
||
- Thursday 2nd Jan: Joaquin & Uri
|
||
- Friday 3rd Jan: Joaquin & Uri
|
||
- Monday 6th Jan: National Holidays
|
||
|
||
|
||
|
||
Thank you for a fantastic year, and we’re excited to reconnect in the new year. Wishing you all joy, rest, and a bright start to 2025!
|
||
|
||
## Power BI User Class
|
||
|
||
On Wednesday, we hosted an informative Power BI user class aimed at empowering our team to make the most out of this powerful data analytics tool. The session was packed with valuable insights and hands-on learning opportunities, guiding attendees through three key areas: navigation, basic usage, and advanced tools.
|
||
|
||
To ensure ongoing learning and support, the following resources are available:
|
||
|
||
- [**Power BI Documentation](https://www.notion.so/Power-BI-users-Tips-Tricks-1510446ff9c98056ad77ead40eef2c45?pvs=21):** A complete guide covering everything discussed in the session and more.
|
||
- [**Slack Data Channel](https://superhogteam.slack.com/archives/C06GFGHJD7H):** Our data team is always available to answer questions or provide assistance.
|
||
|
||
**Missed the Class?**
|
||
|
||
Don’t worry! A recording of the session is available [here](https://guardhog-my.sharepoint.com/:v:/g/personal/joaquin_ossa_superhog_com/EXaErNTuspFAolaTgWSdLVAB-_OWKUsyzoITweyBFHCyuA?e=uSc4l7&nav=eyJyZWZlcnJhbEluZm8iOnsicmVmZXJyYWxBcHAiOiJTdHJlYW1XZWJBcHAiLCJyZWZlcnJhbFZpZXciOiJTaGFyZURpYWxvZy1MaW5rIiwicmVmZXJyYWxBcHBQbGF0Zm9ybSI6IldlYiIsInJlZmVycmFsTW9kZSI6InZpZXcifX0%3D). We encourage everyone to watch it and explore the resources to enhance their Power BI experience.
|
||
We hope this session inspired confidence and curiosity to explore Power BI’s capabilities.
|
||
|
||
## How to make more revenue? Analysis on Payment Validation Rate decrease
|
||
|
||
[Last week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) we explained that we were carrying out an in-depth analysis on the decrease of the Payment Validation Rate. After a few final validations, we’ve wrapped up and shared our conclusions with the stakeholders.
|
||
|
||
In short, we’ve gathered a few data-driven actionable items for RevOps teams that could help bringing more revenue by increasing the Payment Validation Rate of certain accounts. The fully detailed analysis can be found here:
|
||
|
||
- [2024-12-16 Payment Validation Rate Decrease](https://www.notion.so/2024-12-16-Payment-Validation-Rate-Decrease-462917ff9de0403392d6a35f9a3e3d85?pvs=21)
|
||
|
||
## Setting the ground for a new KPI: Onboarding MRR
|
||
|
||
There has been several discussions in the latest weeks on the need of being able to measure, somehow, the average monthly revenue a new account could potentially bring to our business at the moment of onboarding.
|
||
|
||
While this kind of predictive approaches with few data are usually a challenge, we’ve dedicated a bit of time to explore a set of alternatives to be able to quantify the degree of discrepancy we would have if creating this new KPI. The detailed analysis can be found here:
|
||
|
||
- [Onboarding MRR Definition](https://www.notion.so/Onboarding-MRR-Definition-f1bada4ea5b942568d5c6b2c7917fc5c?pvs=21)
|
||
|
||
At this stage we’ve shared our conclusions and recommendations with the stakeholders and once we have feedback we’ll continue working towards the new Onboarding MRR KPI implementation.
|
||
|
||
# 2024-12-13
|
||
|
||
## (Another) incident survived
|
||
|
||
This week we experienced an incident in our infrastructure that brought a lot of our daily data integration and processing jobs to a halt. Fortunately, we caught the incident on minute 0 and were able to put a remedy to it rather fast, so you probably didn’t even get time to notice it in our PBI reports.
|
||
|
||
You can read more details on the incident here: [20241211-01 - DWH scheduled execution has not been launched](https://www.notion.so/20241211-01-DWH-scheduled-execution-has-not-been-launched-1590446ff9c9806086e0ec77336d4c51?pvs=21)
|
||
|
||
## Screen and Protect & CheckIn Hero API reports
|
||
|
||
After integrating Screen and Protect data into our DWH last week, we have now added CheckIn Hero API data from a new Cosmos DB container. With the data fully modelled in the DWH, we have launched two new reports, one for each system. These reports are designed to give the API team a clear view of system activity and performance while offering the flexibility to dive deeper into specific details about guests, users or key metrics. Both these reports are available in the Power BI API repository https://app.powerbi.com/groups/me/apps/043c0aec-20b8-4318-9751-f7164b3634ad/reports/a19a4491-8576-4109-b3ca-9e26d67d7b03/ReportSectionbd92a560d1aa856ba993?experience=power-bi.
|
||
|
||
|
||
|
||
## Upcoming Power BI User Class
|
||
|
||
Next week on Wednesday, we’ll be hosting a Power BI user class designed to help master the fundamentals of working with Power BI dashboards. Whether you’re a seasoned user or just getting started, this session is packed with practical insights and tips to enhance the user experience with this powerful tool.
|
||
|
||
Here’s what we’ll cover during the session:
|
||
|
||
- **How to navigate and interact with Power BI dashboards effectively:** Learn to explore and understand key insights quickly and efficiently.
|
||
- **Tips for making the most of reports:** Discover hidden features and best practices to maximize the value of your dashboards.
|
||
- **Basics of filtering, slicing, and exporting data:** Gain hands-on experience with essential tools for customizing and sharing data views.
|
||
|
||
We’re looking forward to seeing our fellow coworkers there to learn, collaborate, and grow their Power BI skills. Don’t miss this opportunity to unlock the full potential of Power BI!
|
||
|
||
## A/B test has been launched
|
||
|
||
After a [successful validation on the A/A Guest Journey test](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), this week the Guest Squad released the real A/B test. The purpose of this A/B test is to understand if showing a Product Selection button always visible (independently of the scrolling) increases the Guest Revenue, rather than keeping the button locked on the bottom of the screen - which is the current behaviour.
|
||
|
||
So far, with just 5 days of data, the results are still not statistical significant thus we cannot conclude that one version is better or worse than the other. If you’re interested in following the results, we invite you to join the open slack channel [#ab-test-guest-journey](https://superhogteam.slack.com/archives/C083V5Q7K7W).
|
||
|
||
Great job Guest Squad!
|
||
|
||
## Analysis Payment Validation Rate decrease
|
||
|
||
This week we’ve also dedicated some time to do an in-depth analysis on Payment Validation Rate decrease. In essence, we’re observing from different data sources (Mixpanel, DWH) that the Rate of Guest Journeys that offer Payment Validation is decreasing in these past months, which could be linked to a potential revenue loss in the Guest Journey. In other words, we could have gained more revenue from our guests. The main hypothesis that we’re currently investigating and quantifying are whether 1) Churned clients offered more Guest Journeys with Payment Validation, 2) New clients are offering less Guest Journeys with Payment Validation and/or 3) Existing clients (not new, not churned) have changed the behaviour and are now offering less Payment Validation than before.
|
||
|
||
At this stage the analysis is mostly complete and we aim to wrap up and share it in the following days.
|
||
|
||
# 2024-12-06
|
||
|
||
## Screen and Protect data integrated in DWH
|
||
|
||
This week we’ve integrated a new Cosmos DB container for Screen and Protect API service. With the help of the APIs Squad we managed to integrate the data through our tool Anaxi into our DWH. With this new data available, we started modelling new tables within DWH and are now able to advance on the dedicated reporting for Screen and Protect.
|
||
|
||
We’ve also started discussions to handle a similar integration for the Check-In Hero API service, since we have the first client onboarding on it.
|
||
|
||
## Screen and Protect API reporting advances
|
||
|
||
With the successful integration of Screen and Protect data into our DWH, we are now developing a new report. This report will provide easy access to detailed information for each verification request generated by the new API, along with an overview of performance over time. Its goal is to enhance decision-making and empower the API team with a comprehensive view of the new metrics aligned with their objectives.
|
||
|
||
## Athena API migration
|
||
|
||
This week we’ve also handled the migration of Athena API, [similarly as we did a few weeks ago for the e-deposit migration](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md). In essence, the APIs team has a new Cosmos DB instance in which they wanted to migrate the Athena (Guesty) records. Since we already had some reporting dependencies for Athena, we needed to coordinate between the 2 teams to avoid any downtime.
|
||
|
||
Everything went quite smoothly and since Wednesday afternoon reports have been reading from the new stream without any interruption. Good job, APIs Squad!
|
||
|
||
## A/A test has been launched… and is looking good!
|
||
|
||
Great news: after a few technical alignments, discussions, and some extra work due to Data needs, Guest Squad finally launched the A/A test this past Tuesday, 3rd of December!
|
||
|
||
The purpose of this A/A test is simple: ensure that everything works as expected before the real A/B test. “Everything” is a broad word, but in essence, it means ensuring that we can randomly split the Guest Journey traffic into any desired variation that will be affected by a given production-ready configuration.
|
||
|
||
Effectively, in this A/A test, the Guest Journey traffic is redirected into 2 different setups that… well… are exactly the same. Since these are the same, we should expect no difference for any metric when comparing one variation versus the other. However, **this will never be true** because we have some uncontrolled effects : maybe a guest selects a Waiver, and another one a Deposit. What we are really expecting is that there’s **no statistically significant difference** between these 2 variations.
|
||
|
||
That’s why in the Data team we started analysing and implementing a minimal tracking that takes into account statistical analysis. For instance, here’s the results extracted on Thursday morning:
|
||
|
||
|
||
|
||
All metrics have the label ‘(not significant)’ meaning that we cannot conclude that one variation is better or worse than the other. For information, we go for a level of confidence of 95% - as the usual business standard.
|
||
|
||
We can see that PAYMENT RATE is +6% greater in terms of relative increment for variation B with respect of variation A. However, since the statistical test concludes that this difference is not significant, **we cannot conclude that variation B is better than A in achieving a better payment rate**. In essence, the statistical analysis will ensure that we will take proper data-driven conclusions when running the real A/B test.
|
||
|
||
In general, the more data we have, the more diluted the random/uncontrolled effects will be and thus the more certain we will be in the conclusions we extract from a given A/B test. This effectively means that the A/B test needs to run for a certain amount of time before taking any decision. If we’re not certain on what business decision to take, we can always keep it running longer to get even more samples. In the screenshot above, we just had a couple of days of data with around ~1.5k Guest Journeys - and this is clearly not enough!
|
||
|
||
On Monday morning we will extract the latest results and if we observe that metrics for this A/A test are still not showing any significant differences, we will conclude that the setup is correct - and then we’ll be ready to go for the real A/B test! Exciting!
|
||
|
||
# 2024-11-29
|
||
|
||
## New Dash reporting improvements: Chargeable Services
|
||
|
||
This week we have implemented a new tab in New Dash reporting to account for when New Dash services are expected to be charged. This part of the report reads from the new Billing tables of the backend, and we expect that these are updated accordingly to be reliable and the single source of truth. At the moment, the data displayed is not qualitative enough and should not be trusted until the source tables are correctly and fully updated.
|
||
|
||
There will be some additional work needed from Data side to ensure that we are able to track Guest Payments within this report. However, at the moment we do not have any New Dash user with Guest Payments related services, and thus it will be done in a later step.
|
||
|
||
## Guest KPIs report improvements: Billing country and robust testing
|
||
|
||
The Guest KPIs report has received two significant updates aimed at improving usability and data reliability.
|
||
|
||
First, we’ve introduced a **billing country dimension**, allowing users to analyse metrics with a country-specific focus. This addition empowers teams to gain deeper insights into region-based trends, helping drive more informed decisions.
|
||
|
||
Secondly, we've implemented advanced testing mechanisms within our data warehouse. These tests automatically flag extreme data deviations, ensuring potential anomalies are quickly identified and investigated. By proactively monitoring the data, we aim to maintain the highest quality and reliability in our reporting.
|
||
|
||
# 2024-11-22
|
||
|
||
## New Dash reporting improvements: Created Services Evolution
|
||
|
||
This week we have been working on providing some visibility on the kind of services (protection, screening and deposit management) that New Dash users apply to their Bookings.
|
||
|
||
In order to do so, we have created a new tab in the New Dashboard Overview Power BI reporting to track a new metric called Created Services. Created Services stands for the moment in time a given service was created within a Booking that comes from a user in New Dash. Even though the moment of creation of the service could be similar in many cases as the moment the Booking it’s created, this does not necessarily need to be always true. Thus, so far, all services are attributed to the moment these are applied to the Booking.
|
||
|
||
|
||
|
||
Detail by Service Created. Basic Screening is still dominating, even though Basic Protection follows closely and we have some Waiver Pro.
|
||
|
||
We have different time granularities (Daily, Weekly, Monthly) and different Dimensions: By Service, By Deal, By Has Upgraded Service, etc. When playing with the different selectors, the table and the graphs will update accordingly. You can also click on the different lines of the table to specifically just track what the values that you’re interested in.
|
||
|
||
|
||
|
||
|
||
|
||
In the detail By Deal, we can see that the majority of Created Services correspond to a single account, which is Home to Host.
|
||
|
||
Lastly, we conducted an important cleaning: any New Dash user that has been migrated that does NOT have a Deal id filled will be excluded from the reporting. This is mostly to avoid tracking test/fake accounts, and focus on the real accounts. Therefore, the adoption funnel and the global indicators have been adjusted accordingly.
|
||
|
||
There’s still many more improvements that we want to apply in this reporting, such as Revenue reporting or a more detailed view per user/service.
|
||
|
||
## New Dash/New Pricing modelling within DWH continues
|
||
|
||
This week we’ve continued with the internal DWH modelling of New Dash and New Pricing scopes. Part of it it’s already being used in the latest reporting improvements on New Dash, [as mentioned before](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md).
|
||
|
||
At this stage, we started integrating the data contained in the new Billing tables to be able to compute expected Revenue at Service and Booking level. Even though the skeleton for these models exist, there’s still need to backfill the data to have consistency, before we aim to enhance the reporting.
|
||
|
||
## New Guest KPIs Report updates on the way
|
||
|
||
Exciting improvements are already in development for the Guest KPIs Report. A new dimension incorporating billing countries will soon provide enhanced segmentation capabilities, offering deeper insights into guest behaviours across different regions. Additionally, robust data quality measures are being implemented, including an outlier detection test. This feature aims to flag potential anomalies in data, ensuring reliability and enabling proactive issue resolution.
|
||
|
||
Outlier detection has proven highly beneficial in other models, enhancing data trustworthiness and operational efficiency. By bringing this functionality to the Guest KPIs report, the team continues to set a high standard for data excellence.
|
||
|
||
## Data Team Empowers Colleagues
|
||
|
||
The data team is taking strides to enhance company-wide data accessibility and expertise by expanding its own knowledge and toolset while enabling others to make the most of the data warehouse. This initiative includes training sessions tailored for members of other teams, equipping them with the skills and permissions needed to access and utilize the data warehouse efficiently.
|
||
|
||
By providing easier access to critical data, team members across various departments can independently find the insights they need to make informed decisions and helping others in their data request when in need of someone of more expertise on the subject. This initiative reflects the data team’s commitment to fostering a culture of data-driven decision-making throughout the organization.
|
||
|
||
## CIH Reporting incident
|
||
|
||
Last week we experienced a new incident around CheckIn Hero reporting. The incident caused our reporting figures for CheckIn Hero sales and revenue to be inflated for some time during last Tuesday, but thankfully we managed to mitigate it on the same day.
|
||
|
||
You can read the details of the incident here: [20241119-01 - CheckIn Cover multi-price problem (again)](https://www.notion.so/20241119-01-CheckIn-Cover-multi-price-problem-again-1430446ff9c98088b547dfb0baff6024?pvs=21). This incident was somewhat of a repeat of this one from months ago: [20240619-01 - CheckIn Cover multi-price problem](https://www.notion.so/20240619-01-CheckIn-Cover-multi-price-problem-fabd174c34324292963ea52bb921203f?pvs=21) . They both stem from the rather awkward backend design of CIH prices.
|
||
|
||
The tech team is already working on the issues that triggered this incident (you can check for progress here: [https://guardhog.visualstudio.com/Superhog/_workitems/edit/24505](https://guardhog.visualstudio.com/Superhog/_workitems/edit/24505))
|
||
|
||
## dbt docs available for all analysts
|
||
|
||
Our Datawarehouse is where all the good magic of the Data team takes place. But it is not the most welcoming place to onboard into: with hundreds of different tables and hundreds of millions of records, navigating its contents can feel daunting. Our Domain Analysts are experiencing this pain for the first time right now!
|
||
|
||
To alleviate this, we’ve started to host our DWH table documentation in a web version. All analysts have access to it now.
|
||
|
||
|
||
|
||
Our hard-earned documentation, ready to help colleagues in despair.
|
||
|
||
With these docs, Jamie and Alex will be able to better find their way around all the stuff in the DWH. And it’s also a convenient tool for the data team members!
|
||
|
||
# 2024-11-15
|
||
|
||
## Fixes for invoicing have been agreed
|
||
|
||
Following up on [the incident we experienced last week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), this week we sat down with stakeholders to agree on a final fix for the root cause of the incident. This had to included many areas (Product, Finance, Tech) since the required changes had both business and technical implications.
|
||
|
||
We managed to agree on the necessary changes and now have a clear way forward (you can find the details here: [Fixing the invoicing incident](https://www.notion.so/Fixing-the-invoicing-incident-13d0446ff9c98056a65bc3676a34873c?pvs=21)).
|
||
|
||
The next steps are to apply the agree changes on our invoicing exports tool, `sh-invoicing`, which the Data Team will take care of.
|
||
|
||
## We have consensus on currency rates architecture
|
||
|
||
This week we had the chance to sit down with the Lead devs to discuss the [architecture proposal](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) around opening up the currency rates in the DWH that we arranged a couple of weeks ago. In our meeting, we discussed the different options on how we can ensure that all the applications in Superhog can get the currency rates their need, pondering on the pros and cons of different approaches.
|
||
|
||
We came to a decision and now have an agreed design in mind, which we have documented here: [ADR: SQL Server rates mirroring](https://www.notion.so/ADR-SQL-Server-rates-mirroring-13f0446ff9c980d4a559fcfdaf251499?pvs=21)
|
||
|
||
We will soon start to sort out the low level details of the implementation with Ben and after that, it will be building time.
|
||
|
||
## Guest KPIs Report
|
||
|
||
We are excited to announce the launch of a brand-new Power BI report designed exclusively for the Guest Squad. This report provides an in-depth view of the squad's KPIs, offering actionable insights into the metrics that matter most to their success.
|
||
|
||
The report includes dynamic visualizations, trend analyses, and comparison tools to help the team monitor their performance effectively. It has been thoughtfully crafted to address the unique needs of the Guest Squad, ensuring they have the information they need at their fingertips to make data-driven decisions.
|
||
|
||
This marks the first step in a larger initiative to create tailored reports for all teams across the organization. Our goal is to empower each squad with the tools they need to track their KPIs, uncover opportunities, and drive success.
|
||
|
||
|
||
|
||
## Data requests
|
||
|
||
As the year draws to a close, the Data Team has been busier than ever, with a significant increase in data requests pouring in. From custom analyses to ad-hoc reporting, the demand for insights has kept our team, particularly the Data Captain, working at full capacity.
|
||
|
||
We understand the importance of delivering timely and accurate information to support your decisions, and we are doing our best to keep up with the workload. The end of the year is always a critical time, and with so many projects and initiatives in progress, our hands are full, but our commitment to excellence remains unwavering.
|
||
|
||
## Adapting DWH to the latest Backend changes
|
||
|
||
This week we did some adaptations to the DWH and respective Power BI reports to remove functionalities and data that will be dropped soon.
|
||
|
||
To adapt on Guest Squad initiatives, we removed the modelisation of Address Validation that was mostly being used for Check-in Hero reporting. This implied the removal of some functionalities that were being used in the report, most notably the Funnel and the Purchase Record detail. We also removed any table regarding Address Validation within DWH.
|
||
|
||
|
||
|
||
Final state of Check-in Hero reporting Funnel tab.
|
||
|
||
On Dash Squad, we did a couple of small changes:
|
||
|
||
Firstly, we dropped a column on SuperhogUser table that was not being used and will be deleted in the Backend soon.
|
||
|
||
Secondly, we adapted the code to be able to retrieve the Claim property NewDashMoveDate indistinctly if the value contains a Date - which was the previous behaviour - or a Timestamp, increasing robustness. This should avoid any New Dash reporting issues once more users are moved from old dash to new dash in the coming weeks.
|
||
|
||
## New Dash reporting initiative resumes
|
||
|
||
This beginning of the week we managed to resolve some issues around BookingToProductBundle table thanks to the Dash Squad.
|
||
|
||
After these latest fixes, we’ve resumed the modelisation of New Dash tables within DWH, with the aim to be able to report the adoption of the different Services - specially the paid ones - and the related revenue. At the moment this is being handled within DWH but we hope that soon enough we’ll be able to work on the Power BI itself.
|
||
|
||
Lastly, we did some small improvements in the reporting: now in the User Detail tab we report for each user the e-mail and the Deal ID if available.
|
||
|
||
# 2024-11-08
|
||
|
||
## Invoicing Incident
|
||
|
||
The highlight of this week is the incident we experienced with the Invoicing exports for the Old Dash earlier this week. A combination of shaky logic and out of the usual operations in our backend databases left us unable to export the bookings to be charged to Old Dash users properly.
|
||
|
||
We mitigated the problem temporarily to unblock invoicing for this month, but we still have not applied a definitive, proper solution to the root cause. We will be working with stakeholders next week to fix it.
|
||
|
||
You can read the post-mortem report of the incident here: [20241104-01 - Booking invoicing incident due to bulk UpdatedDate change](https://www.notion.so/20241104-01-Booking-invoicing-incident-due-to-bulk-UpdatedDate-change-82f0fde01b83440e8b2d2bd6839d7c77?pvs=21)
|
||
|
||
## Currency Rates Architecture Proposal
|
||
|
||
You might remember that months ago, back in June, [we ran a project in the Data team to integrate with an external currency exchange rates provider](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) (xe.com) into our DWH. Ever since then, we’ve been receiving currency rates on a daily basis and storing them in the DWH. This is what enables us to perform all sorts of cross-currency amount conversion, which are needed for many of the reports and exports that we produce for you.
|
||
|
||
This week, colleagues from the tech team got in touch because some of our internal applications are planning features that will require performing currency conversions, so they are interested in learning about our data and how could they use it.
|
||
|
||
We’ve prepare a design doc to discuss with them the best technical architecture to serve the rates to other applications within Superhog, and we will discuss it next week to hopefully come to a decision.
|
||
|
||
You can read the design doc here: [Design Doc: Opening Currency Rates across our systems](https://www.notion.so/Design-Doc-Opening-Currency-Rates-across-our-systems-1380446ff9c9808e82ddf229e2976d2a?pvs=21)
|
||
|
||
And you can learn more about our integration with [xe.com](http://xe.com) here: [[XE.com](http://XE.com) integration](https://www.notion.so/XE-com-integration-f9b1836b67f0474389e9a7284b683343?pvs=21)
|
||
|
||
## Domain Analysts in the (Dataware)house
|
||
|
||
[After starting out a couple of weeks ago](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), our Domain Analysts have made great progress. Alex and Jamie have completed the initial SQL training we agreed with them, and this week have finally received access to the DWH. It’s a great feat! They are the first Superhog employees *outside* of the Data Team to have straight access to the DWH.
|
||
|
||
But that doesn’t mean their training is finished… They still have a lot to learn, both about SQL Databases and about Superhog’s DWH. To continue their journey, we have prepared [a set of challenges](https://www.notion.so/Domain-Analyst-Exercises-1370446ff9c980bea918ed122d8ddbc5?pvs=21) that will force them to sharpen their tools.
|
||
|
||
We will spend the next couple of weeks helping them out complete the challenges and learn more about the DWH.
|
||
|
||
## Guest tax cross-checks finally finished
|
||
|
||
After many weeks and a lot of back and forth (it all started [here](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md))… we did it! Guest taxes are now computed in the DWH with great quality, and the Finance team is happy with the cross-checks that we’ve run.
|
||
|
||
This means that the DWH doesn’t just contain how much guests are paying: we can also break down payments into taxes and revenue for Superhog. This will help us provide more accurate figures in different reports depending on what you need to know *exactly*.
|
||
|
||
Be aware that our figures do not match to the cent with the accounting books: you shouldn’t consider them tax-declaration grade. But the deviations with our accounting figures are minimal, and thus we can confidently use them for business decision making.
|
||
|
||
## Guest KPIs Report
|
||
|
||
After successfully launching our Main KPIs report, we are now expanding our efforts to create specialized KPI reports for each squad, focusing on the metrics that matter most to their unique objectives. In collaboration with each team, we’ve defined key metrics and optimal data presentation formats that will support informed decision-making and real-time tracking.
|
||
|
||
The Guest squad’s report is currently in development, with data models being built to capture all relevant information. A draft of the Guest squad’s Power BI report will soon be ready, providing an initial glimpse of the report’s structure and functionality. This project is expected to enhance each squad's ability to monitor progress and respond quickly to emerging trends, ensuring every team has the insights they need to thrive.
|
||
|
||
## KPIs refactor: now live
|
||
|
||
After some weeks working on improving the KPIs computation flow, we’re happy to announce that all metrics and categories displayed in Main KPIs have been successfully migrated to the new flow. At the moment, there’s minimal to no change on how the KPIs are displayed to business teams.
|
||
|
||
Here’s the list of improvements that we bring with this new flow:
|
||
|
||
- Entities are more granularly split depending on the purpose they identify. For instance, we used to have the computation of Xero metrics within a single flow; while now we effectively split Host Resolutions from Invoiced Revenue into two separated entities.
|
||
- KPIs are computed at daily level with the deepest granularity needed, and afterwards aggregated into the desired time aggregation level. For instance, we used to compute metrics such as Created Bookings directly as a MTD+Monthly per category computation, and a Monthly by Deal computation for Main KPIs. Now, we have a common source of daily created bookings per any desired category that allows us more flexibility on the dimensions and aggregations that will apply to Created Bookings.
|
||
- Centralised KPIs computation within DWH. Before, we used to have the different KPI source models divided within different DWH folders, while now these are centralised within a single KPI folder with their dedicated nomenclature.
|
||
|
||
There’s still some additional work that we aim to complete in the following days, such as finalising the migration of the skeleton of dates needed for Main KPIs, improving the performance of daily segmentation models to speed it up, as well as updating the technical documentation. But the major part of work has been done successfully!
|
||
|
||
# 2024-11-01
|
||
|
||
## Data shows [Booking.com](http://Booking.com) is overtaking Airbnb in Europe
|
||
|
||
Earlier this week, Leo got in touch with us sharing this article: https://www.holidaycottagehandbook.com/post/rates-up-in-europe-and-more-growth-for-booking-com?utm_source=newsletter&utm_medium=email&utm_term=2024-10-30&utm_campaign=Booking+com+growth+and+how+to+thrive+as+Airbnb+co-host. The main point from the article is how [booking.com](http://booking.com) is overtaking Airbnb as a booking channel in Europe, with some specific figures:
|
||
|
||
> According to [Key Data](https://www.keydatadashboard.com/products/prodata?utm_source=referral&utm_medium=partner&utm_campaign=holiday_cottage_handbook), 47% of reservations in Europe come from Booking.com, while 40% come from Airbnb. Eleven percent of bookings are direct, while a small percentage come from Vrbo.
|
||
>
|
||
>
|
||
> Since 2021, in Europe, Booking.com’s market share has grown from 32% to 47%, while Airbnb’s has dropped from 43% to 40%. Direct bookings have fallen from 23% to 11% – but this is likely linked to the COVID-19 pandemic. Vrbo’s market share, meanwhile, has remained flat at 2%.
|
||
>
|
||
|
||
Leo was sceptic about this: did our data match with Key Data’s statement?
|
||
|
||
Uri came to rescue and shed some light on the topic. It seems we are in line with Key Data:, and our data also shows [booking.com](http://booking.com) having more weight than airbnb in Europe.
|
||
|
||
|
||
|
||
Uri to the rescue.
|
||
|
||
|
||
|
||
## Dagster experimentation
|
||
|
||
This past couple of weeks, Pablo started a research spike to evaluate orchestration engines for our Data Platform. Orchestration engines are an important component we are missing in our infrastructure: their role is to organize the execution of jobs, mainly for moving data around, in an orderly way. Pull data from there, transform that table here, update that report there… We are currently doing this in a rather crude way, and we need to use an orchestration engine if we have any hope in scaling things so you can have the data and insights you need, when you need them.
|
||
|
||
|
||
|
||
We couldn’t find an online image with only Dagster and Prefect. But this doesn’t look that bad, does it?
|
||
|
||
The two strong contenders are [Dagster](https://dagster.io/) and [Prefect](https://www.prefect.io/). Pablo is currently busy giving Dagster a test ride to understand how well it would cover our needs. Once we are done with it, we’ll move to Prefect and compare the two. We hope to pick and deploy one of them in production before Christmas hits.
|
||
|
||
## Guest taxes cross-check advances
|
||
|
||
This week we finally got to implement [the recently speced out ruling about taxes for host-takes-risk waivers](https://www.notion.so/Guest-Services-Taxes-How-to-calculate-a5ab4c049d61427fafab669dbbffb3a2?pvs=21) in the DWH, which means we are now in sync with the finance teams in terms of how to compute taxes for the sales of services to guests (Waivers, CIH, etc).
|
||
|
||
[We’ve repeated our cross-check procedure](https://www.notion.so/20240917-Guest-payment-taxes-cross-check-1bbda7c2145c4d60979d049565c1443b?pvs=21) with the new ruling and our numbers are almost matching, so we are currently waiting for Suzannah to give us a thumbs up so we can finally say that our revenue KPIs are reliable and take taxes into account they way it’s meant to be.
|
||
|
||
## A/B Testing warming up
|
||
|
||
One of the most exciting novelties we bring this quarter is Superhog’s first A/B test.
|
||
|
||
If you are not familiar with A/B testing, you can read a bit on the practice here: . It’s a very simple concept which yields a lot of value, even though it’s *not* so simple to implement.
|
||
|
||
This quarter, the Guests Squad and the Data team will team up to run a first A/B test on some of the Guest Journey UX details. We will play with what guests see when going through the journey, hoping to improve conversion rates and revenue metrics.
|
||
|
||
We’ve already agreed with Joan on the details on what changes will we tested and what metrics we will be on the look for. We also discussed this week with the whole squad the technical implementation details: how to show different guests different versions of our journey, and how to ensure we track all data properly so we can compare and study afterward.
|
||
|
||
|
||
|
||
## Refactoring KPIs: first daily models computed
|
||
|
||
This week we’ve continued advancing on modifying the logic of the data flows used for KPIs. As [explained last week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), the goal is to be able to accommodate more needs - such as having daily metrics, product specific KPIs and more - in a centralised, scalable and likely more flexible way.
|
||
|
||
Be warned! this post is a bit more technical. The current architecture is the following:
|
||
|
||
- **Daily stage**: We compute a set of metrics at daily level, at the deepest granularity that we need. We do the huge part of business logic at this stage. Data is materialised into a table to speed-up performance.
|
||
- For instance, we can have created bookings at daily level, and split among the Deal that these can be attributed to, Billing Country, etc. At the same time, we can know if these bookings have been created in the New Dash or in the Old Dash, the Listing Segmentation for that client and date, etc.
|
||
- **Time aggregates**: We can easily aggregate each metric into any desired timeframe. Currently, our Main KPIs use only Month-To-Date (MTD) and Monthly, so we have 2 aggregates per model - but we can basically do whatever we want: Yearly, YTD, MoM, etc.
|
||
- Continuing with our daily created bookings, we can have these aggregated at monthly or MTD level, while still keeping the granularity on the dimensions. For instance, monthly bookings that come from a certain Billing Country, Deal and that are from Old Dash.
|
||
- **Dimension aggregates**: These mainly provide the capacity to make models agnostic on the categories used to split the original metrics. Basically these follow a strategy of given a time range, a dimension and a dimension value; provide a metric value - basically the current setup for MTD/Monthly data display on the Main KPIs report.
|
||
- For instance, monthly created bookings by Deal. Or MTD created bookings by Billing Country
|
||
|
||
|
||
|
||
Current production-ready KPIs following the new strategy. We have 9 entities related to Bookings, Guest Journeys and Guest Payments. The red box encapsulates all Daily models. In the green box, we have the Time Aggregates. In the brown box, all Dimension Aggregates. Lastly, in yellow, we have some temporary tests to validate that the final output is the same as we have currently deployed for reporting purposes.
|
||
|
||
Since this is a business critical refactor, we’ve added some additional tests to ensure the quality of the data. The reality is that for all metrics that are currently in Main KPIs, we just need to ensure that the new ones computed with this strategy have **exactly the same value** for a given date and category.
|
||
|
||
At this stage everything is advancing without blockers, under the hood of DWH. We already have 9 entities comprising mostly Bookings, Guest Journey and Guest Payments metrics that are ready to be deployed. Starting Monday, we will start deploying these new metrics and deprecating the old models to minimise the transitional parallel flow that we currently have.
|
||
|
||
In less words for all our KPIs lovers: you should not observe any difference and all this magic will happen without being aware 🧛🏽♂️
|
||
|
||
## Updating how we retrieve New Dash users
|
||
|
||
This week we’ve also did a quick implementation to improve the way we’re tracking that a user is in New Dash.
|
||
|
||
With the help of the Dash Squad, that have put in place a more precise logic, we’re now able to easily determine if:
|
||
|
||
- A User is in New Dash or not
|
||
- In which New Dash version a user has first appeared
|
||
- If a User was originally moved from Old Dash to New Dash and when did it happen
|
||
- If a User was directly created in New Dash
|
||
|
||
This will help us in the reporting of New Dash performance, as well as be able to track V2 users as they get created or moved in the future.
|
||
|
||
Special thanks to Luke for the support on this subject!
|
||
|
||
# 2024-10-25
|
||
|
||
## New Churn metrics are available in Main KPIs
|
||
|
||
This week we’ve finalised the main line of work on computing and reporting Churn figures. As we explained last week, the volume of churning accounts is not a good representative on the impact it has to our business - mainly because small hosts that are churning will have a much more limited impact in terms of Revenue, Listings and Bookings with respect of a big host churning.
|
||
|
||
We’ve come up with 3 different Churn Rate metrics, which measure the relative impact the churning accounts in a month have with respect of the overall business. Specifically, these metrics are:
|
||
|
||
- Bookings Churn Rate
|
||
- Listings Churn Rate
|
||
- Revenue Churn Rate
|
||
|
||
The detailed definition of these rates is accessible in the Data Glossary of Main KPIs, as described in the screenshot below (double click to make it larger!)
|
||
|
||
|
||
|
||
These metrics have been validated with Matt and Suzannah and have been made accessible in Main KPIs, specifically in the tabs:
|
||
|
||
- MTD
|
||
- Monthly Overview
|
||
- Global Evolution over Time
|
||
- Detail by Category
|
||
|
||
This also means that these metrics can be seen as well by the 2 categories: Billing Country and Number of Listings segment.
|
||
|
||
Overall these metrics show quite a bit of volatility in a monthly basis because the share of Revenue, Bookings and Listings each churning account has can deeply vary over time. We do not observe any clear pattern of seasonality at this stage.
|
||
|
||
|
||
|
||
Example of the volatility we have for these new metrics in the Global Evolution over Time, in some random selection. This is linked to the fact that the different Churning accounts have diverse characteristics. Please go to the report to see the actual figures.
|
||
|
||
That’s it for the time being for the Data line of work in the Churn subject. But likely we’ll work more on this in future months to come. Very exciting project and nice collaboration with Alex, Suzannah and Matt!
|
||
|
||
## Improvements in Account Managers reporting (previous Top Losers)
|
||
|
||
This week we’ve also finalised the line of work of Top Losers → well, now it’s called Account Managers reporting.
|
||
|
||
The main improvement - aside of the name of the report - has been integrating Hubspot key attributes of each account, such as the Account Manager each account is assigned to, the moment an account went live, went it was offboarded - if it’s the case, etc. This allows for more flexibility when exploring the performance of each account and the impact it can have for our business.
|
||
|
||
Additionally, we’ve included Listing information of each account as well as other minor changes, such as renaming TOP LOSERS to MAJOR DECLINE; TOP WINNERS to MAJOR GAIN, etc. These new names should better reflect the meaning behind the scoring computation.
|
||
|
||
Even though the reporting is quite simple - just one interactive tab - the possibilities are quite interesting. For instance, in the screenshot below we can see the performance of 2 accounts: one categorised as MAJOR DECLINE (purple) and another as MAJOR GAIN (green).
|
||
|
||
|
||
|
||
Example with 2 account selection. Green line is categorised as MAJOR GAIN while Purple line as MAJOR DECLINE.
|
||
|
||
We can visually see how the purple line has been decaying over time, while the green one is increasing - specially in the Revenue chart. In this case, both accounts are currently in the lifecycle state of Active, meaning these have not churned - yet we can clearly see the decline of the purple account: time to act!
|
||
|
||
The fact of actually being able to quantify both the growth of the account and the impact this growth can have to our business is key on prioritising retention efforts. That’s why specifically focusing on those accounts that are tagged as MAJOR DECLINE but that have not churned yet can be very meaningful on ensuring the long-term objectives of Truvi.
|
||
|
||
Lastly, we’ve also conducted a training session with the account managers to explain how to use the report and what kind of information can be found. Hopefully it will become a key report for better data-driven actions from AM side!
|
||
|
||
## How are we going to handle more demand for KPIs?
|
||
|
||
At this point you’ve seen we’ve closed two lines of work this week: Churn definition and the Account Managers reporting, to - hopefully - help understanding and preventing Churn. Cool, what’s next?
|
||
|
||
Well, the reality is that these two lines of work have some clear dependencies within DWH with our main data modelisation flow of KPIs, and has proven to show some limitations. This by itself is not a big problem, but we need to take into account how are we going to accommodate future needs for KPIs. And these needs are already here!
|
||
|
||
In essence, we will start shortly with the dedicated Product KPIs, mostly for Dash and Guests as a first start. However, we had a decision to make - are we going for a centralised approach, meaning, computing all KPIs within the same flow or having dedicated flows for each reporting line?
|
||
|
||
In short, centralising seems a better option, specially because there’s some needs that clearly will be needed between multiple reports: for instance, if there’s a new product launch, likely we’d like to see a more detailed version of the product performance while still report product revenue in Main KPIs. And handling a similar modelisation within 2 flows will become messy overtime. Specially if it’s 3 flows instead of 2. Or 4. You get the point.
|
||
|
||
This has some drawbacks though, which mostly are related to the fact that we do not store (yet) daily figures to have quite a speedy process, which we should do since it opens up many more reporting possibilities. Additionally, we’d need to be able to contain many more metrics, categories, etc., in order to fit all needs.
|
||
|
||
|
||
|
||
Even Boromir agrees…
|
||
|
||
So how can we be able to scale up the KPIs flow to accommodate these and future needs?
|
||
|
||
Well, the answer is… we’re working on it. Some areas are quite straight-forward to tackle, others a bit more complex. But more complex means funnier - *such as the 80 million records of a potential daily listing segmentation*. At the moment we’re currently doing a proof of concept and so far it’s going great. With a bit of luck we’ll have more interesting news to share soon on this subject.
|
||
|
||
# 2024-10-18
|
||
|
||
## Athena and e-deposit databases have been successfully split
|
||
|
||
[After some weeks of preparation](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), this week we finally pulled the trigger together with the API Squad and performed the migration of the Athena/e-deposit database.
|
||
|
||
The records for both services lived together in a single database up until last Wednesday, but that won’t be the case anymore. After the changes made by the API Squad, Athena (aka Guesty) records will keep appearing in the same database, but e-deposit records will land in a new one.
|
||
|
||
On the DWH side, we replicated the split by going from one to two ingestion pipelines into the DWH, one for each database. This split also got propagated throughout the DWH, with independent table and pipelines handling the two services. Despite this, related reports will keep showing the same data thanks to the prep work done by the Data team.
|
||
|
||
In the end, this is a technical change with little noticeable impact as of today, but it will help us work better long-term. Kudos to the API Squad for the good work.
|
||
|
||
## Domain Analysts Programme begins
|
||
|
||
This week we also began work on one of the most exciting goals we have for this quarter: onboarding our first Domain Analysts!
|
||
|
||
Let’s cover definitions first: our vision for the Domain Analyst profile is a hybrid between a Data Analyst and a functional expert in some area (Marketing, Finance, Product, etc). This is, someone how is extremely knowledgeable on some Domain, and counts with Analyst knowledge and access to [Superhog’s Data Platform](https://www.notion.so/Data-Platform-908fafb0c4b345139a89d8684c281d24?pvs=21). With this combination, the Domain Analyst can be a reference expert that helps leverage Data in its specialized area. To clarify, we expect these analysts to sit within teams in their domains, not within the Data team itself. With this, we achieve a bit of a hub-and-spoke set up that balances centralization and decentralization in Superhog’s data expertise.
|
||
|
||
And no, we haven’t hired any new faces. Instead, we’ve decided to grow the talent internally! Alex A. and Jamie D. have been selected to become our first Domain Analysts. They have been doing a great job with us for a long time, and it shows since they are already acting as go-to people within their areas. With their onboarding, we expect them to increase their skills and, simply, do what they are already doing, but even better.
|
||
|
||
During the next quarter, the Data team will work together with them to improve their skills on databases, SQL, data modelling, and other tools that any analyst should have in their belt. By the end of the quarter, we expect to all be wondering how did we manage to survive so long without these powers in their hands.
|
||
|
||
Good luck Alex and Jamie!
|
||
|
||
## Athena claims negotiation support
|
||
|
||
Following up on our [last weeks update](https://www.notion.so/Data-Platform-908fafb0c4b345139a89d8684c281d24?pvs=21), this week we continued analysing the patterns on our Athena (guesty’s e-deposit) API to better understand them and provide intelligence around some ongoing terms negotiation.
|
||
|
||
We discussed together with the involved team the Data and were able to draw interesting insights that will drive some of the points in our proposals to Guesty.
|
||
|
||
Now that the Data is served, it’s up to our expert negotiators (Leo and Humphrey) to seal the deal.
|
||
|
||
## Top losers report is now live
|
||
|
||
In the previous entry of the Data News we presented a [work-in-progress report](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) to be able to track the performance of the different accounts and categorise them based on growth and impact. During this past week we have finalised the Power BI reporting and shared it with users to gather impressions and improvements.
|
||
|
||
We already implemented some small changes, such as quantifying the amount of Bookings each account has had in the past and provide a summary table.
|
||
|
||
With the integration of Hubspot data we will be able to enrich the reporting by identifying key aspects of each account, such as the moment these accounts went live, when they have offboarded (if it’s the case) and even the Account Manager that is assigned to each account.
|
||
|
||
## Churn definition update
|
||
|
||
This week we made great advances towards the definition of Churn rates. As a reminder [from last week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), the goal is to measure the impact our churn is having in different indicators, mainly Revenue, Bookings and Listings. Why?
|
||
|
||
Well, imagine in month A we had 50 accounts churning and in month B we had only 10. We could be tempted to say that month A was worse in terms of churn than month B, but that might be inaccurate. Maybe those 10 accounts that churned in month B actually provided much more revenue and bookings that the whole 50 accounts of month A!
|
||
|
||
The problem is how can we quantify in a monthly basis these Revenue, Booking and Listing Churn in terms of rates, meaning attributing a given % of Revenue, Bookings and Listings over Churning accounts with respect of the global. After some refinement sessions with Matt and Suzannah, we prioritised Revenue and Booking Churn, and ended up with two measuring possibilities, each one with its pros and cons - it’s a bit technical so we won’t go into the details. At that stage we decided the best was to actually compute both possibilities and take a final decision based on real numbers rather than assumptions.
|
||
|
||
First things first though, we needed to update our consideration for Churning accounts in a given month. With the recent integration of Hubspot Deals data into the DWH and the outstanding support from Alex A., we managed to implement a more accurate definition:
|
||
|
||
> A Deal is considered as churning in the month that:
|
||
>
|
||
> - The contract is marked as offboarded in Hubspot, **OR**
|
||
> - last booking created was 13 month ago
|
||
|
||
This definition has already been implemented for the metric **Churning Deals** and is **fully available in Main KPIs reporting**. This has also improved the quality of the Deal Lifecycle, since we’re able to capture Deal offboarding, which is much more precise than our previous definition. No change has been made in the Listing lifecycle or Churning Listings at this stage.
|
||
|
||
Lastly, the new metrics for Revenue and Booking Churn rates are at this moment under validation. Once validated, we will provide the final definition and make these new KPIs available in the Main KPIs reporting. Special thanks to Alex Anderson for his massive support on this subject!
|
||
|
||
# 2024-10-11
|
||
|
||
## Guesty claims analysis
|
||
|
||
This week we got pulled in to support some data-driven decision making around our Athena service (e-deposit for Guesty). Leo and co. were interested in understanding the patterns of claim posting by the different partners that come through this channel. This would better help us propose terms better in an upcoming contract negotiation we will have.
|
||
|
||
Our work is still WIP, but we’ve already been able to identify very distinct claiming patterns across the partner base, which is exactly the kind of fact we needed to learn about to support the business decision. We will keep working on this together with the team.
|
||
|
||
This is also a great example of how you can rely on the Data Team for support in your day to day!
|
||
|
||
## Churn metrics and Top losers report
|
||
|
||
This week we started investigating on the different forms of Churn we have in Truvi. In essence, Churn is a measure of the clients that at some point in the past had some activity within Truvi and now not anymore. Having a proper **Churn definition** can help the understanding of the general trend of the business, as well as identifying areas of improvement by providing further knowledge on seasonality and reasons for offboarding.
|
||
|
||
At this stage, we have two separated Churn definitions, at deal level: the RevOps one, mainly, when did a client offboard and the Data one, which is based on the [Deal Lifecycle](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) and tags clients as Churning if their last booking created was 13 months ago. First things first, we are in need to align the definitions to have a coherent understanding of churn among the different areas in the business - and likely, the definition will take a combination of both definitions.
|
||
|
||
Once we have this definition setup, we also need to attribute activity metrics to these Churning customers. This will include being able to measure **Revenue Churn**, **Booking Churn** and **Listing Churn**. While the churn definition discussion is still ongoing, you probably have noticed that the previous definitions are quite strict in the sense that the possibilities of acting to retain these customers once these are tagged as churned are quite minimal. This is when we discuss **Churn Prevention**, and it’s a different line of work.
|
||
|
||
In order to anticipate which accounts are “at risk of Churning soon” or even “have had some recent decay in performance”, we are currently building a **Top Losers** report, to help Account Managers on identifying and prioritising retention efforts. At the moment the idea is to provide a very simple reporting that provides two scores:
|
||
|
||
- **Growth**: as a data-driven measure to identify if the account is growing or decaying
|
||
- **Impact**: the impact in terms of revenue a certain growth can have
|
||
|
||
Thus, if Growth is negative, meaning the account is decaying, we would be able to prioritise efforts by the revenue Impact it can mean for Truvi. Lastly, this work-in-progress report can be enriched with the data we are ingesting from Hubspot, thus it’s a clear use-case for [the work we’ve been conducting in previous weeks](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md).
|
||
|
||
|
||
|
||
Our one-pager Top Losers report. This is still WIP and might change in the future.
|
||
|
||
That’s it! This Churn project it’s still in early stages at the moment so keep tuned for future updates in the coming weeks.
|
||
|
||
## Migration of e-deposit database
|
||
|
||
This week we’ve finally aligned all the pieces with the API Squad for the upcoming Athena/e-deposit database migration. Next Wednesday, the API squad will be splitting the current database into two distinct ones: the existing one will remain the DB for Athena, while the new one will be dedicated exclusively to the other e-deposit clients.
|
||
|
||
The Data Team has prepped to keep ingesting everything correctly in the DWH, and we aim to support this migration while keeping our reporting up and running without downtime.
|
||
|
||
Will keep you posted and hopefully come back next Friday with the announcement that everything took place successfully.
|
||
|
||
## dbt meetup
|
||
|
||
Last week Data Team went out for lunch and continued the afternoon with a quick field trip to the local Barcelona dbt meetup. dbt is one of the core technologies we use in the Data Team, and without which doing the work we do would be *really* hard. There is a local community that holds technical meetups every couple of months, and these are typically attended by other data, product and software professionals.
|
||
|
||
All of us attended the meetup for the first time, and we had the chance to learn how colleagues from other companies work with Data in their businesses.
|
||
|
||
|
||
|
||
Superhog’s Data Team in the first row. Pablo’s pony tail finally serves a useful purpose.
|
||
|
||
## A/B testing discussions
|
||
|
||
This week we’ve also started the discussion to launch the first A/B test within the Guest Journey, with the goal being launching and finish an A/B test before the end of Q4.
|
||
|
||
The idea of A/B testing is to randomly split traffic into 2 groups, A and B; and group A will see a different setup of the Guest Journey with respect to B. Generally, one of the 2 groups is the same as the current state, thus referred as the Control group, and the other has some controlled changes with respect to the Control group - different pricing, different visuals, etc - usually named as Study group.
|
||
|
||
A/B testing can provide many benefits on understanding cause-effect when there’s a new deployment, since we’ll be observing the performance of two groups in a controlled environment, at the same time, which reduces the seasonality bias. Also, it ensures that if there’s a buggy deployment in place, the negative impact is minimised since it’s not affecting all traffic.
|
||
|
||
|
||
|
||
We’re starting small at first - we want to do this right. There’s plenty of things that can go wrong in A/B test implementation, and wrong configurations means wrong results which leads to poor decision making. But once we succeed on this first A/B and ensure the process is right, taking decisions based on actual measurable performance will be much easier in future months.
|
||
|
||
## Main KPIs Significant Renaming
|
||
|
||
On Thursday 10th of November we’ve deployed new changes in the Power BI report of Main KPIs within Business Overview. With the goal to better align with Finance figures, now **Guest Revenue won't deduct anymore the amount that is paid back to hosts**, and in contrast, will identify any guest payment after taxes. **This also impacts the figures in Total Revenue** and weighted revenue figures. The detail of the Waivers is still available (revenue, payments to hosts and retained amount).
|
||
|
||
Additionally, there has been a **renaming of revenue KPIs** to clarify the meaning of the values observed. We encourage the users to check the updated Data Glossary for further information.
|
||
|
||
Find below a summary table of the changes:
|
||
|
||
| Metric name | Metric previous name | Computation changes |
|
||
| --- | --- | --- |
|
||
| Total Revenue | Total Revenue | Waiver amount paid back to hosts is no longer deducted, thus figure is now higher than before. |
|
||
| Total Revenue per Booking Created | Total Revenue per Booking Created | Waiver amount paid back to hosts is no longer deducted, thus figure is now higher than before. |
|
||
| Total Revenue per Guest Journey Created | Total Revenue per Guest Journey Created | Waiver amount paid back to hosts is no longer deducted, thus figure is now higher than before. |
|
||
| Total Revenue per Deals Booked in Month | Total Revenue per Deals Booked in Month | Waiver amount paid back to hosts is no longer deducted, thus figure is now higher than before. |
|
||
| Total Revenue per Listings Booked in Month | Total Revenue per Listings Booked in Month | Waiver amount paid back to hosts is no longer deducted, thus figure is now higher than before. |
|
||
| Guest Revenue | Guest Revenue | Waiver amount paid back to hosts is no longer deducted, thus figure is now higher than before. |
|
||
| Guest Revenue per Guest Journey Completed | Guest Revenue per Guest Journey Completed | Waiver amount paid back to hosts is no longer deducted, thus figure is now higher than before. |
|
||
| Guest Revenue per Guest Journey with Payment | Guest Revenue per Guest Journey with Payment | Waiver amount paid back to hosts is no longer deducted, thus figure is now higher than before. |
|
||
| Waiver Revenue | Waiver Amount Paid by Guests | - |
|
||
| Damage Host-Waiver Payments | Waiver Amount Paid back to Hosts | - |
|
||
| Waiver Retained | Waiver Net Fees | - |
|
||
| Check-in Hero Revenue | Check-in Hero Amount Paid by Guests | - |
|
||
| Deposit Fees Revenue | Deposit Fees | - |
|
||
| Invoiced Booking Fees Revenue | Invoiced Booking Fees | - |
|
||
| Invoiced Listing Fees Revenue | Invoiced Listing Fees | - |
|
||
| Invoiced Verification Fees Revenue | Invoiced Verification Fees | - |
|
||
| Invoiced Athena Revenue | Invoiced Guesty Fees | - |
|
||
| Invoiced E-Deposit Revenue | Invoiced E-Deposit Fees | - |
|
||
|
||
Lastly, Guest Payments and Guest Payments weighted measures have been deleted since they represent now the same as Guest Revenue and Guest Revenue weighted measures.
|
||
|
||
# 2024-10-04
|
||
|
||
## Q3 Data Achievements, bye bye Q3!
|
||
|
||
October already! It’s been 3 busy months, and here at the Data Team we did tons of things: set up business KPIs, support product and finance initiatives and continue setting up our Data foundations.
|
||
|
||
It’s time to close Q3 and start focusing on the latest quarter of the year. Before that though, we wanted to take a moment to write down our collective data achievements. Find the full content below:
|
||
|
||
[Q3 Data Achievements ](https://www.notion.so/Q3-Data-Achievements-1130446ff9c9800e84e4f03750b752a1?pvs=21)
|
||
|
||
Also, our dear Joaquín will be off for a couple of weeks to take some very well deserved holidays.
|
||
|
||
## New Dash and New Pricing data integration moving forward
|
||
|
||
This week we have been quite busy advancing in the reporting needed for New Dash. Our current goal is to integrate the new backend tables in the scope of New Pricing, at first, to be able to monitor New Dash V2 once deployed. Overall, we would like to set up monitoring on the Services and the revenue that these are brining.
|
||
|
||
Specifically, we’ve integrated 9 new tables this week:
|
||
|
||
- `ProductService`
|
||
- `ProductServiceToPrice`
|
||
- `BillingMethod`
|
||
- `InvoicingMethod`
|
||
- `PaymentType`
|
||
- `Protection`
|
||
- `ProtectionPlan`
|
||
- `ProtectionPlanToPrice`
|
||
- `ProtectionPlanToCurrency`
|
||
|
||
… and we’ve started playing around with the data in order to propagate this information within the different layers of our DWH. Additionally, we’ve asked for some updates additional content in order to properly track which services are being applied to each booking. Since this is starting to get bigger, we’ve also spent some time to track the current status of the different new data flows in order to not miss anything important. It’s accessible through [this Notion page](https://www.notion.so/2024-10-02-Integrating-New-Dashboard-New-Pricing-into-DWH-1130446ff9c9804a9cb2f5d49e073bab?pvs=21). Thankfully we’ve counted with extensive support from the Dash squad, so many thanks to Dagmara, Gus and Yaseen!
|
||
|
||
Lastly, there has been a couple of fixes on our current pipelines for New Dash MVP monitoring, especially thanks to Clay’s test account!
|
||
|
||
## First steps towards dedicated Product KPIs
|
||
|
||
A few weeks ago we started gathering requirements on the KPIs needed for the different product managers in order to bring more data-driven decision making on the product initiatives.
|
||
|
||
At the moment, we’ve completed the first round of contacts in the main areas, as well as clarified the first drafts within Guest and APIs needs so we can start planning development on our side.
|
||
|
||
|
||
|
||
Cool metric but… at which date do you want to attribute it, creation, check in or check out?
|
||
|
||
Overall, very nice deep-thinking sessions. More on this subject soon!
|
||
|
||
## Foreign Data Wrappers are here and analysts are loving them
|
||
|
||
Last week, we rolled out a new improvement to our DWH development environment to improve the experience of the Data team members: our local Postgres environments now include Foreign Data Wrappers to the production DWH instance for sync schemas.
|
||
|
||
[Foreign Data Wrappers (FDWs)](https://wiki.postgresql.org/wiki/Foreign_data_wrappers) are a very convenient Postgres feature. FDWs allow setting a connection within a Postgres server to some other external data store, making the tables in that external system appear as local tables which can be queried exactly the same as regular tables and views.
|
||
|
||
We have leveraged them to allow analysts to easily access real production data in their local environments. This allows a very smooth developer experience: Data team members can build models in their laptops with exactly the same data that will be found in the production DWH, which makes spotting errors and performance issues much simpler and faster. This setup, together with our adherence to [trunk based development](https://trunkbaseddevelopment.com/) allow us to deliver changes to our production DWH fast, often several times per day.
|
||
|
||
Even though this is a rather technical and internal improvement, you might notice it because Uri and Joaquín yell less frequently at their laptops since they don’t have to struggle with copying data anymore.
|
||
|
||
## Continuing work on Hubspot data
|
||
|
||
After [integrating our Hubspot instance with our DWH](https://trunkbaseddevelopment.com/), we’ve started to work on modelling it properly so that it can be leveraged to build analyses and reports. Hubspot tables are tremendously complicated and data heavy (some of our servers choked reading from them for the first time), so cooking them up to ease their consumption will be a must.
|
||
|
||
We are teaming up with Alex A. to understand the different properties and decide which bits are most critical. We have decided to focus on Deals and Engagements (ie records about calls, mails, meetings, etc) for now, so we will try to leverage the most important fields out of those tables.
|
||
|
||
Stay tuned for some great reports making the best out of this data very soon.
|
||
|
||
# 2024-09-27
|
||
|
||
## Progress in CIH and Cancellation API billing process definition
|
||
|
||
This week we’ve made progress in documenting the billing processes that we will be followed for two of our new services: CIH API and Cancellation API.
|
||
|
||
The Data team will be acting as a data bridge between the backend systems that support these products and the delivery of the invoicing data in Xero. This way, we will be able to generate invoices in our accounting system without any human interaction, allowing us to scale our services without major operational pains.
|
||
|
||
You can read our WIP process documentation here:
|
||
|
||
- [CIH API Invoicing process](https://www.notion.so/CIH-API-Invoicing-process-1060446ff9c980d5a5cdfaf253667bac?pvs=21)
|
||
- [Cancellation API Invoicing process](https://www.notion.so/Cancellation-API-Invoicing-process-5c83b1465bb744f89d052232f39396bf?pvs=21)
|
||
|
||
We will now wait for inputs from the Finance and API teams so we can settle for a final and complete definition before we move on to some tests.
|
||
|
||
Hopefully, we will soon be making invoices for real sales!
|
||
|
||
## HubSpot Data Now Integrated into Our Data Warehouse
|
||
|
||
## HubSpot Data Now Integrated into Our Data Warehouse
|
||
|
||
We’re excited to announce that we have successfully extracted and integrated data from HubSpot into our data warehouse (DWH). This is a significant milestone, giving us access to a wealth of valuable data that was previously kept in HubSpot. While we are still navigating the vast amount of information stored in HubSpot, we have started by focusing on what we believe to be the most relevant datasets for our current reporting needs.
|
||
|
||
The integration of HubSpot data into our DWH provides significant benefits, including easier and faster access to key metrics by centralizing data, eliminating the need for manual exports or separate logins. This also enhances reporting capabilities, allowing for deeper insights into customer interactions, sales, and marketing performance. By combining HubSpot data with existing operational data, we can achieve more comprehensive analysis, offering a clearer understanding of performance, customer behaviour, and opportunities for improvement.
|
||
|
||
## Updated Host Fees Report
|
||
|
||
This week, the Host Fees report received a significant update aimed at improving user experience. The report now displays all payments in their respective currencies, accurately converted to GBP using the correct exchange rates. Additionally, new visualizations have been added, and existing data has been refined to provide clearer insights. These enhancements ensure a smoother, more efficient experience for users accessing the report.
|
||
|
||
# 2024-09-20
|
||
|
||
## New Dash MVP reporting fixes, preparing for V2 launch
|
||
|
||
This week we’ve also fixed a downtime of the New Dash reporting, which currently contains the MVP performance. A couple of weeks ago, with the appearance of new MVP users, our data transformations were not able to process the data correctly. After some discussions with the tech team, we managed to find a way to properly track MVP performance, which we implemented and deployed soon after.
|
||
|
||
In order to reduce potential future downtimes we are already preparing for the launch of V2. At this stage, we aim to detect moved users from the old dash to the new with the newly configured claim values - and if everything goes according to plan, it should happen automatically on V2 launch without any action from Data side.
|
||
|
||
Of course though, there’s going to be some other actions to be handled by the Data team before the launch. We also need to improve the capabilities of the New Dash Reporting from which we have already gathered requirements and started understanding how to extract this data. So stay tuned and hopefully we’ll have more news in a couple of weeks!
|
||
|
||
## Check-in Hero reporting now without taxes
|
||
|
||
It’s been a while since we’ve been working to be able to deduct the [taxes on Guest Payments](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) to have a more consistent computation of the different revenue sources. In regard with this initiative, we’ve also taken the opportunity to modify the [Check-in Hero reporting](https://app.powerbi.com/groups/me/apps/14859ed7-b135-431e-b0a6-229961c10c68/reports/8e88ea63-1874-47d9-abce-dfcfcea76bda/ReportSection?experience=power-bi) so the monetary amounts displayed are consistent with those of other reports, such as Main KPIs, which are without taxes.
|
||
|
||
Now, the Check-in Hero amounts reported are without taxes. In some cases though we’ve decided to keep both with and without taxes amounts since it can be useful for different teams. In any case, the visuals properly identify the exclusion or inclusion of taxes.
|
||
|
||
Lastly, we’ve taken the opportunity to do some small visual changes around the report to improve the user experience.
|
||
|
||
## Guest Payments Report & Main KPIs now without taxes
|
||
|
||
Just like with Check-in Hero report, we have updated both the [guest_payments - Power BI](https://app.powerbi.com/groups/me/apps/33e55130-3a65-4fe8-86f2-11979fb2258a/reports/01d5648d-1c0b-4a22-988d-75e1cd64b5e5/ReportSection?experience=power-bi) and [main_kpis - Power BI](https://app.powerbi.com/groups/me/apps/33e55130-3a65-4fe8-86f2-11979fb2258a/reports/5ceb1ad4-5b87-470b-806d-59ea0b8f2661/cabe954bba6d285c576f?experience=power-bi).
|
||
|
||
In the first report, you can easily see all guest payment values, both with and without payment, by applying a simple filter based on the user's needs. We have also updated some visuals on the report to enhance its usability.
|
||
|
||
|
||
|
||
For the main KPIs, we have updated all guest payment values to exclude taxes, ensuring better alignment with the finance team and their reporting. Additionally, we resolved issues with rates that were not being calculated correctly when selecting multiple countries or groups based on the number of available listings.
|
||
|
||
A small note on this: when selecting a category with multiple values, the rate metrics do not aggregate correctly. As a result, we do not display these metrics when multiple values are selected. We recommend reviewing rate metrics for each category individually.
|
||
|
||
|
||
|
||
***When selecting 2 or more countries you won’t see any values***
|
||
|
||
## More Cosmos DB integrations: Screening API
|
||
|
||
Following [our recent integrations to DWH for e-deposit](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), this week we’ve started to integrate as well Screening API verifications into the DWH. By using our internal tool `Anaxi`, we tested the new configuration and seems to be working well. This will allow in the following days the modelisation of the screening data within DWH, on which the Data team has much more versatility and migrate the source of the Screening API report in Power BI from Cosmos DB to DWH.
|
||
|
||
|
||
|
||
This is why you don’t let Data Analysts do Data Engineer jobs 😛. Special thanks to Pablo for the knowledge sharing on this area!
|
||
|
||
# 2024-09-13
|
||
|
||
## Quarterly alignment with TMT
|
||
|
||
[After some recent preparations](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), this week we finally held the meeting together with the TMT to discuss the priorities and scopes of the Data team for Q4. It was a good session in which we were able to go over our proposal contents together with the team and discuss around them.
|
||
|
||
Overall, we were pretty well aligned already (which is great news, in our opinion) and we only made minor edits in the plan. You can check the scopes we are aiming for here: [Q4 Data Scopes proposal](https://www.notion.so/Q4-Data-Scopes-proposal-75bf38ab8092471d910840ab86b0ec60?pvs=21)
|
||
|
||
For now, we will focus on brushing up on the Q3 outstanding items so we can happily close the ongoing quarter.
|
||
|
||
## Small updates on KPIs by Deal
|
||
|
||
This week we’ve added a couple of improvements on the Main KPIs reporting, specifically on the Deal tabs.
|
||
|
||
First things first: we have now an account name linked to the Deal ID, to better understand which account are we referring to when selecting a deal. Now, you’ll be able to select the KPIs per deal via the ID or the Name. Keep in mind though that currently we do not have a source of truth for “this ID Deal has this Name”, so the names displayed might be different than those that you might be used to. If you observe any inconsistency, please let us know!
|
||
|
||
|
||
|
||
Name and Billing Country are now displayed in the Deal Comparison and Detail by Deal tabs. Additionally, a new filter on Deal Name is now available.
|
||
|
||
Additionally, we are now providing the Billing Country of each Deal to ease up the comparisons. This is specially useful for whenever we’re comparing KPIs within different Deals, so we can easily understand where these hosts are located.
|
||
|
||
In the following days we will wrap up this exercise of Main KPIs, since most of the requirements discussed have already been implemented.
|
||
|
||
# 2024-09-06
|
||
|
||
## We need your feedback!
|
||
|
||
This week we sent a survey to assess the current process of handling Data requests. It's been ~3 months since we have implemented the process, so we would appreciate any feedback you might have around it to make it even better!
|
||
|
||
|
||
|
||
Everyone is invited to answer - those who use the Data Request workflow, those who directly contact Pablo, Uri or Joaquín directly or those who have never requested any help from Data. Any input is valuable to improve!
|
||
|
||
We promise it will take you 2 minutes to answer it. Here’s the link to the survey:
|
||
|
||
→ [Survey link here](https://forms.office.com/Pages/ResponsePage.aspx?id=30IohpgpJki-qbcmvAHTp3Q6r_qBevlBs8LDITDWGdFUMlJWQjhHWE80SFI5QjVJQUdXU1MyN1RZNC4u)
|
||
|
||
A massive thanks to all people who already submitted your feedback!
|
||
|
||
## Now available: KPIs by host Billing Country
|
||
|
||
A few days ago we implemented the first category - or dimension - within the [Main KPIs](https://app.powerbi.com/groups/me/apps/33e55130-3a65-4fe8-86f2-11979fb2258a/reports/5ceb1ad4-5b87-470b-806d-59ea0b8f2661/cabe954bba6d285c576f?ctid=862842df-2998-4826-bea9-b726bc01d3a7&experience=power-bi) reporting, namely the [host segmentation based on the number of active listings](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md).
|
||
|
||
This week we have deployed a new category, the Country in which our clients are being billed in. This category reflects the location of the clients in terms of sourcing effort, but of course their listings can be placed anywhere in the world, as we saw in [this analysis](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md).
|
||
|
||
With this new dimension, we’re able to provide more specific insights based on the Host location. Let’s see some of them!
|
||
|
||
1. Around ~80% of the Check-in Hero revenue comes from USA hosts:
|
||
|
||
|
||
|
||
1. USA is steadily gaining market share over GBR in terms of number of Listings Booked in Month and Bookings Created:
|
||
|
||
|
||
|
||
Listings Booked in Month evolution
|
||
|
||
|
||
|
||
Created Bookings evolution
|
||
|
||
Additionally, this week we’ve added a new metric, Billable Bookings. It’s been… well, very complicated to get the logic in place to compute them in the DWH and still we observe some small discrepancies here and there. In any case, the order of magnitude should be close to the reality thus we decided to move forward and expose this new metric. We just added the prefix “Est.” to specify that Billable Bookings are estimated.
|
||
|
||
|
||
|
||
Lastly, Main KPIs report is now appearing on the top of Business Overview Power BI app. After many weeks of work, the most critical information of the revenue reports is already included in the Main KPIs reporting, as well as many other business-wide insights. So now Main KPIs leads Business Overview!
|
||
|
||
## First steps towards business-oriented Data Tests on KPIs
|
||
|
||
Now that we have [implemented an automatic way to test the behaviour we expect from the data](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), we decided to improve the bandwidth of alerts by including some business logic…
|
||
|
||
… and what better place that doing so in the main KPIs of the company!
|
||
|
||
|
||
|
||
A real Superhog example of outlier - can you guess what is represented in the Y-axis?
|
||
|
||
This week we covered the KPIs with a couple of meaningful tests:
|
||
|
||
1. Ensure that the sum of a given set of metrics for any category cannot be higher than the Global reported value.
|
||
1. For example: the sum of bookings created in the different host billing countries of USA, GBR, CAN, etc cannot surpass the bookings created stated in the Global category.
|
||
2. Ensure that the latest values of a given set of metrics are within an “acceptable range” based on the previous history.
|
||
1. For example: if the amount of bookings created usually are around 1k, we will raise an alert if one day we spot a value of 10k.
|
||
|
||
Beyond extending the capacity to detect that our developments within KPIs are not flawed, we are in a much better spot to automatically detect and alert us if there’s any massive underlaying data issues - such as the increase of Checkout/Cancelled Bookings we had a few days ago.
|
||
|
||
## E-Deposit Report Update
|
||
|
||
Our team has been hard at work updating the E-Deposit report as part of our ongoing efforts to improve data handling. We’ve successfully migrated data from Cosmos DB into our Data Warehouse (DWH), enabling smoother integration with our reporting systems. This significant step forward will allow us to better manage, manipulate, and connect the data with existing tables for enhanced analysis and reporting.
|
||
|
||
While the migration has presented several challenges, including issues with data integrity, we are actively collaborating with the development team to resolve these as quickly as possible. Our goal is to ensure that the final report delivers the most accurate and reliable insights, reinforcing our commitment to high-quality data.
|
||
|
||
We expect the updated report to be available early next week for everyone who needs access. Stay tuned for further updates!
|
||
|
||
|
||
|
||
## Quarterly planning: Our proposal is on the table
|
||
|
||
Following up from [our last update](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), we’ve already finished up our proposal for which scopes and priorities we want the Data team to deliver for the company in Q4’24.
|
||
|
||
The full blow proposal is quite detailed and still subject to change, since we will be discussing it next week in a meeting with the TMT. Nevertheless, you can check below a screenshot of its executive summary so you can get a feel on which way are planning to go.
|
||
|
||
|
||
|
||
And again: if we have somehow managed to not be aware of something critical you need from the Data team, this is a last minute call to bring it up so we can properly plan for it. [Get in touch with us!](https://www.notion.so/Data-Homepage-0ac0a2e52a8940c7ba4f31e5ffcc33e8?pvs=21)
|
||
|
||
# 2024-08-30
|
||
|
||
## Automated Data Tests are now live
|
||
|
||
When you are sitting on top of a lot of data, there are *tons* of things that can go wrong.
|
||
|
||
As we keep on ingesting data from different systems into our DWH, and then transform it, mix it and prepare it there so it’s useful for everyone, many Data Quality issues can pop up. Missing records, duplicated fields, IDs that should be unique but are not, gaps in time series, negative prices… you name it.
|
||
|
||
The quality of our data is a sensitive topic because many of you across the company are relying on it to make decisions and do your job. If the data that we show is telling lies, we will be building on top of air. Definitely not a good plan.
|
||
|
||
|
||
|
||
Data Team checking whether the data in the DWH tastes good.
|
||
|
||
To improve in this area, we have developed and deployed a new tool to test our data regularly. What does testing mean here? Well, it means that, throughout the DWH, we are setting expectations for our tables and columns and then checking if they hold true. These expectations are things like:
|
||
|
||
- The ID of bookings should be unique in the booking table.
|
||
- Records in the guest payments table should never be more than a day old, since we are loading data daily and there are payments every day.
|
||
- Our exchange rate timeseries should have values for all days between today and January 1st 2020, without any individual days missing data.
|
||
- The number of bookings created yesterday should be within 2 standard deviations of the daily average for the past month.
|
||
|
||
We then have a little piece of software that checks all of these every morning and sends a warning to the Data team if any of our expectations is not met so we can remediate.
|
||
|
||
Our test suite is still small, but we expect to grow it over time to catch more and more issues as soon as they happen. With this, we will achieve more and more quality and speed over time.
|
||
|
||
## Preparing for quarterly planning
|
||
|
||
As part of [our ways of working](https://www.notion.so/Data-Team-Organisation-81ea09a1778c4ca2ab39e7f221730cb5?pvs=21), we will soon hold our quarterly planning session with the TMT. In this session, we will review on the progress made during the previous quarter and discuss what are the top priorities and goals that we should set for the upcoming one.
|
||
|
||
We are currently in drafting and discussion phase, with already [quite a few scopes and ideas on the table](https://www.notion.so/482df2f675d24173adbeb0c619e301c4?pvs=21) that we need to refine so we can have more concise discussions and agreements with the TMT.
|
||
|
||
If you think there is something critical you need from the Data team that is not currently in our radar, this is the perfect moment to bring it up so we can properly plan it. [Get in touch with us!](https://www.notion.so/Data-Homepage-0ac0a2e52a8940c7ba4f31e5ffcc33e8?pvs=21)
|
||
|
||
## Analyst Postgres setup optimization
|
||
|
||
Everyone in the Data Team has permission to build tables in our DWH. This is the way we describe the logical steps that we follow to process data and get it pristine for everyone to read.
|
||
|
||
Because it’s important to keep the DWH clean and working at all times since we are all relying on it, we don’t build these tables directly on it (on what we call the *production* environment). Instead, each member of the Data Team has a tool to replicate a working copy of the real DWH in their laptops. This way they can create, destroy, mess up and do anything they want there without breaking things in the production DWH.
|
||
|
||
This is all nice and convenient… but laptops are not exactly Ferraris when it comes to computers. Since a few weeks ago, our team started having trouble with running things locally. Running the DWH computations took an increasing amount of CPU and RAM, and we started to literally be unable of running commands. This was affecting our productivity significantly, because developing new stuff for the DWH was becoming a pain in the ass.
|
||
|
||
|
||
|
||
Uri’s laptop while trying to run the KPIs for all of Superhog in one go.
|
||
|
||
To mitigate the situation, Pablo put his engineer hat on this week and designed some optimization settings to improve the performance of our local DWHs. And it worked like a charm! We are now back in the green, with analysts happily working without failed executions and our laptops eating them like champs.
|
||
|
||
## Migration of Cosmos DB reports to DWH
|
||
|
||
We're excited to announce that we're currently migrating all reports connected to Cosmos DB to our Data Warehouse (DWH). This transition is a significant step forward, allowing us to centralize our data and integrate it more seamlessly with other datasets. By moving to the DWH, we can now perform complex data manipulations more efficiently and enhance our reporting capabilities.
|
||
|
||
This migration not only simplifies data connections but also improves the scalability and flexibility of our reports. With the data now in the DWH, we can deliver more accurate, comprehensive insights and better connect our reports to other crucial business metrics.
|
||
|
||
We're confident that this move will greatly enhance our analytical capabilities and help us continue to provide high-quality, data-driven insights across the organization. Stay tuned for further updates as we complete the migration process.
|
||
|
||
## New Dashboard reporting is now available
|
||
|
||
This week we have finalised the ingestion and modelisation of the [minimum data for New Dash monitoring](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) to our DWH. With this data available, we have created and published a new report in PBI that currently tracks some key indicators at global and New Dash user level.
|
||
|
||
We have also incorporated an adoption funnel for users in the New Dash MVP to visually understand the main drivers or blocking points in the adoption.
|
||
|
||
|
||
|
||
This [new report](https://app.powerbi.com/groups/me/apps/7197c833-dbf9-4d2c-bca1-95f74aec4b11/reports/f0bad5b7-d9d2-45ba-a3cb-d190dd91b493/1bbfbee419e040409b95?experience=power-bi) is expected to evolve in the coming weeks and months with new information and visuals as the New Dash initiative advances into following stages.
|
||
|
||
## KPIs progress, working on Billing Country segmentation
|
||
|
||
This week we did some under-cover, hidden work on a new segmentation for the KPIs. In this case, we’re currently developing the possibility to have the KPIs per Country, and specifically per Host Billing Country.
|
||
|
||
We are currently reviewing the changes and checking if we are able to improve performance on the runs of these new models, since each dimension we’re including it’s making our runtime increase. However, these optimisations are also part of our job to keep things steady - and actually a very fun challenge!
|
||
|
||
We will keep you posted once this segmentation is available in the [Main KPIs](https://app.powerbi.com/groups/me/apps/33e55130-3a65-4fe8-86f2-11979fb2258a/reports/5ceb1ad4-5b87-470b-806d-59ea0b8f2661/cabe954bba6d285c576f?experience=power-bi) report!
|
||
|
||
# 2024-08-23
|
||
|
||
## KPIs categories: segmentation by number of listings is now live
|
||
|
||
Finally! We’ve been working in allowing KPI split per categories - well, the technical word is dimension - for quite a bit of time already. It has been proved to be a challenging task because this has impacted literally all the existing data modelisation used for the KPIs, as well as it forced us to optimise the existing code to allow for better scalability.
|
||
|
||
The result is that now we will be able to easily integrate new categories for the KPIs split. So far, we’ve only added a new category: a client segmentation, based on deal, on how many listings have been booked in the past 12 months.
|
||
|
||
We have added 5 segments, inspired from what is available in Hubspot - even though the logic used for the computation is slightly different:
|
||
|
||
- 61+: Customers that have 61 or more listings booked in the last 12 months
|
||
- 21-60: Customers that have between 21 and 60 listings booked in the last 12 months
|
||
- 06-20: Customers that have between 6 and 20 listings booked in the last 12 months
|
||
- 01-05: Customers that have or more between 1 and 5 listings booked in the last 12 months
|
||
- 0: Customers that have 0 listings booked in the last 12 months. This is a special case in which generally represents few cases of Deals that are churning, but still we want to report it since it’s part of the reality.
|
||
|
||
> A small note: not all users have a deal, specially for historic values. So keep in mind that the aggregates of most of the KPIs by this category selecting all possible segments will be strictly lower than the reality. If at some point you want to just keep an eye on the total values, best is to use the Global category which represents the previous state of the KPIs.
|
||
>
|
||
|
||
This is how the “active” customer base in 2024 (until June) looks like:
|
||
|
||
|
||
|
||
Data extracted from Main KPIs reporting, within the new tab Detail by Category.
|
||
|
||
As you can see, around ~68% of the customer base is composed of small clients that have between 1 and 5 listings booked in the last 12 months. In the other hand, the smallest group is those clients that have 61 or more listings booked in the last 12 months, accounting for ~5.8%.
|
||
|
||
Ok but… you might be wondering why is this important, anyway? Let’s show some examples!
|
||
|
||
|
||
|
||
|
||
|
||
In this case we’re showing the distribution of 2 of the main sources of Revenue:
|
||
|
||
- **Guest Revenue**, mainly an aggregation of Deposit Fees, Check-in Hero Fees and Waiver Net Fees (deducting the amount paid back to hosts)
|
||
- **Invoiced Operator Revenue**, mainly an aggregation of Booking Fees, Listing Fees and Verification Fees
|
||
|
||
> Note that APIs revenue is not displayed in this segmentation because API’s deals do not have listings associated.
|
||
>
|
||
|
||
The insights are quite straight forward: ****
|
||
|
||
- **the big accounts** (+61, orange) **that represent ~5.8% of the customer base bring more than 50% of the Guest and Invoiced Operator Revenue**.
|
||
- On the other hand, **the small clients** (1-5, pink) **that represent ~68% of the customer base bring around ~18% of the Guest Revenue and ~13% of the Invoiced Operator Revenue.**
|
||
|
||
Interested on knowing more? You can use the new segmentation and the new tab Detail by Category to deep-dive in any existing metric!
|
||
|
||
In the following days we will focus on fixing the monetary amounts discrepancies - the famous tax inclusive/exclusive subject, while at the same time we will continue to integrate a new KPI segmentation: by Country. Stay tuned for more KPIs!
|
||
|
||
## New Dash MVP monitoring: starting to ingest the data into DWH
|
||
|
||
This week we’ve also started to ingest the new tables related to the MVP, and more generally, to the New Dash into the DWH. There’s still a bit of work to do since the schema is new and we want to make sure we model it in a proper way to have consistency with the already existing data modeling for the current setup. Also, we’re trying to be smart and anticipate the following user migrations that will come from old dash to new dash in the following stages, so we can minimize future work.
|
||
|
||
In the meantime, we’re still providing 3 times a week the ad-hoc extraction in order to [track New Dash MVP](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) performance.
|
||
|
||
## New features in Check-in Hero report
|
||
|
||
We're excited to announce the inclusion of a new feature in the Check-in Hero report—Address Validation. This enhancement allows us to track which Check-in Cover purchases have been rejected or failed, providing valuable insights into potential issues with specific hosts or accommodations.
|
||
|
||
With the Address Validation feature, we can now identify patterns or trends in rejections, helping us understand the root causes behind these failures. This could reveal whether certain hosts or accommodations are frequently encountering issues that might be addressable through targeted support or adjustments.
|
||
|
||
By leveraging this new capability, our team can work more effectively to ensure a smoother experience for our users, ultimately reducing the number of rejected Check-in Cover purchases and enhancing overall customer satisfaction.
|
||
|
||
## Data Team Expands Capabilities, Unlocking Deeper Insights
|
||
|
||
The Data Team has been hard at work, responding to an increasing number of data requests from other departments. This collaborative effort has not only helped meet the growing needs of our colleagues but has also uncovered new layers of valuable data that are transforming our understanding of key processes.
|
||
|
||
One of the major breakthroughs is our ability to access more detailed information about guest journeys. This enhanced data visibility allows us to analyse which purchase options are available to our customers and assess their impact on user behaviour. Additionally, we've gained the ability to track whether guests are seeing logos from hosts during their verification process and compare how these visual cues may influence the speed and completion rates of their verifications.
|
||
|
||
It is important to note that our current data certainty is limited to the present. However, the development team is actively working on providing access to historical data, which will allow us to analyse trends over time and further enhance our understanding.
|
||
|
||
## Xero Invoicing and Crediting report is now fully live
|
||
|
||
A long while ago, we started developing and Invoicing and Crediting report in PBI. This report is driven by the details of invoices and credit notes in our accounting system, and can satisfy a lots of needs around sales:
|
||
|
||
- Finding out how much we’ve invoiced a customer…
|
||
- which of his payments are pending…
|
||
- or how much we’ve paid out in Damage Waivers back to hosts on some month
|
||
- The report allows both visualizing individual deal and global amounts, as well as high level totals or transaction level detail
|
||
|
||
The report was ready for some time but was awaiting data quality checks from the Finance and Data teams. We’ve finally managed to conclude them and the report is now ready to use!
|
||
|
||
If you feel you could use some data from this report, or think should have access to this report, please get in touch with Jamie Deeson in Finance.
|
||
|
||
## Successful DWH integration of our first Cosmos DB container!
|
||
|
||
Great news! After months of research, spinning around and hard work, we’ve finally integrated our first Cosmos DB container into the DWH!
|
||
|
||
|
||
|
||
Pablo when he saw the first records flowing to the DWH.
|
||
|
||
[Our tests](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) with `anaxi` have been successful and we have connect the e-deposit verifications database to the DWH. This allows us to access the e-deposit data within the DWH, and leverage it along all the other data from our systems.
|
||
|
||
We also took the chance to meet with Ray and Manu, who are the leads of the tech squads using Cosmos DB, to align and discuss how we will work together from now on. You can read more about this in our documentation:
|
||
|
||
- General docs on the integration: [Cosmos DB Integration](https://www.notion.so/Cosmos-DB-Integration-2f780b754cd948f38051dfb30d3a5beb?pvs=21)
|
||
- Teams alignment: [Dependency management](https://www.notion.so/Dependency-management-7341e3d98f69424090bd9a2f3b227472?pvs=21)
|
||
- Inventory of live integrations: [https://www.notion.so/knowyourguest-superhog/Integration-Inventory-6fc3900234f44f67a2ceb7274589d700?pvs=4](https://www.notion.so/Integration-Inventory-6fc3900234f44f67a2ceb7274589d700?pvs=21)
|
||
|
||
Even though the effects have yet to be felt, this milestone unlocks a world of joy! We can now develop all sorts of reporting, automation and insights around e-deposit data. We will soon be migrating our old reports that read directly from Cosmos DB into the DWH, and also assist with building new stuff like further automation for invoicing e-deposit customers.
|
||
|
||
# 2024-08-16
|
||
|
||
## `anaxi` is ready for testing
|
||
|
||
This week we managed to release the first version of `anaxi`, the tool we have developed to sync data between our Cosmos databases and our DWH. This is a great step towards leveraging this data for all sorts of purposes: developing new business KPIs around API services, automating invoicing of services like e-deposit, or setting up monitoring reports to track the performance of our services.
|
||
|
||
We will soon begin tests with some our databases to polish the rough edges of the tool, and also soon align with our colleagues in the tech team since keeping this integration up and running in a smooth way will be a team effort.
|
||
|
||
## Guest taxes logic documented, ready to implement in DWH
|
||
|
||
This week we worked together with the Finance team to build some documentation around how should taxes be computed in the area of Guest services, such as damage waivers or CheckIn Hero covers. You can read it here: [Guest Services Taxes - How to calculate](https://www.notion.so/Guest-Services-Taxes-How-to-calculate-a5ab4c049d61427fafab669dbbffb3a2?pvs=21)
|
||
|
||
This was relevant because [a few weeks ago](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) we realized that revenue metrics were being reported differently across some data and finance reports. We spotted taxes being the issue, and aligned with the Finance team that we would reproduce tax computations in the DWH to be able to report both tax-inclusive and tax-exclusive amounts in our reports. Documenting the tax logic was a first step to start work on this.
|
||
|
||
Next, we will allocate some capacity to apply this logic in our data processing in the DWH. Once that happens, we will be able to show the right amounts in our reports.
|
||
|
||
## Cosmos DB connection problem on Screening API fixed
|
||
|
||
We successfully resolved an issue we were facing with extracting data from Cosmos DB and establishing a connection between Cosmos and the Power BI app. Working closely with the development team, we overcame the problem and plan to maintain closer communication to prevent similar issues in the future. The Screening API Report in Power BI is now up and running, currently featuring mock data, and is ready for the new tool to start functioning.
|
||
|
||
|
||
|
||
## Check-In Hero address validation
|
||
|
||
With the rapid growth of Check-in Hero, we are continuously monitoring our services to ensure everything functions correctly and to identify new opportunities to enhance the guest experience. We now have the capability to detect any instances where attempts to add this cover have been rejected by the system. By analysing these patterns, we aim to resolve these issues and offer this additional security to as many guests as possible.
|
||
|
||
We are currently integrating this data into our Check-in Hero reports in Power BI, making it easily accessible to all interested in it.
|
||
|
||
## Payment options in Guest Journey
|
||
|
||
In recent weeks, we've received requests for information about the available payment options provided to our guests during their verification requests. Unfortunately, we've found this process to be complex, with unreliable data for historical records. At present, we cannot reliably determine which services and at what price they were offered to guests in the past; we can only extract data on what is currently being offered.
|
||
|
||
The development team is actively working on fixing this bug, but we don't yet have an estimated date for resolution. Even after the fix, it may not be possible to recover historical data.
|
||
|
||
While we hope this issue is resolved as soon as possible, we can at least now extract data on the services presently being offered to customers in their Guest Journeys.
|
||
|
||
You can find more details in our notion documentation:
|
||
|
||
[Payment Validation Set data problems](https://www.notion.so/Payment-Validation-Set-data-problems-2382b2ecb24243449caac4687f044391?pvs=21)
|
||
|
||
# 2024-08-09
|
||
|
||
## Currency rates historical loading is finished
|
||
|
||
Finally!
|
||
|
||
[After two long months](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) and many thousands of API calls to xe.com, we finally have stored in our DWH the exchange rate history for all the currency pairs we work with since January 1st 2020 to today.
|
||
|
||
This took a bit longer than we would like to because we have a monthly limit in how many times we can request rates from xe.com, so we had to spread the load across time to avoid hitting our monthly caps.
|
||
|
||
From now on, we will simply keep on getting new rates on a daily basis.
|
||
|
||
## Cosmos DB integration research shows first results, starting development work
|
||
|
||
This week we continued [our work around finding a good system design to bring data from our Cosmos DB databases into our DWH](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md).
|
||
|
||
After running some tests on Azure and diving deep into Cosmos DB capabilities and connectors, we finally have a draft design that we are ready to implement and test. The plan is to develop in-house a small Python tool to perform the syncs between any of our Cosmos DB and the DWH. Our assessment indicates that this solution and would do a great job at covering our needs.
|
||
|
||
We are planning to run a Proof-of-Concept: we will implement a first version of the tool ASAP and then try to hook one of our Cosmos DB containers into our DWH in production. If everything o
|
||
|
||
As a reminder you can keep track of this project through this page: [CosmosDB <> DWH Integration Project](https://www.notion.so/CosmosDB-DWH-Integration-Project-e87c41a93d9f484c842261eb55517470?pvs=21) . If you are technically inclined, you can also checkout the tool repository here: [https://guardhog.visualstudio.com/Data/_git/data-anaxi](https://guardhog.visualstudio.com/Data/_git/data-anaxi)
|
||
|
||
## KPIs progress
|
||
|
||
As usual, this week we have been working on KPIs. Besides the [exploration of MetricFlow](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), we’ve also been working on several open fronts:
|
||
|
||
- Firstly, we’re doing advances on providing **KPIs split by different dimensions**. First things first, we needed to tackle some improvements on performance to accommodate for these new dimensions. At this stage we’ve validated the approach we’re going to take and we have started building KPIs by customer type, segmented based on the number of active listings. It will still take a while until we can have this split available in the report though, but the initiative it’s advancing.
|
||
- Additionally, we’ve also took some time to ensure there’s a minimum **technical documentation** on the KPIs as is today, containing meaningful information on the data workflow, how to add new metrics or even the Power BI report itself. This documentation is available here:
|
||
|
||
[(Legacy) Technical Documentation - 2024-08-05](https://www.notion.so/Legacy-Technical-Documentation-2024-08-05-aa7e1cf16b6e410b86ee0787a195be48?pvs=21)
|
||
|
||
- We’ve also deployed a visual change in the conditional formatting for metrics where 'more' indicates 'worse,' which we previously didn't account for. Additionally, we’ve formatted the values to make the amounts and units easier to understand. For example, with Churn, an increase in volume is now reported in red, and metrics like payments now display the currency symbol along with thousands separators for better readability of large numbers.
|
||
|
||
|
||
|
||
- Lastly, we also had a discussion with Finance team to aim to understand and solve the **discrepancies on the figures reported between Data and Finance**, mostly linked to the [tax inclusion/exclusion in Guest payments](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md). With some new insights on the table we can now re-take the subject with the goal to fix it in the following days.
|
||
|
||
## New Dash barebones tracking
|
||
|
||
This week we also started monitoring a very minimal set of indicators of how the New Dash MVP is performing after the launch since July 30th.
|
||
|
||
At this stage this tracking is quite ad-hoc, directly plugged into the Superhog backend in order to rush it and have some early data available.
|
||
|
||
Here’s the main indicators we’re tracking so far, screenshot of Friday 9th of August:
|
||
|
||
|
||
|
||
In future days we will start integrating the new tables linked to the New Dash MVP so we can work on creating a Power BI report.
|
||
|
||
## MetricFlow research finishing
|
||
|
||
Last week we explained that [we started investigating a new package called MetricFlow](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) that could help on the scalability of the KPIs, especially on adding new dimensions such as customer segments, countries, etc.
|
||
|
||
This week we assessed the 2 remaining points to take a decision on whether we will move forward or not with this package, namely 1) materialising the data and 2) configuring multiple metrics with segmentations that depend on different entities.
|
||
|
||
On the second point, it seems indeed it’s possible and it’s quite impressive how easy it is to do so *(well, once you have set up everything properly, which it’s not straight-forward)*. However, we didn’t find the way to materialise the MetricFlow queries into tables, so this looks like a blocking point.
|
||
|
||
In summary, **we decided NOT to use MetricFlow because it’s in too early stages and would not fit our immediate needs**. However, once this product gains maturity, we don’t discard that it could be potentially a nice tool to configure business KPIs.
|
||
|
||
If you are interested in knowing more about MetricFlow, you’ll find additional details of the research in this dedicated Notion page: [Exploration - MetricFlow - 2024-08-06](https://www.notion.so/Exploration-MetricFlow-2024-08-06-f45d91500ad7433d9ff4e094b8a5f40b?pvs=21)
|
||
|
||
# 2024-08-02
|
||
|
||
## Minimum Listing Fee is now being applied in Invoicing
|
||
|
||
This month, we’ve extended our invoicing tools to apply a contractual term that many of our customers had agreed into but we had never applied so far: the Minimum Monthly Listing Fee. The agreement specifies that Superhog will charge a minimum amount each month as a Listing Fees, even if the set per-listing fee times the number of active accommodations falls below that.
|
||
|
||
We’ve modified our code to apply this logic and the Finance team is already working this month with data that takes this contractual term into account.
|
||
|
||
## Cosmos DB integration research continues
|
||
|
||
After having to park this topic for some time due to other priorities, this week we’ve resumed our investigation on how can we sync the data in our multiple Cosmos DB containers to our DWH. As a reminder, you can read our documentation on this topic in this page: [CosmosDB <> DWH Integration Project](https://www.notion.so/CosmosDB-DWH-Integration-Project-e87c41a93d9f484c842261eb55517470?pvs=21)
|
||
|
||
We’ve found a promising architectural pattern that could satisfy our needs. We will soon design a plan to test it out and confirm it’s validity, step after which we will craft a final design and discuss with the engineering team to have everyone aligned.
|
||
|
||
## Revenue details now available in the Business KPIs
|
||
|
||
This week we have released new revenue metrics that are more granular than what was already available. In essence, now we’re able to track for both the Global and Deal-based view of KPIs, the following metrics:
|
||
|
||
- For Invoiced Operator Revenue:
|
||
- 🆕 Invoiced Booking Fees
|
||
- 🆕 Invoiced Listing Fees
|
||
- 🆕 Invoiced Verification Fees
|
||
- For Invoiced APIs Revenue:
|
||
- 🆕 Invoiced Guesty Fees
|
||
- 🆕 Invoiced E-Deposit Fees
|
||
- For Guest Revenue:
|
||
- 🆕 Waiver Net Fees
|
||
- 🆕 Waiver Amount Paid by Guests
|
||
- 🆕 Waiver Amount Paid back to Hosts
|
||
- 🆕 Deposit Fees
|
||
- 🆕 Check-In Hero Amount Paid by Guests
|
||
|
||
Keep in mind that the Invoiced figures as well as the Waiver Amount Paid back to Hosts has the Invoicing delay, thus is not available in the current nor the previous month. Now that we’re in August, the data for June is fully available.
|
||
|
||
**Last but not least:** we still have the discrepancy on revenue figures from Xero (Invoiced) and Backend (Guest related payments), so keep in mind that the revenue figures are not displaying correct data. You can learn more on this subject in the [previous entry of the Data News](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md).
|
||
|
||
## MetricFlow exploration
|
||
|
||
This week we started to explore the possibility to create a semantic layer within DWH by using MetricFlow package.
|
||
|
||
In essence, a semantic layer is a data aggregation layer ready for reporting metrics at different granularities, which could be very useful for the scalability of the Business KPIs initiative - but also for enhanced reporting and other initiatives in the future.
|
||
|
||
We started exploring this MetricFlow possibility now that we’re interested on creating Customer Segmentations and Geography slices, which theoretically could benefit from this approach. At this stage we managed to solve version dependencies and configurate a very simple Bookings model with different aggregations - and we managed to retrieve the information by querying within MetricFlow! Here’s an example:
|
||
|
||
|
||
|
||
In this example we’re using the metric total bookings. We can retrieve this without specifying any other command thus it returns the total amount of bookings we have available. We can also group it by booking state and mainly then it slices total bookings by the booking state. There’s much more advanced features (so far this is a very SQL query anyway…) but still under investigation 😄
|
||
|
||
There’s 2 key aspects that we need to assess still, which are:
|
||
|
||
- Is it possible to materialise these MetricFlow queries into tables that could be used afterwards for our Power BI reporting?
|
||
- Are we able to configure multiple models with segmentations that depend on different entities, and more importantly, does it return accurate data?
|
||
|
||
Likely we’ll continue the investigation by next week.
|
||
|
||
## Updating Business Overview reports
|
||
|
||
We are currently updating several Power BI reports in our Business Overview app, leveraging more accurate data to ensure the information we present is as reliable as possible. For the Host Fees report, we can now use real exchange rate data for the various currencies used by our users. Previously, without access to the currency details for each transaction, we made a crude aggregation of all booking fees. With the availability of each currency and their daily exchange rates, we can now provide a more precise total of the booking fees in GBP, so expect to see this number go down when updated.
|
||
|
||
Parallel to Host Fees, we are also updating the E-deposit and Guest Payments reports in collaboration with the Finance team to better align with the numbers reported by each team. As mentioned last week, we are investigating the discrepancies between our teams, which are very likely tax-related.
|
||
|
||
|
||
|
||
We are aiming to solve these discrepancies as soon as possible so we can ensure consistency and accuracy in our reporting.
|
||
|
||
# 2024-07-29
|
||
|
||
## Revenue figures discrepancy investigation
|
||
|
||
This past week we aimed to investigate in greater detail the differences on the revenue figures between what we report as Data team in the Business Overview vs. Finance reporting.
|
||
|
||
Seeing that guest-related revenues coming from guest payments were overestimated on Data side with respect to Finance side, we reached to the hypothesis that probably guest payments were tax inclusive in the backend, while the rest of invoiced revenues to hosts we’re certain that these are tax exclusive. After a quick discussion with Ben R, it seems this hypothesis is correct.
|
||
|
||
As of today, this issue still persists and we need to tackle it in the following days with the help of Finance. In the meantime, keep in mind there’s some reporting areas that are showing incorrect insights, specifically:
|
||
|
||
- **Business Overview - Guest Payments report**
|
||
- Waivers: total waiver amount charged (tax incl.) vs. amount paid back to hosts (tax. excl). The % Paid to Host is also impacted
|
||
- **Business Overview - Main KPIs**
|
||
- Total Revenue and derived metrics combine both data from SH (Guest Revenue, coming from guest payments) and Xero (Invoiced Operator Revenue, Invoiced APIs Revenue). Also, keep in mind that by nature the different Revenue sources can be inconsistent between them.
|
||
|
||
For a more detailed investigation, we invite you to take a look at this Notion page:
|
||
|
||
[Data quality assessment: DWH vs. Finance revenue figures](https://www.notion.so/Data-quality-assessment-DWH-vs-Finance-revenue-figures-6e3d6b75cdd4463687de899da8aab6fb?pvs=21)
|
||
|
||
|
||
|
||
## Business KPIs alignment - 3rd session
|
||
|
||
In the [previous edition of the Data News](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) we explained the new deliveries that have been made available within the KPIs initiative for the second batch.
|
||
|
||
This past week we had a sync session with the TMT to discuss further deliverables for the coming weeks. At this stage, the amount of available metrics has grown by quite a bit (a total of 37) so should be quite good for a first rough understanding of the business situation. Therefore, for this next delivery we’re not aiming to include tons of new metrics except for the more fine-grained revenue metrics that should help us on the revenue discrepancy investigation. Rather, we’re going to start to provide KPIs categorisations or segmentations.
|
||
|
||
There’s tons of ways we can categorise the data: geography, currencies, sources of bookings/verifications, types of hosts, etc. To start with, we’re going for 2 main groups:
|
||
|
||
- **KPIs by Geography**: most likely, we will do this by country. And actually it’s not fully clear when we say country, which country we are referring to… because a host can be based on UK, but have a listing in the US that is being booked by a guest from Spain. Ignoring the fact of the guest for now, we’ve noticed we don’t know that much up to which extent this host-is-based-in-X-but-has-listing-in-Y is actually happening, and since we’re data-driven, we conducted a [small analysis](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) 😊
|
||
- **KPIs by Customer segmentation**: likely, this is going to be a kind of segmentation based on the amount of listings that a Client has active with us in Superhog. There’s already some segmentations created on this area, and we’re currently trying to understand how they are built and the motivation behind them to see if it makes sense to replicate those or aim to improve it. More on this, we hope, for the next Data News.
|
||
|
||
Besides this, we will deliver a few more minor details to help the visualisation and usage of the reporting, starting with a few modifications in the graphic display of metrics that was deployed last Friday:
|
||
|
||
|
||
|
||
Now we have the possibility to display a single metric split by Year, or if clicking the “Metrics” button…
|
||
|
||
|
||
|
||
… we will return to the full timeline, in which we can select one or multiple metrics. Clicking in the “Years” button will move back to the previous screenshot. Impressive dashboard user experience thanks to our expert Joaquín!
|
||
|
||
All the information of the KPIs session as usual is available here:
|
||
|
||
[Business KPIs Definition (III) - TMT session 24th July 2024 ](https://www.notion.so/Business-KPIs-Definition-III-TMT-session-24th-July-2024-1bd5435844ac432f9161b1ccf4c4d062?pvs=21)
|
||
|
||
## Host Billing Country vs. Listing Country
|
||
|
||
Have you ever wondered the percentage of how many active listings are located in the US from hosts that are located in the UK, over the total active listings?
|
||
|
||
Well, the answer is 2.36% of all active listings.
|
||
|
||
|
||
|
||
Funny enough, I expected US and UK to lead somehow the ranking when I first thought about this example, and I was not that wrong. That’s why I initially believed that the most representative example of cross-country was going to be host in UK and Listings in US. But actually it’s not! It’s host in the UK with listings in Ireland, representing 2.61% of all active listings 🇮🇪. Nice auto-self-reminder of why we need to trust data, and not intuition 😇
|
||
|
||
As [mentioned earlier](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), we have conducted a quick analysis to understand these situations in which a host might be based on a given country but have listings in other countries. We call the first Billing Country and the second Listing Country. Here’s the main insights of this analysis:
|
||
|
||
- 13.2% of the active listings are located in a different country that does not correspond to the host billing country.
|
||
- 11.5% of all hosts with active listings have at least one listing located in a different country.
|
||
- Finally, ~50% of the total active listings come from a 6.5% of hosts that operate in more than one abroad country. These hosts have ~26% of their listings abroad.
|
||
|
||
There’s a few more insights and potential to deep-dive, so if you’re interested, we’re sharing the file here.
|
||
|
||
- **Analysis here!**
|
||
|
||
[Analysis_billing_vs_listing_country.xlsx](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a/Analysis_billing_vs_listing_country.xlsx)
|
||
|
||
|
||
Let us know what do you think in the Slack thread!
|
||
|
||
## Screening API report ready for deployment
|
||
|
||
We have a new report ready to go for the new Screening API which will start working in August.
|
||
This report will show information on verifications through the new Screening API, the types of verifications requested and if there was any problem which each of these. Right now we only have some mock data to work with on the report, but as soon as we have real data we will deploy this new report and give access to everybody that is interested in the data.
|
||
|
||
|
||
|
||
I wonder what this *fakeuser@email.com* whose name is *Not Clay* is…?
|
||
|
||
|
||
|
||
## New addition to the Check-in Hero reports
|
||
|
||
This week we added some new data to one of the reports inside the Check-in Hero app. Inside the Host Data report there is a new tab with Hosts listings with Check-in cover active, here you will find information for each of these listings, like country or town, and how many covers have been purchased for each of these listings. It contains very similar data to the previous Host Details tab but to a more granular level.
|
||
|
||
|
||
|
||
Wait to hear more from us as we are still working on more updates and new reports to help facilitate access to the data that we know will help our business keep growing.
|
||
|
||
# 2024-07-22
|
||
|
||
## Currency rates incident
|
||
|
||
This past week we faced an incident on the currency rates retrieved from Xe.com. Specifically, on Thursday 18th our automated daily process failed and we needed to deep-dive into it to understand what was going on. Fortunately, with the help of the tech team we managed to identify and fix the issue the same day, thus the incident was contained within a relatively constraint timeline.
|
||
|
||
You can check all the details of the incident [here](https://www.notion.so/20240718-01-Xe-com-data-not-retrieved-5c283e9aa4834323b38af0bff95477a5?pvs=21).
|
||
|
||
## Improvements on Guest Satisfaction Report
|
||
|
||
We are focused on enhancing the quality of our reports to facilitate easier understanding and better data exploration. A key part of this initiative involves adding data about the types of hosts from which verification requests originate. This improvement is aimed at providing more insightful analysis and reporting capabilities.
|
||
|
||
**Host Types Included**:
|
||
|
||
- **PMS (Property Management System)**
|
||
- **OSL (Online Service Listing)**
|
||
- **API/MANUAL**: Currently, we do not have the data to separate API and Manual requests, so they are grouped together.
|
||
|
||
This data has already been integrated into the **Guest Satisfaction** report so users can easily filter by each of these host types.
|
||
|
||
|
||
|
||
## Second batch of Business KPIs ready
|
||
|
||
This week we put quite a bit of effort towards aiming to finish the second batch of KPIs deliveries.
|
||
|
||
Now we’re able to see revenue metrics, from Host side (operator), APIs (Guesty + E-deposit) and the already existing Guest Revenue. With these we’re able to compute a Total Revenue figure and different weighted measures. These figures should be consistent with what is already reported in the Business Overview on Guest Payments, Host Fees and e-deposit reports. However, at this stage we do not retrieve the revenue splits (Listing fees, Verification fees & Booking fees for Hosts, etc), though these are already available in the reports mentioned before.
|
||
|
||
For more details remember that you have much more information in the Data Glossary of the same report, which we encourage to read 😊
|
||
|
||
|
||
|
||
I know what you are thinking… the amount of metrics has grown by quite a bit so now we have a scroll bar in this section 😇
|
||
|
||
Keep in mind that since all these metrics have somehow a dependency with Xero, these are not available in the current month nor the previous one. So for example, today in mid July we’re able to see the final figures of May, and beginning of August those figures from June. Additionally, we’ve added figures regarding Host Resolutions, and again, these should be consistent with the [Accounting Reports](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md).
|
||
|
||
For the remaining metric, namely Billable Bookings, at the moment it’s not available. The main reason is that it’s technically feasible to retrieve figures in the same essence as we do for the invoicing, but there’s some considerations behind the logic that should be discussed with Pablo once he’s back from holidays, as he is the owner of the invoicing exporter tool at the moment. The very technical details on this subject can be found [here](https://www.notion.so/Data-quality-assessment-Billable-Bookings-97008b7f1cbb4beb98295a22528acd03?pvs=21). Once this is settled, it should be feasible to move forward with Billable Bookings!
|
||
|
||
|
||
|
||
Lastly, we’ve included a quick-win asked by Suzannah. Now it’s possible to plot all metrics to visually observe trends and evolutions over time. It’s only available for the global view. Hopefully this will facilitate interpretation and reduce a bit of manual work!
|
||
|
||
# 2024-07-15
|
||
|
||
## Guest Satisfaction Report is now live
|
||
|
||
As previously announced, we have completed the Guest Satisfaction report. This report includes ratings given by guests who completed a satisfaction survey after their guest journey. This data is crucial for us to assess our progress in enhancing user experience and identifying areas for improvement.
|
||
|
||
We are still working on adding new features to this report, but it is already available for browsing. If you need access, please let us know.
|
||
|
||
|
||
|
||
## Business KPIs per Deal is now live
|
||
|
||
This week we have been working on implementing a good chunk of the expected second batch of deliveries for business KPIs.
|
||
|
||
One key aspect that we wanted to enable is having the possibility to visualise all these metrics for each Deal Id. With this new delivery we have two new tabs in the report that allows for tracking the metric evolution for a single deal, as well as being able to compare the metrics of two or more deals in the same month. The screenshots will probably be more self explanatory:
|
||
|
||
|
||
|
||
Detail for the Deal 000…000 over time. We can see in a monthly basis the evolution of metrics for this single deal. This one looks like a test account, so most of the metrics do not report actual values.
|
||
|
||
|
||
|
||
Comparison of metrics for multiple deals at end of January 2024. It seems we have a Deal that is going to churn!
|
||
|
||
This new delivery also includes new metrics related mostly to Guest Payments/Revenue, as well as some minor changes in the report.
|
||
|
||
The development is still ongoing for other metrics, such as host revenue (that we will call operator revenue) and host resolution payments metrics. Stay tuned to read more about it!
|
||
|
||
## Great effort towards handling ad-hoc requests
|
||
|
||
It’s been a bit more than a month since we started with the new [way of handling ad-hoc data requests](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) through the #data channel. And a lot of people is using it, so thanks to everyone for following the procedure!
|
||
|
||
However, the amount of tickets that have been created over these past weeks have increased at a faster pace than what we are able to accommodate - even though some of them we’ve resolved, we needed to focus on other priorities as you can read in the history of the Data News. The stockpile of tickets was growing quite a bit lately…
|
||
|
||
So we decided to put a bit more effort on these ad-hoc requests this week, specially with the massive help of Joaquín. Specifically, we worked on:
|
||
|
||
- K Suites analysis on cancellations ratios,
|
||
- Deposit/Waiver price analysis for Dashboard V2,
|
||
- Pricing tier analysis for Checkin Hero fake door A/B test,
|
||
- List of incomplete verifications for a client asking for it,
|
||
- Extraction of Verification Payments configurations,
|
||
- … and we’re still working on the booking/verification source split
|
||
|
||
|
||
|
||
There are still some tickets on our backlog - we have not forgotten them. But hopefully, this has reduced by quite a bit!
|
||
|
||
# 2024-07-08
|
||
|
||
## First set of business KPIs delivered, moving to the second batch
|
||
|
||
This week we validated with the TMT the delivery of the first batch of business KPIs, which mostly consists of very high-level metrics and the capability of visualize both the historical figures and the ongoing ones via a month-to-date computation.
|
||
|
||
The work on this subject however is far from over: our effort resides now on computing and reporting the second batch of KPIs. This batch mostly contains high-level revenue metrics, as well as related weighted measures. We also take the opportunity to include a few more metrics to support the general comprehension of the business that we started on the previous batch. Additionally, thanks to the creation of the [Host Resolution payments report](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) of last week, we will be able to include the first metrics on resolutions as well.
|
||
|
||
Lastly, this week we started setting the foundation to allow the possibility to have all these metrics for each deal, in essence, what we call the “by deal” view, to complement the global view. It’s still work in progress and we’re currently discussing internally on what is the best way to have this modelling in the DWH with our Lead Data Engineer @Pablo Martin before he leaves on holidays!
|
||
|
||
|
||
|
||
For more details about the second batch of KPIs, you can check the following Notion page:
|
||
|
||
[Business KPIs Definition (II) - TMT session 3rd July 2024 ](https://www.notion.so/Business-KPIs-Definition-II-TMT-session-3rd-July-2024-36696d11d29a442d9b85a925dfc071b2?pvs=21)
|
||
|
||
## Check-in Hero report updates
|
||
|
||
This week we bring new updates for the Check-in Hero report with some additions to the existing ones in the dashboard and a new report inside the Dashboard.
|
||
|
||
For the new addition we have the Host Rates tab inside Overview, in here you can see the rates of hosts that have Check-in Hero available in their listings, the evolution of this rate across time and how many of them have guests that have purchased the cover. This will be a very useful view especially when we have more history with Check-in Hero to see how it has been evolving and how attractive it is for our guests or if it might be more focused on some specific hosts for some reason.
|
||
|
||
The new report in the app is called **Hosts Details**, in this ****report you can find detailed information on the hosts that have Check-in Hero available, the amount of guest journeys they have and how many Check-in hero have been purchased by their guests. Related to the previous included tab but with more detailed data on each individual host and how much income each of them have generated through Check-in Hero.
|
||
|
||
[Link to the report](https://app.powerbi.com/groups/me/apps/14859ed7-b135-431e-b0a6-229961c10c68/reports/b88e01e0-d2ad-4911-9cec-cb9fbd8ae840/d39d985ecac6a5971aad?ctid=862842df-2998-4826-bea9-b726bc01d3a7&experience=power-bi)
|
||
|
||
## CSAT Survey report WIP
|
||
|
||
We have some data from some guests that get shown a satisfactory survey. We are in the process of building a new PBI report that was previously being delivered in a small excel presentation. In this report you will be able to see ratings and comments given to us from our guests users, which services did they pay for and how are these scores distributed across time or age.
|
||
|
||
|
||
|
||
Expect to hear more about this report in the upcoming week
|
||
|
||
## Xero Resolutions report is fully ready
|
||
|
||
Just a quick heads-up: after some [very useful troubleshooting with Jamie during the past week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), our new resolutions host payment report is ready for everyone’s eyes. As a reminder, this reports tracks our accounting books to give you Data on all the payments we make to hosts as part of approved claims, both in aggregates and in detail. And also, by Deal Id!
|
||
|
||
|
||
|
||
If you would like to have access to this report, feel free to get in touch.
|
||
|
||
## Currency rates ingestion progressing, almost there
|
||
|
||
After our [updates from last week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), this week we’ve been simply loading more and more rates from the history. Currently, we have all rates for all currencies for all 2024 YTD, all of 2023 and all of 2022, which should cover most of the reporting and finance needs we have nowadays.
|
||
|
||
We are still working on 2021 and 2020. Once we have the rates all the way to January 1st 2020, we will call this line of work done!
|
||
|
||
## Pablo protects his frail heart from scare-induced heart attacks
|
||
|
||
Recently, we experienced multiple technical issues ([such as this one](https://www.notion.so/20240619-01-CheckIn-Cover-multi-price-problem-fabd174c34324292963ea52bb921203f?pvs=21)) related to the integration between our [Core database](https://www.notion.so/Superhog-Core-Database-70786af3075e46d4a4e3ce303eb9ef00?pvs=21) and [the DWH](https://www.notion.so/DWH-78ce5f76598d49d185fa5fc49a818dc4?pvs=21). These issues are relevant because they tend to mess up the reporting in different ways. Sometimes it’s just data moving a bit slowlier than usual, sometimes its numbers becoming completely bogus. The worse times is when numbers are wrong, but in sneaky ways that might trick the reader into believing they are true. These are the worse situations that mess with Pablo.
|
||
|
||
The root causes of some of these are related to ways of working with the data and tables in Core itself, so we decided to make a small document to remind everyone who works on our beloved SQL Server database on how the Data Team depends on it and certain actions can wreak havoc.
|
||
|
||
You can find the document here: [Careful with the DB: How to work in SQL Server without giving Pablo a stroke](https://www.notion.so/Careful-with-the-DB-How-to-work-in-SQL-Server-without-giving-Pablo-a-stroke-405c497b76c74bb29dcc790bc59928fd?pvs=21)
|
||
|
||
Hopefully we can learn from these to reduce our rate of incidents in the future and protect poor Pablo’s frail heart ✌️.
|
||
|
||
# 2024-06-28
|
||
|
||
## New Currency Exchange report
|
||
|
||
Now that we finally have currency data from xe.com, we created a new report in Power BI so that everyone has easy access to this data. Here you can find exchange rate data for any specific date and pair of currencies (currently we have the top 8 most used currencies from our user).
|
||
|
||
Some points to consider, we are still working on filling all the historical data of these currencies. Right now we have from 1st of December 2023 to date, but we will keep on filling until we get to 1st of January 2020. Also we have some very basic forecasting and back filling of the rates using the most recent and latest data from [xe.com](http://xe.com) and pushing it.
|
||
|
||
If you need access to the report please let us know and as always feel free to reach the data team for any questions or concerns regarding the report.
|
||
Link: [Currency Exchange](https://app.powerbi.com/groups/me/apps/10c41ce2-3ca8-4499-a42c-8321a3dce94b/reports/fcfd0a77-6c2a-4379-89be-aa0b090265d7/64ddecd28ca50dc3f029?ctid=862842df-2998-4826-bea9-b726bc01d3a7&experience=power-bi)
|
||
|
||
|
||
|
||
## Upgrades in [xe.com](http://xe.com) rates ingestion
|
||
|
||
This week we’ve had a couple of new things going on with our [xe.com](http://xe.com) integration.
|
||
|
||
First, as [we discussed the last week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), we’ve upgraded our subscription so that we have 30,000 API calls instead of 10,000. This will help us fill our historical tables at a much faster rate, and also make the integration just more easy to work with in the future.
|
||
|
||
We also had a working session with the Finance team were they rightfully pointed out that we needed more decimal precision in the exchange rates. We were stupidly losing precision as we fetch the rates
|
||
|
||
We have made a new release of `xexe` that now has the right decimal precision, so rates will start coming in with the required decimal positions from now on.
|
||
|
||
## Xero Resolutions payments report fresh out of the oven
|
||
|
||
We finally got one of our new Xero reports ready after [the past few weeks of work](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md): the resolutions - host payments report!
|
||
|
||
This report uses our accounting records to track all payments made to hosts as part of approved resolution processes. Even though it doesn’t provide details on the actual incident, at least we can report on how many payments happened, the $$$ amount and which host the payment is related to.
|
||
|
||
We are still validating the data together with Jamie before opening up access. If you would be interested in the data in this report, do get in touch so we can provide you with access.
|
||
|
||
## Data Team are a bunch of sloths
|
||
|
||
As proven by the fact that summer is coming and we will take some days off 😎
|
||
|
||
We just wanted to give you a heads-up so you are aware of when we will be off. We are already planning our capacity taking these into account, but it might be good for you to know in case you need something from a specific team member:
|
||
|
||
- Pablo: OOF from 10/07 to 25/07.
|
||
- Uri: OOF from 12/08 to 16/08
|
||
- Joaquín: will be around our July and August.
|
||
|
||
## KPIs reporting available in Business Overview
|
||
|
||
This last Wednesday we’ve finally published the Main KPIs report in the Business Overview Power BI application. As explained in the [previous editions](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) of the Data News, we’ve been working on the Main KPIs subject for a while, and this week we’ve finished the remaining aspects to cover the first batch of deliverables.
|
||
|
||
Specifically, this week we’ve added the Listings and also the Deal lifecycle metrics - that we changed from an original Host/PM approach, to account for the unique B2B entity that can be considered as our clients. Additionally, we created a Data Glossary to explain how the different metrics are computed and their definitions, as well as general comments about the data itself.
|
||
|
||
|
||
|
||
Main KPIs report available in Business Overview
|
||
|
||
Following this first batch we aim to capture feedback and continue the work towards the second batch of deliverables, that we will re-align on with the TMT this week.
|
||
|
||
## Listings and Deals lifecycle
|
||
|
||
In order to develop the first batch of business KPIs, at Data team level we’ve taken the opportunity to propose a first approach on the lifecycle evolutions of two of our main entities at Superhog: Listings and Deals.
|
||
|
||
We have defined a set of 7 states that will allow to determine, for each listing and deal, the lifecycle state in a given month - yes, not only the current one, but all history since it was created! Here’s the list of states:
|
||
|
||
1. **New**: Listings/deals that have been created in the current month, without bookings.
|
||
2. **Never Booked**: Listings/deals that have been created before the current month, without bookings.
|
||
3. **First Time Booked**: Listings/deals that have been booked for the first time in the current month.
|
||
4. **Active**: Listings/deals that have booking activity in the past 12 months (that are not FTB nor reactivated).
|
||
5. **Churning**: Listings/deals that are becoming inactive because of lack of bookings in the past 12 months.
|
||
6. **Inactive**: Listings/deals that have not had a booking for more than 12 months.
|
||
7. **Reactivated**: Listings/deals that have had a booking in the current month that were inactive or churning before. After the 2nd booking during the reactivation month, will be categorised as Active directly.
|
||
|
||
Additionally, in order to measure the activity of a listing/deal with different recencies, we’ve set up the following 3 flags:
|
||
|
||
- **Has the listing/deal been booked in 1 month?**: If a listing/deal has had a booking created in the current month
|
||
- **Has the listing/deal been booked in 6 months?**: If a listing/deal has had a booking created in the past 6 months
|
||
- **Has the listing/deal been booked in 12 months?**: If a listing/deal has had a booking created in the past 12 months
|
||
|
||
If you want to deep-dive on this lifecycle as well as get a high-level overview of the current volumes that applied to each state, we invite you to check the dedicated Notion page:
|
||
|
||
[Listing & Deal lifecycle - 2024-07-29](https://www.notion.so/Listing-Deal-lifecycle-2024-07-29-4dc0311b21ca44f8859969e419872ebd?pvs=21)
|
||
|
||
# 2024-06-21
|
||
|
||
## Currency Rates Updates
|
||
|
||
This week our integration with [xe.com](http://xe.com) has been running nicely after last week’s deployment. Every day, we fetch new rates from it.
|
||
|
||
Besides that, we’ve been working on a Power BI report to make the rates accessible to the Finance team and generally, to anyone who needs it. We expect to have it ready and open up access during next week.
|
||
|
||
Finally, we also encountered a blocker. The Subscription level we have purchased only allows to fetch 10,000 rates per month. This is enough for our daily loads, but we will need way more records to recover all the historical rates between now and the past years of Superhog history (we’re planning on fetching rates up to January 1st 2020). We will discuss with Ben R. upgrading our subscription once he’s back so he can have more firepower to fetch the needed rates.
|
||
|
||
## Xero Reporting in progress
|
||
|
||
Following our [planning with the Finance earlier this month](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), we’ve started work on some reports to be built on top of Xero data. These reports will leverage [our integration between Xero and the DWH](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), which enables us to visualize Xero data on Power BI.
|
||
|
||
We took the chance when Jamie D. visited the Barcelona office early in the week to refine the final details of these reports. We are currently working on a Claim Payments report that will allow us to track how much Superhog has paid to Hosts and PMs to compensate for damages. This data will be visible across Deals and time, so it will be a very interesting report for many areas within Superhog. More news on it next week.
|
||
|
||
## Check-In Hero reporting incident
|
||
|
||
This Wednesday we also had a bitter situation. A technical incident caused the CheckIn Hero reporting suite to show inflated numbers in counts of sales and revenue. Luckily, the figures differences were small (since the figures as of today are still small), and the Data team fixed the issue fast. You can read more about the incident here: [20240619-01 - CheckIn Cover multi-price problem](https://www.notion.so/20240619-01-CheckIn-Cover-multi-price-problem-fabd174c34324292963ea52bb921203f?pvs=21).
|
||
|
||
Even though we got lucky this time, this incident could have led to massively wrong reporting and was only caught by chance this time. We will be aiming to run some meetings with the involved parties to prevent mistakes like this in the future, as well as improve our own detection systems to raise these issues as soon as possible when they happen.
|
||
|
||
## Check-in Hero report updates in progress
|
||
|
||
We are working on adding more valuable data to the Check-in Hero report, after the inclusion of rates with our guests now we are adding more information about hosts and how is the application of Check-in Hero option evolving and how effective has been.
|
||
|
||
|
||
|
||
We are also planning on adding more detailed data about hosts and their listing with Check-in Hero and how is it performing for our business, this is still a work in progress but expect to hear from us very soon with these updates being available.
|
||
|
||
## KPI implementation is in progress
|
||
|
||
Following [last week’s progress](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) on the KPI definition and implementation, this week we continued this effort.
|
||
|
||
Firstly, we have finalised the implementation of the main Guest Journey metrics, which mainly consist of how many Guest Journeys have been created, started and completed. From these metrics, we are also able now to monitor the evolution of the Guest Journey start rate and completion rate every day on the Month To Date tab, as well as retrieve the past history. For instance, these are the historic values for # Guest Journey Created, Start Rate and the # Guest Journey Started.
|
||
|
||
|
||
|
||
Hm… looks like we have an outlier somewhere, can you guess which one?
|
||
|
||
Secondly, a small but interesting addition of the cancelled bookings allow us to have a clearer picture of how our business operates.
|
||
|
||
Additionally, we have been working on revamping a bit the look and feel of the dashboard that step by step gets more and more filled up. This is how it currently looks, with the addition of the metrics mentioned above:
|
||
|
||
|
||
|
||
All the available metrics so far - more to come 😎
|
||
|
||
Lastly, we’ve started working on the Host/Listings lifecycle - from creation, activation, activity, churning, etc. At this stage it’s pretty much still work in progress, all the magic being hidden at the moment in the DWH… So for this you’ll need to wait until the next edition of the Data News 😮.
|
||
|
||
# 2024-06-14
|
||
|
||
## Advances in KPI definition with TMT
|
||
|
||
This week we experienced great advances on [the KPI definition](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) - and even in the implementation -, as we had the chance to present the Data proposal for KPIs to the TMT.
|
||
|
||
In a nutshell, we’re following a process of batch-delivery: each batch can contain a set of metrics that we will start measuring, as well as a set of ways to represent and filter the data. Each batch will be delivered incrementally, and as we advance on the implementation we will also take the opportunity to refine and agree on following batches.
|
||
|
||
At this stage, we aim to provide a first batch of 21 KPIs by the end of June, with a month-by-month overview, to keep track of the historic figures, and a Month-to-Date (MTD) overview, to better anticipate the landing of the KPIs by the end of the month while it’s on progress. This first batch will mostly contain high-level volume-based metrics, and we aim to include more Revenue-based figures for the second batch.
|
||
|
||
|
||
|
||
A draft of how the new dashboard is looking so far - still quite empty for the time being 😄
|
||
|
||
Additionally, as part of the KPIs exercise, this week we have also implemented an easy way to estimate - yes, ***estimate*** - when the guests start and complete the guest journey, that would enable us to easily extract and represent both historical and current month Guest Journey related figures.
|
||
|
||
For more details about the first batch of KPIs, you can check the following Notion page:
|
||
|
||
[Business KPIs Definition - TMT session 12th June 2024](https://www.notion.so/Business-KPIs-Definition-TMT-session-12th-June-2024-3b32b4c2c2904cdf89abdeea536332fb?pvs=21)
|
||
|
||
## `xexe` is now in production
|
||
|
||
This week we’ve finalized the implementation of `xexe`, our internal tool to read rates from the [xe.com subscription that we purchased last week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md). `xexe` bridges the gap between xe.com and our DWH, loading rates into it on a daily basis.
|
||
|
||
This is a great step forward in our [[XE.com](http://XE.com) Project](https://www.notion.so/XE-com-Project-b5001ea18b634519b814cb8014e36581?pvs=21). We will continue work with leveraging the rates within the DWH and also opening up access and providing training and support for different stakeholders. Stay tuned for more updates.
|
||
|
||
For developers and other technical profiles, you can review the tool’s [repo here](https://guardhog.visualstudio.com/Data/_git/data-xexe).
|
||
|
||
## Upgrading the Check-in Hero Report
|
||
|
||
We have updated the [Check-in Hero report](https://app.powerbi.com/Redirect?action=OpenReport&appId=14859ed7-b135-431e-b0a6-229961c10c68&reportObjectId=8e88ea63-1874-47d9-abce-dfcfcea76bda&ctid=862842df-2998-4826-bea9-b726bc01d3a7&reportPage=ReportSectionddc493aece54c925670a&pbi_source=appShareLink&portalSessionId=2763b723-4cd5-4d70-9a3f-229730ceaa8b) to better visualize the funnel flow and included a new tab that shows both the conversion rate of total guest journeys that offer check-in hero vs total guest journeys, as well as the rate of check-in hero purchased vs total guest journeys that offer check-in hero.
|
||
|
||
Take a look at it to check these new information and know that we are still working on it to keep adding more relevant data.
|
||
|
||
|
||
|
||
# 2024-06-07
|
||
|
||
## Data Team organisation: alignment with TMT
|
||
|
||
This Thursday, the Data Team had an alignment session with the TMT on the team organisation [we talked about a couple of weeks ago](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) and the main priorities for the following months. In a nutshell, our aim is to foster a Data-Driven culture within Superhog.
|
||
|
||
In terms of how we organise work, we identify 3 main lines of work, namely: Maintenance, Projects and Ad-hoc requests. The following table summarises it:
|
||
|
||
| **Type** | **Nature** | **Tracking** | **Time allocation** | **Estimation / priority** | **Examples** |
|
||
| --- | --- | --- | --- | --- | --- |
|
||
| Maintenance | Reactive, ensuring data systems and processes work well | DevOps | No constraint | Top priority, unplanned | Data pipeline issues, outages, data quality, availability of critical reports |
|
||
| Projects | Long-term projects to build data products to contribute to the strategic value | High-level ProductBoard
|
||
|
||
Low-level DevOps | No constraint | High priority, Planned following Agile iterative approach | New data pipelines, dashboards, data gov frameworks, alerting, A/B tests |
|
||
| Ad-hoc Requests | Short-term, small tasks | DevOps (for non-trivial) | Data Captain, max. 10h/week | Priority based on common sense. No estimation | Run queries, small insights, quick report |
|
||
|
||
The main initiatives will be placed in our [Data Roadmap](https://superhog.productboard.com/roadmap/8171557-7-data-roadmap) in ProductBoard, knowing that this roadmap is likely to change as new topics and priorities arise.
|
||
|
||
***Ok but… how can I submit requests for the Data Team?***
|
||
|
||
We have implemented a slack Data Request workflow in our [#data](https://superhogteam.slack.com/archives/C06GFGHJD7H) channel that will centralise the request in-take! Check the screenshots below:
|
||
|
||
|
||
|
||
|
||
|
||
Each week, someone from the Data Team will be designated as the **Data Captain**, and this will be the person that will manage the incoming requests through our Data slack channel. Ahoy, Data Captain! 🚢
|
||
|
||
For more details on the organisation, you can check: [Data Team Organisation](https://www.notion.so/Data-Team-Organisation-81ea09a1778c4ca2ab39e7f221730cb5?pvs=21)
|
||
|
||
If you’re interested into knowing the main Data priorities, you can check our OKRs: [Data OKRs](https://www.notion.so/299e4da6e92043899646d11609c051ae?pvs=21)
|
||
|
||
Ah! And we also have a Data Team official photo, by our photographer Alex Simon!
|
||
|
||
|
||
|
||
*Pablo, Joaquín and Uri working very hard to keep their eyes open at the moment of the picture*
|
||
|
||
## Defining KPIs: first steps
|
||
|
||
This week we also resumed the KPIs definition subject. In this long-term project, we aim to provide the key metrics that would help TMT and the main business areas to understand how the business is doing and take better decisions based on facts.
|
||
|
||
We already started refining the activity of listings a few weeks ago, as well as finalising the implementation of the main sources of revenue. This week though, our focus was more on laying the foundations for the broad KPIs definition. Our current priority is to set the main, company-wide KPIs, while in further iterations we will continue going into the details of each product/business area.
|
||
|
||
|
||
|
||
The hog, busy setting up the KPI control room wirings.
|
||
|
||
So far, we conducted 2 internal workshops in the Data Team with 2 different approaches: a detailed refinement of existing high-level metrics and needs, and a more top-down approach from scratch. Lastly, we’ve also checked the key metrics needed for Superhog OKRs, since the nature of these can actually help on determining the main priorities on metric implementation.
|
||
|
||
Next week we will have the first high-level workshop with the TMT, so stay tuned!
|
||
|
||
## Survey report for Marketing
|
||
|
||
We obtained data from a survey with around 4000 entries, sent to different hosts and managers across the US, covering many interesting topics for the business. With this data, our team built a report in Excel to make the analysis of this data easier to digest and interpret.
|
||
|
||
This report delves into a variety of topics like trends, challenges, and opportunities for the business. From customer relationships to operational preferences, there is a lot of data available to work within this report.
|
||
|
||
If you are interested in taking a look at it, please give us a shoutout, and if needed, we can arrange a meeting to explore the report in detail.
|
||
|
||
|
||
|
||
## [XE.com](http://XE.com) subscription ready, work has started
|
||
|
||
This week we’ve started technical work on integrating [xe.com](http://xe.com)’s currency API into our systems. This API will allow us to fetch currency exchange rates in an automated way to feed our DWH and other systems. This way, we’ll be able to perform currency conversion in all of our reporting and many other processes.
|
||
|
||
|
||
|
||
The piggies invading the FX trading floor.
|
||
|
||
This week we purchased a yearly subscription to the service and we are now busy building the necessary code to fetch the rates into our DWH. We have baptised the tool we’ll use for it as `xexe` (*shay-shay*). If you are technically inclined and feel curious, you can checkout [the repository](https://guardhog.visualstudio.com/Data/_git/data-xexe).
|
||
|
||
You can keep track on the progress of this line of work here: [[XE.com](http://XE.com) Project](https://www.notion.so/XE-com-Project-b5001ea18b634519b814cb8014e36581?pvs=21).
|
||
|
||
## PMS volume figures export available
|
||
|
||
This week, starting from [a request by Claire](https://guardhog.visualstudio.com/Data/_workitems/edit/16919/), we’ve done some number crunching to compute some figures around how big each of the different PMSs that plug into Superhog’s platform is. The result is a simple yet interesting excel export showcasing the data. This includes aggregations such as counts of active listings, created bookings or host and guest revenue.
|
||
|
||
If you would like to request access to this data, please get in touch with you to share the data.
|
||
|
||
## Priorities aligned and refined with the Finance team
|
||
|
||
As you can see in [our roadmap](https://superhog.productboard.com/roadmap/8171557-7-data-roadmap), Finance is going to get a lot of love from the Data team in the upcoming weeks. We have multiple joint lines of work open to improve reporting on financial figures and streamlining some business processes. Some of these topics include:
|
||
|
||
- Formalizing and implementing proper processes to invoice e-deposit customers
|
||
- Formalizing and implementing proper processes to invoice new screening API customers
|
||
- Creating a new suite of Xero-driven reports: Damage Waiver payouts,
|
||
- Integrating Currency rates into some reports and processes
|
||
- Providing general support across general invoicing and new dashboard topics related to Finance and Invoicing
|
||
|
||
After some sessions with the team, now we have a long road ahead of work to do to get this done. We’ll keep updating around here on our advances as they happen.
|
||
|
||
# 2024-05-30
|
||
|
||
## Waiver payouts now present in Business Overview
|
||
|
||
Our [Business Overview reporting suite](https://app.powerbi.com/Redirect?action=OpenReport&appId=33e55130-3a65-4fe8-86f2-11979fb2258a&reportObjectId=01d5648d-1c0b-4a22-988d-75e1cd64b5e5&ctid=862842df-2998-4826-bea9-b726bc01d3a7&reportPage=ReportSection57283b6e80c2d286de47&pbi_source=appShareLink&portalSessionId=248e0b8a-7246-4ec4-a1b4-b82ee7a564e0) now displays the amounts paid back to hosts as due waivers for hosts that take the waiver risk. This is an improvement from [the previous version](https://app.powerbi.com/Redirect?action=OpenReport&appId=33e55130-3a65-4fe8-86f2-11979fb2258a&reportObjectId=01d5648d-1c0b-4a22-988d-75e1cd64b5e5&ctid=862842df-2998-4826-bea9-b726bc01d3a7&reportPage=ReportSection57283b6e80c2d286de47&pbi_source=appShareLink&portalSessionId=248e0b8a-7246-4ec4-a1b4-b82ee7a564e0), which only showed the total charged to guests.
|
||
|
||
The visuals show simultaneously the total amount we charged guests and the total amount we sent back to hosts, making it simple to see what’s ours to keep.
|
||
|
||
## Xero-based fees reports for Guesty
|
||
|
||
[Last week we made a release](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) in [Business Overview](https://app.powerbi.com/Redirect?action=OpenReport&appId=33e55130-3a65-4fe8-86f2-11979fb2258a&reportObjectId=0642f366-c243-4879-8228-d8d6cc78f266&ctid=862842df-2998-4826-bea9-b726bc01d3a7&reportPage=95e1c6dfd47615e58712&pbi_source=appShareLink&portalSessionId=248e0b8a-7246-4ec4-a1b4-b82ee7a564e0) to show the fees we should theoretically charge Guesty and e-deposit customers based on the data available in our [Superhog Cosmos DB](https://www.notion.so/Superhog-Cosmos-DB-b76557e0b49149cf8cbfed7309e16ac6?pvs=21) .
|
||
|
||
To complement this report, we now also show the revenue we have effectively charged Guesty according to Invoices/Credit notes existing in [Xero](https://www.notion.so/Xero-8085e30c86624af48ca39ca047b6dffe?pvs=21) .
|
||
|
||
## Refining invoicing exports for the new Screening API
|
||
|
||
The API team is moving forward with our new screening API. This week we started some refinement discussions with Ana to better understand the data structures and the data that we will need to pull out so that our Finance colleagues can invoice properly the customers of this API.
|
||
|
||
Ana dropped [this wonderful documentation](https://www.notion.so/Screening-API-Project-final-b99730e6962545a389c5f838b0bcbcb4?pvs=21) that will help a lot. We will tackle this during [upcoming weeks](https://superhog.productboard.com/entity-detail/features/27338025) as the technical and commercial launch of the service closes in.
|
||
|
||
## CTO and senior devs greenlight to integrate CosmosDB with DWH
|
||
|
||
As work on APIs and Resolutions increases, there are more and more expectations around reporting needs for those areas. Currently, we are facing a tricky situation because Airbyte, our preferred tool for data extraction, does not have native support to extract data from CosmosDB, which were a good chunk of the data related to those functions lives. Thus, integrating CosmosDB and DWH will take some effort.
|
||
|
||
We have planned some capacity for this topic in June. But, as a first step, we already sat down this week with Ben R., Ray and Manu to discuss the role of CosmosDB in Superhog’s technology in the long term, as well as the technical side of things and possible architectural patterns we could follow.
|
||
We still haven’t settled for one technical approach to implement this, but we all agreed on the fact that it makes perfect sense to go for the integration if we find one good way to do it.
|
||
|
||
Next week we expect to start doing some whiteboarding, research and testing to better judge our options and hopefully come out with a design for how to implement the integration. We will keep posting updates around here, so stay tuned.
|
||
|
||
## Automated Alerts in Slack
|
||
|
||
The Data Team generally enjoys *not* having to do things, also known as being efficient. As part of it, we try to automate a lot of things in our infrastructure. We automate the extraction of data from many of our systems, like the Superhog backend, Stripe or Xero. We also regularly automate processes and transformations that run inside the DWH.
|
||
|
||
This is all nice and smooth, until one day something breaks. If something breaks, step number one is to be aware of it. Now that the size of the team has increased, we decided to invest a bit of time in monitoring automatically the success or failure of many of our automated jobs. Without this, it would be easy for something to slip and for the team to drop the ball.
|
||
|
||
|
||
|
||
The Data Team, busy putting out fires.
|
||
|
||
Since this week, all our Airbyte and dbt jobs will drop messages in some slack channels so we can monitor them. That way, we can know for sure when we can lay back and relax doing other stuff 😎.
|
||
|
||
# 2024-05-24
|
||
|
||
## Data team grows: meet Joaquín
|
||
|
||
This week we celebrate an exciting onboarding! The analysis muscle gains some extra strength with Joaquín’s arrival.
|
||
|
||
Joaquín is originally from Chile and came to Barcelona to pursue an MSc in Data Science. A Civil Engineer by education, his career in Walmart led him to pivot towards Data. Hence why he joins us as a Data Analyst.
|
||
|
||
Joaquín will be based in Barcelona. You can find him by searching in Slack for `joaquin.ossa`
|
||
|
||
|
||
|
||
Welcome Joaquín!
|
||
|
||
## New Data Team organization coming soon
|
||
|
||
With Uri and Joaquín around, the data team enters a new phase and leaves behind the era of Pablo playing one-man orchestra.
|
||
|
||
|
||
|
||
Pablo parting ways with his one-man orchestra phase.
|
||
|
||
The new team will be able to deliver much more and bring a new wave of capabilities to Superhog, but it also requires more organization and better processes to ensure everything is properly lubed and working.
|
||
|
||
As part of this, Uri and Pablo are already working in defining the new organization for the team. Once the new structure is defined, we will communicate it company wide so that we can all be aligned with our new ways of working. Stay tuned!
|
||
|
||
## E-deposit and Guesty revenue available in Business Overview
|
||
|
||
This week we started recovering the revenue information for the first 2 API sources: Guesty and E-deposits. The figures of revenue are now available in the [Business Overview reporting suite](https://www.notion.so/Business-Overview-Reporting-Suite-9e1662c7b9c042f3bd4c053364ba30ab?pvs=21). These two sections display the information of bookings and the respective revenue coming directly from the [Cosmos DB](https://www.notion.so/Superhog-Cosmos-DB-b76557e0b49149cf8cbfed7309e16ac6?pvs=21) backend source. Special thanks to Ana for her support on understanding the logic behind it!
|
||
|
||
|
||
|
||
## Xero Booking, Verification and Listing net fees are now available in Business Overview
|
||
|
||
After [last weeks release](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), we’ve done some more work on the Xero data inside the DWH. This has allowed two new improvements:
|
||
|
||
- Besides Listing and Verification fees, Booking fees are also now available in the reporting suite.
|
||
- We are now able to display *net ****fees*. This means that revenue figures now take into account that we don’t just invoice our customers, but also credit them back. The new charts show the invoiced amounts with the credited amounts subtracted, showing a more realistic picture of what’s the final revenue for Superhog.
|
||
|
||
# 2024-05-17
|
||
|
||
## CheckIn Hero revenue available in Business Overview
|
||
|
||
This week we extended a bit our efforts on the [reporting around CheckIn Hero](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) to also include the juicy revenue figures into our [Business Overview reporting suite](https://www.notion.so/Business-Overview-Reporting-Suite-9e1662c7b9c042f3bd4c053364ba30ab?pvs=21). You can now find it in the Guest Payments section, along with the Waiver and Fees revenue sections.
|
||
|
||
|
||
|
||
## First release of Xero host fees
|
||
|
||
The [Business Overview](https://www.notion.so/Business-Overview-Reporting-Suite-9e1662c7b9c042f3bd4c053364ba30ab?pvs=21) has also received two new data points: we are now finally leveraging our [integration between Xero and the DWH](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) to show you fees invoiced according to our accounting books.
|
||
|
||
We’ve begun with Listing and Verification fees, which are now available in the Host Fees section. Our confidence in the figures is high, although there might be small adjustments in the next days as we run some checks.
|
||
|
||
|
||
|
||
Booking fees will soon follow, but we are still working on some data quality issues that we want to address before releasing the data to avoid misinformation across the organization.
|
||
|
||
## Guesty and e-deposit fees in the works
|
||
|
||
Besides the previous updates on revenue figures, we are also working on running some automated calculations on the theoretical revenue for e-deposit clients in general, as well as for Guesty. We will feed these straight from our [Cosmos database](https://www.notion.so/Superhog-Cosmos-DB-b76557e0b49149cf8cbfed7309e16ac6?pvs=21) into PBI reports that will run the numbers on the different nightly fees according to the activity of our customers. Stay tuned for more updates.
|
||
|
||
# 2024-05-10
|
||
|
||
## CheckIn Hero Reporting is now live
|
||
|
||
This week our beloved Guest Squad has put CheckIn Hero live and our first customers are being offered this new cover. There was even a sale on the very same launch date!
|
||
|
||
The Data team has also collaborated with this project by delivering a first reporting suite to monitor the evolution of the product. The reporting suite shows key KPIs of the product: revenue, conversion rates, outstanding risk, etc. The data is refreshed automatically by our Data Platform and shown with a <24 hours latency.
|
||
|
||
|
||
|
||
A sample of the CheckIn Hero reporting, showing our first sale.
|
||
|
||
This reporting suite raises the bar. In the past, analysing the performance of our products has been a challenge that implied a lots of manual work and significant time lags between facts happening and them being reported. With this suite, we are able to monitor the key metrics of CheckIn Hero automatically and pretty much as they happen. In the Data team we are delighted with this delivery and we look forward to ensure all of our operations enjoy levels of data maturity at least as good as this example.
|
||
|
||
Finally, congratulations to everyone involved in launching CheckIn Hero!
|
||
|
||
|
||
|
||
CheckIn Hero to the rescue.
|
||
|
||
## Data team grows: meet Oriol
|
||
|
||
This week we celebrate an exciting onboarding! Oriol joined the Data team this Friday to help us leverage Data Analysis to improve Superhog. We are thrilled by the cool stuff we will be able to achieve with Oriol’s help.
|
||
|
||
Oriol comes with a strong background in Data Science, ecommerce and digital analytics. He was previously a Data Science Manager in Veepee, where he and his team focused on tailoring customer experiences to boost sales.
|
||
|
||
Oriol will be based in our Barcelona office, so do look for him around to present yourself. If not, feel free to ping him on Slack! (oriol.roque)
|
||
|
||
|
||
|
||
# 2024-04-19
|
||
|
||
## Xero integration with DWH
|
||
|
||
Great news! After our research during the past week, we have finally pulled the trigger and we have now integrated our [Xero](https://www.notion.so/Xero-8085e30c86624af48ca39ca047b6dffe?pvs=21) tenant with the DWH. This gives us the ability to pull data from our accounting system into our DWH so we can build reporting on top of it. The most interesting part will probably be reporting on our revenue by leveraging the invoices that our Finance team builds with a lot of effort.
|
||
|
||
## Currency Exchange Rates adoption is getting started
|
||
|
||
Superhog is a multicurrency company: we operate on many regions and accept payments in several currencies, both from guests and hosts.
|
||
|
||
Managing this is a challenge. Handling multiple currencies means that prices, amounts, payments and many other pieces of financial data can come in a variety of units. So, answering questions like “what’s the average booking fee for our customer base?” or “what’s the total revenue we had in waivers last March?” always generate the need of converting a lot of different amounts in multiple currencies into a single one.
|
||
|
||
To succeed at managing this challenge, we need to have a complete, up-to-date and easy-to-access database of conversion rates. So that our reports, our processes and our people can always have the right rate handy. Today, this is a capability that we are lacking.
|
||
|
||
We have done some pre-alignment with Finance, Product and Engineering, but Data will be leading this effort. We will soon document and share our plans so you can stay up to date.
|
||
|
||
|
||
|
||
The hog, trying to convert some dollars to good old pounds before heading to the pub.
|
||
|
||
# 2024-04-05
|
||
|
||
## Exploring integrations with Xero
|
||
|
||
This week we’ve worked together with the Finance team to explore our options in terms of programmatically creating invoices for our hosts. The creation of invoices in Xero, our accounting system, is currently manual. Creating +1000 invoices by month manually is not the most pleasant, efficient or error-proof way of running this, so we
|
||
|
||
Our outlooks are positive: it seems Xero does have the capabilities required to make this happen, and thus we think the integration is feasible. In the following weeks we will organize work around this.
|
||
|
||
|
||
|
||
The hog, wishing it was doing something more interesting than creating invoices in Xero.
|
||
|
||
## Working on Booking fees reporting
|
||
|
||
This week we’ve also been busy on working on Booking Fee’s calculation within our DWH. These are numbers we usually run as part of our monthly invoicing process outside of the DWH, but doing them inside the DWH enables us to quickly run them for any period of time in the past on demand.
|
||
|
||
We are close to having it ready, but we’re not fully there yet. As soon as the data model and related reports are ready, they will become available in the [Business Overview](https://www.notion.so/Business-Overview-Reporting-Suite-9e1662c7b9c042f3bd4c053364ba30ab?pvs=21) reporting suite. Stay tuned.
|
||
|
||
# 2024-03-22
|
||
|
||
## Waiver stats now live in Business Overview
|
||
|
||
This week we have managed to deploy a new tab on our [Business Overview](https://www.notion.so/Business-Overview-Reporting-Suite-9e1662c7b9c042f3bd4c053364ba30ab?pvs=21) - Guest Payment reports. This tab tracks the Waiver payments that we have processed through our backend.
|
||
|
||
|
||
|
||
There are some caveats on the data, all listed on the report itself so you can take them into account.
|
||
|
||
## Data Quality Audit
|
||
|
||
This week we also ran some Data Quality checks to ensure proper invoicing during April. The checks revolved around ensuring that pricing of new accounts and accounts finishing free trials were up to date.
|
||
|
||
Thanks to Kayla, Alex and all the AM team for cleaning things up.
|
||
|
||
# 2024-03-15
|
||
|
||
## A new reporting suite has come to life 🚀
|
||
|
||
This week we’ve finally deployed a new Reporting Suite built with Power BI: the Business Overview.
|
||
|
||
The goal of this suite is to act as a central point to monitor the most important metrics on how the business is doing: monitoring how much revenue comes in from different products, counts on users, bookings, listings, etc.
|
||
|
||
We have started small with the first content we’ve managed to get ready. We will slowly grow the scope of the suite as we clean and prepare more and more data in [our DWH](https://www.notion.so/DWH-78ce5f76598d49d185fa5fc49a818dc4?pvs=21).
|
||
|
||
You can read more about the suite here: [Business Overview Reporting Suite](https://www.notion.so/Business-Overview-Reporting-Suite-9e1662c7b9c042f3bd4c053364ba30ab?pvs=21)
|
||
|
||
## Still looking for Data Analysts
|
||
|
||
We are still looking for new members for the data team! We are going through some interviews, but finding good talent is challenging.
|
||
|
||
If you have any contact in your agenda that you would like to refer to us, we are all ears!
|
||
|
||
# 2024-03-01
|
||
|
||
## `sh-invoicing` upgrades and new run
|
||
|
||
Last week we focused mainly on Finance work. Within that, the big bulk of work was delivered on delivering a few upgrades to our internal tool for generating invoicing reports, `sh-invoicing`. The most important item was upgrading our tool to be able to read from multiple Stripe accounts, since we are now receiving waiver payments in two different accounts. We also added other improvements on the structure of files and fixed a few small bugs.
|
||
|
||
With these improvements, and with the reduction of Acquired transactions to a pretty much residual size, we are hoping to reconcile all waivers this month automatically without having any of our finance colleagues chewing through a huge pile of spreadsheets.
|
||
|
||
## Iplicit API
|
||
|
||
This week we also received access to the API of Iplicit, our new accounting software. This will enable us to develop code in `sh-invoicing` to automatically generate invoices in Iplicit without manual interaction. This will be a big focus during the next week.
|
||
|
||
# 2024-02-23
|
||
|
||
## Upgraded e-deposit Report
|
||
|
||
After some discussions with @Ana de Vega and @Leo, with some support from @Ray, and a bit of work from our side, we have refurbished the old Athena PBI report and turned it into our brand new [e-deposit PBI report](https://app.powerbi.com/Redirect?action=OpenReport&appId=86bd5a07-0cd9-40ab-9e97-71816e3467e8&reportObjectId=91e9961d-0376-4199-a40c-da6fd1d4afcf&ctid=862842df-2998-4826-bea9-b726bc01d3a7&reportPage=ReportSectioncac343fda6a46e7ca83e&pbi_source=appShareLink&portalSessionId=abc1f4da-2785-4097-a49e-a05c27027234).
|
||
|
||
|
||
|
||
The new report now shows details for all verifications performed by Guesty or by other customers (when they actually do it, now it’s just an empty table). We also show some aggregates and over time info so that you can monitor how the product adoption is evolving.
|
||
|
||
## Stripe US ↔ DWH integration in progress
|
||
|
||
After completing [the integration our Stripe UK account with our DWH](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), we are now working on bringing over the records from our separate US account so we can have a unified view of all transactions, independently of on which Stripe account they are taking place.
|
||
|
||
This is currently a work in progress. The US data is already landing our DWH, but we still have to merge it together with the UK data to provide a simple experience downstream.
|
||
|
||
## Cancellation Launch: validating data model and preparing to design reports
|
||
|
||
This week we’ve spent some time together with @Gus and @Lawrence working on the design of the data model behind our new Cancellation Cover product. We were able to align reporting needs and validate that, once the product hits production, the Superhog backend will be storing all the information that we will need for reporting purposes.
|
||
|
||
During the next weeks we will also be meeting different stakeholders to gather requirements for the data needs around the new product so that we can work on building the necessary data products for everyone.
|
||
|
||
If you think you will some data on the Cancellation Product, and we haven’t discussed it, please, [get in touch](https://www.notion.so/Data-Homepage-0ac0a2e52a8940c7ba4f31e5ffcc33e8?pvs=21) as soon as possible.
|
||
|
||
## Leveling the ground for more accounting automations
|
||
|
||
With the new Iplicit deployment getting closer, we have requested the Iplicit team to provide us API access to our testing environment so we can start looking into the automatic generation of invoices. During the next weeks, we will be developing tools on our side to include this as part of the wider invoicing process so that our finance team can automatically generate for our host customers each month.
|
||
|
||
# 2024-02-16
|
||
|
||
## Data infra is now ready
|
||
|
||
**Data infrastructure is now live!** 🥳🥳🥳🥳🥳
|
||
|
||
|
||
|
||
A hog that is nearly as happy as us.
|
||
|
||
After some weeks of work, many technical meetings, a lot of tests and experiments in Azure, and many coffees, we finally deployed the production environment for our data infrastructure. We now have a Datawarehouse, a data integration tool (Airbyte) to pick data from different sources and a data modelling tool (dbt) to make it all work. We are now able to ingest data from several sources, clean it, prepare it, analyse it and serve it through reports and other channels.
|
||
|
||
We will be holding a few meetings during the next couple of weeks to get the word out and provide more details to different stakeholders so we can all align on how this infrastructure will be used in the coming months (and years).
|
||
|
||
Our heartfelt gratitude to @Ben for the help along the way!
|
||
|
||
## Stripe UK data now available in DWH
|
||
|
||
Our first step since we got the DWH and Airbyte running has been to integrate our Stripe UK Account with it. We are currently absorbing data for charges, payment intents and balance transactions into the DWH. We are now able to model this data in any way we need and build reports and exports on top of it.
|
||
|
||
Note that our Stripe US account is still not integrated.
|
||
|
||
Do you have great ideas as to how to put this data to work? If so, please do [get in touch](https://www.notion.so/Data-Homepage-0ac0a2e52a8940c7ba4f31e5ffcc33e8?pvs=21) so we can discuss them and add them to our backlog.
|
||
|
||
# 2024-02-09
|
||
|
||
## Small `sh-invoicing` fixes
|
||
|
||
This week we’ve been applying some quick fixes on the [sh-invoicing](https://www.notion.so/sh-invoicing-fdcf47ce663a4ed584593caab53aaa1e?pvs=21) tool to cover for a few edge cases that had slipped through. There are many subtleties in how we invoice and it shows through this little situations that appear every now and then. But thankfully, we keep on spotting and controlling them.
|
||
|
||
You can read more about these changes in the tool’s [changelog](https://guardhog.visualstudio.com/Data/_git/data-invoicing-exporter?path=/CHANGELOG.md).
|
||
|
||
## Rehearsing final infrastructure deployment
|
||
|
||
This week we have finalized documenting and testing our infrastructure design and deployment procedure. We are now happy with the end result and thus, ready to go and deploy in production, which we plan on doing next week.
|
||
|
||
[It’s been a long journey](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) to get here, but we’re confident it’s worth it. Once we deploy our new tools and start using them, the productivity and capabilities of Superhog in using data will skyrocket.
|
||
|
||
# 2024-02-02
|
||
|
||
## Search by Booking ID in PBI reports
|
||
|
||
If you regularly use our [Bookings report](https://app.powerbi.com/Redirect?action=OpenReport&appId=86bd5a07-0cd9-40ab-9e97-71816e3467e8&reportObjectId=40261ecd-9e80-42ec-8650-40ed0edf56d4&ctid=862842df-2998-4826-bea9-b726bc01d3a7&reportPage=ReportSection&pbi_source=appShareLink&portalSessionId=01a046fd-8d4c-4095-baf3-172dde28fd52) from our [PBI Reporting Suite](https://www.notion.so/Superhog-Reporting-Production-Suite-6da7d7a2c37a43bc9b82802670e46b97?pvs=21), we’ve made a little change that might make your life easier.
|
||
|
||
You can now search for a specific Booking ID in the filters. With this, you can narrow down the data to one specific booking for which you already know the ID without going crazy playing tricks with other filters.
|
||
|
||
|
||
|
||
## Invoicing tool Baptism of Fire
|
||
|
||
Finally, after a few weeks of work, it’s time to start a new invoicing cycle with great novelties.
|
||
|
||
Yesterday we began the invoicing process for January 2024 with [our new tool](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), `sh-invoicing`. We have used the tool to:
|
||
|
||
- Fetch all necessary data from the app.
|
||
- Export all transaction records from our UK Stripe account.
|
||
- Automatically compute the hosts’ amounts due for waivers processed through Stripe.
|
||
- Automatically perform currency conversions between the payee and host currencies.
|
||
|
||
Even though it doesn’t sound like much, the last couple of bullets were being done pretty manually until now, which meant someone had to go through *hundreds* of spreadsheets doing tasks like copy pasting from one place to another, applying formulas, etc. We’ve done a great deal of saving time with these already.
|
||
|
||
|
||
|
||
The hog and the new tool, having a cocktail thanks to the time they saved.
|
||
|
||
More changes and improvements will come next cycle. For now, we will be supporting the finance team during the execution of the current cycle in case errors arise or last minute fixes are needed.
|
||
|
||
Besides that, as a result of some last minute work done by Clay, Lawrence and Ben R., no more waiver payments will go through Acquired, which means February payments will be fully processed with Stripe. Without going into much detail, this means that processing February will be *way way way* less painful. Thanks for the great work guys!
|
||
|
||
# 2024-01-27
|
||
|
||
## New invoicing tool
|
||
|
||
After [discussing and passing on many of the open issues in our invoicing process](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) at the start of the week, this week we’ve been fully dedicated to starting to develop tools to solve part of the issues.
|
||
|
||
The first version of this is a command line (CLI) app we have dubbed `sh-invoicing`. If you are on the techy side, you can check the code here: [https://guardhog.visualstudio.com/Data/_git/data-invoicing-exporter](https://guardhog.visualstudio.com/Data/_git/data-invoicing-exporter).
|
||
|
||
|
||
|
||
What running a CLI app looks like.
|
||
|
||
This app will be a swiss-army knife of sorts to execute different tasks around preparing our invoices. The first tasks it can already do are:
|
||
|
||
- Exporting account data from Dashboard, like Booking, Verifications or Listings.
|
||
- Exporting transactions from Stripe.
|
||
|
||
Our next planned feature is making the tool capable of reconciling the waivers paid through Stripe. This is the biggest pain of the current invoicing process, and we hope that tackling it will already make a great difference for our colleagues in finance.
|
||
|
||
During the next week, we will be running some tests together with the finance team and finally use the tool for the first time to get our invoices for January’s activity.
|
||
|
||
# 2024-01-19
|
||
|
||
## Data for 2024 Bookings is now visible in PBI
|
||
|
||
If you used any of the Power BI reports in the [Core Reporting Suite](https://www.notion.so/Superhog-Reporting-Production-Suite-6da7d7a2c37a43bc9b82802670e46b97?pvs=21) you might have noticed that bookings for 2024 were not appearing. [The issue](https://guardhog.visualstudio.com/Data/_boards/board/t/Data%20Team/Stories/?workitem=12662) has now been dealt with. The underlying reason was some missing data in the [Core database](https://www.notion.so/Superhog-Core-Database-70786af3075e46d4a4e3ce303eb9ef00?pvs=21): we had a dates table that only ran until December 2023 and we had to push that further to 2024.
|
||
|
||
This is also a good time to remind you that, if you ever see anything wrong or need any assistance around our dashboard, you can always [get in touch with us](https://www.notion.so/Data-Homepage-0ac0a2e52a8940c7ba4f31e5ffcc33e8?pvs=21).
|
||
|
||
## The Invoicing Reformation moves forwards
|
||
|
||
This week we have finalized the first phase of the [Invoicing Reformation](https://www.notion.so/Start-here-93981184e2154dee9a4800f51d8c6e89?pvs=21). During this 2-week effort the Finance and Data team have gone through quite a few brain-heavy sessions to go through the invoicing process without leaving any stones unturned. We couldn’t be happier with the outcome:
|
||
|
||
- We have successfully managed to [document the existing process](https://www.notion.so/As-Is-Documentation-2024-01-22-e75dbf8244274c018a93b46c471fbdc1?pvs=21), which helps dramatically in understanding how should we move forward with improving our way of working.
|
||
- We have composed a [list of issues and improvement opportunities](https://www.notion.so/Issues-and-Improvement-opportunities-ec58b170df9541e2985e3db052c73930?pvs=21) that we will use to guide us forward in how to incrementally make invoicing more accurate, more efficient and more flexible.
|
||
|
||
|
||
|
||
The Data hog making a massive effort to understand how the heck waivers work.
|
||
|
||
I want to give a big shoutout to Elaine, Jamie and Amanda. They’ve been extremely helpful and we have come out of this with exactly what we need thanks to their effort.
|
||
|
||
Next week we will start organizing work on improving the invoicing process. We expect to be able to deliver some of them in the January cycle, and to have much, much better tooling by the time we have to process February.
|
||
|
||
## dbt is working like a charm, preparing for production
|
||
|
||
Between finance and finance meeting, this week we managed to scratch some time to work on our dbt code runner [as we planned last week.](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md) As part of it, we started the repository where we will store our data models.
|
||
|
||
We already managed to connect them to the DWH to run some tests and successfully deployed tables there. This means we now have a pretty complete landscape in terms of data capabilities: we can integrate data from different sources with Airbyte, store it in our DWH, work it with dbt and present it through Power BI.
|
||
|
||
Next week we will document how we deployed and integrated all of these components in order to get ready to deploy them in production and start using them.
|
||
|
||
# 2024-01-12
|
||
|
||
## Advances in Data Architecture
|
||
|
||
Architecture has made some nice progress [since the last time we discussed it](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md). We began the week with some great work and an important milestone: we presented and discussed our proposed infrastructure architecture to Ben R, and we obtained his blessing on our proposal! He was happy with our design and we all agreed on moving forward with it.
|
||
|
||
Besides that, we did some more work, like creating a connection between PBI and our DWH in its dev environment. With that, we managed to validate that we will be able to build reports on top of the DWH.
|
||
|
||
Next week we will test the only missing part: a [dbt](https://docs.getdbt.com/docs/introduction) code runner. This element will be responsible for processing the data from our different sources to build clean, tidy and easy to read data models so that we can all build reports on top of great stuff. Once we manage to deploy and run this, we will finish our full documentation on the Data Architecture to get ready to re-deploy it in a Production environment.
|
||
|
||
## Working through the details of Invoicing with Finance
|
||
|
||
[As we introduced last week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), this week was the start of a new project to improve our Invoicing process. We have named the project the Invoicing Reformation, a little nod to the [Protestant Reformation](https://en.wikipedia.org/wiki/Reformation). The project has [a little space here in Notion](https://www.notion.so/Start-here-93981184e2154dee9a4800f51d8c6e89?pvs=21) which you can check out if you feel curious.
|
||
|
||
|
||
|
||
During the week, we’ve spent a lot of time together with the Finance team in long and heavy sessions where we deep dived into the details of executing the process. As we advance, we are both [documenting the existing process as it is](https://www.notion.so/As-Is-Documentation-2024-01-22-e75dbf8244274c018a93b46c471fbdc1?pvs=21) today, as well as [identifying and organizing all the existing issues](https://www.notion.so/Issues-and-Improvement-opportunities-ec58b170df9541e2985e3db052c73930?pvs=21) that make the process hard.
|
||
|
||
It’s been a tough but productive week. The process has many important details, handles a lot of data and currently faces many corner cases, exceptions, data consistency issues and other problems. Next week we will keep discussing some parts of the process with Finance and Engineering before moving on [to the next phase](https://www.notion.so/Start-here-93981184e2154dee9a4800f51d8c6e89?pvs=21) where we will jump into problem solving mode.
|
||
|
||
|
||
|
||
Some live footage of how you look like 5 hours into discussing all the little details of invoicing.
|
||
|
||
# 2024-01-05
|
||
|
||
Happy new year everyone!
|
||
|
||
|
||
|
||
## First batch of cataloguing finished
|
||
|
||
Finally, after some weeks of work, we are happy with the current state of our [Data Catalogue](https://www.notion.so/Data-Catalogue-78d91434aa1442cbb6cc13b73c7fb664?pvs=21) and think is ready to start being useful for all the company! A few bits and pieces will still be added by some colleagues, but the main trunk is already there.
|
||
|
||
We will soon make a big announcement to get it in front of all colleagues in Superhog, but if you are already reading this, feel free to peek around.
|
||
|
||
We expect the Catalogue to be a great asset that helps a lot silently. As we grow and build cool stuff, it’s going to be increasingly harder for each of us to know about *everything* that exists in Superhog. Our hope is that the Data Catalogue will prevent work duplication and will help colleagues share their work and leverage existing work from others. We already had our first case of this! The Business Systems was looking at how the heck they could count how many guests are starting the verification journey… and [the product team was already doing that](https://www.notion.so/Mixpanel-Reporting-Suite-8b1f1bd30bab4c8ca33fb3d0c57f7e71?pvs=21).
|
||
|
||
|
||
|
||
You when you don’t waste 20 hours with some data-thingy because you discover someone else has already done it for you.
|
||
|
||
From now on, this becomes a living thing: feel free to reach out to us to edit and add as the Catalogue becomes outdated. As well as to come in regularly to stay up to date with the existing databases and data products in the company.
|
||
|
||
## Data architecture is moving to the cloud
|
||
|
||
Continuing with our [Data Architecture saga](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), we have already started deploying our software and databases in a [development environment](https://dev.to/flippedcoding/difference-between-development-stage-and-production-d0p) in Azure. In doing so, we can continue testing in an environment that is much more similar to how the final production deployment (the one that *you* will be using). This way, we slowly work out the rough edges and ensure that, once we finally go for it, we encounter no issues at all.
|
||
|
||
This is still a WIP, but we expect to complete a first full round of work by Monday, when we will sit down with Ben R. (our CTO) to get his feedback on security, performance and the general soundness of what we are building. Once we have a final architecture and his blessing for it, we will move on to deploying the real production one that you will be benefitting from.
|
||
|
||
|
||
|
||
Our data pig-services, happily living in the cloud.
|
||
|
||
## Warming up to turn invoicing from pain to pleasure
|
||
|
||
Invoicing our customers is quite an important thing: we won’t be paying our bills unless we do this timely and accurately.
|
||
|
||
As Superhog has been growing, invoicing has also been turning into a more complex and challenging process. Our colleagues in Finance are currently feeling the pain because running the numbers for each customer is now far from trivial, and it’s taking a tremendous amount of effort and hours.
|
||
|
||
TMT has decided it’s time to turn this upside down and make invoicing swift. To achieve this, we will run a multi-week project to crawl out of the current situation into a simpler, more automated and scalable process.
|
||
|
||
The Data Team will be spearheading a first shot at improving data access and automating as much data wrangling as possible. Along the way, we will also count on other teams (engineering, revops, product, etc) assistance to improve data management, business processes, and other elements that currently create challenges for invoicing.
|
||
|
||
We will get in touch with the related stakeholders soon, and we will update you through the advances here.
|
||
|
||
# 2023-12-22
|
||
|
||
Merry Christmas to everyone!
|
||
|
||
](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a/Untitled%2040.png)
|
||
|
||
[https://xkcd.com/1933/](https://xkcd.com/1933/)
|
||
|
||
## Closing in on finishing the first cataloguing batch
|
||
|
||
After a nice week working on more details about the Core database and Hubspot, the team also had time to pay attention to other systems and data products within the company. Thanks to this, we are very close to finishing our first version of the [Data Catalogue](https://www.notion.so/Data-Catalogue-78d91434aa1442cbb6cc13b73c7fb664?pvs=21).
|
||
|
||
If you are involved in any of the [Data Sources](https://www.notion.so/Data-Sources-739e7af77fd0407ca51f2a1c33e2c526?pvs=21) and [Data Products](https://www.notion.so/Data-Products-5030f44a0f764adebb1443ea0681f68a?pvs=21) contained in it… expect news from us soon. We will need your help to double check the contents and ensure it’s all top notch material.
|
||
|
||
And for everyone else: we will make a nice, big announcement once the Catalogue is complete and ready for you to enjoy. Stay tuned!
|
||
|
||
## Handing over of the PBI reports on top of Core
|
||
|
||
After some sessions together with the Engineering Team to perform the handover, we can finally announce that the Data Team is now ready to take care of the existing [Power BI reports](https://www.notion.so/Superhog-Reporting-Production-Suite-6da7d7a2c37a43bc9b82802670e46b97?pvs=21) sitting on top of the [Dashboard database (Core)](https://www.notion.so/Superhog-Core-Database-70786af3075e46d4a4e3ce303eb9ef00?pvs=21).
|
||
|
||
You can contact us to:
|
||
|
||
- Request access
|
||
- Notify issues on data
|
||
- Request changes on the dashboard contents
|
||
- Clarify doubts on the dashboard contents
|
||
- And anything else you might need in relations to these reports.
|
||
|
||
A small spoiler: as part of working on an improved architecture for our data systems, we expect to sunset these reports somewhere in the upcoming weeks and provide similar ones on top of our future DWH afterwards. So, be aware that right now we will only address truly urgent hotfixes on the existing reports. Any new cool stuff, we will built directly on top of our new DWH.
|
||
|
||
## First architecture tests and discussions in progress
|
||
|
||
|
||
|
||
The Data Team, busy at the engineering lab trying out weird ideas.
|
||
|
||
The work on architecture has moved forward [since we last updated you](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md). After some discussions with our Engineering Team to align and design [a first draft of something that works for everyone](https://guardhog.atlassian.net/wiki/spaces/Data/pages/159023188/Data+Infra+Architecture), we have already started running our first tests.
|
||
|
||
This involves designing and implementing different pieces of software in a development environment so we can validate that all moving parts work together as intended before we jump on to deploying the real stuff on our cloud. It’s a time of big headaches and lots of open questions, but also of excitement because all of this will be *insanely* useful and productive once we set it up properly.
|
||
|
||
|
||
|
||
We deal with this crazy stuff so you don’t have to.
|
||
|
||
We will need more time and tests to get this ready, but we are on the right path to provide great foundations for all of us to enjoy data here at Superhog. We will keep you posted as we get closer to an internal launch.
|
||
|
||
# 2023-12-15
|
||
|
||
## Successful kickoff of the Data Team
|
||
|
||
[As we told you about last week](Data%20News%20-%20From%201st%20Dec%202023%20to%207th%20Feb%202025%2019d0446ff9c9803983f5db69fb38e82a.md), this week we had our big meeting to present our plans to some of the management in order to align on the future of our team’s role. The meeting went great: we left the room with a common vision on what the data team will be taking care of, clarity on the most important priorities and a rough plan and what comes next.
|
||
|
||
If you are curious, you can check the slides we went through here: [20231214 Data Team Starting Presentation - Shared.pptx](https://guardhog.sharepoint.com/:p:/s/DataTeam/EVT1b3XYR6NJqur8QnWTsywBxbj9LeigursF4JiVmxUHpg?e=9Fo8Y7)
|
||
|
||
|
||
|
||
The Data Team busy at room M3.01 convincing colleagues on how to move forward.
|
||
|
||
## Documentation keeps on growing
|
||
|
||
This week we kept working on documenting important systems within Superhog. Our focus at this point is both on the Dashboard backend database (which we have unilaterally baptised as Core, for clarity’s sake) and Hubspot. We’ve chosen these two because:
|
||
|
||
- They are our largest, most used systems.
|
||
- Some reporting already exists on top of them which we need to maintain.
|
||
- Integrating certain bits of data across the two and making that accessible would be a great win for Superhog, since a lot of people regularly need insights that draw from both.
|
||
|
||
The documentation is still very much a WIP, but you can feel free to take a peek both here [in Notion](https://www.notion.so/Data-Sources-739e7af77fd0407ca51f2a1c33e2c526?pvs=21) and [in Confluence](https://guardhog.atlassian.net/wiki/spaces/Data/overview?homepageId=152731908).
|
||
|
||
## Drawing first bits of our future architecture
|
||
|
||
Making data clean, ready and accessible to everyone in Superhog will require us to build a few things that are lacking today. Some of you are probably already familiar with ideas like [Datawarehouses](https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-a-data-warehouse/), [ETL](https://learn.microsoft.com/en-us/azure/architecture/data-guide/relational-data/etl) and [ELT](https://learn.microsoft.com/en-us/azure/architecture/data-guide/relational-data/etl#extract-load-and-transform-elt) pipelines, [orchestration engines](https://blog.devgenius.io/modern-data-orchestration-stack-with-prefect-2-0-airbyte-and-dbt-e7c0e9b27add), etc. All these bits of infrastructure that we are currently missing will lead to our Data Architecture: basically, a fancy name for a bunch of computers and software running on it that will:
|
||
|
||
- Store data (and data about the data, which is called [Metadata](https://lakefs.io/blog/metadata-guide-for-data-engineers/))
|
||
- Clean, process and move data
|
||
- Make it available to you through reports, dashboards, etc.
|
||
|
||
Building this infrastructure will allow us to do all of this in a secure and efficient way. Without it, building a report is an Herculean task (which probably some of you are familiar with, since you are having to do it regularly *precisely* because these architecture is not yet in place. We will save you soon™).
|
||
|
||
We are in an early stage, so the work at this point is working together with the Engineering Team to design a Data Architecture that makes sense and will reasonably cover our needs during 2024. Once we have a plan… we will go and get dirty setting up the metal.
|
||
|
||
# 2023-12-07
|
||
|
||
## End of the first round of contacts
|
||
|
||
After a very intense first two weeks, we have met with most stakeholders in the company to better understand the current situation around data, systems, processes, etc.
|
||
|
||
We still have plenty to do, and we will most surely sit down and talk *many* more times soon. If we haven’t been in touch with you already, and you want to discuss any need or requirement around data, please, take the lead and [get in touch with us](https://www.notion.so/Data-Homepage-0ac0a2e52a8940c7ba4f31e5ffcc33e8?pvs=21).
|
||
|
||
## Preparing proposal
|
||
|
||
The next week we will sit down with the TMT team to present our vision and plans on how should the Data Team and its work look like. We hope to come out of it with a shared vision and some plans that will trickle down throughout other teams. We will share the presentation in our next update.
|
||
|
||
## Start of the Data Catalogue
|
||
|
||
The brand new [Superhog Data Catalogue](https://www.notion.so/Data-Catalogue-78d91434aa1442cbb6cc13b73c7fb664?pvs=21) has been born and you can find it right here, in Notion!
|
||
|
||
The Data Catalogue will act as an index to Data in Superhog. In it, we will place the full vision on the existing Data and Data Products within the company.
|
||
|
||
It’s going to be a company-wide effort to keep it updated: we will probably get in touch at some point to ask for your help filling details out, and you can always [get in touch](https://www.notion.so/Data-Homepage-0ac0a2e52a8940c7ba4f31e5ffcc33e8?pvs=21) first if you want to proactively add contents to the Catalogue. You can take a look at the existing entries to get a feel for what kind of information gets included in the Catalogue.
|
||
|
||
|
||
|
||
The Data Team, busy documenting the Data Catalogue.
|
||
|
||
# 2023-12-01
|
||
|
||
## Hello World
|
||
|
||
The Data Team just started out! The first member of the team, Pablo, joined Superhog last Monday.
|
||
|
||
There is a lot to untangle, discover, plan and execute, so it will take a bit until interesting stuff begins to appear here.
|
||
|
||
If you have suggestions/concerns/ideas/proposals/etc around data in Superhog and we didn’t get a chance to sit and talk yet, feel free to [get in touch](https://www.notion.so/Data-Homepage-0ac0a2e52a8940c7ba4f31e5ffcc33e8?pvs=21).
|
||
|
||
Have a nice weekend!
|
||
|
||
 |