You did not build your GTM container. An agency did, or a freelancer, or a developer who has since moved on. You inherited it, assumed it was fine, and kept running ads against the data it produces. 70% of WooCommerce stores have broken or incomplete Google Tag Manager tracking — and most discover this only after weeks of misallocated ad spend (Conversios, cited by Seresa, 2025).
GTM Preview mode shows green. That does not mean the data is right. GTM Preview Mode has 26 documented failure scenarios where a green tick does not confirm production accuracy (Analytics Mania, cited by Seresa, 2025). The container looks fine. The data feeding your campaigns is silently wrong.
This is the 10-point audit that surfaces what is broken — and what it is costing you. It takes 30 minutes. You do not need a developer to run it.
Before You Start: Open GTM in One Tab, Your Live Site in Another
You need access to your GTM container (container.google.com), your live WooCommerce store in a browser with the GTM Preview extension active, and your GA4 Realtime reports. Keep all three visible. Each check below tells you where to look and what a pass versus a failure looks like.
The 10-Point Audit
Check 1: Is GTM Actually Firing on Every Page?
Open your live site with GTM Preview active. Navigate to your homepage, a product page, category page, and checkout. GTM Preview should show your container connected on every page. If Preview shows “Tag Assistant not connected” on any page, your GTM snippet is missing or broken on that page type. This is the most fundamental failure — and it is more common than you would think on WooCommerce sites that have had their theme updated since GTM was installed.
Pass: GTM Preview connects on all page types.
Fail: Disconnected on one or more page types — check that wp_head() is present in your theme and your GTM snippet is correctly placed.
Check 2: Do You Have a Duplicate GA4 Configuration?
Go to Tags in your GTM container and search for “GA4” or “Google Analytics”. Count the configuration tags. There should be exactly one GA4 Configuration tag. If you have two — one installed via GTM and one via a WordPress plugin like Site Kit — every pageview is being sent twice. Your session counts are inflated. Your conversion rate is understated. Every decision you make from GA4 is skewed.
Pass: One GA4 Configuration tag, no plugin installing GA4 separately.
Fail: Two or more sources sending to the same GA4 property — deactivate the plugin version and keep the GTM version.
Check 3: Does Your Purchase Tag Have a Deduplication Mechanism?
Find your purchase or conversion tag — the one that fires on the order confirmation page. Now find its trigger. Is it firing on a URL match like “/order-received/”? Without a deduplication mechanism, every time someone visits that URL — including when they refresh, share the link, or return to check their order number — the tag fires again. Your purchase data is inflated. Your ROAS figures are wrong.
Pass: Purchase tag uses a dataLayer event like purchase pushed by your WooCommerce plugin, not a URL-based trigger.
Fail: URL-based trigger on the thank-you page — implement transaction ID deduplication or switch to a dataLayer-driven trigger.
You may be interested in: Your WooCommerce Tracking Failed 30 Days Ago
Check 4: Are Tags Firing on Admin and Logged-In Pages?
Log into your WordPress admin and open your site with GTM Preview active. Check which tags fire when you browse your own store. If your GA4 event tag fires when you, your team, or your developers visit the site, you are polluting your analytics with internal traffic. Poor data quality costs organisations an average of $12.9 million per year (Gartner, 2025) — internal session contamination is one of the most common preventable sources.
Pass: Tags have exclusion conditions filtering out admin users, or your GA4 property has an internal traffic filter active.
Fail: Tags fire on all sessions regardless of user role — add a trigger exception for logged-in admin users.
Check 5: Do Your Trigger URL Patterns Match Your Current Site Structure?
WooCommerce URL structures change. Slugs get updated. Permalink settings get adjusted after migrations. Go through every trigger that uses a URL match condition. Open your live site and verify that each URL pattern still matches actual pages.
Pass: All URL-based triggers match current live page structures.
Fail: Triggers referencing old URL patterns (e.g. /shop/checkout/ when your current URL is /checkout/) — update each pattern and republish.
Check 6: Are There Dead Tags From Old Campaigns?
Open the Tags list and look at every active tag. For each advertising tag — Google Ads remarketing, Facebook Pixel, TikTok, LinkedIn — ask whether the campaign it supports is still running. GTM4WP is active on over 500,000 WordPress installs (WordPress.org, 2025). Most containers on stores older than 12 months are carrying tags from campaigns that ended years ago. Every one of those tags loads on every page and costs your visitors milliseconds they did not consent to spend.
Pass: Every active advertising tag maps to a currently running campaign or active remarketing audience.
Fail: Tags from ended campaigns are still active — pause or delete them.
Check 7: Do Your dataLayer Variable Names Match Your Plugin?
Your GTM container references variable names like ecommerce.purchase.transaction_id or ecommerce.items. These names are defined by whichever WooCommerce tracking plugin pushes your dataLayer — GTM4WP, DataLayer for WooCommerce, or similar. If that plugin was updated, swapped, or removed, the variable names may have changed while your GTM variables still point to the old ones. Your tags appear to fire. They are capturing nothing.
Pass: Open GTM Preview on a product page and purchase flow — GTM Variables panel shows populated values for all ecommerce variables.
Fail: Variables show “undefined” or blank — check that your plugin is active, updated, and its dataLayer output matches your GTM variable configuration.
You may be interested in: How to Check If GTM Is Actually Working on Your WordPress Site
Check 8: Is Consent Mode V2 Integrated and Initialised Before GTM Fires?
Open your page source and find your GTM snippet. Search above it for gtag('consent', 'default'. That consent initialisation must appear before GTM loads — not after, not alongside. If GTM fires first, it fires with no consent state defined and defaults to granted behaviour. Your consent banner is cosmetic. Your compliance is not real.
Pass: Consent default initialisation appears above the GTM container script in page source, with all four consent types set: ad_storage, analytics_storage, ad_user_data, ad_personalization.
Fail: GTM appears before consent initialisation, or consent initialisation is missing — fix script loading order before any other optimisation.
Check 9: Does Your Live Site Match What Is Published in GTM?
Open GTM and check the current published version number. Then open GTM Preview and compare what fires in Preview against what you expect from the published container. If there is a mismatch — tags firing in Preview that should not be live, or tags expected to fire that are not — your published container does not match your workspace edits.
Pass: Published version reflects all intended tag configurations. Preview behaviour matches expectations.
Fail: Unpublished workspace changes are affecting your expectations — review workspace edits, confirm what is actually live, and publish a clean version.
Check 10: Is Your Purchase Data Reaching GA4 With the Right Parameters?
This is the final confirmation check. Open GA4 Realtime, place a real test order on your store using a low-value product, and watch the Realtime Events panel. Within 30 seconds you should see a purchase event appear with a transaction ID, revenue value, and at least one item in the items array. If the event appears without a transaction ID, or with zero revenue, or with no items — your ecommerce data is structurally incomplete. 62% of WooCommerce stores running GTM hit exactly this structural wall, where GTM cannot pass what the dataLayer does not provide (SimilarTech, cited by Seresa, 2025).
Pass: purchase event visible in GA4 Realtime with correct transaction ID, revenue, and items populated.
Fail: Event missing, revenue zero, or items array empty — the dataLayer push from your WooCommerce plugin is incomplete or misconfigured.
What the Audit Results Tell You
Checks 1 through 7 are fixable within GTM itself. Adjust triggers, remove dead tags, update variable names, add deduplication — most of these are configuration corrections that take less time than the audit did. Check 8 is a consent architecture issue that requires coordination between your consent plugin and your GTM setup.
Check 10 is different. If your purchase event is arriving in GA4 without complete data, the problem is not GTM configuration — it is what GTM has access to. GTM can only pass what the browser’s dataLayer provides. If your WooCommerce plugin is not pushing complete ecommerce data to the dataLayer, no amount of GTM configuration fixes that. That is an architectural constraint of client-side tracking.
The Transmute Engine™ resolves that constraint at the server layer. Events are captured from WooCommerce server-side hooks — the same hooks that process the actual order — before they touch the browser. Transaction IDs, revenue, items, customer data: all present, all accurate, regardless of what the browser dataLayer does or does not contain. A GTM container audit surfaces where client-side tracking has reached its ceiling. Server-side capture removes that ceiling entirely.
Key Takeaways
- 70% of WooCommerce stores have broken GTM tracking — a container that has never been audited is almost certainly wrong somewhere.
- GTM Preview green does not mean production accurate — 26 documented failure scenarios exist between preview and live.
- Duplicate GA4 tags and URL-based purchase triggers are the two most common errors that silently corrupt your data.
- Dead tags from ended campaigns cost page speed and load on every visit — audit and remove them.
- Consent Mode V2 must initialise before GTM loads — check your page source, not just your banner.
- If your purchase event is incomplete in GA4, the problem is the dataLayer, not the tag — that requires a server-side fix.
Use GTM Preview mode to confirm the container connects on all page types, then place a test order and verify the purchase event appears in GA4 Realtime with a correct transaction ID, revenue value, and items array. If any of those three fields are missing or zero, your ecommerce tracking is structurally incomplete regardless of how the GTM Preview tick looks.
Start by listing every active tag and mapping each one to a currently running campaign, active audience, or live tracking requirement. Any tag with no active purpose should be paused and documented before deletion. Then audit your triggers — URL patterns change with site migrations and WooCommerce updates, and stale triggers silently break without error messages. Fix triggers, remove dead tags, verify variable names match your current dataLayer plugin.
Run all 10 checks from this audit before launch. Priority items: confirm the GTM snippet fires on all page types, verify Consent Mode V2 initialises before GTM loads, test a real purchase event end-to-end in GA4 Realtime, confirm no duplicate GA4 configuration exists, and check that your purchase trigger uses a dataLayer event rather than a URL match to prevent double-counting on order confirmation page refreshes.
GTM Preview confirms that tags fired — it does not confirm that the data inside them was correct. A purchase tag can fire with an empty transaction ID, zero revenue, and no items in the items array, and Preview will show a green tick. The issue is the dataLayer: if your WooCommerce plugin is not pushing complete ecommerce data, GTM has nothing to pass. Check the Variables panel in Preview during a test purchase to see what values GTM is actually capturing.
