There’s a mistake that quietly poisons your analytics before you ever open a chart, and almost nobody catches it until the numbers stop making sense. You set up tracking, you start logging what people do in your product, and months later you sit down to answer a simple question and you can’t, because the same action got recorded three different ways under three different names.
I run my own small businesses, and I’ve learned this one the hard way more than once. I’m not selling you an analytics platform. I’m the person who opened his own event data a year in and found a mess he had to spend a weekend untangling. So here’s the plain version, the way I’d explain it to a friend about to add tracking to their first product.
What a tracking plan actually is
A tracking plan is a written document that lists every event you record, what each one means, and the details you attach to it. That’s the whole idea. It isn’t a tool you buy, it’s a decision you write down.
At its simplest it’s a spreadsheet with a row for every action worth tracking: a clear name, a plain description of when it should fire, and the handful of properties that travel with it. Before you touch any code, you decide on paper what you’ll call things and what each thing means.
Why it matters more than it sounds
Analytics is only as trustworthy as the consistency underneath it. A chart is just a pile of events counted up. If the underlying events are named carelessly, the chart is confidently wrong, and confidently wrong is far more dangerous than obviously broken. When a number looks clean but rests on messy data, you make real decisions on it and never think to question the foundation.
The mess when you skip it
Without a plan, you name events on the fly while you’re busy building something else. One week a user finishing registration fires an event called signup complete. A month later, adding a new flow, you call the same idea account created. Later, on a rushed evening, it becomes reg done.
Now you have three names for one moment in a customer’s life, the counts are split across all three, and no single chart tells you how many people actually signed up. Worse, a funnel built on those split names shows people vanishing at a step they never reached, so you fix a problem that doesn’t exist while the real leak keeps running.
Names are the hardest part
The core of a good plan is a naming convention, and naming is genuinely hard, because there’s no single right answer, only a consistent one. Pick a pattern and never drift from it.
A pattern that works well is object then action: describe the thing, then what happened to it. account created, project deleted, invoice sent, subscription upgraded. It reads naturally, groups related events when you sort them, and scales, because someone new can almost guess an event name before looking it up.
Then pick a text style, lower case with spaces, or underscores, or run together, and hold it. Analytics tools treat two differently formatted names as two separate events, and you won’t notice until your counts are quietly split in half. Write the chosen style at the top of the plan in one sentence so there’s never a debate.
Properties are where the value hides
An event on its own tells you something happened. The properties attached to it tell you the story worth knowing. A property is a piece of context recorded alongside the event: the plan a user was on when they upgraded, the source that brought them in, the size of an order.
These let you slice a number later and actually learn something. With a source property on your signup event, you can see whether customers from one channel stick around longer than another, which is the difference between spending your next marketing dollar well or spending it blind. Name each property once, because plan in one event and plan type in another is the same split problem one level down.
A small example
Here’s a tiny plan so this stops being abstract. For a simple subscription app I might track six events to start:
| Event | Fires when | Key properties |
|---|---|---|
| account created | the account record is saved | source |
| trial started | a free trial begins | plan |
| project created | the user creates their first project | none |
| subscription started | a card is charged the first time | plan, amount |
| subscription cancelled | the user turns off renewal | plan, reason |
| support ticket opened | a ticket is created | topic |
Six clearly named events, each defined once, and already I can answer how many people signed up, activated, paid, and left. You add the seventh the day a real question needs it.
Keep it small on purpose
Track less than you think you need. It’s tempting to record every click on the theory that more data is better, but a plan bloated with hundreds of events nobody looks at is a plan nobody maintains. I’d rather have 20 events that map to real moments in the business than 200 that drown the signal. Every extra event is one more thing to implement, check, and get subtly wrong.
Write the description, not just the name
The column people skip is the one that saves you. Next to each event name, write one sentence saying exactly when it should fire. account created fires the moment the record is saved, not when the form opens and not when the welcome email sends. That sentence feels obvious the day you write it and becomes priceless the day you, a contractor, or your first hire has to decide whether to reuse an event or make a new one.
Treat it as your source of truth
Once it exists, the plan becomes the single source of truth for your data. Before anyone adds a new event, they check the plan. Does something like this exist already? If so, reuse the exact name. If not, add a row, with a description, before writing code. That one habit, check the plan first, is what stops the slow drift into chaos. A shared spreadsheet everyone treats as the authority works fine for a small operation.
Give it a light review each quarter: prune events that no longer fire, catch names that drifted, and add actions that became important. A plan that no longer describes reality is worse than none, because you trust it without checking.
The honest limits
A tracking plan doesn’t make your data correct by itself. Someone still has to implement each event faithfully and confirm it fires when the plan says. And it won’t tell you what to build or what a number means. It’s a foundation, not a strategy, the boring layer that makes everything built on top of it trustworthy.
If this made event tracking feel less like a chore and more like a habit you can keep, that’s the goal. Every one of these explainers lives in writing over here, the whole library in plain English, so you can read this again while you sketch your own plan.
Get new guides and videos first — join the Telegram channel.