When do you know when you're wasting time and money on data?
(and by the way: related revenue opportunities)
When the following symptoms appear:
'Nobody understands data.’
'We don't trust it.’
'We know we should be more data-driven but it's such a mess, so we don't use it'.
In other words, you’re deep into the 💩 Data Wheel of Death 💩 :
The easy - and useless - path to react is to change tooling, adding BI analysts or data engineers to your headcount.
It might be a great band-aid, but you're ignoring the root causes.
Here's a 3-step process to audit your approach.
It all boils down to an efficient tracking plan.
👀 What the heck makes a tracking plan great?
It is the output of your business goals (not the other way around).
→ If you don't know where to start, start with tracking your acquisition funnel, with a AARRR framework (Acquisition, Activation, Retention, Referral, Revenue).
It is consistent/structured in a way that makes it self-explanatory. Anyone in your organization should get it, including new joiners.
→ Test it with new joiners!
Maintaining the tracking plan is embedded in your team rituals.
There might be one overall owner (within the Growth or Data team), who’s a super coordinator. But it’s not enough:
-> A rule of thumb is:
You need 1 tracking plan for each codebase (front, back or mobile).
Each Product Manager (or your engineer in charge, if you don’t have PMs) should make sure new tracking needs are addressed at each release (e.g., if you release a new feature, you might want to track its usage), and existing tracking is maintained as well (because a new release can ‘break’ existing tracking).
It should be a reflex.
Bonus: here are tracking templates you can use:
1. Adopt a business mindset, not a data engineer mindset
Tracking can rapidly become overwhelming: should you track everything? Client-side or Server-side? With what tool?
I'll spare you the pain, think about your business goals and user journeys.
Example: Let's say you're a neobank and you want your users to order their payment card and make a 1st payment with it. That's how you defined activation.
Goal: Improve the activation rate of users
Intent: Orders a new card & makes first payment
Success: Card ordered → First payment made
Failure: Card not ordered OR Card ordered but no first payment
From this framework, you can define a set of events you can track to monitor your 'activation actions' (e.g., emailing campaigns, product tour, etc.). In this example, it can be:
Was the form to order a card filled?
Was it sent?
Was the card received?
Was the pin code of the card set?
Was a payment attempted (but failed for some reason)?
Was a payment successful?
⚠️ Stress test: once you have your list of events, imagine you had 10% or 80% of your users who performed a specific event, would you be able to take business actions on it? If not, tracking it is probably not that helpful.
2. Structure your tracking plan so that anyone can understand it
Short and sweet: use a naming convention and STICK TO IT.
What a waste of time when an analysis is put to waste because there are several events named 'Signed Up', 'signed_up', 'User_Signed_Up'.
If you don't know how to start, I recommend: 'environment_object_action', in snake case, as a convention.
When a form on the website is submitted:
→ Event name: website_contact_form_submitted
Feel free to add additional information, such as the 'environment' where this event comes from (mobile, front, back). But only if it serves a business goal (cf point 1). A tracking plan should always stay as lean as it can.
Two useful tracking templates you can use:
⚠️ Stress test: can anyone, especially new joiners, understand what the events in the tracking plan refer to?
3. Data tracking is a day-to-day team's sport
In the early days of your tracking efforts, a single person can own every task: defining the tracking plan with business owners and implementing tracking on your website/back-end/mobile app.
However, you'll soon have hundreds of events and realize each time your website or your app evolves, tracking should evolve too.
One efficient way to organize it is to have:
An overall owner of tracking who acts as a coordinator: usually someone on the Growth or BI team
One owner by codebase, either in the Tech or Product team: website, back-end, mobile
⚠️ Stress test: do your product specifications systematically include tracking needs/updates?
Want to go further?
Book a personalized 25-min ‘data for business’ coaching session with Lago team. What we usually help on: your tool stack, tracking plan, team organization, recruitment.
Join our invite-only community: comment this post, and I’ll follow-up!
What topics woud you like us to cover next Thursday?
Option 1: a framework to prioritize growth/revenue actions
Option 2: when, why, and how to hire a growth engineer?
Let us know in the comments!