Instrumenting Your Business: A Practical Tracking Plan
On this page
Analytics & Data
A tracking plan is a specification that names the events a business will capture, the properties each event carries, and the one canonical name and definition for each, written before any tracking code ships, in the context of small and mid-sized businesses capturing data they can actually answer questions with. It is a spreadsheet and a one-page spec, not a tool and not a guess. It is the artifact that turns "we should track that" into a finite, named, hand-off-able list an implementer can wire without inventing anything.
The owner of a forty-person online supplier wanted one number in a Tuesday meeting: of the people who started a checkout last month, how many finished. It is not an exotic question. It is the question that decides whether the checkout is the problem or the traffic is. The answer did not exist. Not "the answer was bad". It did not exist, because over two years three different people had instrumented the checkout three different ways. One had fired an event called Checkout Started. Another, hired later, had used begin_checkout because that was the name the ad platform suggested. A third had added checkout with no properties at all when a new payment page shipped. The completion side was worse: Order Complete, purchase, and a server log nobody had connected to any of it. To answer "started, then finished" you have to match a start to a finish for the same person, and nothing in that pile agreed on what a start was, what a finish was, or how to tell they belonged together. The owner made the call that meeting on instinct, redesigned the payment page, and found out a quarter later the page had never been the problem. The data to know that had been collected the whole time. It had just been collected as three unrelated piles that could not be added together, because nobody had ever written down, once, what a checkout-start event was called and what it carried.
That is the failure this guide exists to prevent: a question that cannot be answered, not because the data was never collected, but because it was collected with no plan, under names that do not reconcile. By the end you will be able to say in one sentence what a tracking plan is and why it is written before any tag fires, name the events your business needs and the properties each must carry, write a naming convention and one canonical definition per event so the same thing is never captured four ways, produce a capture spec a non-engineer can hand to whoever implements it, and leave with the first event to define.
What a tracking plan is
A tracking plan is a finite list, decided once, of every event the business will capture, what each event means, what properties it carries, and the single name it is known by everywhere. It is tool-agnostic on purpose. The same plan implemented in any analytics tool produces the same answers, because the plan, not the tool, is what fixes the names. Strip the plan away and what you have is whatever names whoever happened to be holding the keyboard chose on the day, which is exactly the pile the supplier could not add up.
The plan answers three questions for every single thing you will ever capture, before a line of tracking code exists. What happened, named once: the event. What was true about it, named once each: the properties. What this event means, in one sentence, so two people never disagree about whether a given moment counts as that event: the definition. Those three, written down, are the whole artifact. Everything later in this guide is how to fill them in.
Events, properties, and a naming convention, written before any tag fires
An event is a thing that happened that you care about: a checkout started, a quote requested, a subscription canceled. A property is an attribute of that specific occurrence: which plan, what amount, which traffic source, which location. A naming convention is the rule that decides, in advance, what every event and property is called, so the answer is never "whatever the person typed". Decide all three on paper. The order matters: events first, because they come from the decisions you need to make; properties next, because they are the cuts you will need to slice those events by; the convention last, applied across the whole list at once so it is actually consistent.
The reason it has to be before any tag fires is mechanical, not stylistic. Once a tag is live and sending data, its name is load-bearing: reports, dashboards, and saved queries point at that exact string. Rename it later and you either break everything pointing at the old name or you carry both forever. The supplier was carrying Checkout Started, begin_checkout, and checkout forever, because each had some history behind it nobody dared delete. A plan written first means there is one name from the first tag, and nothing to reconcile later because nothing ever diverged.
An example: the unanswerable question and the four-spelling mess
Hold the supplier's checkout in front of you, because it is the entire lesson in one object. The question was "started, then finished, last month, what fraction". To answer it you need exactly two events that agree with each other: one that means a person began checkout, one that means a person completed an order, both carrying enough to tie a start to a finish for the same person and the same attempt.
What existed instead was three start-shaped things and three finish-shaped things, none designed to be matched. Checkout Started carried a cart value but no order identifier. begin_checkout carried an item count but used a different anonymous id scheme. checkout carried nothing. On the finish side, Order Complete had an order id, purchase had a revenue figure and a different id, and the server log had the truth but no link to any front-end event. There was no single property that appeared on a start and its matching finish, because no one had ever decided there should be. The question was not hard. The answer did not exist, because the event behind it had three spellings, the matching key had none, and no one had ever agreed, on paper, which one counted.
Ad-hoc tagging is why your data cannot answer the question
Capture-as-you-go is the default and it is the failure mode. The pattern is always the same: a question comes up, someone adds a tag to answer it, the tag works that one time, and it accretes into a pile of one-off tags that each made sense alone and add up to nothing. Nobody decided to build an unanswerable mess. It built itself, one reasonable-at-the-time tag at a time, because there was no plan saying what the names were before the names were needed.
The cost is invisible until the exact moment it is catastrophic, which is the moment a decision needs a number. Up to that moment, every individual tag looks fine. It fires, it shows up, the person who added it got their one answer. The bill comes due when someone asks a question that requires two of those tags to agree, and they do not, and the answer that should be a five-minute query becomes a forensic reconstruction or an instinct call. The supplier paid the full bill in one meeting: a quarter of work redesigning a payment page that was never the problem, because the number that would have said so could not be assembled.
What capture-as-you-go actually costs when the question finally gets asked
The cost is not the missing tag. It is the unmatchable pile. A missing event you can add and start collecting from today. An event collected three inconsistent ways for two years you cannot retroactively reconcile, because the history is the history: you cannot go back and re-fire begin_checkout as Checkout Started with the property it never carried. The data that exists is the data that exists, in the shape it was captured in, and no plan written afterward repairs the past. This is why the plan is worth writing before, and only marginally worth writing after: written first, it prevents the pile; written after, it can only stop the pile from growing, not undo it.
A question comes up Tuesday. Someone adds a tag named whatever felt right that day. It answers Tuesday's question and goes quiet. Six months later a different person, solving a different question, adds a near-duplicate tag under a different name because they did not know the first one existed and there was no list to check. Two years in, one real-world action has three or four event names, the matching keys do not line up, and the first question that needs two of them to agree cannot be answered at all. The data was collected. It cannot be added together. The cost lands as a blind decision and the rework when the blind decision was wrong.
Before any tag exists, the events are listed, named once, defined once, and the properties needed to tie them together are decided. The first tag ships with the canonical name and the matching key. Every later tag is checked against the list, so a near-duplicate is caught as "that is the existing event, use this name". Two years in, one action has one event name, one definition, and the same key on both ends, so "started, then finished" is a query, not a reconstruction. The cost of writing the plan is one focused day. The cost of not writing it is paid forever, in decisions made blind.
Why the plan precedes the tool, not the other way around
Most teams pick the analytics tool first and treat the plan as something the tool will sort out. It will not. The tool stores and queries whatever names it is sent; it has no opinion about whether Checkout Started and begin_checkout are the same thing, because to it they are two different strings. The plan is what makes them one thing, and the plan is the same regardless of which tool eventually holds the data. Choosing the tool is a real decision with its own tradeoffs, and it belongs to the minimum data stack for a business with no data team; it is downstream of the plan, not a substitute for it. Write the plan tool-agnostic, then implement it in whatever tool that guide leads you to. A plan with no tool is still a plan. A tool with no plan is the supplier's pile with better charts.
How to write the tracking plan, step by step
This is the procedure. It is five steps, each executable in a spreadsheet and a one-page document, with no software a business does not already have. It does not decide what to measure: that is the measurement plan, and this procedure consumes it rather than re-deriving it. It does not pick the tool and it does not clean up old data. It produces one artifact: a finite, named, defined, hand-off-able capture spec, plus the check that confirms the data arrives the way the spec says.
- →Derive the events from the measurement plan
Open the one-page measurement plan for the business. It already states which decisions the business makes and which numbers those decisions need. Do not re-derive that here. Read each metric on it and ask one question: what raw thing has to be recorded for this number to be computable. "Checkout completion rate" needs a checkout-start event and an order-complete event. "Quote-to-job conversion" needs a quote-requested event and a job-won event. List the events that fall out, one per metric, and stop. The measurement plan is the input; the events are what it implies. If a metric implies no capturable event, the gap is in the measurement plan, not here, and it goes back to that guide.
- →Define the properties and the naming convention
For each event, write the properties it must carry to answer the questions the metric demands. A checkout-start event that will be sliced by traffic source and plan needs a
sourceproperty and aplanproperty. Critically, write the property that ties related events together: if you will ever ask "this start, did it finish", both events need the same key, anorder_idor equivalent, present on both ends. Then fix the naming convention across the whole list at once: pick a case (for examplelower_snake_casefor both events and properties), pick a tense for events (past tense:checkout_started,order_completed,quote_requested), and write the rule down at the top of the sheet. Apply it to every row in one pass so it is actually uniform, not uniform-ish. - →Write one canonical definition per event
Next to every event, write one sentence stating exactly when it fires and when it does not, precise enough that two different people reading it would tag the same moment. "
checkout_startedfires once when the customer reaches the payment step with a non-empty cart, not on cart view, not on retries of the same attempt." Ambiguity here is the four-spelling mess in slow motion: if the definition is loose, two implementers will reasonably fire it at different moments and the event will mean two things under one name, which is worse than two names. One event, one sentence, one moment. - →Turn it into a capture spec a non-engineer can hand off
Collapse the sheet into a one-page spec an implementer can wire with zero questions back to you. For each event: the canonical name, the one-sentence definition (when it fires, when it does not), the full property list with the type and an example value for each, and which property is the key that links it to its paired events. That is the whole hand-off. It is deliberately implementation-free: it does not say which tool or which code, only what must arrive and what it must be called. The owner does not write tracking code and does not need to. They write this page and hand it to whoever does.
- →Run a verification pass that confirms the data arrives as specified
After the implementer wires it, do not assume it is right because it shipped. Trigger each event yourself in the real product: start a checkout, complete an order, request a quote. For each one, confirm three things against the spec: the event arrived under the exact canonical name, every required property is present and non-empty, and the linking key matches across the paired events for the same attempt. An event that arrives as
checkout_startinstead ofcheckout_started, or with an emptysource, or with anorder_idthat does not match the order-complete it should pair with, has failed the spec and goes back before it is ever used in a report. The plan is not done when the tags fire. It is done when the data arrives the way the page says.
A note on doing this faster without doing it sloppily. Deriving a candidate event-and-property list from a written measurement plan is a structured transformation, and Claude models via the Claude API are well suited to producing a first-draft event list and property set from the measurement plan's decisions, which you then tighten by hand against the definitions rule in Step 3. For generating the one-page hand-off spec and running the Step 5 verification against captured data, Claude Code works as the agentic tool: it can draft the spec document from the sheet and check arriving events against the canonical names and required properties. Other assistants can do parts of this; lead with Claude because it is the one being specified here, and treat any generated list as a draft to verify, never as the plan itself. The verification pass is not optional just because a tool produced the draft.
The most expensive mistake in this procedure is a loose definition in Step 3. A misspelled event name fails verification loudly and gets fixed. An event with a vague definition passes verification, because it does arrive, and then quietly means two different things because two implementers fired it at two different moments. One sentence per event, precise enough that two strangers tag the same instant, is the part to be strict about.
A tracking plan versus the things it gets confused with
Four distinctions decide whether the plan is the right artifact at all. Each is a different thing with a different owner, and conflating any of them is how teams end up doing the wrong work or none.
A tracking plan vs a measurement plan
The measurement plan decides what to measure and why: which decisions the business makes, which numbers inform them, what each number's target is. The tracking plan decides what to capture and how to name it so those numbers are computable. They are sequential, not interchangeable: the measurement plan is the input, the tracking plan is the implementation of capture for it. Deciding which metrics matter is owned by the one-page measurement plan, and this guide does not re-derive that. If you do not know what to measure yet, you are not ready to write a tracking plan; you are ready to read that guide first. The tracking plan starts where the measurement plan ends.
An event vs a property
An event is the thing that happened. A property is an attribute of that thing. order_completed is an event. The amount, the plan, the source are properties of that event. Conflating these is half of every instrumentation mess: people make order_completed_pro and order_completed_free two events when it should be one event, order_completed, with a plan property whose value is pro or free. The test is whether you would ever want to count them together. If "total orders" is a number you need, plan is a property, not part of the event name. Bake an attribute into the event name and you have permanently split a number you will later want whole.
A tracking plan vs the analytics tool
The plan is tool-agnostic. The tool is where the plan gets implemented. The same plan in any tool yields the same answers, because the plan fixes the names and the tool just stores them. The choice of tool, what it costs, what it can and cannot do for a team with no analyst, is a real decision owned by the minimum data stack for a business with no data team. This guide stops at the spec. It does not pick the tool, and it deliberately writes the plan so that the tool choice can change later without the plan changing. Plan first, tool second, in that order, every time.
Capture vs cleanup
Capturing right is deciding the names and definitions before the data exists so it arrives clean. Cleanup is fixing data that was already captured wrong, plus keeping captured data from rotting over time as the business changes. They are different jobs at different moments. This guide is entirely the first one. The second one, keeping the captured data trustworthy after it lands, is owned by data hygiene for a small team, and a good tracking plan is precisely what makes that job small instead of endless. Capture-once is prevention. Hygiene is maintenance. You want most of the work to be prevention, because the supplier's pile is what maintenance looks like when prevention was skipped.
What instrumenting once and right changes
How a capture-once plan turns unanswerable questions into answerable ones
The supplier's question, "started, then finished, last month", is a one-line query the moment two events agree on what a start is, what a finish is, and share a key. Nothing exotic makes it answerable. The plan does, by having decided, before any tag, that there is one checkout_started, one order_completed, and an order_id on both. Every future question of the shape "did this thing lead to that thing" falls out of the same property: if the events that bracket the question were planned to share a key, the question is answerable; if they were captured as you went, it is a reconstruction. The plan is not paperwork. It is the difference between a query and an instinct call in the meeting where it matters.
How the plan becomes the input to hygiene
A planned capture is the thing hygiene maintains. There is no version of keeping data clean that works on top of a pile with no canonical names, because there is nothing to keep clean against: a hygiene rule like "every order_completed must have a non-empty amount" requires that order_completed is one defined event with a known property list, which is exactly what the plan produces and exactly what the supplier did not have. The plan feeds hygiene, and hygiene depends on the plan; that seam is owned by data hygiene for a small team. Wiring the instrumentation correctly and keeping it correct as the business changes is sustained engineering work, not a one-time setup, and most SMBs of ten to two hundred people do not have anyone whose job it is. When the work outgrows what the owner can hand to a generalist, the engineering work of wiring and maintaining instrumentation is where it gets done as ongoing engineering rather than left to accrete into the next pile. The plan is what makes that work boundable in the first place.
How it depends on a place to land
The plan needs somewhere to send the events. A spec with no implementation answers nothing; the data has to actually land in a tool that stores and queries it. That choice, the minimum viable stack for a team with no analyst, is a deliberate decision with real tradeoffs and is owned by the minimum data stack for a business with no data team. The dependency runs one way and only one way: the plan is written first and tool-agnostic, the stack is chosen second, and the stack implements the plan. Reverse that order and the tool's defaults pick your event names for you, which is how begin_checkout got into the supplier's pile in the first place.
The instrumented business decides on data it can actually trust
Capturing data an SMB can answer its own questions with is one discipline with three artifacts in order: decide what to measure, decide what to capture and how to name it, keep what you captured clean. The tracking plan is the middle one and the one that decides the other two, because the first is wasted if the capture is unplanned and the third is impossible if the names never agreed. This matters more, not less, as more decisions lean on AI: a model asked to act on your business data inherits whatever the capture was, and a model reasoning over Checkout Started, begin_checkout, and checkout as if they were one thing produces confident answers to a question the data never actually supported. Clean, planned capture is the floor under every later use of the data, automated or not.
Do one concrete thing this week. Open your measurement plan, take the single metric the business argues about most, and write the one event that metric most depends on: its canonical name, the one sentence stating exactly when it fires and when it does not, and the one property that ties it to whatever it pairs with. One event, fully specified, on paper. That is the first row of the plan, and the row that proves the rest is an afternoon, not a project. The supplier's whole quarter of blind rework was the price of that one row never being written. Write it before the next meeting where a question hits the wall.
