Most analytics projects start the wrong way round: the tool is installed, every available option is switched on, and only a few months later does anyone ask what the numbers mean. A measurement plan reverses the order. First you decide what you want to know, then you establish what to collect. It is a short document, often a single table, but it saves months of useless data.
The five-level structure
An effective measurement plan moves down from what matters to the organisation to the technical detail:
- Business objective: why the site exists. Example: generating quote requests.
- Questions: what you need to know to judge whether the objective is met and how to improve.
- Metrics and KPIs: the numbers that answer the questions.
- Events and dimensions: the actions to record and the information that accompanies them.
- Implementation and ownership: where and how each event is recorded, and who maintains it.
Every row at level 4 must trace back to a row at level 1. If an event answers no question, it should not be collected.
A concrete example
Imagine the website of a technical consultancy that lives on enquiries.
| Question | Metric | Event | Dimensions |
|---|---|---|---|
| How many people request a quote? | Requests sent per month | form_submitted |
service type |
| Where do the others get stuck? | Form abandonment rate | form_started, form_error |
field with error |
| Which content leads to requests? | Requests by landing page | form_submitted |
landing page |
| Is the phone used as a channel? | Clicks on the number | phone_click |
page |
| Which services attract interest? | Visits to service pages | page view | page category |
With five events, some of which are recorded by default, the consultancy has everything it needs to decide where to invest.
How to write the questions
Good questions share three traits:
- they lead to a decision: if the answer is A I will do one thing, if it is B I will do another;
- they are specific: "do users like the site?" is not measurable, "how many people who land on the pricing page move on to the form?" is;
- they have a cadence: they are reviewed weekly, monthly or with each campaign.
A useful exercise is to write, next to each question, the action you would take depending on the answer. If no action comes to mind, the question is curiosity, not measurement.
Dimensions and context
An event without context says little. "Form submitted" becomes useful once you know from which page, for which service, on which device. Dimensions should be chosen by the same standard as metrics: they exist to answer specific questions.
Be careful, though, not to put personal data into dimensions. The name of the company asking for a quote, the email address or the phone number do not belong in the analytics tool: they belong in the contact management system, not in the statistics.
Documentation and maintenance
The plan is not a document to file away. It has to be kept up to date along with the site:
- when a page or form is added, check whether new events are needed;
- when a feature is removed, delete the related events;
- each event has an owner, someone who knows where it is implemented and will notice if it stops working;
- note the date of every change, because a jump in the charts often coincides with a tracking change.
In my work I keep the plan in the same repository as the site's code, in a plain text file. That way anyone changing a form immediately sees which events depend on it.
Common mistakes
- Tracking everything "just in case": it increases noise, script weight and the amount of data to protect.
- Starting from the tools: available features are not goals.
- Forgetting negative cases: besides the form submission, you need to know when it fails.
- Inconsistent names:
submit_form,formSubmittedandform-submitfor the same action make reports unreadable. - No review: a plan written two years ago describes a site that no longer exists.
In short
- A measurement plan starts from objectives and ends with events, never the other way round.
- Every event must answer a question that leads to a decision.
- Dimensions provide context but must not contain personal data.
- The plan is maintained together with the site, with an owner for each event.
- A few well-defined events are worth more than a hundred collected without purpose.
