Skip to content
Log in
← Statistics glossary

tracking plan

Also called: event plan, instrumentation plan, event tracking plan, analytics tracking plan, event taxonomy

A document that lists the questions a feature must answer, the events and properties needed to answer them, where each is logged and how it will be checked before launch.

A tracking plan is the contract between product, engineering and analytics about what gets logged and what it means. It is written before a feature is built, starting from the questions the team will need to answer after launch, and it lives next to the code (a shared doc or a schema file in the repository).

A useful plan has, for every event:

Field
What it says
Question
Which decision this event helps with
Event name
One consistent convention, e.g. object_action in snake_case and past tense: reminder_sent
Trigger
The exact moment it fires ("after the server accepts the expense", not "on tap")
Properties
Name, type and allowed values: channel: push / email
Source
Client or server, and why
Metric definitions
The formulas built from it, with units, windows and exclusions
Owner and QA check
Who maintains it, how it's verified before release

Two choices matter most. Where to log: server-side events are reliable for things that happen on the server (payments, recurring bills, sent notifications) and aren't blocked by ad blockers, but they don't prove a person did anything; client events capture what the user saw and tapped. What to name: few events with rich properties (paywall_viewed with trigger) age much better than one event per button.

Before launch, check the plan against reality: run the feature in a test build, compare the events you expected with the ones that arrived, and confirm that each metric can be computed from them. After launch, keep the plan current; a tracking plan that nobody updates is worse than none, because people trust it.

Example

Halves is adding payment reminders: a user can nudge a friend who owes them money. Maya's question: "Do reminders get debts settled faster?" The plan (excerpt):

Event
Source
Key properties
Used for
reminder_sent
server
reminder_id, group_id, amount_usd, channel (push / email)
denominator of open and settle rates
reminder_opened
client
reminder_id, channel
open rate
settle_up_recorded
client
settlement_id, amount_usd, reminder_id (empty if none)
settled within 7 days of a reminder

Metric definition: reminder open rate = distinct reminder_id with at least one reminder_opened ÷ distinct reminder_id with reminder_sent, excluding staff accounts, per calendar week (UTC).

In the first week the raw counts are 4,000 reminder_sent and 1,000 reminder_opened events, which suggests a 1,000 / 4,000 = 25% open rate. But some people opened the same reminder twice: the 1,000 open events belong to 800 distinct reminders. By the written definition the open rate is 800 / 4,000 = 20%, not 25%. Because the plan fixed the definition and required reminder_id on both events, the right number is one query away instead of a debate.

Common mistakes

  • Writing it after launch. Missing properties can't be backfilled; the first weeks of data, often the most interesting, are lost.
  • Events without questions. Logging every tap creates noise and cost; every event should serve a named decision.
  • Vague triggers. "When the user adds an expense" can mean the tap or the server confirmation; failed saves then count as expenses.
  • Inconsistent names. expenseAdded, add_expense and Expense Added in one project split the same action into three.
  • No QA before release. Compare expected and received events in a test build; fixing tracking after launch costs a release and the lost data.