Also called: measurement plan, analytics spec, event schema
A minimal usable plan lists, per event: the event name, when it fires, its parameters with types and whether each is required, the destinations it goes to, and the owner. Without types and required-flags it is documentation; with them it is something you can validate against automatically.
The plan is what turns tracking from tribal knowledge into a reviewable artefact. New engineers can implement against it, agencies can be held to it, and a schema-drift check can compare incoming events to it and flag violations.
Plans go stale faster than code. Treat the plan as versioned, review it whenever an event changes, and prefer a plan generated from or validated against live traffic over one maintained by hand in a spreadsheet.
Without a tracking plan there is no definition of correct, so no monitoring can alert on incorrect — every measurement bug has to be noticed by a human who happens to be looking at the right chart.
Per event: name, firing condition, parameters with types and required flags, destination platforms, and an owner. Add the business question each event answers — events nobody can justify are the ones safe to delete.
The plan is the intent; the container is one implementation of it. Comparing the two is exactly how you find drift — the gap between what was specified and what is deployed.
TagEasy's free auditor checks any URL for Consent Mode v2 signals, PII in tracking, duplicate pixels, and 10 other tracking-quality faults. No signup.
