An event tracking plan is a single shared document that lists every event your product sends, what triggers it, and the properties it carries, using one strict naming convention. Build it before you instrument anything: agree on a naming pattern, list events by funnel stage, define each event's properties and types, assign an owner, and treat it as the source of truth every new event must pass through.
The tracking plan is the difference between analytics you trust and a pile of events nobody queries. It is the first artifact in a real product analytics setup, and skipping it is why so many startups end up with three spellings of "signup" and dashboards they cannot believe.
What Is an Event Tracking Plan?
An event tracking plan (also called a tracking spec or data dictionary) is the governance document for your product analytics. It defines every event you deliberately track, the exact conditions that fire it, the properties attached to it, and the types those properties must be. It lives somewhere the whole team can see - a spreadsheet, a Notion table, or a schema file in your repo - and it is the contract engineering implements against.
A tracking plan defines what to capture; a data layer is the structured object on the page that delivers those events to your tags consistently.
Without it, every engineer names events their own way, properties drift, and by the time you try to answer a real question the data is uninterpretable. With it, anyone can look up what "Activated" means and trust that it means the same thing in every report.
Why Does a Startup Need a Tracking Plan Before Instrumenting?
Because bad event data is worse than no event data - it looks authoritative while being wrong, and you make decisions on it. The three failure modes a plan prevents:
- Naming drift. "signup", "Sign Up", "user_signed_up" logged by different engineers become three events for one action, so every funnel undercounts.
- Property chaos. One event sends plan as "pro", another as "Pro", another as a number. Segmentation silently breaks.
- Orphan events. Events instrumented with no owner and no question behind them pile up as noise nobody trusts or deletes.
A plan is cheap insurance. An afternoon writing it saves the multi-week cleanup of re-instrumenting a live product, which almost always means shipping code and waiting for fresh data before any analysis is reliable again.
What Should an Event Tracking Plan Include?
Every row in the plan is one event. At minimum capture these columns:
| Column | What it holds | Example |
|---|---|---|
| Event name | The exact string sent, following your convention | Project Created |
| Trigger | The precise user action or system condition that fires it | User clicks Create and the project saves successfully |
| Funnel stage | Where it sits: acquisition, activation, engagement, monetization | Activation |
| Properties | Key/value context, each with a type | plan_tier (string), template_used (boolean) |
| Owner | Who is accountable for it firing correctly | Growth eng |
| Status | Proposed, live, or deprecated | Live |
Also record user and group identity fields (user_id, account_id, plan) once at the top, since they attach to every event and should never be redefined per row.
How Should You Name Events and Properties?
Pick one convention and enforce it without exception. The specific style matters less than consistency, but two patterns dominate:
- Object-Action, Title Case ("Project Created", "Invite Sent") - readable in reports, the most common analytics convention.
- snake_case verbs ("project_created", "invite_sent") - engineer-friendly and safe across SDKs.
Whichever you choose, lock these rules:
- Past-tense actions. Events are things that happened: "Signed Up", not "Sign Up".
- Consistent casing everywhere - event names and property keys and values.
- Properties describe, events count. Do not encode data in the event name ("Upgraded to Pro"); make it a property (event "Upgraded", property plan="pro").
- No PII in event names or properties you would not want in analytics - keep emails and tokens out.
How Do You Keep a Tracking Plan from Rotting?
A plan is only useful while it matches reality, and products change. Keep it alive with light process, not heavy ceremony:
- One gate for new events. No event ships without a row in the plan first. Make the plan the pull-request checklist item.
- An owner. One person (usually whoever owns growth analytics) reviews additions and kills orphans.
- Quarterly pruning. Mark unused events deprecated and stop sending them; dead events cost money and confuse newcomers.
- Verify on every release. Trigger changed events in a live view and confirm they fire with the right properties, the same discipline the conversion tracking setup guide applies to ad events.
The plan feeds everything downstream. Your PLG funnel metrics and any growth experiments you run are only as trustworthy as the events underneath them, so the tracking plan is the foundation the rest of your analytics sits on.
TL;DR
- An event tracking plan is one shared document defining every event, its trigger, properties, types, and owner under a single naming convention.
- Write it before instrumenting - bad event data looks authoritative while being wrong, and re-instrumenting a live product takes weeks.
- Each row is one event with name, trigger, funnel stage, typed properties, owner, and status; identity fields are defined once at the top.
- Pick one naming convention (Object-Action Title Case or snake_case), use past-tense actions, and put data in properties, not event names.
- Keep it alive with a one-gate rule for new events, a single owner, quarterly pruning, and verification on every release.
FAQ
What Is an Event Tracking Plan?
An event tracking plan is a single shared document that defines every event your product deliberately tracks, the exact condition that fires each one, the properties it carries, and the types of those properties, all under one strict naming convention. It lives where the whole team can see it and acts as the contract engineering implements against, so an event means the same thing in every report.
Why Do You Need a Tracking Plan Before Instrumenting Analytics?
Because bad event data is worse than none - it looks authoritative while being wrong, and you make decisions on it. A plan prevents naming drift (three spellings of one action), property chaos (inconsistent values that break segmentation), and orphan events with no owner. An afternoon writing it saves the multi-week cleanup of re-instrumenting a live product and waiting for fresh data.
What Should an Event Tracking Plan Include?
Each row is one event and should capture the event name, the precise trigger, the funnel stage, its properties with their types, an owner, and a status (proposed, live, or deprecated). Identity fields like user_id, account_id, and plan are defined once at the top because they attach to every event and should never be redefined per row.
How Should You Name Analytics Events?
Pick one convention and enforce it: either Object-Action in Title Case (Project Created) or snake_case verbs (project_created). Use past-tense actions, keep casing consistent across event names and property keys and values, put variable data in properties rather than the event name, and keep PII out of names and properties. Consistency matters more than which style you pick.
If your tracking has already drifted, start with marketing tech debt cleanup.
How to Keep the Plan from Rotting
Rot happens when the doc and the code diverge, so tie the change to the edit. Every time an event is added or renamed, update the plan in the same PR, because the discipline of one change is what keeps the two in sync. The plan that lives apart from the code dies, and the linked update is the cure.
Assign an owner who approves new events. Without a gate, anyone ships a name that breaks the scheme, so a named reviewer keeps the convention intact as the team grows. The human in the loop is what preserves the plan's usefulness past the first sprint, and the ownership is the point.
How to Name Events and Properties
Name by object and action, not by screen. "checkout_started" beats "button_click_3" because the phrase tells the story when read later, so the convention carries meaning. The consistent verb-noun pattern is what lets a new analyst read the plan without a guide, and the clarity is the value.
Use properties for the context, not for the event itself. The action is the event; the who and the what are properties, so keep the split clean. The right shape makes the data queryable, and the discipline of separating the two is what turns the plan into a tool instead of a list.
What the Plan Should Include
Include the event, the trigger, the owner, and the reason. A row without the why is a mystery a month later, so capture the intent with the definition. The complete row is what lets the plan answer "should we track this" without a archaeology dig, and the completeness is the point.
Keep it small at first. A startup that plans a hundred events tracks none of them, so start with the few that drive the decision and grow as needed. The lean plan that is used beats the comprehensive one that is ignored, and the honesty of scope is what makes the doc live.