You configured cross-domain tracking. You added your checkout subdomain to GA4’s list. You watched the _gl parameter appear in Tag Assistant. GA4 still shows checkout.yourstore.com as your top referral source — and your ad campaigns are getting credit for nothing. Here’s the architectural reason every setup guide leaves out: GTM’s cross-domain linker only fires on link clicks, and WooCommerce checkout doesn’t use link clicks.
How GTM Cross-Domain Tracking Actually Works
GA4 cross-domain tracking works by appending a _gl parameter to outbound links. When a user clicks a link to your checkout subdomain, GTM intercepts that click, adds the parameter to the URL, and the receiving domain picks up the session ID — keeping the user in the same session across both domains.
The key word is clicks. Google’s own documentation is explicit: the linker parameter solution requires click-based navigation between domains. Form submissions and server-side redirects are outside its scope entirely.
WooCommerce checkout submits via HTTP form POST. There is no link click. The user fills in their details and presses “Place Order” — the browser sends a POST request directly to the checkout endpoint with no outbound link for GTM to intercept. The _gl parameter is never added. The session breaks. GA4 sees a new visitor arriving from your checkout domain.
The Three WooCommerce Flows That Fail
This isn’t limited to stores with a separate checkout subdomain. Three common WooCommerce configurations expose you to this failure mode:
- Checkout subdomain setup: Stores that move checkout to
checkout.yourdomain.comfor PCI compliance or security isolation. Any form POST to the subdomain bypasses the linker. - External payment gateway redirect: PayPal, Klarna, and Afterpay redirect users to an external payment page. Even with referral exclusion configured, the session breaks on the return trip if the confirmation page is on a different domain.
- WooCommerce Blocks checkout: The React-based Block Checkout handles its own state and navigation. The traditional GTM link decoration hooks don’t apply to its routing model.
PayPal alone processes roughly 30% of WooCommerce transactions. If you accept PayPal, you’re already exposed — even if you never configured a checkout subdomain.
You may be interested in: Your WooCommerce ROAS Is Probably Wrong
Why the Setup Guide Worked in Testing
Here’s the part that makes this so frustrating: the setup guides are correct for the scenario they describe. If your checkout link is an actual anchor tag — <a href="..."> — the cross-domain linker will work exactly as documented.
But WooCommerce’s checkout flow doesn’t use anchor tags for the final submission. When you tested cross-domain tracking, you likely clicked a navigation link to the checkout page — and that click worked perfectly. The form POST that sends the order is a different mechanism entirely, and it runs after your test already passed.
Tag Assistant confirms the _gl parameter is appended to the checkout page link. It can’t tell you the parameter is then lost the moment the customer hits “Place Order” and the form submits to your payment handler.
70% of ecommerce stores have broken or incomplete tracking configurations, with cross-domain misconfiguration as one of the largest contributor categories — and most of those stores genuinely believe they’ve set it up correctly.
What the Data Looks Like When This Breaks
The attribution failure shows up in two places. First, your GA4 acquisition report lists your checkout subdomain or paypal.com or stripe.com as a significant traffic source — sometimes the top source. Second, your campaign attribution shifts toward “direct” because the original session data was lost at the checkout boundary.
A 15-25% attribution gap between WooCommerce orders and GA4 conversions is typical for stores in this situation. EU stores with GDPR consent enforcement can see gaps of 40-60%. Cross-domain failure compounds with every other data loss source you’re already experiencing.
The practical consequence: your ad platform bidding models are optimising on incomplete conversion data. Google Smart Bidding and Meta Advantage+ both use the conversion signals you send them. If cross-domain failure means a third of your purchases aren’t attributed to the campaigns that drove them, your bidding is training on the wrong dataset — and your ROAS figures are structurally understated.
You may be interested in: Why Google Ads and Facebook Both Claim the Same Sale
The Client-Side Fix (and Its Limits)
There is a client-side workaround. Before the checkout form submits, JavaScript can intercept the form’s action URL and decorate it with the _gl parameter — essentially doing manually what the linker would have done for a link click.
The implementation in GTM: a trigger fires on form submission, reads the current linker parameter from the GA4 client, appends it to the form’s action attribute, then allows the submission to proceed. It works — with caveats.
- It requires custom GTM code or a theme-level JavaScript addition that must be maintained through WooCommerce updates.
- It must be tested against every checkout variant you support — standard checkout, express checkout, guest checkout, and any third-party checkout plugin.
- It still depends on the browser running your GTM snippet cleanly. Ad blockers affect 31.5% of users. Those sessions never get the
_glparameter regardless of your fix. - 62% of WooCommerce stores using GTM already experience plugin conflicts that cause silent data loss — adding custom form-decoration code introduces another fragility point.
The fix solves the architectural problem for users who run GTM without interference. It doesn’t solve the underlying browser dependency.
The Referral Exclusion Mistake
Most store owners who discover this problem reach for the GA4 referral exclusion list first. Adding your checkout subdomain and payment domains to the exclusion list stops those domains from appearing as traffic sources — but it doesn’t restore the original attribution.
What referral exclusion actually does: it tells GA4 to continue the current session when traffic arrives from the excluded domain, rather than starting a new one. But if the original session data (including the campaign source) was never transferred across the domain boundary, there’s nothing to continue. The conversion gets attributed to “direct” because that’s the only information available.
Referral exclusion and cross-domain tracking are related but different fixes. You need both — and even with both configured correctly, the form POST problem remains.
Why Server-Side Tracking Is Architecturally Immune
The Transmute Engine™ by Seresa approaches this differently. Rather than tracking events at the browser layer — where domain boundaries, form submissions, and ad blockers all create gaps — it captures events at the WooCommerce PHP layer, where none of those factors apply.
When a WooCommerce order completes, the woocommerce_payment_complete hook fires on the server. That hook includes the full order data: customer details, revenue, products, order ID. The Transmute Engine captures this event before it reaches a browser, before any domain transition occurs, and routes it server-side to GA4, Google Ads Enhanced Conversions, Facebook CAPI, and any other configured destination.
Domain boundaries are irrelevant when the purchase event is captured on the server that processed the order. There’s no _gl parameter to manage, no form POST to intercept, no ad blocker to bypass. The event either fires or the order didn’t complete — and if the order completed, it’s captured.
Key Takeaways
- GTM’s cross-domain linker requires link-click navigation — WooCommerce form POST checkout is outside its scope by design.
- Following the GA4 cross-domain setup guide correctly does not fix WooCommerce — the guide describes a different navigation model.
- Referral exclusion removes the symptom (checkout domain appearing as traffic source) but not the cause (lost session attribution).
- The client-side JavaScript fix works for GTM-visible users — it doesn’t address the 31.5% running ad blockers or the ongoing maintenance overhead.
- Server-side tracking via WooCommerce order hooks captures purchase events before domain boundaries matter — the correct architectural solution for stores where checkout crosses domains.
GTM’s cross-domain linker appends a _gl parameter to outbound links. WooCommerce checkout submits via HTTP form POST — not a link click — so the _gl parameter is never appended and the session breaks at the domain boundary. Setup guides are written for link-click navigation and don’t account for WooCommerce’s form-based checkout flow.
When cross-domain tracking fails, GA4 treats the user’s return from your checkout subdomain or payment gateway as a new session starting from that domain. The checkout domain appears in acquisition reports because GA4 has no session continuity data — each return visit looks like a fresh entry from that source.
Referral exclusion stops the checkout domain from appearing as a traffic source, but it doesn’t restore the original session attribution. The conversion gets counted, but the campaign credit is lost — attributed to “direct” because no session data was transferred across the domain boundary.
You need JavaScript that intercepts the form submission, reads the current GA4 linker parameter, and appends it to the form’s action URL before the POST fires. This requires custom GTM or theme code and must be tested across all checkout variants you support — standard, express, guest, and any third-party checkout plugins.
Yes. Server-side tracking via WooCommerce order hooks fires on the server when the order is placed — before any domain boundary is involved. The purchase event is captured regardless of what the browser did, which checkout flow was used, or which payment gateway processed the transaction.
GTM cross-domain tracking was built for a world of link clicks. WooCommerce checkout lives in a world of form submissions, payment redirects, and React block rendering. When those two worlds collide, the browser-layer tracking always loses. Learn how Seresa’s Transmute Engine captures WooCommerce purchase events at the server layer — where domain boundaries don’t exist.