Write the measurement plan before you write the tracking code

There is a familiar way a tracking project begins. Someone installs the analytics tag, someone else asks for "all the events", and a few weeks later there are three hundred of them. Nobody can say what half of them mean, the dashboards disagree, and the question that started the whole exercise is still unanswered.

The fix is dull and works every time: write the measurement plan first. One page is enough.

Start with the decision, not the data

For every number you intend to collect, ask: what will someone do differently depending on this number? If you cannot name the decision, you do not need the number yet.

A useful plan reads from the top down:

1. Business goal. What the organisation is trying to achieve. Grow subscriptions, reduce support costs, sell more of one product line.
2. Decisions. The choices people will make to get there. Which landing page to keep, where to spend the next budget, whether the checkout needs a redesign.
3. Questions. What you would need to know to decide. Where do visitors drop out of checkout? Which sources bring people who stay?
4. Metrics. The measures that answer those questions, defined precisely.
5. Events and properties. What the site or app must record to calculate each metric.

Most teams start at step 5 and work backwards, hoping it all adds up. Starting at step 1 means every event has a reason for existing, written next to it.

Define metrics so two people get the same number

"Conversion rate" can mean orders divided by sessions, by users or by product page views. They give three different answers. For each metric, the plan should say:

• Name. One name, used everywhere.
• Definition. The exact formula and which events feed it.
• Segments. The cuts people will want: device, channel, country, new or returning.
• Owner. The person who answers when someone asks what it means.

A shared definition is cheaper than the meeting where two dashboards disagree.

Keep a tracking specification beside it

The plan says why. A tracking specification says how: for each event the exact name, when it fires, the parameters it carries with an example value, and where it is implemented. Developers build from it, testers check against it, and analysts read it a year later when they have forgotten everything. The data layer guide and the UTM conventions guide describe two parts of that specification.

What the plan prevents

• Tracking nobody uses. Every event costs build time, testing time, and a little more clutter in every report forever.
• Missing the one number you needed. Starting from the decision exposes the gap while it is cheap to close.
• Privacy problems. When each field has a stated purpose, it is easy to see that nobody needs the full e-mail address, and to leave it out.
• Endless argument. A written definition ends the debate about whose number is right.

A plan that stays alive

A measurement plan is not a document you write once. Review it each quarter: retire the metrics nobody opened, add the ones new decisions call for, and update the specification to match what the site now does. A short plan, kept current, is worth more than a long one nobody trusts.

If you do one thing first, take your three most important reports and write, next to each, the decision it supports. If you cannot, you have found your first thing to fix.