Enhancement: Add support for Server-Side Tracking / Custom Gateway routing (transport_url)

[hardik18882]

User story

As a WooCommerce merchant or agency using First-Party Server-Side Tracking (such as Cloudflare Google Tag Gateway or GTM Server-Side), I want the plugin to route its Google Ads tracking tags through my custom first-party domain so that my conversion tracking is accurate, respects ITP/ad-blockers, and does not result in double-counted conversions.

Is your feature request related to a problem?

Yes. As the industry moves toward Server-Side tracking to combat ITP and ad blockers (as officially recommended by Google), we are finding that the Google Listings & Ads plugin is structurally incompatible with these setups.

Currently, the plugin hardcodes the base configuration string and lacks a filter to inject a custom transport_url or server_container_url.

When a merchant uses a First-Party Tag Gateway, the gateway successfully intercepts the main checkout.min.js script. However, because the base config lacks the transport_url parameter, the plugin’s inline scripts and companion pixels (like 1p-conversion) bypass the gateway entirely and fall back to hitting googleadservices.com directly. This results in two completely separate initiator chains firing simultaneously for every order, artificially inflating ROAS and double-counting conversions in Google Ads.

How to reproduce the problem

1. Install and configure the Google Listings & Ads plugin with Conversion Tracking active.
2. Set up a First-Party Tag Gateway (e.g., Cloudflare Google Tag Gateway) to route Google tags through a first-party subdirectory like https://example.com/gateway/.
3. Complete a test purchase and inspect the browser's Network Tab on the Order Received page.
4. Observe Chain 1: The primary conversion script successfully routes through the first-party gateway (/gateway/...).
5. Observe Chain 2: Simultaneously, companion pixels (like 1p-conversion) bypass the gateway and fire directly to google.com/pagead/... because the base config lacks routing instructions.

Describe the solution you'd like

Please allow developers to modify the base gtag config to include Server-Side routing parameters.

Either:

1. Developer Hook (Quickest/Preferred): Wrap the return in get_gtag_config() with a WordPress filter (e.g., apply_filters( 'woocommerce_gla_gtag_config_params', ... )) so developers can natively append "transport_url": "https://example.com/gateway/" to the config array.
2. Native UI Feature: Add a text field in the plugin settings for "Server-Side Container URL", which automatically appends the transport_url parameter to the global gtag config.

Describe alternatives you've considered

Currently, the only workaround for advanced tracking setups is to use the woocommerce_gla_disable_gtag_tracking filter to completely kill the plugin's tracking capabilities, and rely entirely on third-party data layer plugins (like GTM4WP) to handle the routing via Google Tag Manager.

Technical

In src/Google/GlobalSiteTag.php, the configuration string is strictly hardcoded within the get_gtag_config() method:

protected function get_gtag_config( string $ads_conversion_id ) {
	return sprintf(
		'gtag("config", "%1$s", { "groups": "GLA", "send_page_view": false });',
		esc_js( $ads_conversion_id )
	);
}

Because there is no apply_filters() hook wrapped around this return statement, developers are completely locked out from injecting the transport_url parameter.

Acceptance criteria

• The base gtag('config', ...) output can be modified via a WordPress filter or a plugin setting to include additional parameters like transport_url.
• When a custom transport_url is applied, all Google Ads conversion hits and companion pixels successfully route through the defined first-party domain without falling back to default Google endpoints.

[hardik18882]

Hello,

Just a friendly follow-up on this Enhancement request.. Have you got a chance to discuss this internally yet? Any Plans to implement in near future?

We are Unable to use First-Party Server-Side Tracking (such as Cloudflare Google Tag Gateway or GTM Server-Side) with this plugin.

Looking forward for updates.

Thanks,
Hardik

[hardik18882]

Hi team,

Following up on this request with additional technical detail, including network-level evidence and a formal finding from Google's own Technical Solutions Team that confirms this is a real, measurable data integrity issue.

---

Official Confirmation from Google

After reporting anomalies in our Google Ads data, Google's Technical Solutions Team conducted a network tab analysis of our Order Received page and formally identified the following (summarised from their written response):

"The purchase conversion is firing twice via two different initiation chains. Chain 1 is triggered through the Google Tag Gateway measurement path (/[gateway-path]/as/d/ccm/conversion/...). Chain 2 is a second, identical conversion firing via the standard URL (https://www.googleadservices.com/pagead/conversion/...). This indicates a conflict between the custom Google Tag Gateway setup and the existing plugin-based implementation."

Google's own team attributed this directly to the plugin's inability to route through the gateway, and recommended either migrating to GTM entirely, or having the plugin's support team investigate why conversions are initiating through both chains simultaneously.

We chose the latter — which is why this issue exists.

---

Network Evidence: Two Separate Initiator Chains for the Same Transaction

Both chains carry identical parameters:

• Transaction ID: [ORDER_ID]
• Conversion Label: [CONVERSION_LABEL]
• Event name: purchase
• Conversion value: [test order value]

Chain 1 (Gateway — correct):
Initiator: checkout.min.js → Order Received page → /[gateway-path]/ → googletagmanager.com/debug/bootstrap → googleadservices.com/pagead/conversion/AW-XXXXXXXXXX/
URL path: /[gateway-path]/as/d/ccm/conversion/AW-XXXXXXXXXX/ ✅ Routes through the First-Party Gateway as intended.

Chain 2 (Plugin bypass — the problem):
Initiator: googleads.g.doubleclick.net/pagead/viewthroughconversion/ → google.com/pagead/1p-conversion/AW-XXXXXXXXXX/
URL: https://www.googleadservices.com/pagead/conversion/AW-XXXXXXXXXX/ ❌ Bypasses the gateway entirely and fires directly to Google's servers.

Chain 2 is the 1p-conversion companion pixel that fires because the plugin's gtag("config") and gtag("event", "purchase") calls lack a transport_url parameter, leaving companion pixels with no routing instruction and causing them to fall back to default Google endpoints.

---

Root Cause in GlobalSiteTag.php

After reviewing the source, the transport_url gap exists in three locations in the current codebase:

1. get_gtag_config() — Line 305

protected function get_gtag_config( string $ads_conversion_id ) {
    return sprintf(
        'gtag("config", "%1$s", { "groups": "GLA", "send_page_view": false });',
        esc_js( $ads_conversion_id )
    );
}

No apply_filters() hook. transport_url cannot be injected.

2. maybe_display_conversion_and_purchase_event_snippets() — Lines 429–458
The gtag("event", "purchase", { send_to: "...", ... }) call is fully hardcoded with no filter on its parameters. This is the direct source of Chain 2 — even if the config is patched, the purchase event hit itself has no gateway routing instruction.

3. Legacy GA4W inline config — Line ~255
A third hardcoded config string exists via preg_replace for the legacy Google Analytics for WooCommerce path (v < 2.0.0), also without a filter.

---

The Pattern to Apply Already Exists in This File

get_consent_mode_config() (line 329) already uses apply_filters( 'woocommerce_gla_gtag_consent', $consent_mode_snippet ), and PR #3234 introduced apply_filters( 'woocommerce_gla_add_legacy_conversion_event', true ) in the same class.

This request asks for the same established pattern to be applied to:

• get_gtag_config() → suggested filter: woocommerce_gla_gtag_config_params
• The purchase event params → suggested filter: woocommerce_gla_gtag_purchase_event_params

Both follow the existing woocommerce_gla_* naming convention and require no breaking changes to default behaviour.

---

This is causing real, Google-confirmed data corruption for merchants using First-Party Gateway setups — which Google itself recommends as the standard approach to combat ITP and ad blockers.

Thanks,
Hardik