61 lines
No EOL
6 KiB
Markdown
61 lines
No EOL
6 KiB
Markdown
# 2024-10-24 - Glad you’re back, Joaquin
|
||
|
||
Pablo and Uri hope you had an amazing holidays. Some things happened when you were not here, so here’s a summary!
|
||
|
||
# Domain Analysts programme has started
|
||
|
||
We had the first session with Jamie and Alex and explained a bit what we aim to achieve during this Q4 - as well as given them some SQL homework to do!
|
||
|
||
There’s a new slack channel named #analyst-guild in which we can discuss directly with them and you will find more relevant information in there. Check this [Notion page](https://www.notion.so/Q4-Training-and-Onboarding-Plan-1210446ff9c980cb9eb1c2e1895c0f46?pvs=21) to learn more.
|
||
|
||
# Athena claims analysis
|
||
|
||
Pablo did some not planned work yet very critical for Athena. Apparently, it was assumed that Athena was a good source of cash for us, but it seems the amount paid out for claims is huge. After further checks, it seems that the majority of critical claims come from just a few claimants, and thus a re-negotiation has been started by key people of the company. A very good example of why we need Data!
|
||
|
||
# E-deposit migration was a great success
|
||
|
||
After some weeks preparing the migration with API squad, now we have two independent flows to feed E-deposit vs. Athena. Everything went according to plan. This effectively means that the current status looks like this:
|
||
|
||
E-deposit:
|
||
|
||
|
||
|
||
Athena:
|
||
|
||
|
||
|
||
# Hubspot deal data is integrated and being used
|
||
|
||
We focused on integrating Deal data as soon as possible as we had some max priority needs for Account Managers reporting and Churn definition. Among the different Hubspot entities, we focused first on Deal. This data is already being used in KPIs and new models, as can be seen here:
|
||
|
||
|
||
|
||
We’ll discuss on what’s next for the remaining entities, but so far, this has proven to be enough and already very valuable, as you can see in following entries.
|
||
|
||
# Churn definition
|
||
|
||
A big subject has been to define Revenue, Listing and Booking Churn Rates. We did this exercise with Suzannah, Matt and Alex.
|
||
|
||
In short, we assume Revenue, Listing and Booking Churn to be coming from accounts that are churning. In other words, from Deals being in a Churning state (which can only be in 1 month before becoming Inactive).
|
||
|
||
First things first, we improved the logic for when we’re considering a Deal to be Churning. We keep either the already existing definition (i.e., a Deal is Churning if the last booking created was exactly 13 months ago) OR a Deal has offboarded in a given month. This offboarding information comes from Hubspot, from the cancellation date attribute. This is one of the changes that can be seen in the previous screenshot, in which int_mtd_deal_lifecycle now has a dependency with Hubspot deals. You might notice as well that this model is no longer in Core, but in Cross since it has both Hubspot and Core dependencies.
|
||
|
||
Second thing - we need to have a proper computation of Revenue. If you remember, before Revenue was deducting the amount that we were paying to hosts in terms of waivers. This is not the case anymore, meaning total revenue figures are closer to the Finance definition (and bigger than before). This has been already deployed for a couple of weeks.
|
||
|
||
Also we’ve created new contribution models that allow us to know the % of Revenue, Listings Booked in Month and Created Bookings each Deal has in a 12 month window. This is a bit more complex since we’re not doing an Additive approach but rather an Average one, because of business needs in the definition itself. It’s a bit complex so I encourage you to check the model implementation if you’re interested [here](https://guardhog.visualstudio.com/Data/_git/data-dwh-dbt-project?path=/models/intermediate/cross/int_monthly_12m_window_contribution_by_deal.sql). This “by deal monthly” computation is then used to compute the Main KPIs, meaning that now we have a strict dependency on Global KPIs depending on Monthly KPIs by Deal. With this we have a final model that computes the Churn contribution [here](https://guardhog.visualstudio.com/Data/_git/data-dwh-dbt-project?path=/models/intermediate/cross/int_monthly_churn_metrics.sql).
|
||
|
||
These 3 Churn Rates are already deployed since Tuesday 22nd and available in Main KPIs.
|
||
|
||
# Churn prevention → top losers → Account managers reporting
|
||
|
||
Another piece of work related to churn. In this case it’s not focusing on measuring churn, but rather, providing indicators for each account in terms of “growth” and “impact” so Account Managers and RevOps generally speaking can smartly dedicate effort towards where it’s really needed. This, if actioned by AM, should reduce Churn (thus why it’s churn prevention).
|
||
|
||
Long story short, we have a [new report here](https://app.powerbi.com/groups/me/apps/bb1a782f-cccc-4427-ab1a-efc207d49b62/reports/797e7838-3119-4d0e-ace5-2026ec7b8c0e/cabe954bba6d285c576f?experience=power-bi). Originally it was called top losers (because we categorised accounts as top losers, losers, winners, etc) but now has grown a bit in scope so it’s just Account Managers Overview. This report gathers all accounts by deal and each month evaluates the growth and the impact this growth has upon the overall business. Aaaaand with this we just categorise accounts in 5 groups. I’d recommend to check the readme since it’s quite detailed, or, if you prefer 423 lines of SQL code, you can check [the model here](https://guardhog.visualstudio.com/Data/_git/data-dwh-dbt-project?path=/models/intermediate/cross/int_monthly_growth_score_by_deal.sql).
|
||
|
||
Lastly, we’ve recently integrated some Hubspot information of each Deals so Account Managers and decision-makers have greater detail. For instance, we’re able to detect accounts that have not churned yet and still these are active, thus potentially actionable on AM side.
|
||
|
||
It’s extremely useful to explain increases in Churn Rates in specific months - I’ll let you check August 2024 peak and get your own conclusions 🙂
|
||
|
||
# General update
|
||
|
||
We’ll discuss talk about this in the first meeting |