Designing a Tracking Plan Before You Instrument Anything

Most analytics problems I get asked to fix are not analytics problems. They are planning problems that were postponed until they hardened into data problems. Someone dropped a tool into the product, fired a few dozen events, and six months later nobody can answer a simple question because “signed up” means three different things depending on which engineer wrote which event on which sprint. The dashboard says one number, the database says another, and the growth team has quietly stopped trusting either.

This is the single most expensive mistake I see teams make with measurement, and it is entirely avoidable. The fix is not a better tool. No tool rescues you from bad instrumentation, because the tool only records what you told it to record, in the shape you told it to record it. If you instrument before you plan, you get a swamp: inconsistent event names, half-populated properties, duplicate fires, and definitions that live only in the head of whoever wrote the code. You cannot clean that up retroactively. The events already fired. The history is already wrong.

So the tracking plan comes first. Before GA4, before PostHog, before you touch a single SDK, you write down exactly what you are going to track, what each event means, when it fires, and why it exists. That document is the actual foundation of your analytics. This post is the “do this first” post of the whole measurement cluster, because everything else I write about, dashboards, product analytics, experimentation, depends on the data underneath being trustworthy. And trustworthy data starts here.

What a tracking plan actually is

A tracking plan is a documented, shared specification of everything you track. Not a vague list of “things that would be nice to know.” A precise spec: the events you fire, the properties attached to each one, the exact moment each event triggers, and the reason it exists. It is the contract between the people who ask questions of the data and the people who write the code that produces it.

Concretely, for every event, the plan should answer a small set of questions. What is the event called, written in your naming convention exactly as it will appear in code? When does it fire, described precisely enough that an engineer can implement it and a data analyst can trust it? What properties does it carry, with their types and allowed values? And, the question people skip most often, what decision or metric does this event support? If you cannot name the question this event answers, the event should not exist yet.

The plan is not code and it is not a tool configuration. It sits above both. Engineers implement against it. Analysts query against it. Growth reads it to understand what is measurable. When it is done well, a new person can open the plan and understand your product’s entire measurement surface in an afternoon, without reading a line of the codebase or reverse-engineering a dashboard. That is the standard to aim for.

Start from the decisions, not the events

The instinct when you sit down to plan tracking is to list features and imagine every interaction you could capture. Resist that completely. You do not start from the product surface. You start from the decisions you need to make and the metrics that inform them, then work backward to the smallest set of events that answer those questions.

Begin at the top. What is your north-star metric? That single number is the anchor, and it decomposes into inputs. If your north-star is weekly active teams doing meaningful work, the inputs might be new teams created, teams reaching their first meaningful action, and teams returning week over week. Each of those inputs is a question, and each question implies a small number of events you must capture to answer it.

Then walk the important stages of the product. What does activation look like, the moment a new user first gets real value? What are the steps of your core funnel from arrival to that activation moment? What signals tell you a user is retained versus churning? Every one of these is a measurement need, and you translate each need into the minimum events required to satisfy it. The output of this exercise is a short, deliberate list. It is far shorter than the list you would have produced by staring at the UI, and every event on it earns its place by answering a real question.

Track with purpose, not just in case

The most common failure mode after “no plan at all” is the plan that tracks everything. It usually comes from a good intention: we do not know what we will need later, so let us capture it all now and figure it out afterward. This feels prudent. It is the opposite.

Every event you add is a liability, not just an asset. It is code that has to be written, maintained, and kept correct as the product changes. It is a row in the plan someone has to understand. It is a property that can drift or break silently. When you track everything, you do not get a rich dataset you can mine later. You get noise that buries the signal, a plan nobody can hold in their head, and a false sense that because the event exists it must be trustworthy. “Track it just in case” produces hundreds of events, most of which fire into a void that no one ever queries, while the handful of events that actually matter get lost in the pile.

The discipline is simple to state and hard to hold: every event maps to a question someone will actually ask. If you cannot name the question, you do not add the event. This does not mean you never expand the plan. It means expansion is deliberate. When a new question arrives, you add the events that answer it, on purpose, with the same rigor as the original set. A lean plan where every event is trusted beats a sprawling one where nothing is, every single time.

Naming conventions are the whole game

If I could enforce one rule across every team I work with, it would be a naming convention, applied without exception. Consistency in how you name events and properties is not a nice-to-have detail of tracking plan design. It is most of what makes the data usable at all. Inconsistent names are the single biggest source of the “numbers nobody trusts” problem, because they fragment the same real behavior across multiple event names that no query will ever reconcile.

Pick a pattern and hold it everywhere. I favor an object-action structure: the thing, then what happened to it. Project Created, Project Deleted, Invite Sent, Invite Accepted, Subscription Started. It reads naturally, it groups related events together when sorted, and it scales because new events slot obviously into the existing shape. Whatever pattern you choose matters less than choosing one and never deviating.

Casing is part of this, and it is where consistency quietly dies. Decide once whether events are Title Case, snake_case, or something else, and whether properties are camelCase or snake_case, and write it in the plan as a rule. If half your events are signup_completed and the other half are Signup Completed, your tool treats them as two different events forever, and no amount of downstream cleanup fully undoes it. Standardize your property names too: if a plan uses plan_type in one place and subscription_tier in another for the same concept, every analysis that touches billing becomes an archaeology project. The taxonomy, the vocabulary of objects, actions, and properties you allow, is a real asset. Write it down and defend it.

Define events precisely enough to be unambiguous

A name is not a definition. “Signed Up” tells you almost nothing. Signed up when the user submits the form, or when the account is created server-side, or when they verify their email? Each of those fires at a different moment and produces a different number, and if the definition is not written down, different people will implement and interpret it differently. That is exactly how you end up with three conflicting signup numbers.

So the plan defines each event with enough precision that there is no room for interpretation. “Signed Up fires once, server-side, when a new account record is successfully created, after email verification succeeds.” That sentence eliminates a whole category of future arguments. Do the same for your fuzzy, high-stakes events. What exactly counts as activated? Not “when the user seems engaged,” but a specific, observable condition: created their first project and invited at least one teammate within the first session, for instance. What counts as a completed purchase, a churned account, a returning user? These definitions are where trust is built or lost.

Precision here pays off far downstream. When the activation definition is written and shared, the growth team, the data team, and engineering are all counting the same thing. When it is vague, everyone counts something slightly different and every meeting includes ten minutes of reconciling why the numbers disagree. Write the definitions once, precisely, and reclaim that time permanently.

Identity and user properties

Events describe what happened. Identity describes who it happened to, and getting it right is what lets you connect anonymous browsing to a known user, stitch a person’s actions across devices, and roll individual behavior up to the account or team level. The tracking plan has to handle this deliberately, not leave it to whatever the SDK does by default.

Decide how you identify users and when. What is the identifier before someone logs in, and how does the anonymous history connect to the identified user once they authenticate? If you get this wrong, you either lose the pre-signup behavior that matters enormously for understanding acquisition, or you fail to merge it and count one person as two. For any B2B product, you also need a group or account concept, because the questions you care about are usually about teams and companies, not just individuals.

Then define your user and account properties with the same rigor as events. Plan, signup date, role, company size, acquisition source: these are the dimensions you will slice every metric by, so they need consistent names, clear definitions, and a known moment they get set or updated. A tracking plan that nails events but treats identity as an afterthought still leaves you unable to answer the questions that matter most, the ones about who does what and how different kinds of users behave.

Ownership and governance keep it from drifting

A tracking plan written once and then abandoned decays into fiction within a couple of release cycles. The product changes, engineers ship new events under deadline pressure, and if nobody owns the plan, those events get named however felt natural at 5pm on a Friday. Within months the plan describes a product that no longer exists and the real tracking is an undocumented mess again. You are back where you started, having done the work once.

So the plan needs an owner. One person, usually in growth or data, is accountable for keeping it correct and coherent. That does not mean they write every event. It means they own the standard and the process. The critical piece of that process is a review step: no new event ships without being added to the plan and checked against the conventions first. This is a small gate, a few minutes of review, and it is the difference between a plan that stays true and one that rots. It catches naming drift before it enters the data, questions events that do not map to a real need, and keeps the taxonomy coherent as the product grows.

Governance sounds heavy but it is mostly this one habit: planning is part of shipping a tracked feature, not an afterthought, and someone signs off. Teams resist it because it feels like bureaucracy until the first time it saves them from a month of corrupted funnel data. After that, nobody wants to go back.

Validate the tracking, because bad data is worse than none

Here is a hard truth that took me a while to fully internalize: bad data is worse than no data. No data makes you cautious and forces you to go find out. Bad data makes you confident and wrong. It sends you charging in the wrong direction with a dashboard backing you up. So validation is not an optional final polish on tracking plan design. It is part of the job.

When events are implemented, verify them against the plan before you rely on them. Does each event actually fire, and fire at the moment the definition says it should? Does it fire exactly once, or is a re-render or a retry firing it two or three times and silently inflating every count? Are the properties present, correctly named, and correctly typed, or is half the payload null? These are not exotic bugs. They are the normal state of freshly written tracking, and they are easy to catch if you look and invisible if you do not.

Build a habit of QA on instrumentation the same way you QA a feature. Fire the events in a staging environment, inspect the payloads, confirm they match the spec. Do it again whenever the product changes around an event, because a refactor two floors away can quietly break a fire condition. This is unglamorous work and it is the work that makes every number downstream believable. A validated plan is what turns your data from something people argue about into something people act on.

The plan as a living single source of truth

Once the plan exists, is owned, and is validated, it becomes the single source of truth that product, growth, data, and engineering all share. That shared reference is the real payoff. Product knows what is measurable when scoping a feature. Growth knows what questions the data can answer. Data knows what every event means without asking. Engineering knows exactly what to implement. One document, one vocabulary, no translation layer between teams.

It has to stay living. The plan is not a document you finish; it is one you maintain, updated as part of shipping every tracked change, versioned so you can see when definitions shifted and why. When someone asks “what does this event mean,” the answer is always “read the plan,” and the plan is always current because the review step keeps it current.

On tooling, do not overthink it. A well-maintained spreadsheet is a genuinely good tracking plan and I have run serious measurement on exactly that. Columns for event name, definition, trigger, properties with types, and the owning question get you most of the value. There are dedicated tools that add schema enforcement, validation against live data, and tighter integration with your stack, and those earn their keep as you scale and the plan grows past what a spreadsheet comfortably holds. But the tool is not the point. The discipline is the point. A spreadsheet everyone trusts beats an expensive platform nobody maintains.

Why this makes everything downstream trustworthy

Everything I write about measurement sits on top of the tracking plan, and this is why I insist it comes first. When the plan is right, your dashboards actually drive action instead of provoking arguments about whether the numbers are real, because the numbers feeding them are defined, consistent, and validated. Your product analytics in PostHog surface genuine behavioral patterns rather than artifacts of inconsistent naming, because the events are clean and mean what they say. Your funnels and cohorts in GA4 built for growth hold together because the events fire when they should and carry the properties you need to slice them.

And experimentation, the highest-stakes use of your data, only works if the underlying events are trustworthy. An A/B test is a comparison of metrics between groups, and if the metric is built on ambiguous or broken events, the test result is noise dressed up as a decision. Every one of these downstream capabilities inherits the quality of the tracking plan. Get the plan right and they all become reliable. Skip it and no amount of sophistication in the tools above rescues you, because they are all reading from the same polluted well.

That is the whole argument. The tracking plan is not paperwork you do before the real work. It is the real work. It is the cheapest, highest-return hour you will spend on analytics, and it is the one teams are most tempted to skip.

The short version

• Instrumentation without a plan produces inconsistent, untrustworthy data that no tool can fix later, because the history is already wrong. The tracking plan comes before GA4, PostHog, or any SDK.
• A tracking plan is a documented, shared spec of exactly what you track: events, properties, when each fires, and the question it answers.
• Start from the decisions and metrics you need, north-star, activation, funnel, retention, then work backward to the minimum events that answer them. Do not track everything.
• Every event maps to a real question. If you cannot name the question, do not add the event. “Track it just in case” is bloat that buries the signal.
• A consistent naming convention and taxonomy, object-action names, standard property names, one casing rule, is most of what makes data usable.
• Define events precisely so “signed up” and “activated” mean one unambiguous thing everyone counts the same way. Handle identity and user properties deliberately.
• Give the plan an owner and a review step before new events ship, or it drifts into fiction within a couple of release cycles.
• Validate that events fire correctly, once, with the right properties. Bad data is worse than no data because it makes you confident and wrong.
• Keep the plan a living single source of truth shared across product, growth, data, and engineering. A trusted spreadsheet beats an unmaintained platform.

---

I am Deepanshu Grover, a Growth Product Manager in Paris. If your analytics are a mess of inconsistent events nobody trusts, connect on LinkedIn or get in touch.