Dokven

Loading Dokven.
Advanced 8 min read

How to audit GA4 and GTM tags: a practical checklist

Analytics quietly rots: duplicate tags, dead events, consent gaps, PII in parameters. A step-by-step tag audit that finds what your dashboards are hiding.

Analytics fails silently. A checkout redesign renames a button and the purchase event stops firing; nobody notices for six weeks because the dashboard still shows some number, just a wrong one. A tag audit is the periodic health check that catches this rot: proving what is actually installed on the page, what it actually sends, and whether you can trust the numbers you make decisions with.

What a tag audit checks

  • Presence: is the tag (GA4, GTM container, pixels) actually on every page it should be on, and only those?
  • Duplicates: is the same tag firing twice (hardcoded snippet plus GTM is the classic), double-counting every pageview?
  • Event coverage: do the events you report on (sign_up, purchase, add_to_cart) still fire, with the parameters reports depend on?
  • Configuration drift: right measurement ID per environment, cross-domain linking, internal-traffic filters, currency and value parameters.
  • Consent: do tags respect the consent banner, or do they fire before a choice is made?
  • Privacy: are emails, names, or tokens leaking into URLs and event parameters? GA4's terms prohibit sending PII.

The audit, step by step

  1. 1

    Inventory what is really installed

    Load key pages (home, a product or feature page, checkout or signup, a blog post) and record every analytics tag that loads: GA4, the GTM container, ad pixels, session-replay scripts. Compare against what you believe is installed. Orphan tags from old experiments show up here embarrassingly often.

  2. 2

    Hunt duplicates first

    Two GA4 tags with the same measurement ID means every metric is roughly doubled. Look for a hardcoded gtag.js snippet coexisting with a GTM-fired tag, or two GTM containers. Fix this before judging anything else; duplicated data poisons every later check.

  3. 3

    Walk one real user flow with a debugger open

    Use GA4's DebugView or GTM Preview and walk the money path: land, browse, add to cart or start signup, finish. Every step should emit exactly the events you expect, once each, with the parameters filled. Note events that never fire and events that fire twice.

  4. 4

    Diff the event names against your reports

    Pull the event list your dashboards and audiences depend on, and check each one still exists with the same spelling and parameters. Renames are the silent killer: sign_up becoming signup breaks every funnel that referenced it without a single error anywhere.

  5. 5

    Check consent behavior in a fresh session

    Open an incognito window, load the site, and watch the network before touching the banner. Which tags fire pre-consent? If you operate where consent is required, marketing tags firing before acceptance is both a compliance problem and a data-quality one (consented and non-consented traffic get mixed).

  6. 6

    Scan parameters for PII

    Search collected events for emails, phone numbers, and names, especially in page_location when forms put values in the URL. If PII reaches GA4 you are violating its terms and likely your own privacy policy; fix the source, then delete the affected data.

  7. 7

    Write down the baseline, then re-audit on a schedule

    Record what is installed, what fires where, and what each event's parameters are. The next audit becomes a diff instead of an archaeology dig. Quarterly is a good default; after every major release is better.

Symptom in reportsUsual causeWhere to look
Traffic roughly doubled overnightDuplicate GA4 tag (snippet + GTM)Page source vs container tags
Conversions flatline after a releaseRenamed CSS selector broke a click triggerGTM trigger conditions
Sessions from your own team inflate everythingInternal-traffic filter never definedGA4 data filters
(direct) / (none) suddenly dominatesCross-domain linking broken between site and checkoutReferral exclusions + linker config
Events exist but parameters are emptydataLayer push happens after the tag firesTag sequencing / dataLayer timing
Numbers differ between GA4 and ad platformsConsent gating one but not the otherConsent mode configuration
The failures that show up in almost every audit.
Audit the page, not the plan

Documentation says what should be installed. Only the live page says what is. Always audit from the rendered page inward: what loaded, what fired, what got sent.

Common questions

+How often should I audit analytics tags?
Quarterly as a baseline, plus after any release that touches templates, the checkout or signup flow, or the consent banner. Tags break when the DOM changes, and the DOM changes when you ship.
+Why are my GA4 events not showing up?
The usual suspects, in order: the event fires but only in DebugView (data can take 24 hours to appear in standard reports), a GTM trigger stopped matching after a UI change, the tag is consent-blocked, an ad blocker or CSP is blocking the request, or the event name in reports does not match what the site actually sends. Walking the flow with DebugView open pinpoints which one in minutes.
+What is the difference between GA4 and GTM?
GA4 is the analytics product that stores and reports events. GTM (a tag manager) is the delivery mechanism that decides which tags fire and when. You audit them together: GTM explains why something fired; GA4 shows what arrived.
Key takeaways
  • Audit from the live page inward: what is installed, what fires, what gets sent. Documentation lies; the network tab does not.
  • Find duplicates before anything else; doubled data invalidates every other check.
  • The money path (landing to purchase or signup) deserves an event-by-event walk with a debugger open.
  • Consent and PII checks are part of the audit, not a separate compliance chore.
  • Baseline the setup and re-audit on a schedule; a diff beats a dig.