Every campaign I have watched go wrong went wrong in the same place, and it was never the ad. Nobody wrote down what the campaign was supposed to prove. Money went out, traffic came in, and four weeks later a room full of people argued about whether it had worked, using two dashboards that disagreed with each other.
A measurement plan is the cheapest insurance you can buy against that meeting. It takes about an hour. It fits on one page. And it is the habit that separates somebody who runs ads from somebody a company trusts with a budget.
What a measurement plan actually is
It is not a tracking specification, and it is not a dashboard. It is a written agreement, made before launch, about what you are going to decide and what evidence would let you decide it.
The tracking specification comes out of it. The dashboard comes out of the tracking specification. If you start at the dashboard you will build something that looks impressive in a screenshot and answers nothing.
Start with the decision, not the metric
Before you name a single metric, finish this sentence: in four weeks we will decide whether to …
- keep spending on this channel, or move the budget somewhere else
- send this traffic to the landing page, or to the homepage
- keep the current offer, or test a different one
- put a second person on this, or leave it as it is
If you cannot finish that sentence, you do not have a campaign. You have an expense.
The decision determines the metric, which is the reverse of how most people work. “Track everything” is not a plan. It is a way of postponing the question until the money has already gone.
The four questions the plan has to answer
What is the one number that changes the decision?
One number. Not a dashboard of twelve. Everything else is diagnostic: useful for explaining the number, not for making the call. If two metrics could each push the decision in opposite directions, you have not finished thinking about it yet.
What has to happen on the site for that number to exist?
Write the user action in plain language first. “Submits the enquiry form and reaches the thank you page.” Then, and only then, name the event, the parameters and the condition it fires on. A developer can build from the second version. Nobody can build from “track conversions”.
What would make the number lie?
List the ways it could be wrong before you trust it:
- duplicate submissions, because the thank you page can be refreshed
- consent banners blocking the tag for part of your audience
- internal traffic from your own team and your own agency
- bot traffic on a page that happens to rank
- a form that reports success before the server has accepted it
Each of these has a fix. Every one of them is cheaper to fix in the week before launch than in the review afterwards, when the number is already in a slide.
What result would make you stop?
Write the threshold down. If cost per qualified enquiry passes this figure, we stop. Agreeing that in advance is the only real protection you have against the argument you will make to yourself in week three, when the campaign is underperforming and you have already spent half the budget.
Write the events down before a developer touches anything
A short table settles more arguments than a long conversation. Four columns is usually enough.
| User action | Event | Parameters | Fires on |
|---|---|---|---|
| Submits the enquiry form | generate_lead | form_id, page_path, value | Server response 200, once per submission |
| Starts the enquiry form | form_start | form_id, page_path | First field interaction |
| Opens the pricing section | view_pricing | page_path | Section 50 per cent in view |
| Clicks the WhatsApp button | contact_click | method, page_path | Click, once per session |
Notice that the firing condition is part of the specification. “Once per submission” and “once per session” are the difference between a number you can defend and a number that quietly doubles.
Decide what good looks like before the data arrives
A result you have not set expectations for is not a result, it is a Rorschach test. Everyone will read it as confirmation of what they already believed.
You have three honest ways to set the bar. Use whichever you actually have:
- Your own history. The same channel, the same offer, the previous period. Weakest as a benchmark, strongest as an argument, because nobody can dispute your own data.
- Unit economics. What can you afford to pay for a customer and still make money? This is the only bar that matters in the end, and it is the one juniors almost never ask for.
- A documented industry figure. Fine as a sanity check, but cite it and say where it came from. Averages across an industry are made of businesses that are nothing like yours.
What to do when two reports disagree
They will disagree. The ad platform and your analytics will not match, and neither of them is lying. They are answering different questions.
The platform counts conversions it believes it caused, inside its own attribution window, often including view-through. Your analytics counts sessions it can see, after consent, attributed on a last non-direct basis. Those are two different definitions of the same word.
The fix is not to reconcile them. The fix is to write into the plan, in advance, which system is the source of truth for this decision, and to use the other one only as a directional check. Choose before the numbers are in, because afterwards everybody’s preference will happen to align with the number they liked.
Why an hour of this is worth a month of dashboards
The plan is not paperwork. It is the thing that lets you say, in a review, that the campaign was designed to answer one question, here is the evidence, and here is the decision. That sentence is the entire job.
It is also the artefact that hiring managers ask about. Anyone can say they ran campaigns. Very few juniors can put a one page measurement plan on the table and walk somebody through the reasoning behind it. If you want something in your portfolio that separates you from the rest of the applications, this is cheaper to produce than a case study and harder to fake.