GTM preview mode says your purchase event fired. GA4 shows nothing. You’ve refreshed the real-time report three times. Still nothing. With GTM4WP installed on over 2 million WordPress sites and Google Tag Manager commanding 94% of the tag management market (Analytico Digital, 2024), this exact scenario plays out in WooCommerce stores every day — and most store owners never find out why. The answer is one WordPress hook, one plugin update, and one design decision that were never meant to coexist.
What Changed in GTM4WP v1.21 (And Why It Matters)
Before GTM4WP v1.21, the plugin pushed purchase data to the dataLayer using JavaScript triggered on the thank-you page load. It was fragile, but it worked with most custom templates because the script fired as part of the page’s general JavaScript execution.
In v1.21, the plugin’s developers tied the purchase dataLayer push to the woocommerce_thankyou WordPress action hook. This hook fires when WooCommerce renders its native order confirmation template — the order-received.php file inside the WooCommerce template hierarchy.
Here is the problem: if anything replaces that native template, the hook never fires. No hook, no dataLayer push. No dataLayer push, no GTM event. No GTM event, no purchase data in GA4, Facebook CAPI, or Google Ads. Complete silence, while your store processes real orders.
Page builders that create custom thank-you pages — Elementor, Bricks, Divi, Beaver Builder — replace the WooCommerce template with their own rendered output. They do not trigger woocommerce_thankyou. From GTM4WP’s perspective, the order confirmation page simply never happened.
Why GTM Preview Mode Lies to You
This is where the debugging nightmare deepens. GTM preview mode often shows the purchase event firing correctly. You see the green tick next to purchase in the Tag Assistant panel. You feel confident. You close the laptop.
In debug mode, certain browser states and cookie contexts can cause the hook to fire differently than in a live production environment. The preview session may also be loading a slightly different page state than what your actual customers see. The result is a false positive that sends you back to blaming GA4 instead of finding the actual root cause.
43.4% of all websites run on WordPress (W3Techs, 2025), and WooCommerce is the dominant e-commerce layer on that platform. That means millions of stores could be running a tracking setup that looks healthy in preview and is functionally broken in production.
You may be interested in: Your WordPress GTM Plugin Just Broke
How to Diagnose Whether You Have This Problem
Three checks will confirm or eliminate this issue in under ten minutes.
Check 1: What is your thank-you page template?
In WordPress, look for any page assigned to the WooCommerce order-received URL — typically yourstore.com/checkout/order-received/. If there is an Elementor or Bricks template assigned to this URL pattern, that template is replacing the native WooCommerce output. That replacement is what kills the hook.
Check 2: Test with a real order in GA4 DebugView
Place a test order using a free or 100% coupon product. Do not use GTM preview mode for this test — go straight to GA4 DebugView. Watch for a purchase event to appear in real time. If the order completes and no purchase event appears within 30 seconds, the hook is not firing in production.
Check 3: Confirm with a PHP log entry
Add a temporary snippet to your child theme’s functions.php: add_action('woocommerce_thankyou', function($order_id) { error_log('thankyou hook fired: ' . $order_id); });. Place another test order. If no log entry appears, the hook is definitively not executing — and your custom template is the cause.
GTM implementation costs between $1,000 and $10,000 in agency fees (Analytico Digital, 2025). Silent purchase tracking failures mean that investment is returning bad data from the moment the custom thank-you page went live.
The Three Fix Options
Once you have confirmed the diagnosis, you have three paths forward. They are not equally good.
Option 1: Remove the custom thank-you page template
If the page builder template is only cosmetic — a branded header, a recommendation block, a cleaner layout — evaluate whether the design value justifies the tracking cost. Restoring the native WooCommerce order-received.php template immediately fixes the hook dependency. You can still inject custom content using woocommerce_thankyou hooks in functions.php without replacing the entire template.
Option 2: Add a manual dataLayer push via PHP
Add a custom function that hooks into woocommerce_thankyou and manually pushes the purchase data to the dataLayer via an inline script. This approach preserves your custom template and restores GTM tracking simultaneously. The implementation requires pulling order data from the WooCommerce $order object — items, revenue, order ID — and formatting it to the GA4 ecommerce schema. It works, but it is custom code that must be maintained across WooCommerce and GTM4WP updates.
Option 3: Move purchase tracking to the server
This is the architectural fix. Server-side tracking hooks into WooCommerce at the PHP level — specifically woocommerce_payment_complete or woocommerce_order_status_completed — and fires the purchase event from the server the moment the order is created. The browser is not involved. The page template is not involved. The woocommerce_thankyou hook is not involved.
You may be interested in: Why You Should Never Start With GTM for Your New WooCommerce Store in 2026
Why This Problem Will Not Be the Last One
The custom thank-you page issue is a symptom of a deeper architectural constraint. Browser-side GTM plugins — GTM4WP, GTM Kit, and every alternative — depend on a predictable chain of events: WordPress loads, WooCommerce renders its template, a hook fires, JavaScript executes, and data reaches GTM. That chain has at least eight documented failure points on a standard WooCommerce store.
Custom page templates break it at the template layer. Ad blockers break it at the JavaScript layer. Payment gateway redirects break it at the navigation layer. Slow connections and aggressive caching break it at the load-time layer. Each failure mode shares the same root cause: tracking that depends on browser-side JavaScript in an environment that is increasingly hostile to browser-side JavaScript.
GTM4WP’s developer has fixed the hook dependency issue across multiple versions — the plugin’s GitHub issue tracker documents recurring purchase tracking regressions with each major WooCommerce update. The fixes are genuine and well-intentioned. But every fix is a patch on a structural dependency that does not go away.
The Permanent Solution
Transmute Engine™ by Seresa routes WooCommerce purchase events from the server — hooking into PHP-level order actions that fire regardless of what the browser did, which template rendered, or which page builder designed the confirmation page. The purchase data travels from WordPress to your first-party tracking server on your own subdomain, and from there to GA4, Facebook CAPI, Google Ads Enhanced Conversions, and BigQuery simultaneously. Your Elementor thank-you page can look exactly how you designed it. The tracking runs on a layer that page builders cannot touch.
Key Takeaways
- GTM4WP v1.21+ uses the woocommerce_thankyou hook for purchase events — and custom page builder templates bypass this hook entirely.
- GTM preview mode does not replicate production conditions — a green tick in preview does not mean the event fires for real customers.
- Diagnosis takes ten minutes: check your template assignment, run a test order against GA4 DebugView, and confirm with a PHP log entry.
- Three fix options exist: remove the custom template, add a manual PHP dataLayer push, or move purchase tracking to the server layer.
- Server-side tracking eliminates the page template dependency because it captures the order at the PHP hook level, before any browser-side rendering occurs.
Preview mode loads your page in a debug context that can still trigger the woocommerce_thankyou hook. In production, if your thank-you page is built with Elementor, Bricks, or a custom template, the hook never fires — so GTM never receives the purchase event data.
woocommerce_thankyou is a WordPress action hook that fires when WooCommerce loads its native order confirmation template. GTM4WP v1.21+ listens to this hook to push purchase data to the dataLayer. Replace the default template with a page builder and the hook never executes.
You have three options: restore the default WooCommerce order-received template by removing the Elementor override, add a custom PHP snippet that fires the dataLayer push on the woocommerce_thankyou hook regardless of template, or switch to server-side tracking that captures the order at the PHP level and never depends on page templates.
Yes. GTM Kit and most browser-side GTM plugins share the same woocommerce_thankyou hook dependency. The root cause is architectural — client-side JavaScript cannot fire before the page template renders. Any plugin relying on this hook will fail on custom thank-you pages.
Yes — but not with browser-side GTM plugins alone. Server-side tracking captures the purchase event at the WooCommerce order hook level in PHP, before any page template renders. Your Elementor thank-you page can look however you want. The tracking does not care.
If your GA4 purchase data looks thin and your WooCommerce orders dashboard tells a different story, the hook is the likely culprit. Ten minutes of diagnosis will confirm it. The fix — whichever path you choose — is worth running before you spend another month optimising ad spend against incomplete conversion data.