A public GitHub issue (#3266) has been open against Google’s official Google for WooCommerce plugin since February 24, 2026, documenting a structural incompatibility with Google Tag Gateway. Enabling GTG with this plugin produces duplicate Google Ads conversions on every order. The plugin’s main gtag chain routes through the gateway correctly, but companion pixels like 1p-conversion fire directly to googleadservices.com and bypass it entirely. The fix would be roughly three lines of WordPress filter code. It hasn’t shipped. Stores enabling GTG right now are silently inflating their reported ROAS until they audit the network tab on their order-received page.

GitHub Issue #3266 Has Been Open Since February#

The issue, filed February 24, 2026 by a community contributor, opens with one line that names the problem cleanly: “Currently, the Google for WooCommerce plugin is structurally incompatible with First-Party Tag Gateways (such as Cloudflare Google Tag Gateway) or Google Tag Manager Server-Side Containers” (GitHub issue #3266, 2026). It has carried the needs: discussion label ever since, with no merged fix as of late April 2026.

The angle here is plugin lag, not platform malice. The bug is real. The mechanism is well-understood. The workaround exists in the issue body. The thing that hasn’t happened is the merge.

Chain 1 and Chain 2: Where the Double-Fire Comes From#

Google Tag Gateway proxies the main Google tag script (gtag.js or the GTM container) through a path on your own domain via a CDN like Cloudflare. To browsers, the tag looks first-party. To ad blockers, it does not match the public Google domain block list. That is the legitimate value proposition — and it works for the main gtag chain.

The Google for WooCommerce plugin emits two chains of network requests when an order completes. Chain 1 is the configured gtag script, which routes correctly through the GTG path. Chain 2 is a set of inline companion pixels — most importantly the 1p-conversion pixel — that the plugin hardcodes to fire directly to googleadservices.com. Chain 2 has no transport_url parameter, no filter to redirect it, and no awareness that GTG is enabled. Both chains carry the same transaction ID. Both land as conversions in Google Ads.

That is the double-count. One purchase, two conversion calls, two recorded conversions on the campaign that drove the click.

The fix the issue body suggests is straightforward: expose a transport_url filter on the inline companion pixels so they can be redirected through the same first-party endpoint as the main gtag chain. Three lines of filter code. It hasn’t been merged.

The Symptom: Silent ROAS Inflation#

Google reports a median 11% measurement signal improvement from Tag Gateway adoption (Google data cited by Conversios and Napkyn, 2026). Industry-reported conversion lift after GTG deployment runs 10-15% (Napkyn analysis, 2026). Those numbers are real. They reflect recovery of conversions that were previously lost to ad blockers and tracking-prevention features — and 31.5% of global users run ad blockers (Statista, 2024), so there is real signal to recover.

Here’s the problem: a WooCommerce store on the official plugin can’t tell the difference between a 10-15% recovery lift and a 100% double-count. Both look like “conversions went up after we enabled GTG.” Smart Bidding sees the inflated number. The CPA target tightens around it. Budget reallocates toward the campaigns the plugin is double-counting. The ROAS dashboard glows.

WordPress powers roughly 43.5% of all websites (W3Techs, 2024), and the official Google for WooCommerce plugin is the default tracking install path for stores that follow Google’s own onboarding. The compatibility gap is not a fringe edge case.

How to Detect the Double-Fire on Your Store#

Open Chrome DevTools, go to the Network tab, and place a test order. Watch the order-received page. Filter the network calls by googleadservices.com and by your Tag Gateway endpoint (typically a path on your own domain like /cdn-cgi/zaraz/ or /gtg/). If you see conversion calls hitting both targets carrying the same transaction_id, you are double-firing.

The other diagnostic: compare the conversion count in Google Ads against the order count in WooCommerce for the same period. If Google Ads shows materially more conversions than WooCommerce shows orders attributable to the same campaigns, the chain 2 fire is the most likely cause.

The Workaround Ladder#

Three options sit between “live with the bug” and “wait for the merge.”

Workaround one: kill the plugin’s tracking layer. The plugin exposes a documented filter — woocommerce_gla_disable_gtag_tracking — that, when returned true, disables the plugin’s gtag tracking entirely. Drop this in a small must-use plugin or your theme’s functions.php:

add_filter( 'woocommerce_gla_disable_gtag_tracking', '__return_true' );

Both chains stop firing. You now need a different pipeline to deliver conversions to Google Ads, but you no longer have a double-count.

Workaround two: route conversions through GTM4WP instead. GTM4WP is the long-standing community plugin that captures WooCommerce events into the dataLayer for a Google Tag Manager container you control. The container’s tags can be configured with a clean transport_url and routed through GTG without the inline-pixel problem. Whether GTM is the right architecture for a new WooCommerce store in 2026 is a separate conversation, but for an existing GTG deployment that needs to escape the double-fire, it works.

Workaround three: send conversions server-side from the WooCommerce PHP hook. The woocommerce_payment_complete hook fires when an order is paid. From PHP, you can post the conversion to Google Ads (Enhanced Conversions for Web or via the Google Ads API) without touching the gtag layer at all. There is no Chain 2 because there is no client-side companion pixel. A clean WooCommerce tracking setup without GTM walks through the same architectural pattern.

The Architectural Lesson#

Tag Gateway is the right direction. Google has correctly identified that browser-based measurement is degrading and that first-party endpoints are the way out. The bug is not in GTG itself — it is in the lag between Google’s measurement roadmap and Google’s WordPress plugin layer. Two-month-old issues with three-line fixes ship on plugin layers when there is sustained pressure to ship them. There hasn’t been.

Depending on Google’s WordPress plugin to keep up with Google’s own measurement roadmap is a losing bet. The plugin will eventually be patched. Something else will break next. The structural answer is to stop firing browser-side conversion pixels altogether and send conversions from the PHP hook layer instead.

Transmute Engine™ is a dedicated Node.js server that runs first-party on your subdomain (for example, data.yourstore.com). The inPIPE WordPress plugin captures the woocommerce_payment_complete event server-side and sends it via API to the Transmute Engine, which fans out to Google Ads, Facebook CAPI, GA4, and BigQuery from a single conversion record with a stable transaction ID. There is no Chain 2 because there is no client-side companion pixel to escape.

Key Takeaways#

• Issue #3266, open since Feb 24, 2026: Google for WooCommerce + Google Tag Gateway = duplicate Google Ads conversions, no merged fix.
• Two chains, one transaction ID: The main gtag routes correctly; the companion 1p-conversion pixel bypasses GTG and fires directly to googleadservices.com.
• The plugin lacks transport_url: The standard gtag parameter that would redirect Chain 2 through the gateway is not exposed.
• Detect via DevTools: Network tab on the order-received page; filter by googleadservices.com and your gateway endpoint.
• Workaround filter: woocommerce_gla_disable_gtag_tracking kills the plugin’s tracking entirely.
• Architectural fix: Send conversions from the WooCommerce PHP hook server-side. No client-side companion pixel, no Chain 2.

Frequently Asked Questions#

If you’ve enabled Google Tag Gateway on a store running the Google for WooCommerce plugin, audit the network tab on your order-received page today. Seresa builds the server-side first-party infrastructure that sends conversions from the WooCommerce PHP hook — no Chain 2 to escape.