What makes a good Amplitude tracking plan
Most tracking plans are documents. The good ones are operating models that hold up after the analyst who wrote them leaves.
A good Amplitude tracking plan is not a Google Sheet of event names. It is an operating model — a description of how the product produces data, who is responsible for that data, and what good looks like at each stage.
Most teams treat the tracking plan as documentation. The good ones treat it as architecture.
Why does the distinction matter?
A tracking plan that is just documentation describes the past. It tells you what events were instrumented when the page was last edited. It does not tell you whether the events are still firing, whether they are still meaningful, or whether anyone is using them. After a few months, no one is sure if the document is current. That is when "data drift" sets in — the product changes, the tracking plan does not, and the dashboards quietly start lying.
A tracking plan that is architecture defines how the product produces data going forward. It specifies the events, the properties, the user properties, and the rules — but more importantly, it specifies the ownership and the review cadence. New events go through a review. Deprecated events get sunset. The plan stays current because there is a process that keeps it current.
What does a good tracking plan contain?
The minimum viable structure has six sections.
- Events. Every business action the team needs to measure, with a clear definition of when it fires.
- Event properties. The context attached to each event — which feature, which page, which value, which segment.
- User properties. The stable user attributes — plan tier, signup date, role, primary persona.
- Group properties (B2B). The account-level attributes — company size, plan, lifecycle stage.
- Naming conventions. Snake case, lowercase, length cap, allowed characters.
- Governance rules. Who can add events, how reviews work, what the deprecation process looks like.
The order matters. Without naming conventions and governance, events drift. Without user properties, all you can do is count actions — you cannot segment them.
How do you write the events?
Every event is one row in the plan. Each row answers four questions in plain English.
- What is this event called? Snake case, lowercase, descriptive but short. Verb-object pattern usually works (
signup_started,subscription_renewed). - When does it fire? A specific moment in the user flow. "User clicks the Submit button on the signup form" is good. "When the user signs up" is not — there are five moments that could be.
- Why do we care? What business question does this event let us answer that we could not answer otherwise?
- What properties does it carry? The minimum set that makes the event useful. Usually 3–5 properties per event.
The fourth question is where most plans fall short. Events without properties are counts. Events with properties are stories.
How do you keep it from drifting?
Three habits.
Mandatory review on every PR that touches tracking. New events do not get merged without an entry in the plan. Renames require migration plans. Property additions get logged.
A monthly health check. Pull the top 20 events by volume from Amplitude. Compare to the plan. Flag events firing that are not in the plan (untracked) and events in the plan that are not firing (dead). Resolve each one.
Designated owner. One person who owns the plan, even if it is 5% of their job. Without an owner, the plan decays the moment everyone is busy.
Where does Amplitude Govern fit in?
Amplitude Govern is the product surface for tracking plan governance — categories, blocked events, hidden events, required properties. It is genuinely useful, but it is not a substitute for the plan itself.
Govern enforces the plan. The plan defines what should be enforced. Without a plan, Govern is just a permissions panel.
The right pattern: write the plan in a doc (Google Sheets, Notion, or a real tracking-plan tool like Avo). Configure Govern to enforce the plan. Run the plan-vs-Govern reconciliation in your monthly health check.
What we check for
The Amplitude Auditor automates several of these checks against your project's actual configuration. Among the relevant ones:
- Event naming conventions (snake_case, lowercase, length)
- Event descriptions present in the taxonomy
- Event categories used in Govern
- User properties configured (count and naming)
- Property coverage on top events
- Suspected duplicate events (taxonomy drift signal)
Run an audit on your project and see what shows up. The findings are the start of the plan-vs-reality reconciliation.
FAQ
Do I need a tracking plan if I am a small team? Yes — earlier than you think. The cost of fixing a broken plan grows faster than the team. A team of 5 with 30 events is cheap to fix. A team of 30 with 300 events is not.
How long should the plan be? As long as it needs to be, no longer. A typical SaaS product has 30–80 meaningful events. If you have 300, half of them are probably noise.
Should the plan live in Notion, Sheets, or a dedicated tool? For under 50 events, Sheets is fine. Above that, a dedicated tracking-plan tool (Avo, Iteratively-style) starts paying off — they enforce schema and integrate with code.
Who should own the plan? Whoever cares the most about the data quality. Usually that is a senior product analyst or a head of data. Engineering ownership tends to drift to "whatever is easiest to ship."