Write the tracking plan while you write the PRD, not after the feature ships. Define event names, triggers, properties, and owners as a living section of the spec, so engineering hands off code and instrumentation together — and no one discovers three sprints later that the feature launched unmeasurable.
Treat the tracking plan as a design deliverable that lives inside the PRD — a table of events, triggers, properties, and owners — and gate engineering hand-off on it being filled in, the same way you'd gate on wireframes or an API contract.
Why Instrumentation Written After Ship Always Gets Rewritten
Instrumentation added after launch gets rewritten because it's built to explain a UI that already exists, using whatever properties happen to be sitting in scope in the code. It optimizes for what's easy to grab today, not the questions the roadmap will actually ask next quarter.
Here's the pattern, and you've lived it. A PM ships a redesigned table with a new bulk-export button and asks engineering to "add some analytics." An engineer, mid-sprint on the next ticket, drops in a generic button_click event with a page_name property. Three weeks later, the PM wants to know how many people used bulk export on the new table versus the old one — and can't, because the event doesn't know which table version fired it. Someone files a follow-up ticket. The event gets renamed, the old data becomes an orphaned column nobody trusts, and the dashboard gets rebuilt from scratch.
| Instrumented After Ship | Specced Before Build | |
|---|---|---|
| Event names | Improvised by whoever picks up the ticket | Follow an agreed naming taxonomy |
| Properties | Whatever variables are already in scope | Chosen to answer a specific roadmap question |
| Ownership | Nobody in particular; on-call when it breaks | A named owner accountable at hand-off |
| Timing | Days to weeks after someone asks "how's adoption?" | Ships in the same release as the feature |
| Rework cost | High — renaming breaks historical dashboards | Low — changes happen in spec review, before data exists |
This isn't a new problem, and it isn't specific to software teams. Digital analytics pioneer Avinash Kaushik has argued for two decades, through his Digital Marketing and Measurement Model, that you define business questions and KPIs before you touch a tag, precisely because retrofitted tracking answers whatever was easy to capture — not what the business actually asked. Kaushik's model runs top-down: business objective, then goal, then a small set of KPIs, then the actual data collection — instrumentation is the last step, not the first. If you want the fuller map of how instrumentation fits together end to end, our complete guide to analytics instrumentation covers the pipeline from event to decision.
The cost shows up downstream, too. Surveys of data teams — including Anaconda's long-running State of Data Science research — have repeatedly found that analysts and data scientists spend the majority of their working time cleaning, reconciling, and chasing down inconsistent data rather than analyzing it. Broken or retrofitted event tracking is a recurring, avoidable contributor to that tax, and it compounds: every dashboard built on a shaky event inherits its ambiguity, and every stakeholder who trusted that dashboard now has to be told the number was wrong.
There's also a quieter cost that rarely makes it into the postmortem: trust. The second time a PM tells a stakeholder "we can't actually answer that, the event didn't capture it," the stakeholder stops asking analytics questions altogether and starts making calls on gut feel instead. A tracking plan written before build isn't just cheaper to maintain — it's what keeps data-informed decision-making credible enough that people keep reaching for it.
The Tracking Plan Is a Design Artifact, Not Paperwork
A tracking plan is a design decision because every event name, trigger, and property is a claim about which user behavior matters and how you'll segment it later. That's the same category of decision you make when you draw a wireframe or write acceptance criteria — not a compliance form filled in after the fact.
Think about what a checkout_started event actually asserts. It says: "checkout" is a meaningful unit of behavior, distinct from browsing; the moment it "starts" is definable and singular; and whatever properties ride along with it are the dimensions you'll want to slice by later. Get any of those three wrong and you can't answer basic questions without new code. That's a UX decision wearing an analytics costume — which is why it belongs next to the rest of your product design and UX process, not bolted on after the mockups are approved.
Google's own research backs this up from the metrics side. The HEART framework — Happiness, Engagement, Adoption, Retention, Task success, published by Kerry Rodden, Hilary Hutchinson, and Xin Fu at Google in 2010 — exists specifically to force teams to pick which UX signals matter before they instrument anything. HEART doesn't tell you what to build; it tells you which behaviors are worth measuring, which is a prerequisite for writing a single event name.
Treating the tracking plan as design also means treating naming as a shared vocabulary, the way a component library is a shared vocabulary for UI. Two teams that independently invent signup_complete and user_registered for the same moment have built two different truths about the same product. That's exactly the discipline a design system enforces for buttons and spacing — our event naming and taxonomy conventions apply the same logic to instrumentation, so object_action pairs stay consistent across every team that ships a feature.
There's a Jobs-to-be-Done angle here too, and it's worth sitting with. If you've framed the feature around a job the customer is hiring it to do — the Ulwick-style "get this outcome, faster/cheaper/more reliably" — then your trigger and properties should describe that job, not the UI chrome around it. An event named modal_opened describes a widget. An event named comparison_started with a job_context property describes a customer trying to get something done, which is the version you can actually build a roadmap decision on top of.
The Event-Spec Table: What to Define Before a Single Line of Code
An event spec needs exactly four things to be usable by engineering and durable for analysis later: a name, a trigger, a set of properties, and an owner. Skip any one of them and the event either doesn't fire reliably or nobody can be held accountable when it stops.
Here's what that looks like for a bulk CSV export feature, specced before the ticket is written:
| Event Name | Trigger | Properties | Owner |
|---|---|---|---|
export_started | User clicks "Export" in the table toolbar | table_id, row_count, filter_applied (bool), export_format | PM: Dana (feature owner); Eng: @priya |
export_completed | Export file finishes generating and the download begins | table_id, row_count, duration_ms, file_size_kb | Eng: @priya |
export_failed | Export job errors or times out server-side | table_id, error_code, row_count | Eng: @priya |
export_canceled | User closes the export modal before completion | table_id, step_abandoned | PM: Dana |
The term "tracking plan" itself comes out of analytics infrastructure — Segment popularized it as a literal schema: a spreadsheet or JSON document listing every event and its properties, with types, that gets validated against whatever the app actually sends. That's worth borrowing even if you don't run Segment's pipeline, because the discipline of a schema — not a loose list of "things we might track" — is what makes the plan enforceable.
To fill in each column without guessing, work through it in a fixed order:
- Name the event using your team's
object_actionconvention (past tense, e.g.,export_completed, notexport_finish). - Write the trigger as a single observable user or system action — if the sentence needs "and," it's two events.
- List only properties tied to a specific downstream question — resist copying every field in the object just because it's in scope.
- Assign an owner who is accountable for the event firing correctly after launch, not a rotating "analytics team" mailbox.
- Note the destination — which warehouse table or dashboard the event needs to reach, so QA knows what "working" means.
Two failure modes show up constantly at this stage. The first is over-instrumenting: teams add ten events to cover every possible interaction "just in case," and half of them never get queried — dead weight that still has to be maintained. The second is under-specifying properties: an event fires, but without a plan_tier or cohort property, you can count that it happened without ever knowing whether it happened to the users who matter.
Make the Tracking Plan a Column in the PRD, Not a Follow-Up Doc
The tracking plan belongs inside the PRD, mapped row-by-row against user stories, rather than living in a separate "Analytics Requirements" doc that someone remembers to update — or doesn't. When the spec changes, the event changes in the same diff, instead of drifting quietly out of sync with what actually shipped.
Concretely: next to each acceptance criterion, add the event(s) that should fire when that criterion is met. A row might read: "User can filter the table by status" → fires filter_applied with filter_type, result_count. If a PM cuts a confirmation step from the flow during design review, the confirmation_viewed event gets deleted in the same edit — not discovered as dead code three months later by whoever's debugging a funnel that doesn't add up.
This is also where the event spec earns its keep at hand-off: it should travel in the same package as your API contracts and data model, the parts of the technical foundations engineering needs to actually build the thing. An engineer reviewing a spec that already names every event, trigger, and property doesn't have to reverse-engineer what to log — they just build it, the same way they'd build against a defined endpoint instead of guessing at a response shape.
This is the exact pattern behind Prodinja's Spec Studio: it lets you carry the tracking plan as a living section of the PRD rather than a satellite document, with readiness gates that hold a story back from dev hand-off until the event table is filled in. Because the tracking plan sits inside the same spec, it travels in the same engineering hand-off export as the feature itself — the event table and the acceptance criteria arrive together, not as two documents someone has to remember to reconcile.
The Readiness Checklist That Blocks Hand-off Until Events Are Defined
A readiness checklist works because it turns "please add analytics" from a polite request into a blocking gate — the same gate you'd apply to an unresolved API question or a missing edge case. If the tracking plan isn't filled in, the story doesn't move to "ready for dev."
A workable gate before a ticket leaves refinement:
- Every event name matches the team's naming taxonomy — no ad hoc verbs
- Every trigger describes one observable action, not a bundle of steps
- Properties map to a specific question someone will actually ask (not "just in case")
- Every event has a named owner, not a team alias
- PII and sensitive properties are flagged and reviewed against privacy requirements
- A QA step exists to confirm each event fires with correct values before release
- Someone has confirmed the event reaches its destination (warehouse, dashboard, or
A/B testplatform)
That last line matters more than it looks. A feature can ship flawlessly and still make its own launch un-evaluable if the events needed for a valid holdout comparison were never defined — you can't measure lift you never instrumented for. If you're running structured tests, this checklist is really an extension of the discipline covered in how experimentation programs actually work: an experiment is only as trustworthy as the events feeding its metrics.
The checklist also catches the quieter failure: events that technically fire but that nobody owns. A year in, a codebase can accumulate dozens of zombie events — nobody remembers why they exist, nobody's sure they're still accurate, and nobody wants to be the one to delete them in case something depends on it. An owner named at spec time is the cheapest insurance against that slow rot.
Key Takeaways
- Instrumentation designed after ship answers whatever was easy to capture in the code that already exists — not the question the roadmap actually needs answered.
- A tracking plan is a design decision, on par with a wireframe or an API contract, because event names and properties encode claims about what user behavior means.
- Every event needs four things to be usable: a taxonomy-consistent name, a single observable trigger, properties tied to a real question, and a named owner.
- The tracking plan should be a column inside the PRD next to acceptance criteria, not a separate doc that drifts out of sync as the spec changes.
- A readiness checklist that blocks hand-off until events are defined is the cheapest way to stop "add some analytics" from becoming a post-launch scramble.
- Named owners prevent the slow accumulation of zombie events nobody trusts and nobody's willing to delete.
Frequently Asked Questions
What is a tracking plan in product management?
A tracking plan is a structured spec — typically a table — that lists every analytics event a feature will emit, along with its trigger, its properties, and who owns it. It's the same category of artifact as a wireframe or an API contract: a design decision made explicit before engineering builds against it, not a report written after the fact.
How do you write a tracking plan template for a new feature?
Start with four columns — event name, trigger, properties, owner — and fill one row per meaningful user action in the flow, not per pixel. Name events with a consistent object_action pattern, write triggers as single observable actions, keep properties tied to specific downstream questions, and assign a real owner rather than a team alias.
Who should own event instrumentation — the PM or engineering?
Both, on different columns. The PM typically owns what gets measured and why — which events matter and what properties answer the roadmap's questions — while engineering owns how the event fires correctly and reliably. Splitting ownership by column, not by handing the whole thing to one side, is what keeps the plan both useful and accurate.
When in the development process should analytics events be defined?
During spec and design, alongside acceptance criteria — not after the feature ships. If the event spec isn't finalized before a story moves to "ready for dev," any change to the flow during build risks silently invalidating events that were guessed at too early, which is exactly the rework a pre-build tracking plan exists to prevent.
What happens if you skip the tracking plan and add analytics after launch?
You get instrumentation shaped by whatever was convenient in the shipped code, not by the questions leadership actually wants answered — which is why post-launch analytics so often gets rewritten within weeks. You also lose the ability to run a clean before/after or holdout comparison, because the events needed to measure the change didn't exist when the change went live.