Start with the decision, not the dashboard
A measurement plan is a short agreement about what your team needs to learn from its website and what it will do with that knowledge. Without one, it is easy to collect page views and clicks simply because a tool makes them available. Those numbers may be interesting, but they are only useful when they help answer a question your team can act on.
List two or three decisions you expect to make over the next few months. For example, a community organization might need to decide whether its volunteering page explains the next step clearly, whether visitors can find an event, or which service pages need clearer language. Write each decision as a question: “Should we change the volunteering page’s call to action?” This gives the team a reason to measure and a practical action to consider afterward.
Choose signals that fit each question
For each decision, identify one or two signals that could help. If the question is whether people can find an event, useful signals might include visits to the events page, use of the site’s event search, and clicks through to event details. If the question concerns a contact page, form submissions may be more relevant than total site traffic. Keep a distinction between an action you can count and the outcome you care about: a form submission is not proof that someone received the help they needed.
Write down other explanations for the pattern you see. A drop in form submissions could reflect a broken form, a change in visitor needs, or confusing instructions. A rise in visits to a help page could mean people find it useful, or that another page leaves them with unanswered questions. Pair website data with what staff hear in emails, calls, or conversations. These sources will not always agree, but together they give your team better questions to investigate.
Define what you will collect
Make a small table or shared document with a row for each decision. Include the question, the signal, where the information comes from, who checks it, and the action the team might take. Define terms that could be interpreted differently. For instance, does a “contact” mean a click on an email link, a submitted form, or both? Agreeing on a definition now prevents confusion when someone reviews the numbers later.
Collect only what you need for the decision. If you want to know whether visitors reach a confirmation page after submitting a form, you may not need to retain the words they entered into that form. Check that your analytics and consent settings match your organization’s privacy practices. Limit access to the people who need it, and avoid placing personal details in page addresses or event labels. A modest, well-understood setup is easier to maintain than a long list of events nobody checks.
Check the setup before relying on it
Test each important action yourself. Open the page, follow the same path a visitor would take, and confirm that the action appears in the appropriate report. Test on a phone as well as a desktop device if your team can. Check whether internal staff visits or test submissions could distort what you see, and label any known limitations in your measurement document.
Measurement also needs context. Record significant website changes, such as a rewritten page, a moved button, or a repaired form, alongside the date your team made them. When reviewing results, compare like with like where possible and look at the underlying counts as well as any percentages. If only a few people used a page, a small change in behavior can make a proportion look dramatic. Treat that as a prompt to look closer, not an automatic verdict.
Review, decide, and keep the plan small
Set a review rhythm your team can sustain, such as a brief check-in during an existing planning meeting. Bring the original questions, the agreed signals, and notes about changes or problems. Ask what the information suggests, what remains uncertain, and what small improvement is worth trying. For example, if visitors reach a volunteering page but rarely take the next step, the team could clarify the button label and explain what happens after someone responds.
Record the decision and when you will revisit it. If the signal did not help, change or remove it rather than adding more tracking by default. If a question has been answered, replace it with the next useful question. The aim is not a perfect dashboard. It is a repeatable habit: decide what you need to learn, collect only the information that helps, check its limits, and use it to make the website more useful.
