Google Tag Manager Audit: 20 Checks Before You Trust Your Data

Container hygiene (checks 1–3)

Start with the container itself before looking at a single tag. Most structural faults downstream trace back to a decision someone made at this level.

1. 1. One container per site, one site per containerOpen the site's page source and confirm exactly one GTM snippet is present (search for 'gtm.js'). Multiple containers on the same page cause undefined load order, duplicate tags firing from both containers, and consent logic that only one container respects. If a previous agency installed their own container on top of yours, one of them has to go — merging is usually faster than untangling.
2. 2. Workspaces and uncommitted changesCheck Admin → Workspaces and the version history. Multiple stale workspaces signal abandoned parallel edits, and uncommitted changes sitting in the default workspace mean someone's half-finished work can ship with your next publish. Two or more 'Default Workspace (2)', '(3)' copies usually mean two people have been editing blind.
3. 3. Access, environments and staging leakageReview who has Publish access (it should be a handful of people, not 'everyone who ever worked on the account'), and check every environment snippet. The classic fault: the staging environment's GTM snippet is identical to production, so every test form fill on staging fires real conversions into the production GA4 property and Google Ads account. If you can't demonstrate how staging traffic is excluded, that's a finding.

Tag inventory (checks 4–6)

Export the container (Admin → Export Container) and read it like a document — it's the fastest way to see the whole picture, including tags that don't appear in any folder.

1. 4. Dead tagsLook specifically for Universal Analytics tags (the property died in 2023, yet these survive in a surprising number of containers), old third-party pixels from previous agencies, and tags whose trigger was deleted or paused months ago. Dead tags rarely corrupt data on their own, but every one of them is load-order overhead and a signal that nobody has audited this container in a long time.
2. 5. Duplicate tagsSearch for two tags doing the same job — the most damaging version is two GA4 Configuration or Google tags with the same measurement ID, which double-counts page views, inflates sessions and can double-count every event. Two Meta pixels under different IDs from different vendors is the same disease. Keep exactly one of each, and check the version history to find out who added the second one before you delete it.
3. 6. Tag sequencing and setupGA4 event tags must wait for the configuration tag (Setup tag or tag sequencing), the Google Ads conversion linker must fire on all pages before any conversion tag, and conversion linker parameters must match the account's actual conversion IDs. Missing sequencing produces the sneakiest failure mode: everything looks fine in Preview, events occasionally arrive without session attribution, and nobody notices for months.

Triggers (checks 7–9)

Triggers decide what fires; most data corruption starts here rather than in the tags themselves.

1. 7. Map triggers to tags, and orphans to historyFor every trigger, list which tags fire from it, and for every tag, confirm its trigger still makes sense. Orphan triggers aren't a fault by themselves, but triggers named 'OLD – do not use' still being referenced by an active tag very much are. This mapping is also what makes every later check faster, so don't skip it.
2. 8. Conversions fire on real success events, not page loadsTrace each conversion-critical trigger back to its source. A trigger on a thank-you page URL counts refreshes, direct visits and back-button returns as conversions; a Form Submission trigger on a JavaScript form may never fire at all, or fire on validation errors. The reliable pattern is a custom data layer event pushed only after the server confirms success — if the container doesn't use one for its primary lead action, that's usually the single biggest accuracy finding of the whole audit.
3. 9. Where triggers shouldn't fireCheck for firing on admin, login, checkout-error and internal-team pages, and confirm internal traffic exclusion exists — either via a lookup table on an internal IP variable in GTM or a developer-set data layer flag. Internal browsing inflating engagement and conversion counts is common in smaller companies where the whole team tests the form weekly.

Variables (checks 10–11)

Variables are where containers hide their fragility, because a variable that resolves to the wrong value produces no error anywhere.

1. 10. Where each variable's value actually comes fromCustom JavaScript and DOM Element variables scrape rendered markup, which survives until the next redesign and then silently returns null — a conversion that fires without its value or its form_id. Data layer variables sourced from developer-pushed values are the durable pattern. Flag every DOM/Click-Text-based variable feeding a conversion as technical debt, and check any Auto-Event Variable usage (Click ID, Form ID) against what the forms actually render.
2. 11. Unused and stale variablesDelete variables no tag or trigger references, and verify the constants are current: the Meta pixel ID matches the active ad account, the GA4 measurement ID matches the active property (G- vs G4- prefixed legacy IDs are a recurring find), and any conversion ID/label constants match what's live in Google Ads. A wrong constant fails silently — the tag fires and the data lands in an account nobody checks.

GA4 wiring (check 12)

GA4 faults in GTM tend to be configuration faults rather than broken tags, so this check is about the wiring around them.

1. 12. One property, one config, key events marked in GA4Confirm the measurement ID points at the live property (not a demo or migrated leftover), event tags pass consistent parameters, and the events that matter are marked as key events in GA4's Admin — not merely 'configured in GTM', which does nothing by itself. Then open DebugView and watch real events arrive with their parameters: an event that fires in Preview but never appears in DebugView means a measurement ID, stream or consent problem that Preview alone can't show you.

Google Ads and Meta wiring (checks 13–14)

Both ad platforms have one make-or-break check each, and both faults produce confident-looking numbers that are wrong.

1. 13. Google Ads: linker, enhanced conversions, no double countingConfirm the conversion linker fires on every page before any conversion tag, that enhanced conversions are configured on the tags that support them, and — the expensive one — that the same action isn't counted twice: a native Google Ads conversion tag plus an imported GA4 key event for the same outcome double-counts in Google Ads reporting. One source of truth per action; the other becomes a secondary (or gets deleted).
2. 14. Meta: pixel and CAPI deduplicationIf both the browser pixel and the Conversions API (through GTM server-side or a gateway) fire the same events, they must share event names and event_id values for deduplication to work — check a real event's payload for the event_id on both paths. Also confirm one base pixel ID and no duplicate PageView: a GTM-managed pixel plus a hard-coded pixel snippet in the theme double-counts everything at the top of the funnel.

Duplicate firing and event integrity (checks 15–16)

These two checks are where you find out whether the container's output matches its intent.

1. 15. Count firings per action in PreviewWith Preview mode attached, perform each key action once — one form submit, one phone click, one purchase — and count how many times each relevant tag fires. The classic finds: form triggers firing on both 'submit' and 'click', a consent banner interaction triggering a second page_view, and multi-step forms firing the lead event at step one. Anything firing more than once per real action is a finding, even if it's 'only' an event and not a conversion.
2. 16. Event names match a written planList every custom event the container fires and check the names are consistent snake_case, match the parameters they carry, and — the real test — match a written event plan that someone could reconstruct the container from. If the names only make sense to the person who left the company two agencies ago, the container isn't maintainable no matter how well it fires.

Debugging workflow (check 17)

A container without a debugging routine gets audited only when something is already broken.

1. 17. Verify the full chain, not just PreviewPreview mode proves a trigger fired — it doesn't prove the data landed. Verify each critical path end to end: GTM Preview shows the tag firing once with correct variable values, the network request actually reaches the endpoint (GA4's DebugView, Google Ads' Tag Assistant, Meta's Pixel Helper or Events Manager test events), and a genuine test action appears in the platform's reporting within its normal processing window. Document which of these steps the team actually runs today; 'we trust it because it worked when we set it up' is itself a finding.

Consent, naming and documentation (checks 18–20)

The last three checks decide whether the container stays trustworthy after the audit ends.

1. 18. Consent actually enforced, not just displayedIf the site serves UK/EU visitors, check that consent mode defaults to denied before the banner appears, that tag firing actually consults consent state (GTM's built-in consent checks or additional consent settings), and that a 'denied' session produces no analytics or ad tags in Preview. A banner that displays but never gates anything is the most common consent finding I see — the widget exists, the enforcement doesn't.
2. 19. Naming conventions and foldersCheck tags, triggers and variables use consistent, scannable names — 'GA4 – Event – generate_lead', 'Ads – Conversion – Contact Form' — grouped into folders by platform or purpose. The test: can someone find every conversion-related tag in under a minute without Preview mode? Inherited containers full of 'Copy of Copy of tag' aren't just untidy; they hide the duplicates that check 5 exists to catch.
3. 20. Version notes and a change logRead the last ten versions' notes. 'Updated tags' tells the next auditor nothing. Healthy containers have per-version notes naming what changed and why, plus an external record (even a spreadsheet) of the event plan, what fires where, and who owns it. Then run the 30-minute test: could a competent new analyst understand this container's structure and purpose in half an hour from the documentation alone? If not, the audit isn't finished until the documentation is written.

Score it, then act on it

Score the container out of 20 in check order rather than the order that feels easiest — trigger and firing accuracy (checks 8 and 15) genuinely matter more than naming tidiness, even though tidying is more satisfying. Below 14, resist the urge to patch the worst tag and move on: the score usually reflects a container that grew by accretion, and the durable fix is a written event plan followed by a deliberate rebuild, not a tenth patch.

The build side of the biggest findings is covered step by step in planning a GTM data layer event plan and GA4 conversion tracking through GTM. For the platform-level double-counting checks, see why Google Ads and GA4 conversion counts differ and how the Meta pixel and Conversions API deduplicate.

Get the audit done for you

If you'd rather have a specialist run this — with findings ranked by how much they're distorting your decisions, not presented as twenty undifferentiated checkboxes — that's part of Google Tag Manager setup and container cleanup and the broader conversion tracking work I do. Book a 30-minute call and I'll tell you honestly whether your container needs tidying, fixing or rebuilding.