Every Analytics Event Needs a Job
A practical guide to measuring less, learning more, and keeping product analytics useful.
The Learning Never Began
Most companies I have worked for eventually reached the same moment: one day, somebody decided we needed analytics.
What did we want to learn? Which metric did we want to improve? Nobody really knew. But they knew what they wanted us to track: everything.
On one screen, we added more than thirty events. Every button click. Every map zoom. Every map unzoom.
We shipped a giant stream of data. As far as I know, not one actionable decision ever came from it.
The analytics implementation was finished. The learning never began.
The mistake was treating analytics as a feature we could finish. Add the SDK, name the events, ship the code: done.
An event only records that something happened. A user clicked a button. A map changed zoom level. Without a question behind it, the event is just another line in a database.
Product analytics becomes useful when it can change what you do next.
One result might convince you to improve a feature. Another might tell you to make it easier to discover, or to stop investing in it.
If every possible result leads to the same action—or to no action at all—the event has no job.
Run the session to compare both plans.
Give Every Event a Job
Before naming an event, I would ask the team to write down five things:
- Goal: What part of the product or business are we trying to improve?
- Question: What do we need to learn to make progress?
- Metric: What number would help answer that question?
- Action: What might we do differently depending on the result?
- Events: What is the minimum data required to calculate that metric?
The order matters. An event records one action. A metric turns many of those records into an answer.
Events come last because you cannot know what data you need until you know what you are trying to learn.
The rule: If you cannot fill in the first four lines, stop. Adding events will not produce the missing clarity.
Measure Value, Not Clicks
I am building Fond, a cooking app. If I had to choose the permanent analytics we need today, I would start with five events:
- A user signed up.
- A user imported a recipe, including where it came from.
- A user cooked a recipe.
- A user created a meal plan.
- A user generated a grocery list from that plan.
Signup gives us a starting population. The other four events represent things people came to Fond to accomplish.
They tell us far more than whether somebody opened a tab, zoomed an image, or clicked a particular button.
With this small set, we can already ask useful questions.
How many people do something meaningful after signing up? Which recipe sources matter? Do people stop after organizing recipes, or do they cook them? How many meal planners continue to a grocery list?
Five events can produce many metrics when they describe value instead of interface activity.
It would be tempting to arrange them into one funnel: sign up, import a recipe, cook it, create a meal plan, generate a grocery list.
We could then call everyone who reaches the end successful and everyone else unfinished. But that is not necessarily how people use Fond.
Someone may only want to organize recipes. Someone else may care mostly about meal planning. Another person may use the entire workflow. Each of them can receive real value from the product.
Instead of forcing everyone into one ideal journey, we can group people by the behaviours they share. These groups are cohorts.
Fond might have recipe organizers, active cooks, meal planners, grocery-list users, and people who combine several workflows.
The point is not to push every user toward the same destination. It is to understand the different reasons they return.
Recipe organizers
Imports and sorts recipes, without planning every week.
- Home priority
- Recipe collection
- Gentle suggestion
- Try meal planning
Once we understand those reasons, the product can respond to them.
For someone who mainly organizes recipes, Fond could prioritize their collection and keep meal planning as an occasional, discreet suggestion.
For someone who already plans meals, it could make that workflow prominent and encourage them to try instant meal planning.
Messages can follow the same principle. We can speak to the part of Fond a person already finds useful, then introduce an adjacent feature when it becomes relevant.
A cohort only matters if it changes what you do. Otherwise, it is another chart that changes nothing.
A Metric Is a Question, Not a Verdict
Analytics can reveal when our assumptions about the product do not match reality.
Take instant meal planning. We believe it is extremely valuable—the kind of feature almost anybody planning meals would want.
If very few people used it, I would not immediately conclude that nobody wants it. I would conclude that something needs investigating.
Maybe people cannot find it. Maybe its purpose is unclear. Maybe they try it and the result disappoints them. Maybe another part of the workflow prevents them from reaching it.
The data tells us what happened: usage is low. It does not tell us why.
A surprising metric is not a verdict. It is a good question.
Temporary Analytics Should Be Temporary
That question can justify more detailed instrumentation for a while.
We might break instant meal planning into stages. Did people see it? Did they try it? Did it generate a result?
Did they keep or heavily modify that result? Did they generate a grocery list from it? Did they return and use it again?
These diagnostic events have one job: locate where the experience breaks down.
They differ from Fond’s five permanent events, which describe durable ways people receive value from the product.
Every diagnostic event needs an owner, the question it supports, and a date or condition for reviewing it.
Once the question has been answered, any event that no longer serves a purpose should be removed.
Temporary analytics should be temporary in the code too.
When those events are never removed, the original thirty-event screen is how the story ends.
The product changes, but its old instrumentation survives. Similar actions receive different names. Dashboards mix current behaviour with abandoned experiments.
At a large enough scale, sending all that useless data creates a real financial cost.
The larger cost is confidence.
Nobody remembers why half the events exist, which ones are reliable, or what the charts were supposed to prove.
Finding an answer takes longer than a small team can justify, so people stop looking.
This is analytics debt. The more data a team collects without maintaining its meaning, the less useful the entire system becomes.
Eventually, analytics feels like a mess best avoided—the opposite of the clarity it was meant to provide.
Start With a Document
The next time somebody says, “Let’s add analytics,” do not begin with the SDK. Open a document.
Write down the goal, the question, the metric, and the decision that could change. Then choose the smallest set of events capable of supporting them.
Keep the events that describe lasting product value. Give diagnostic events an expiry condition, and remove them when their work is done.
A good analytics system is not the most complete record of everything users have ever touched.
It is a small body of data that the team understands, trusts, and actually uses.
We do not need to know everything our users do. We need to know enough to decide what to do next.