How to audit your analytics implementation

Most analytics implementations were correct once. Then a redesign moved a button, a marketing tag was added without anyone checking what it also sent, and a dashboard kept displaying numbers nobody had re-verified. An audit is the process of walking backward from what dashboards report to what actually happens on the page or in the app, checking every step in between. Run one whenever a number is disputed, before a major redesign, and on a fixed schedule — annually at minimum — even if nothing seems wrong.

Start with the questions the business actually asks

Before opening any tool, list the five or six questions the organization uses analytics to answer — traffic by channel, conversion rate, activation, revenue by segment. The audit's job is to verify the path from raw collection to each answer, not to review every tag that has ever been installed. A tag firing correctly but feeding nothing anyone reads is a cleanup item, not a priority finding.

This ordering matters because an audit with no scope tends to expand indefinitely — every tool has some tag, some event, some dashboard that could be checked, and a team without a fixed list of what matters will spend a week finding low-stakes issues while a genuinely broken conversion tag sits unexamined. Time-box the audit and prioritize by what a wrong number would actually cost the business if nobody caught it.

Layer 1: what fires on the page or in the app

• Open the browser's network tab (or the tag manager's preview mode) on the two or three highest-traffic page types and confirm every expected tag fires, once, with the right parameters — not zero times, and not twice from a duplicate installation. For a destination such as Google Analytics 4, check the request itself, not just the tool's own real-time report, since the report can mask a malformed parameter that still technically arrives.
• Check the data layer itself: does it contain the values the tags read, in the format they expect? A tag reading order_total from a data layer that publishes orderTotal fails silently — no error, just a missing or zero value downstream.
• Look for tags that should not be there. Old A/B testing snippets, a competitor's pixel added during a since-cancelled partnership, and duplicate installs from a platform migration all accumulate and can skew load time and even conversion tracking through unrelated redirects.
• Check for bot traffic inflation on high-value events — a spike in "sign-ups" with no matching activity two steps later is usually automated traffic, not a growth win.

Layer 2: how consent gates collection

• Trigger the consent banner's "decline" path and confirm the tags that should be blocked actually are, not just visually hidden while still firing in the background.
• Confirm the consent mode configuration matches what your legal or privacy team believes is deployed — this is the single most common gap between "documented" and "shipped."
• If consent state changes what is measured, confirm your dashboards or their footnotes say so. Comparing a pre-consent-banner month to a post-banner month without that caveat produces a misleading trend line.

Layer 3: tag manager hygiene

• List every tag in Google Tag Manager or your tag manager of choice, its trigger, and who owns it. Anything with no known owner is a candidate for removal.
• Check publish history for changes with no matching ticket or change request — an unreviewed edit is how most tracking regressions start.
• Confirm staging and production containers are actually different, and that nobody is testing changes directly in production.

Layer 4: event and property data quality

• Pick your five most-used events and pull a day of raw data. Check for nulls in fields marked required, values outside the allowed range, and unit mismatches (cents vs dollars, seconds vs milliseconds) that a tracking plan should have prevented — see how to write a tracking plan if none exists.
• Compare volumes across a known event to a second, independent source — server logs, a payment processor's own count, a CRM record count. A gap larger than a few percent is a real finding, not noise. If a customer data pipeline such as Segment sits between collection and every destination, check its own delivery logs for a layer where drops or transformation errors are visible independent of any single downstream tool.
• Check timestamp handling: are events timestamped client-side (vulnerable to clock skew and delayed sends) or server-side, and does every report assume the same one?

Layer 5: reports and dashboards

• For each of the business questions from the start of the audit, open the dashboard that answers it and trace every number back to its source query. Confirm the filter logic, date range handling and any exclusions (internal traffic, test accounts) match what the dashboard's title implies.
• Look for orphaned dashboards — built for a project that ended, still linked from a wiki page, still occasionally consulted with stale assumptions.
• Check who can edit versus only view. A dashboard that anyone can silently modify is a data-quality risk of its own.

Turn findings into a report, not a list

Group findings by severity and by who must fix them: a broken conversion tag is urgent and usually one team's fix; an inconsistent naming convention across events is important but can be scheduled; an orphaned dashboard is low-priority cleanup. Attach an owner and a date to each item — an audit that ends as an unassigned document repeats itself next year with the same findings.

A short summary at the top — what was checked, what was found, what changed as a result — is worth writing even for an internal audit nobody outside the team will read. It is the artifact that lets the next person running this audit start from where the last one left off, instead of re-discovering the same handful of known issues from scratch.

Who should run it, and with what access

An audit needs read access across the whole path — the site or app itself, the tag manager, the analytics or event tool, and whatever warehouse or reporting layer sits downstream — which usually means either a single person with broad access or a short-lived cross-functional group for the duration of the audit. Running it as a checklist one person completes alone, without input from whoever owns the tagging and whoever owns the dashboards, tends to miss the layer-4 and layer-5 findings above, since those require knowing what a number was supposed to mean, not just whether a tag fired.

How often to repeat it

• After any redesign or platform migration. These are the highest-risk events for silent breakage.
• Quarterly, lightweight. Spot-check the top few events and dashboards only.
• Annually, full. Repeat every layer above.
• Immediately, when a number is disputed. A disputed number is the fastest way to find a real gap, because someone is already motivated to look closely.

Where to go next

Pair this audit with establishing data governance so ownership survives the next reorganization, and with building a dashboard people use once the underlying data is trustworthy again. Tag management and web analytics tools are browsable at event collection and tracking pipelines and web analytics tools; for a full platform comparison see how to choose a web analytics tool.