Decide what you need to learn
Before installing anything, write down two or three questions the data should answer. A small community organization might want to know which pages people visit before opening its volunteer form, whether visitors can find its contact page, and how often a resource is downloaded. These questions give the setup a purpose beyond collecting page views.
Choose an analytics tool that fits your website, your team’s ability to maintain it, and your privacy requirements. Read its setup and privacy guidance, particularly how it uses cookies or similar technologies and what choices visitors may need. Record who owns the analytics account and who can edit the website. Use an organization-controlled account rather than a staff member’s personal login, and give people only the access they need.
Install the tracking code once
Most analytics tools provide a site identifier and a tracking tag or an integration for your website platform. Follow the tool’s installation instructions, then place the tag in the site-wide location provided by your content management system. If you use a tag manager, add the analytics tag there instead. Pick one installation route: adding the same tag through both a plugin and a tag manager can count a single visit twice.
Publish the change and check that it reaches every page you intend to measure, including pages with different layouts. A site may use one template for articles and another for forms, so a tag added to only one template can leave gaps. If the site has a visitor consent control, configure the tag to respect the choice it records. Avoid sending names, email addresses, form answers, or other personal details in page addresses or event data.
For example, if a thank-you page appears after a volunteer form is submitted, you might measure visits to that page as a completed form action. First check that people cannot reach it simply through a menu link or bookmark; otherwise, its visits will not be a dependable count of submissions.
Test a visit from start to finish
Open the published site in a browser, make the appropriate consent choice, and visit a few distinct pages. Then check the analytics tool’s real-time view or debugging feature for those visits. It may take longer for them to appear in standard reports, so use the tool’s guidance on processing time before treating an empty historical report as a failure.
Test the actions you plan to report on, not just page loads. If you track a resource download, click the link and confirm that the expected event appears with a clear name. If you track a form completion, submit a test entry using the normal visitor path and look for one completion event. Note the test time and the pages you used so another team member can repeat the check.
A browser’s developer tools or a tag-checking tool can help confirm whether the tag loads, but a loaded tag alone does not prove the analytics system accepted the data. Look for the test visit in the analytics interface as well. Test on a phone and a desktop browser if they use different site layouts, and try the consent options your visitors can choose.
Investigate missing or unexpected numbers
If nothing appears, check the basics in order: Is the change published? Is the site identifier correct? Is the tag present on the page you tested? Did your consent choice allow tracking? Browser privacy settings, extensions, and network filters can also prevent a test visit from being recorded. Try another browser before changing the installation.
If numbers look too high, look for duplicate tags, events that fire on both a click and the following page load, or test activity from your own team. If they look too low, check pages that use separate templates and actions that move visitors to another service. Document any exclusions you configure, such as internal traffic, so future readers of the reports know what is missing.
Keep the setup useful
Once the tests pass, create a short measurement record: the questions you want to answer, the pages and events you track, where the tag is installed, how consent affects collection, and the date the setup was checked. Keep it somewhere the website team can find it. This makes it easier to troubleshoot after a redesign or a change in staff.
Review the setup whenever you add a new form, change a page template, or replace a website plugin. A brief monthly check of a key page and action can also catch problems before they affect a long stretch of reporting. Treat analytics as an aid to decisions, not a perfect account of every visitor: some people will decline tracking or use tools that block it. Consistent definitions and a verified workflow are more valuable than a large dashboard you cannot explain.
