Website measurement plan: what should you measure beyond page views?
A measurement plan connects the business goal, user task, events, and the decision the data should support. It improves usefulness rather than merely increasing data volume.
AT A GLANCE
A website measurement plan starts by defining the user and business outcome you need to understand, then selects a small set of clear metrics and testable events. A page view alone rarely proves intent or success. The plan records each event name, exact trigger, required parameters, privacy basis, test, owner, and the decision the data will support.
- Start with the business question, not the analytics tool menu.
- Separate supporting signals from genuine business outcomes.
- Every important event needs a test, privacy condition, and decision owner.
Define the decision that needs evidence
“We want more traffic” is not yet a measurement question. A clearer question is whether the right visitor understands the service, reaches the enquiry path, and sends a request worth responding to. GOV.UK service measurement guidance similarly starts by defining what success means and what needs improvement before selecting metrics.
Write down the decision too. If few people continue from a service page to contact, what will you inspect or change? When no action could follow, the number is probably decorative reporting. Give every primary metric an owner, review cadence, and threshold or comparison that triggers investigation.
Build a short outcome chain
Separate the business outcome, user outcome, and digital signal. A business outcome might be a suitable enquiry. The user outcome is finding enough information to decide and successfully sending the request. Opening the contact page or completing a form are digital signals. They do not carry equal weight.
Add other sources when the real outcome happens later or offline. GOV.UK guidance explicitly advises against relying on digital analytics alone: feedback, sales status, support data, and usability research may also be needed. A click does not prove satisfaction, and a submitted form is not necessarily a qualified lead.
Create an event dictionary with exact triggers
For every event, state exactly when it occurs. A form submission should count only after successful server-side receipt, not when someone presses the button. Record the name, description, trigger, allowed parameters, source, and whether it is a supporting signal or key event. Use standard names when they match the meaning; Google Analytics, for example, defines recommended events for lead workflows.
Do not place personal data in event names, URLs, or free-text parameters. Campaign, page, and service identifiers should use controlled values. Too many custom parameters weaken comparison and increase data-quality errors. Collect only fields with a known purpose and retention rule.
Plan consent and data quality together
For each measurement technology, record what it stores or transmits, when it may start, and how it reacts to the user’s choice. The consent interface and actual tag behaviour must agree. Google Consent Mode documentation distinguishes default and updated consent states; configuration does not replace an appropriate notice or lawful basis.
For personal data, GDPR purpose limitation, data minimisation, and storage limitation matter while designing the field list. Compliance must be assessed for your own processing; a product default is not evidence by itself. Document which data may be missing because of consent, and do not present modelled or partial data as complete observation.
Test, annotate changes, and then interpret
Before launch, test valid and invalid forms, back navigation, double clicks, no-JavaScript submission, mobile layouts, internal traffic, and different consent states. Inspect the browser request, the real-time analytics view, and the later report. Google Analytics documentation also recommends using DebugView and Realtime after event setup.
Give every measurement change a date and short annotation; otherwise a tracking change can look like business impact. Compare periods of equal length and similar composition, mark campaigns and technical incidents, and add qualitative evidence. A useful plan produces fewer unexplained charts and more decisions that can be checked.
A PRACTICAL TEMPLATE
Website measurement plan template
The template connects the business question to the event test. It contains one synthetic example followed by blank rows; do not enter personal data.
- Business question and outcome
- Event and exact trigger
- Privacy condition
- Test, owner, and decision
Sources and further reading
- Measuring the success of your serviceGOV.UK Service Manual · Checked: 2026-10-31
- GA4 recommended eventsGoogle Analytics Help · Checked: 2026-10-31
- Consent mode overviewGoogle for Developers · Checked: 2026-10-31
- General Data Protection Regulation, Article 5European Union · Checked: 2026-10-31
Related questions
What should a website measurement plan contain?
Include the business question, user outcome, metric, exact event trigger, allowed parameters, data source, consent and retention conditions, test case, reporting cadence, owner, and the decision the data should support.
Which website events should be measured as conversions?
Choose the reliably verifiable event closest to the real user or business outcome. For an enquiry, that is usually successful server-side receipt rather than a button click or contact-page view. Keep supporting events separate and add offline outcomes when qualification happens later.
Borbély Kristóf
The developer behind Kriside, writing practical guides about web systems, automation, and AI solutions.