Tracking Plan Template
Spreadsheet-style template covering events, properties, user properties, governance rules, and KPI coverage. The structure Adasight uses on every engagement.
The structure of a tracking plan that ages well. Treat this as a starting structure — adapt the column set to your team's reality, but keep the discipline of having explicit columns rather than free-form notes.
Recommended structure
A tracking plan is six tables (or six tabs). Each does a different job.
1. Events
| Column | What it captures |
|---|---|
| Event name | snake_case, ≤40 chars, verb-object |
| Description | One sentence: when does this fire? |
| Trigger | The exact moment in the user flow |
| Owner | One person responsible |
| Status | Active / Deprecated / Proposed |
| Last reviewed | Date of last reconciliation |
2. Event properties
| Column | What it captures |
|---|---|
| Property name | snake_case |
| Description | What this captures, in plain English |
| Type | string, number, boolean, array |
| Required | Yes / No (Govern enforces this) |
| Allowed values | If enumerated, list them |
| Applies to events | Which events carry this property |
3. User properties
| Column | What it captures |
|---|---|
| Property name | snake_case |
| Description | What this captures |
| Type | string, number, boolean, array |
| Set strategy | $set (mutable) / $set_once (immutable) |
| Source of truth | Where this value originates |
| Update trigger | When the SDK should update this |
4. Group properties (B2B only)
Same shape as user properties, but at the account/workspace level.
5. Governance rules
| Rule | Setting |
|---|---|
| Naming convention | snake_case enforced |
| Length cap | 40 chars for events, 30 for properties |
| Required properties | List per event |
| Reserved prefixes | [Amplitude] auto-collected only |
| Approval process | PR review with tracking-plan link |
6. KPI coverage
| KPI | Defining events | Defining properties |
|---|---|---|
| Activation rate | signup_started → activation_event | activation_event requires plan_tier |
| Conversion rate | pricing_viewed → subscription_started | source channel, plan |
| Retention (W1, W4, W12) | session_started | identification rate ≥90% |
How to use the template
Three habits.
Fill it out before instrumentation, not after. The plan is the spec. Engineering instruments to the plan. Without a plan first, instrumentation drifts toward what was easiest to ship.
Reconcile monthly. Pull top events from Amplitude → compare to plan → resolve gaps. 30 minutes once a month prevents 8 hours of cleanup once a year.
Sunset deprecated events. Mark events deprecated when they stop firing or stop being analysed. Hide them in Govern after 30 days, delete after 90. Otherwise the taxonomy fills with dead entries.
What we check for
The Amplitude Auditor compares your project's actual taxonomy to plan-style criteria:
- Naming consistency
- Description coverage
- Property hygiene
- Required properties enforced via Govern
- Suspected duplicates (drift indicator)
Run an audit to see how your project looks against these.