How to Create a Tracking Plan in Amplitude Data
Most analytics problems are data problems. Two events with slightly different names for the same action, properties sent as strings in one place and numbers in another, and events nobody remembers adding. By the time a PM tries to build a funnel, the data cannot be trusted. A tracking plan prevents this by defining what should be tracked before engineers instrument it.
Amplitude Data is Amplitude's product for managing a tracking plan alongside the analytics itself. This guide covers setting naming conventions, defining events and properties, using branches to review changes, and monitoring for events that do not match the plan. Exact menus can differ by Amplitude plan and version, so use this as a workflow guide.
Measuring a change in Amplitude? Write the experiment brief before you ship.
Describe the change and the number you want to move. Vantage turns it into a written brief you can share with eng and data before anything ships.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds an experiment brief from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Agree on naming conventions
Pick a convention and write it down before adding events. A common pattern is object-action in Title Case, such as 'Project Created' or 'Report Viewed'. Decide on casing for property names too, such as snake_case. Consistency matters more than the specific choice.
- Choose an event naming pattern such as Object Action
- Choose a property naming style
- Document both in a short guide linked from the tracking plan
Start from questions, not events
List the product questions the team needs to answer, such as 'Where do new users drop off in onboarding?' Work backward to the events and properties needed to answer them. This keeps the plan focused and avoids tracking everything 'just in case'.
Define events and properties in the plan
In Amplitude Data, add each event with a description that explains when it fires. Add event properties with types and allowed values, and mark which are required. Clear descriptions are the most important part; they tell engineers exactly what to instrument and tell analysts what the event means.
- Add an event with a precise firing description
- Add properties with data types
- Set allowed values for enum-like properties
- Mark required properties
Use branches to review changes
Amplitude Data supports working on changes in a branch and merging them into the main tracking plan after review, similar to code. Use this for any new feature's instrumentation: the PM or analyst proposes events in a branch, engineering reviews, and the changes are merged when agreed.
Instrument with generated code where possible
Amplitude's Ampli tooling can generate typed tracking code from your plan, so engineers call functions that match the plan rather than typing event names by hand. This catches typos and missing properties at build time. If your team uses a different SDK setup, share the plan with clear event names and property types.
- Set up the Ampli CLI in the codebase if your team uses it
- Pull the latest tracking plan into the project
- Instrument events using the generated functions
- Verify events in Amplitude after deploying to a test environment
Monitor for unexpected events
Amplitude Data flags events and properties that arrive but are not in the plan. Review these regularly. Some are legitimate events that should be added; others are mistakes that should be fixed or blocked. Leaving unexpected events unreviewed is how a clean plan decays.
Make the plan part of the feature process
Add tracking plan review to your definition of ready for features. If the PRD has success metrics, the events needed to measure them should be in the plan before work starts. This avoids launching a feature and discovering a week later that you cannot measure it.
Common mistakes
Tracking everything
Hundreds of loosely defined events make the data harder to use. Track what answers real questions and add more when needed.
Vague event descriptions
'Fires when user clicks button' is not enough. Describe which button, on which screen, and under what conditions.
Ignoring unexpected events
Unexpected events accumulate quickly. Review them weekly or the plan stops reflecting reality.
Tips
Include the PRD link in event descriptions for events added for a specific feature.
Use the same property names across events, such as plan or workspace_id, so breakdowns work everywhere.
Assign an owner for the tracking plan who approves changes.
Archive deprecated events instead of leaving them active in the plan.
How Vantage helps
A tracking plan is easiest to get right when success metrics are defined in the spec. Vantage PRDs include success metrics alongside requirements, so the events needed to measure a feature can be planned before engineering starts, and the resulting tickets push to Linear or Jira with that context attached.