SYS/DEF
Tracking plan
The contract: which events, which properties, which deduplication, which tool receives them. Without it, analytics is folklore.
Definition
A tracking plan is the specification of product events: name, trigger, parameters, user id vs cookie, destinations (analytics, ads, A/B). It also says what you do not measure. The dataLayer is only a pipe; the plan is the law.
Without a version and an owner, the plan rots: a dev renames purchase to purchase_v2, the A/B tool still reads the old one, CRO celebrates a conversion flatten.
When it matters
Before the first test, before a rebuild, before wiring an ads pixel. It is the prerequisite of any testable hypothesis and any credible attribution.
It matters in an integrity audit: an SRM on the A/B tool and conversions that do not match analytics is often a plan not followed, not “chance”.
Pitfalls
Documenting after the fact in a Notion nobody opens. Tracking “everything” (noise, GDPR, tag budget). Duplicating the same event in GTM and in-app. Changing an event name mid-test. Forgetting consent modes: the plan must state cookieless behaviour, not only the ideal case.
Related terms
Related tool
SRM, peeking, tracking: can you spot an invalid test before you read the result: Open experiment integrity quiz.