An analytics data-validation checklist
Before you act on a report, validate the data that produced it. This checklist walks the recurring failure points — duplicate tags, unfiltered bots, internal traffic, wrong time zone, broken events, sampling — and gives a concrete check for each. Run it after any tracking change and periodically, so a metric you trust is a metric you have verified.
Before you trust a number
Most analytics mistakes are configuration, not interpretation. The same handful of issues recur across sites: a tag fires twice, bots are not filtered, the team's own visits are counted, the reporting time zone is wrong, an event quietly broke after a deploy, or a report is sampled. Each is checkable in minutes.
Treat validation as a routine that runs after every tracking change and on a regular cadence, not a one-off at launch.
The checklist
Work top to bottom; a single failure can invalidate a whole report. Confirm the page tag is present exactly once, then walk the rest in order. Re-run the list whenever you change the site, the tag manager, or the analytics configuration.
- Tag fires exactly once per page (no duplicate loads)
- Bot and spam traffic is filtered or classified out
- Internal and QA traffic is excluded
- Reporting time zone and currency are correct
- Key events fire with the right parameters after deploys
- Hostname/valid-property filtering blocks ghost hits
- Check whether the report is sampled before deciding
How it appears in analytics and logs
A report that passes every item is trustworthy for its purpose; a failed item tells you exactly which metric to distrust and why.
Diagnostic use case
Run a fixed validation pass after tracking changes and on a schedule, so decisions rest on data whose known failure points have been checked.
What WebmasterID can help detect
WebmasterID's Event Explorer lets you inspect raw first-party events to confirm a tag fires once and the right parameters arrive — the core of validation.
Common mistakes
- Validating once at launch and never again.
- Trusting a report without checking for duplicate tags.
- Skipping event checks after a site deploy.
Privacy and accuracy notes
Validation inspects configuration and aggregate counts, not individuals. Keep test data and debug views free of unnecessary personal detail.
Related pages
- Double-counting pageviews
Double-counting happens when a single page load fires the analytics tag more than once. Two snippets on the page, a tag added in both the site and a tag manager, or an SPA that fires a virtual pageview on top of the full-load one all do it. The result inflates pageviews and drags engagement and bounce metrics. This page covers detection and the fixes.
- Filtering internal traffic
Visits from your own team, contractors, and office networks inflate engagement on a small site and pollute conversion tests. Analytics tools let you define and filter internal traffic, usually by IP range or a tagging rule. This page covers how internal-traffic filtering works, why developer and QA traffic matters most, and the common mistakes that leave it on.
- Validating event tracking
Custom events power conversions, funnels, and product analytics — and they break quietly. A renamed CSS selector, a refactor, or a tag-manager edit can stop an event firing or change its parameters without any error. This page covers validating events: confirming they fire on the right action, exactly once, with the expected name and parameter values.
- Event Explorer
Inspect raw events to validate tags and parameters.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.