A website measurement plan should tell you what decisions the data will support before anyone installs analytics tags. Otherwise, a business can collect page views, clicks and events without learning whether the website helps customers or produces useful enquiries. More tracking does not automatically create better understanding.
The plan connects business objectives to customer actions, data definitions, implementation checks and reporting responsibilities. It also records what cannot be measured reliably. A small, well-defined set of measures is easier to maintain and interpret than a dashboard filled with numbers that nobody has agreed how to use.
Start with the decisions the business needs to make
Ask what the team will do differently after reading the report. You might need to decide which service pages require clearer explanations, whether a campaign generates suitable enquiries or where customers struggle to complete a form. Each question points towards different evidence.
Write the decision alongside the objective. “Improve enquiries” is an objective, but it does not identify the question. “Determine whether visitors who reach the service page can complete the enquiry journey” gives measurement a clearer purpose.
Identify the person responsible for acting on the result. A report without an owner can become a monthly ritual rather than a management tool. Agree the review frequency and the information needed to make the decision responsibly.
Map the customer journey and its important steps
Describe the customer journey from the first visit through to the business outcome. A service customer may read an overview, inspect relevant details, open an enquiry form and submit a request. Other customers may telephone, email directly or return later through a different route.
Separate meaningful outcomes from supporting activity. Reading a page or clicking a contact button may indicate interest, but neither proves that an enquiry was received. A submitted enquiry may still be spam, irrelevant or incomplete. The plan should preserve those distinctions.
Include journeys that leave the website. If bookings take place on a third-party platform, record where the handover occurs and what information you can obtain from that provider. Do not treat every visitor who leaves as a failed journey when leaving is part of the intended process.
Define each measure before choosing an event name
For every measure, record what it means, how it is observed and what it excludes. A form submission measure should specify whether it fires after a successful server response or merely after the submit button is clicked. Those implementations can produce very different totals.
Google Analytics distinguishes general events from events selected as important business outcomes. Significant actions can be marked as key events. Choose that classification based on the meaning of the action rather than marking every interaction as success. Our analytics event definition guide explains how to validate those meanings.
Use clear names and a short description that another person can understand. For an enquiry event, the description might explain that the website accepted a valid request and displayed its confirmation. Record any parameters needed for analysis, such as a controlled service category, without including the customer's message or contact details.
Keep a distinction between the technical event and the business record. Analytics can describe an observed website action, while the CRM or enquiry system establishes whether the business received and qualified the request. Neither should silently replace the other.
Connect enquiries to quality without exposing personal information
Define how staff will classify enquiries in the business system. Useful categories might include relevant, out of area, duplicate and spam. Agree who records the classification and when. Inconsistent staff judgement can make a detailed analytics report appear more precise than the underlying process allows.
Review trends using appropriately aggregated information. If a campaign produces many form submissions but few suitable requests, the next question may concern targeting, the offer or the form's explanation. A rising submission count alone does not establish that the campaign is working.
Avoid sending names, email addresses, telephone numbers or free-text enquiry content into general analytics events. Review URLs too: a confirmation link or search query may contain information that should not be collected. The measurement plan should identify these exclusions before implementation.
If systems need to be connected, design the data flow deliberately with the appropriate technical and privacy owners. Do not improvise an identifier scheme simply because two dashboards offer a matching field.
Include privacy and user choices in the implementation brief
Record what each proposed technology collects, where information is sent and how user choices affect it. Consider the actual configuration rather than assuming that a tool's name determines its obligations. Measurement should be planned alongside the website's information and preference controls.
The statistical purposes exception for storage and access technologies has specific conditions. It is narrow and does not mean every analytics setup is automatically exempt from consent requirements. Have the responsible person assess the proposed use against current ICO guidance and record the decision. Our website privacy guide helps organise the technical evidence for that assessment.
Specify what happens under relevant preference states. Your testing should establish which tags operate, what they send and whether the resulting behaviour matches the approved design. A banner appearing on the screen is not enough to show that the underlying configuration works as intended.
Explain resulting limitations in reporting. User choices, blocking technologies and other gaps may mean that analytics totals differ from business records. Avoid claiming that a partially observed journey represents every visitor.
Write an implementation specification that can be checked
Create a compact event register. For each event, list the business question, trigger, permitted parameters, exclusions, relevant user-choice behaviour and test method. Add the page or component responsible and a named owner.
Check for duplicate implementations before installing anything. A tag may already be included by a website template, plugin, tag manager or booking platform. Duplicated events can make enquiry totals look impressive while weakening the report's usefulness.
Distinguish environments. Testing should not contaminate the production report without a way to identify or exclude it. Agree how internal testing and development traffic will be handled, and document the limitations of that method.
Keep version notes for changes to event definitions. If a form event changes from button clicks to successful submissions, the historical trend crosses a measurement change. Annotating that change prevents the business from mistaking it for a sudden shift in customer behaviour.
Test the whole journey, including failure and repeat actions
Submit a valid test enquiry and confirm that the website, analytics and business inbox or CRM behave as expected. Then test invalid fields, a server failure, a repeat click and a refreshed confirmation page. Determine whether each case creates zero, one or multiple records.
Test important device and navigation paths. A form opened through a campaign link may behave differently from one reached through a service page. A third-party booking handover may have its own measurement boundary. Follow the customer's actual journey rather than checking an isolated tag.
Compare a controlled set of test actions with the resulting records. Reconcile discrepancies while the examples are still known. This is easier than discovering months later that a confirmation page produced a success event whenever it was viewed directly.
Design reports around interpretation and action
A useful report can remain short. Show the objective, relevant actions, business outcome, important segments and known limitations. Include the question the team should discuss rather than expecting a chart to explain itself.
Choose denominators carefully. An enquiry rate calculated from all visits means something different from a completion rate calculated from people who started a form. State which population you are using so that readers can compare periods sensibly.
For small volumes, avoid treating a handful of enquiries as a decisive trend. Review the underlying cases and combine quantitative evidence with customer feedback. Seasonal demand, campaign changes and measurement changes can all affect what the numbers appear to show.
Giraffe Digital's digital strategy service connects customer journeys, tools and analytics, while website design makes those journeys clearer. A measurement plan brings them together before tags are installed: define the decision, observe the right action, test the implementation and use the evidence to improve the experience.
Frequently asked questions
How should we start with the decisions the business needs to make?
Ask what the team will do differently after reading the report. You might need to decide which service pages require clearer explanations, whether a campaign generates suitable enquiries or where customers struggle to complete a form. Each question points towards different evidence. Write the decision alongside the objective. "Improve enquiries" is an objective, but it does not identify the question. "Determine whether visitors who reach the service page can complete the enquiry journey" gives measurement a clearer purpose. Identify the person responsible for acting on the result. A report without an owner can become a monthly ritual rather than a management tool. Agree the review frequency and the information needed to make the decision responsibly.
