How to Build a Tracking Plan (with a Free Template)
A tracking plan is the cross-team contract that defines every event, property, and user attribute before anyone writes instrumentation code. It's the spec, not the software — the shared document your analysts, PMs, and engineers all agree to so that a "Sign Up" event means the same thing to everyone who touches it. Get this document right and your dashboards inherit its discipline. Skip it, and you'll spend months untangling three slightly different spellings of the same event.
What a tracking plan actually is (and what it isn't)
Let me draw the line clearly, because this is where most teams get confused. A tracking plan is the definition. The instrumentation is the code that fulfills that definition. Amplitude's documentation puts it plainly: "A tracking plan defines every event and property you collect, why you collect each one, and which source emits it." Notice the phrasing. It's a definition, written down, ideally before a single track() call ships.
Think of a city bus network. The plan is the route map: the agreed list of stops, the order they come in, which line serves which corner. The instrumentation is the buses actually running those routes. You can swap out a bus, repaint it, hire a new driver, and the map still holds, because everyone agreed on the map first. When teams treat the code as the source of truth, they've thrown away the map and told each driver to improvise. The buses run. They just don't go anywhere anyone can predict.
Segment frames the same idea as a contract, and I like that word because a contract has signatories. It's not a wishlist one PM keeps in a private doc. It's the thing data, product, and engineering all point at when they disagree about what an event should capture. The document lives outside any one tool. Whether you enforce it in a spreadsheet, in Segment's Protocols, or somewhere else, the plan itself is vendor-agnostic. That separation matters more than it sounds, and we'll come back to it in the governance section.
Define your first 20 events, not 200
How many events should your first tracking plan contain? Fewer than you think, and almost certainly fewer than your instinct is screaming right now. The "track everything, we'll figure out what matters later" impulse feels responsible. It's actually hoarding — the analytics equivalent of keeping every takeout menu in a drawer because one day you might want Thai at 11pm.
Mixpanel's own guidance pushes back on this: "Prioritize the most critical data you'll need based on your analytics strategy and KPIs, then iterate." Segment's academy makes the same case from the other direction, warning that a focused initial set "helps avoid a situation where you become overwhelmed by endless possible actions to track." And the strongest version comes from a guest post on Mixpanel's blog by the founder of deepskydata, who argues — and I'm quoting a claim, not a law of physics — that "50+ events are already too many to track, especially when it comes to product and marketing analytics." Reasonable people disagree on the exact ceiling. The direction of travel is not in dispute.
So here's the framework I use. Call it core-funnel-first.
Start with your one primary conversion path, the single sequence that, if it breaks, your business notices by Friday. Segment recommends building outward from "the key metrics that drive value for your business," and your funnel is those metrics made sequential. Map that path as discrete steps. Tag each step as a must-have event. Cap the first pass at roughly 20 events. Everything else goes into a "later" list, which is not a graveyard. It's a parking lot you'll revisit next quarter.
Let's make it concrete. Say you're a mobile app with this funnel:
Install → Sign Up → Activate → Purchase
Four steps. But four steps don't mean four events, because each step has a real user story around it. Install expands into App Installed and App Opened. Sign Up becomes Sign Up Started, Sign Up Completed, and maybe Sign Up Failed, because you genuinely want to see where people drop. Activate, your aha moment, might be Onboarding Completed, First Project Created, Feature Activated. Purchase spreads into Checkout Started, Payment Info Added, Purchase Completed, Purchase Failed. Add a handful of supporting events — Screen Viewed on your key screens, Search Performed, Notification Opened — and you're sitting at fifteen to twenty. That's a plan a team can actually maintain, tied directly to a path you already care about, and it maps cleanly onto a metric tree if you've done that work. If you haven't, our piece on the North Star metric and its input metrics is the prerequisite reading.
Two hundred events, by contrast, is a plan nobody reads and everybody quietly violates.
Use properties, not new events
Here's the mistake that inflates a clean 20-event plan into a bloated 200-event one: creating a brand-new event for every variation of the same action.
Picture a recipe. You don't write fifty separate recipes titled "Soup With Salt," "Soup With Pepper," "Soup With Basil." You write one soup recipe with a step that says "add seasoning," and seasoning is a variable. Events work the same way. The action is the recipe. The variations are properties.
I see this most often with purchase tracking. A team ships Purchase - Pro, Purchase - Team, and Purchase - Free as three distinct events. Now every funnel query has to union three events, every retention chart has to remember all three exist, and when someone adds an Enterprise tier they forget the fourth event entirely. Collapse it. One Purchase event, with a plan property that takes the values free, pro, team, enterprise. Add an amount property while you're at it. Mixpanel's guidance says it directly: "Properties give you the flexibility to keep your event list small while still allowing rich analysis." You lose nothing analytically. You can still segment purchases by plan, compare revenue across tiers, build a cohort of Pro buyers. You've just done it without breeding events.
The rule of thumb I hand to PMs: if the two things you're about to track answer the same question with a different value, that's a property. If they answer genuinely different questions, that's a new event.
The tracking-plan template, column by column
This is the artifact. A workable tracking plan needs five columns, and no, you don't need more than five to start. Here they are, with fill guidance and one filled row from the funnel above.
| Event | Trigger | Properties | Owner | Priority |
|---|---|---|---|---|
Purchase Completed |
Fires once when payment is confirmed server-side | plan (free/pro/team), amount (number), currency, is_first_purchase (bool) |
Growth PM (Ana) | P0 |
Event is the name, in your chosen convention (more on that below). Trigger is the precise moment it fires, written so an engineer can implement it without a meeting: "when payment is confirmed server-side," not "when someone buys." Properties lists the attributes and their types. Write the type down, because amount: "12.00" as a string will ruin your revenue math six weeks from now. Owner is a named human, not a team, because accountability doesn't survive being spread across a department. Priority tags whether this is a must-have (P0), part of the funnel (P1), or a nice-to-have you're parking (P2).
You can grab the free template at the end of this piece and fill it in against your own funnel.
Naming conventions
Pick one framework and never deviate. Segment's academy is blunt about this: "the most important thing to do is to pick a single naming framework and stick with it." The reason is a problem you've almost certainly lived through. A single newsletter signup gets logged as Sign Up, signup, Signed Up, sign_up, and SignUp across five different features, and now your "sign up" number is scattered across five events that no chart adds together.
The convention I recommend is object-action with consistent casing: Purchase Completed, Project Created, Search Performed. Object first, past-tense action second, Title Case throughout. It doesn't have to be that one. It has to be one. Write it at the top of the plan so every new event has an obvious mold to fit.
Who owns adding new events
A tracking plan without an owner rots. I've watched it happen. The plan launches clean in January, and by June it's a museum of good intentions while the real events live wherever the last engineer felt like putting them.
The fix is a lightweight workflow, and E-CENS's data governance playbook describes the shape of it well: a new-event request gets "reviewed by a designated Data Governor or a small governance committee" before it becomes an engineering ticket. That's the whole spine. Request, review, implement, verify. Someone wants a new event. They file the request against the plan. The Data Governor (or a small committee with data, product, and engineering represented) checks it for three things: does it duplicate an existing event, does it follow the naming framework, and does it actually tie to a metric anyone will use. Only then does it become a ticket. After it ships, someone verifies the live event matches the spec.
Tooling supports this too. Segment assigns a Workspace Owner and Tracking Plan Admin role precisely so that changing the plan is a permissioned action, not a free-for-all. The specific title matters less than the principle: one accountable person signs off, and that sign-off is a real gate, not a rubber stamp. Without it, your compact 20-event plan drifts back toward the 200-event swamp one well-meaning request at a time.
Enforcing the plan against live data
A spreadsheet describes what should happen. It can't tell you whether your live events actually match. For that you need an enforcement layer, tooling that validates incoming events against the plan and flags drift. Several options exist, and they differ mostly in how they surface violations.
Segment (Twilio) Protocols ties the tracking plan directly to the data pipeline, so events that don't match the schema get flagged or blocked before they pollute downstream tools. It's the most mature option if you're already routing data through Segment.
Amplitude offers governance features that compare observed events against the defined plan and surface unplanned or malformed events for review. Useful when Amplitude is your primary analysis tool and you want the plan and the data living in the same place.
Mixpanel provides governance tooling in the same spirit, letting you flag events that stray from your defined schema so cleanup happens continuously rather than in a panicked quarterly audit.
Kixo is a newer, AI-native option worth knowing about. It's a B2B product and marketing analytics platform with a chat-first angle: you ask questions in plain language and it generates the charts, funnels, and dashboards with a visible reasoning trail, alongside product analytics like events, funnels, retention, and cohorts. Kixo is newer than the others here, with fewer public proof points, so I'd treat it as one to trial against your own data rather than assume feature parity on the enforcement side. If the conversational interface fits how your team actually asks questions, it's a reasonable candidate to evaluate.
Whichever you choose, the point is the same: the plan and the live data need a feedback loop, or the plan slowly becomes fiction. If you're weighing the broader question of buying versus building this layer, the trade-offs around analytics tooling are worth reading before you commit.
Mistakes everyone makes
- Tracking events nobody owns. An event without a named owner is an event nobody maintains. It survives exactly until the person who built it leaves.
- Treating pageviews as a product signal. A pageview tells you a page loaded. It does not tell you anyone did anything. Counting pageviews and calling it engagement is how you end up with a beautiful chart that means nothing — the vanity metric that launched a thousand misguided roadmaps.
- Adding events instead of properties. We covered the soup. Every time you feel the urge to create
Event - VariantA, stop and ask whether "variant" is just a property in disguise. It usually is. - No naming framework. Five spellings of "sign up," zero of them agreeing. The cleanup costs you more than the framework ever would have.
- A plan that's never reviewed. The document you wrote in January and never opened again isn't a source of truth. It's a historical record of what you once hoped was true.
Most of these trace back to the same root: skipping the discipline up front because it feels slower, then paying for it in analysis time later.
Grab the template
The free template is the five-column version above — Event, Trigger, Properties, Owner, Priority — ready to fill against your own funnel. Three things to carry with you when you open it. Start from your one primary conversion path and let the funnel steps generate your events. Cap the first pass around twenty and park the rest in a "later" list. Put a real human's name in the Owner column of every single row, because that's the difference between a plan that lives and a plan that rots. Everything else you can iterate on. Those three you can't fake.