A tracking plan is the document that holds every event a product records, the properties each one carries, the person who owns it and the question it exists to answer.
The artefact came out of the analytics tooling world, where vendors found that customers with clean data all kept one and customers with unusable data all did not. Segment publishes guidance on writing one and sells a feature by that name, and several smaller tools exist to hold nothing else. The idea travels without any of those tools, because a tracking plan is a spreadsheet or a schema file before it is a product. The first version fits on one page.
The reason it reaches a product manager is that every column in it is a product decision. An engineer can implement an event from a description and an analyst can query one from a name, and neither of them knows which question the event was added to answer or whether that question still matters. Only the person who asked for the measure knows that, and it is the fact most likely to be lost when they change job.
The sections below set out the columns a row holds, with the one that causes the most argument worked through. They then describe the review a proposed event goes through and the way a plan is versioned. Finally they give the reason a plan kept inside the analytics tool has no owner, and the place a plan lives instead.
What a row in a tracking plan holds
One row describes one event, and eight columns cover almost everything a team will later wish it had written down.
| Column | What it holds | The question it settles later |
|---|---|---|
| Event name | Invoice Sent, in the agreed convention | Which of three similar names an analyst should query |
| Description | One sentence a newcomer can read | What the event means to somebody who was not in the room |
| Trigger | The exact moment the event fires | Whether it fires on the click or on the server confirming |
| Properties | Name, type, allowed values, and whether each is required | Why a chart has a bar labelled null |
| Owner | One named person | Who decides when the definition may change |
| Question | The measure or decision the event serves | Whether the event can be retired next year |
| Added | The date it first went live | Where the usable history starts |
| Status | Proposed, live or retired, with a date | Whether a gap in the data is a bug or a decision |
The trigger column looks like a detail and decides the number. An invoicing
product can fire Invoice Sent when somebody clicks the send button, or when
the mail provider confirms the message left. The first counts invoices somebody
tried to send. The second counts invoices that reached a customer, and on a
product sending through a third party mail service the two figures differ by
the two per cent that bounce. The gap is real money. A team that never wrote
the trigger down ends up with both definitions in use, in two reports, three
months apart, and an afternoon spent working out which one the board saw.
The question column is the one teams leave empty and the one that pays for itself. An event with no recorded reason cannot be retired, because nobody can prove it is unused, so a taxonomy only ever grows. An event with a reason against it can be removed the quarter its reason stops applying.
The review a proposed event goes through
A new event needs one named reviewer and about ten minutes, which is enough to stop most of the damage.
The reviewer checks four things in order.
- The name follows the convention. Object first, action second, past tense, and no value encoded in the name.
- No existing event would do the job with one more property. Most proposals are an existing event with a value lifted into its name.
- A named person asked for it, to settle a named decision. A proposal with nobody behind it usually has no question behind it either.
- No property carries personal data the question does not need. An email address recorded out of habit moves a behavioural dataset into a different legal category.
Merging a proposal into an event that already exists is where the value sits. A team reviewing forty proposals over a year will merge perhaps half of them into existing events, which is the difference between a taxonomy of sixty events and a taxonomy of a hundred that says the same things twice.
Sign off works best as a named role rather than a committee. One person per team, with the product manager as the second reader on anything that touches a measure in a quarterly review. A review board meeting fortnightly guarantees that engineers ship the event first and bring it to the board afterwards, which is the outcome the board was created to prevent.
Versioning a tracking plan and retiring an event
A tracking plan carries a version number and a change log, for the same reason an interface between two systems does.
An event is never deleted from the plan. It is marked retired with the date it stopped firing, and the row stays, because every report built before that date still depends on the name. Deleting the row leaves an analyst in two years looking at a gap in a chart with no way to tell a bug from a decision.
A property gaining a new allowed value is also a change to the plan, and it is
the change teams forget to record. An invoicing product holds a plan
property with three allowed values. The enterprise tier ships in March and the
property quietly gains a fourth. A report that groups by plan gains a fourth
bar and stays correct. A report that filters to a written list of three values
drops every enterprise account and stays silent about it, and the figure it
produces is wrong in a way that looks entirely normal.
Recording the change is half the repair. The other half is a validation step that rejects a property value the plan does not declare, which turns a silent wrong number into a loud failure at the moment somebody introduced it.
Why a tracking plan kept only in the analytics tool has no owner
Every analytics tool shows a list of the events it has received, and a team that treats that list as its plan has confused two different documents.
The tool holds a record of what fired. A tracking plan is a statement of what ought to fire, and the two differ precisely at the points that matter. The event that stopped firing three weeks ago has quietly dropped off the tool's list. The event an engineer added on Friday with no review has quietly appeared on it. Both changes pass unnoticed. Neither difference is visible to anybody reading the tool, because the tool has no opinion about what should be there.
Three further things a plan holds have no column in a tool at all. The first is the owner of each event. The second is the question each event was added to answer. The third is the status of an event somebody has agreed to build and has not built yet. That row is the one an engineer needs most, and no tool can hold it, since a tool learns of an event only when the event arrives.
A typo is the smallest illustration and the most familiar. Somebody ships
Invoce Sent, it fires eleven times before anybody notices, and it is now a
permanent member of the tool's event list sitting next to the correct name. A
tracking plan with a validation step behind it rejects the name before the
release goes out.
Keeping the tracking plan beside the code
A plan does its job when changing it and changing the code are the same piece of work.
The arrangement that holds up is a schema file in the same repository as the product, listing every event, its properties, their types and their allowed values. A change to the plan and the change to the instrumentation then arrive in one review, and the reviewer sees both. A build step validates events against the file, so an event sent with an undeclared name or an undeclared property fails a test in March. The cost of skipping that step is a strange chart in June that nobody can explain.
The people who read the plan most are rarely the people with the repository checked out, so one generated copy belongs somewhere a product manager and an analyst can open it. Generated from the same file, never maintained beside it, because two copies of a definition become two different definitions within a quarter.
A tracking plan settles what a product records and which facts travel with each record. Every one of those records also carries an identifier saying who acted, and that identifier is the part a team is most often wrong about. One person arriving on a laptop, signing in on a phone and returning a fortnight later with the cookies cleared can appear as three. How a product recognises one person, and what a session actually is, comes next.