What a measurement plan contains
A measurement plan is a short document written before any tag is installed. It starts with the business objectives, turns each one into a question somebody will genuinely ask at a review, names the metric that answers that question, and then names the event or field that has to be captured for the metric to exist at all. Read from the bottom up, the same document becomes the tagging brief for whoever does the implementation.
A working plan also records who owns each number, how often it is reviewed, and what would be done differently depending on the answer. That last column is what keeps a plan honest. If no decision changes whatever the number says, the number does not need collecting.
Why a measurement plan matters
It prevents the two failure modes I meet most often in accounts I take over. One is a site with almost nothing tracked, where every question needs a month of waiting before it can be answered. The other is a site with a sprawl of events nobody can name, built up by several agencies over the years, where the reports contradict each other and nobody trusts any of them.
It also makes handovers survivable. Staff change and agencies change, and the plan is usually the only record of why a particular event exists. Without it, the safest thing anyone can do with an unfamiliar tag is leave it alone forever, which is how sprawl begins.
Common mistakes with measurement plans
Writing it after the build is the big one. Done in that order it becomes a description of whatever happens to exist rather than a specification of what is needed, and it inherits every gap in the setup.
Overreach is the next. A plan listing every conceivable interaction never gets implemented in full, and the portion that does get built ends up chosen more or less at random by whoever ran out of time.
Confusing metrics with steering numbers causes the rest of the trouble. A plan should separate the handful of figures a decision hangs on from the many that only provide context; the entry on KPIs covers that distinction and why it is worth drawing sharply.
How to build one
Start with a small number of objectives written in plain business language — more qualified enquiries, higher order value, fewer support calls. For each, write the question you would ask at a monthly review, then the single metric that answers it, then the event, parameter or sales-system field that metric depends on.
Add the naming convention next. Decide once how events and campaigns are named and keep it consistent, because renaming later breaks historic reporting. Then agree the definitions in writing: what counts as a lead, when a lead becomes qualified, which currency figures are reported in, and which system is the final word when two disagree.
Keep the document short enough that people actually read it, and revisit it whenever the business changes. If the plan and the account have drifted apart, the plan is corrected first, and then the tracking implementation is brought back into line with it.