How to Serve GA4 and GTM From Your Own Domain on Magento 2 (the Generated Cloudflare Worker)

TL;DR

This is the field-by-field procedure for First-Party Tracking on Magento 2, and nothing else. Whether serving your Google tag through your own domain is worth doing is a separate argument that our ad-blocker article already makes, so this one does not re-run it. What you get here: the six fields and what each expects, the two things the extension actually does on the page, the Setup Requirements block, the Cloudflare route rules that make the documented route pattern legal, how to build a verification step when no verification procedure is documented, and a short list of stores that should leave this switched off.

Key Takeaways

• First-Party Tracking is PRO only. It uses Google Tag Gateway to serve GTM and GA4 through your own domain, and requires a Cloudflare Worker or an equivalent proxy on your own infrastructure [1].
• It performs two distinct interventions: it loads the GTM container through your proxy with parameter obfuscation, and it intercepts GA4 collection hits to route them through the proxy as well [1].
• Six fields: Enable First-Party Tracking, Measurement Path, GA4 Measurement ID, GTM Container ID, Proxy Google Ads Requests, and the read-only Cloudflare Worker Code [1].
• Measurement Path must start with a forward slash, and it must match the route configured in your Worker. The documentation's examples are /metrics and /metricsyourstore [1].
• The Worker must forward requests to {MEASUREMENT_ID}.fps.goog, and the route to add is yourdomain.com{measurement_path}/* [1].
• No verification procedure is documented for this feature. Build the check from general tooling and do not expect the extension to confirm the gateway is active.

What does it actually do on the page?

Before touching a field, get the mechanism straight, because it is two mechanisms and a reader who proxies one of them has half a gateway.

When enabled, the extension loads the GTM container through your proxy with parameter obfuscation, and intercepts GA4 collection hits to route them through the proxy as well [1]. Container load and collection hits travel separately. The container load is a script fetch at page load. The collection hits are the stream of events your site sends afterwards. Both have to arrive at your own domain for the setup to do what the feature claims.

One thing this is not: a server-side GTM container. If you have been reading about server containers, custom domains for them and preview-versus-production promotion, that is a different architecture, and our guide to creating a server-side GTM container covers it. First-Party Tracking proxies Google's own endpoints through a Worker on your zone. No container, no tag configuration to maintain in a second GTM workspace. The broader question of what changes when you move from client-side to server-side is in our article on client-side GTM versus server-side tracking.

The six fields, in order

Two of these fields decide more than their labels suggest, and one of them is read-only.

GTM Container ID is there because the container load is one of the two interventions. The extension needs to know which container to fetch through your path.

Proxy Google Ads Requests widens the scope past Google Analytics to the three ad-serving domains named above, and the documentation recommends it if you run Google Ads Conversion Tracking, adding that for best results you should link your Google Ads and GA4 accounts and import GA4 purchase events as conversions [1]. Which route you send Google Ads conversions through in the first place is a separate decision, argued in our article on Google Ads conversion tracking on Magento 2. This field only decides whether those requests also travel through your proxy.

Set the Measurement Path and the Worker route from the same clipboard paste. Those two strings disagreeing by one character is the first thing to check when a fresh setup sends nothing.

Setup Requirements, and the route that makes it legal

The documented Setup Requirements are three lines [1]:

1. Configure a Cloudflare Worker or an Nginx or Apache proxy on your domain.
2. The Worker must forward requests to {MEASUREMENT_ID}.fps.goog.
3. Set the Measurement Path to match the route configured in your Worker.

Then copy the generated script out of Cloudflare Worker Code into your Worker and add the route yourdomain.com{measurement_path}/* [1].

That route pattern is legal under Cloudflare's rules, and the rules are worth reading before you invent a variation. As Cloudflare's routing documentation reads on September 21, 2026: the only wildcard operator is *, patterns may begin with http:// or https://, infix wildcards such as example.com/*.jpg are not supported, and query parameters are not allowed in a pattern [2]. Cloudflare also states that all domains and subdomains must have a DNS record proxied on Cloudflare to be used to invoke a Worker [2]. So the store's hostname has to sit on an active Cloudflare zone with the orange cloud on, and a path with a trailing * is the shape Cloudflare expects.

How do you verify it without a documented check?

The documentation stops at configuration. There is no First-Party Tracking verification procedure, and no field or status indicator that tells you the gateway is live. So build the check out of general tooling and be honest with yourself about what each step proves.

1. Load a store page with the browser network panel open and confirm the GTM container and the GA4 collection requests go to your own domain under the Measurement Path, rather than to Google's hostnames.
2. Confirm events still arrive. DebugView, the log file and the order grid column are the general surfaces, all covered in our guide to verifying GA4 events on Magento 2.
3. Place a test order and check the purchase event end to end, since a proxy that works for page views and breaks on one event type is the failure you want to catch before a campaign does.
4. Watch the Worker's own metrics in Cloudflare for errors on the route.

Step one is the only step that tells you the proxy is being used. Steps two and three tell you tracking still works, which is a different question and the one that actually costs money when the answer is no.

Who should leave this switched off?

Three documented constraints, and any one of them is enough.

• Our own label on it. The documentation labels it advanced and experimental, with the note that thorough testing on your own environment is recommended before committing to using it [1]. That label arrived with the initial release in v1.16.1 on March 6, 2026 and the current v1.17.5 guide still carries it [1]. Our article on ad blockers and what server-side actually recovers makes the case for reading that label as the honest signal it is, and also carries the value argument and Google's published uplift figure, which is why neither appears here.
• No Cloudflare zone, or nobody who deploys Workers. Every hostname that invokes a Worker needs a proxied DNS record on an active Cloudflare zone [2]. If that describes someone else's job at your company, this is a change you cannot own.
• A store already running Cloudflare's own Google tag gateway. That is a separate Cloudflare product, enabled from the Google tag console or the Cloudflare dashboard [3], and the documentation tells you not to use it alongside the generated Worker [1], a point our ad blockers article already makes.

The change log for v1.16.1 frames the benefit carefully, and the hedge is the part to keep: the generated Worker script serves the GTM container first-party, preventing most, if not all, ad blockers from stopping container and script loading, and it requires a Cloudflare account with Workers access or an equivalent platform [1]. That hedge is doing real work.

FAQ

Do I need a server-side GTM container for this?

No. First-Party Tracking proxies Google's endpoints through a Worker on your own domain. A server container is a separate architecture with its own setup.

What does the generated Worker code do?

The documentation presents the field as read-only and generated, and does not publish what the script contains [1]. What it does document is the requirement the Worker has to satisfy: forward requests to {MEASUREMENT_ID}.fps.goog [1].

Why does my Measurement Path have to start with a slash?

Because the field requires it, and because the value has to line up with a Cloudflare route, where the pattern takes the form yourdomain.com{measurement_path}/* [1][2]. A mismatch between the two is the most likely reason a first attempt sends nothing.

Will this work behind another CDN in front of Cloudflare?

The documentation does not say, and guessing would not help you. Cloudflare's requirement is a proxied DNS record on an active zone for the hostname invoking the Worker [2]. Anything stacked in front of that is your architecture to test on staging.

First-Party Tracking, including the generated Worker script and the Proxy Google Ads Requests option, is a PRO capability of the Magento 2 Google Analytics 4 extension, currently v1.17.5, released September 16, 2026 [1].

Sources

1. WeltPixel Google Analytics 4 User Guide and Change Log, v1.17.5, September 16, 2026, retrieved September 21, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
2. Routes, Cloudflare Workers documentation, page last updated June 1, 2026, retrieved September 21, 2026, https://developers.cloudflare.com/workers/configuration/routing/routes/
3. Google tag gateway, Cloudflare documentation, page last updated April 17, 2026, retrieved September 21, 2026, https://developers.cloudflare.com/google-tag-gateway/