Your GTM setup looks correct. The tags fire in Preview. The variables return values. And GA4 still shows fewer purchases than your WooCommerce order count. The problem isn’t always configuration—often it’s that two specific events silently fail on classic checkout, and browser-based tracking loses 30-40% of data regardless of how clean your setup is.

Here’s the diagnostic event map most GTM guides skip: every GA4 ecommerce event, the WooCommerce page it belongs to, and the exact failure mode that kills it.

The Six GA4 Events Your WooCommerce Store Is Supposed to Fire#

Google Analytics 4 uses a standardized ecommerce event sequence. For a WooCommerce store, that sequence runs from product discovery through confirmed purchase. GTM4WP—installed on 2M+ WordPress sites (WordPress.org, 2025)—pushes these events to the dataLayer so GTM can forward them to GA4.

But “pushes these events” depends heavily on your checkout setup.

view_item — Product Page

Fires when a visitor loads a single product page. This is the most reliable event in the sequence—GTM4WP pushes it on woocommerce_after_single_product. Failure mode: none if GTM4WP is installed and configured correctly. Check GTM Preview on a product URL and you’ll see it fire immediately.

add_to_cart — Product or Cart Page

Fires when a visitor adds a product to their cart. Variable products (products with size, colour, or other attributes) are the common failure point—if the variation isn’t selected before the add_to_cart button click, some configurations push incomplete item data. Test by adding a variable product to cart and checking the dataLayer push for a complete items array including item_variant.

begin_checkout — Checkout Page Load

Fires when the checkout page loads. Generally reliable. The common failure mode here is page caching—if a caching plugin or CDN serves a cached checkout page, the dataLayer push may not include current cart contents. Always exclude the checkout URL from your caching rules.

You may be interested in: When Does WooCommerce Fire Your Conversion?

add_payment_info and add_shipping_info — The Two That Never Fire

This is where most WooCommerce GA4 setups break silently.

add_payment_info and add_shipping_info require WooCommerce block checkout. Classic checkout—the shortcode-based version using [woocommerce_checkout]—never pushes these events to the dataLayer at all (Seresa, 2025).

GTM doesn’t show an error. GTM Preview doesn’t flag anything. The events simply never arrive. If your store is on classic checkout, your GA4 funnel analysis is missing two of its six steps, with no warning anywhere in the interface.

Block checkout (introduced via WooCommerce Blocks) uses React-based components that emit real-time dataLayer events as shoppers interact with the payment and shipping sections. Classic checkout processes everything server-side on form submit—there’s no JavaScript hook for payment or shipping selection events.

purchase — Order Confirmation Page

Fires on the thank-you page after a successful order. This is the event every store checks first—and the one where the real gap becomes visible. If your GA4 purchase count is more than 5-10% below your WooCommerce order count, you have structural data loss beyond configuration errors.

Cross-checking GA4 purchases against WooCommerce orders is the fastest way to quantify the problem. A 20-30% gap is common. A 40%+ gap usually indicates multiple compounding issues.

Why a Perfect GTM Setup Still Loses 30-40% of Purchase Data#

Configuration is the first problem. Structural loss is the second—and it affects every event in the sequence, even the ones set up correctly.

Browser-based GTM tracking loses 30-40% of WooCommerce conversion data to ad blockers, Safari ITP, and consent rejection combined (Seresa, 2026). Here’s what’s happening:

Ad blockers intercept the GTM container script before it loads. 31.5% of global users run ad blockers (Statista, 2024). On those browsers, no GTM events fire at all—not view_item, not purchase, nothing.

Consent rejection compounds this. In the EU, 60-70% of visitors reject cookies under Consent Mode v2 (Seresa, 2026), suppressing all GTM marketing and analytics tags. The store owner sees a compliant banner—and loses the majority of EU purchase data.

Safari ITP limits first-party cookies set by JavaScript to 7 days. For stores with longer purchase cycles—research-heavy products, B2B, seasonal items—multi-session attribution breaks entirely.

GTM Preview on your own browser, with no ad blocker and accepted cookies, shows clean event firing. That test represents a fraction of your actual visitors.

You may be interested in: WooCommerce Says 50 Orders, GA4 Says 32, Facebook Claims 18

How to Audit Your WooCommerce GTM Event Setup#

Run these checks before assuming your GA4 data is accurate.

Step 1: Confirm your checkout type. In WooCommerce → Settings → Payments, check whether you’re using the block-based checkout. If you’re on classic checkout, accept that add_payment_info and add_shipping_info won’t fire—and weigh the migration cost accordingly.

Step 2: Test each event in GTM Preview on an actual purchase flow. Don’t test on your own device with cookies accepted. Use a browser profile with no extensions, and also test in private mode with a fresh Safari session to see what consent-rejecting visitors experience.

Step 3: Cross-check GA4 purchases against WooCommerce orders. Pull both numbers for the same 30-day period. The gap is your structural data loss floor. Poor data quality costs organisations an average of $12.9 million per year (Gartner, 2025)—for WooCommerce stores, the direct cost is misdirected ad spend optimising against incomplete conversion data.

Step 4: Check GTM4WP configuration for variable products. In GTM4WP settings, confirm enhanced ecommerce is enabled and that the add_to_cart event passes full item data including variation IDs.

Step 5: Verify purchase events in GA4 Realtime, not just GTM Preview. A purchase event appearing in GTM Preview means it fired in the browser. Seeing it arrive in GA4 Realtime → Events confirms it actually reached Google’s servers through the full delivery chain.

The Structural Fix: Capture Events Before the Browser#

Configuration fixes close the gap on add_payment_info and add_shipping_info (by migrating to block checkout) and on variable product add_to_cart events. They don’t fix structural data loss from ad blockers, ITP, or consent rejection—because those block the delivery mechanism itself, not the event configuration.

The structural fix moves event capture upstream. Transmute Engine™ is a first-party Node.js server that runs on your subdomain (e.g., data.yourstore.com) and captures WooCommerce events via the inPIPE plugin’s API calls—before browser restrictions ever apply. The purchase event is captured at the order, not the browser session. Ad blockers can’t intercept it. The data arrives in GA4, Facebook CAPI, and BigQuery simultaneously.

Key Takeaways#

• Six events, one sequence: view_item → add_to_cart → begin_checkout → add_payment_info → add_shipping_info → purchase. Two of these require block checkout.
• Classic checkout silently breaks two events: add_payment_info and add_shipping_info never push to the dataLayer on classic checkout. No error, no warning.
• GTM Preview is an optimistic test: It shows events firing on your browser. It doesn’t show what ad-blocking, consent-rejecting, Safari-using visitors experience.
• Cross-check against WooCommerce orders: Compare GA4 purchase count to WooCommerce order count over 30 days. A gap over 10% confirms structural data loss.
• Configuration fixes have a ceiling: Even a perfect GTM event setup loses 30-40% of data to browser restrictions. Capturing events server-side removes that ceiling.

If your GA4 purchase count doesn’t match your WooCommerce orders, start with the event audit above—then decide whether a configuration fix closes the gap or whether the structural loss requires a server-side solution.