Google tag gateway: what it changes, and what it leaves alone
The gateway moves the Google tag onto a path on the advertiser's own domain and leaves the rest of the setup where it was. This page covers the mechanism, the setup routes, and where it stops. I have set one up through Cloudflare and I run Google Tag Manager server containers in production; the comparison comes from operating both.
Google tag gateway for advertisers, defined
Google tag gateway for advertisers serves Google's measurement scripts, and the requests those scripts go on to make, from a path on a domain the advertiser already owns, through an existing CDN, load balancer or web server. The tag executes in the browser as before; only the addresses it is fetched from and posts to move.
The scope is the Google estate and nothing beyond it, however loosely "first-party" gets used in sales material:
- Google Ads
- Google Analytics
- Campaign Manager 360
- Web containers in Google Tag Manager
The feature opened in beta on 19 March 2025 as first-party mode and was renamed on 8 May 2025. Older write-ups saying first-party mode mean the same thing.
How the gateway works, in the proxy and on the page
Two changes make it run. One lives in whatever sits in front of the origin; the other is an edit to the tag snippet.
The measurement path
A path on the advertiser's domain, /metrics in Google's examples. It must be unused, not the root path, and under 100 characters.
The origin endpoint
Traffic on the path forwards to G-XXXXXXX.fps.goog (a container uses gtm-xxxxxx.fps.goog), with the Host header overridden to match. Cookies and query strings pass through.
Geolocation headers
The proxy attaches approximate location: X-Forwarded-CountryRegion as a single ISO 3166-2 code, or X-Forwarded-Country (ISO 3166-1 alpha-2) with X-Forwarded-Region alongside it. X-Forwarded-Geolocation (latitude, longitude, city) is optional.
The snippet edit
The gtag.js source becomes the measurement path; a Tag Manager container adds ?id= and the container ID. The rest of the snippet is untouched.
The noscript exception
Google documents the Tag Manager noscript snippet as unsupported through the gateway. Sites relying on it should know before switching over.
The health check
Appending /healthy returns "ok" once the route is live; ?validate_geo=healthy confirms the location headers arrive. Tag Assistant then shows hits on the new path.
On Cloudflare none of that is typed out. The proxy intercepts calls to the first-party path, rewrites them to the Google endpoint, and sends every measurement payload down the same route. Nothing is deployed; no CNAME record is created.
What improves for measurement, and what stays exactly as it was
Two things genuinely improve:
- Requests that used to address googletagmanager.com and google-analytics.com now address the advertiser's domain, so network filtering keyed to those hostnames has nothing left to match.
- The script arrives over infrastructure the business already pays for, taking a third-party dependency out of page load.
Google's wording is that some measurement requests move, not all, so a network tab remains the only way to see what a site ends up with.
The blocking gain is partial and not permanent. The site picks the path, so a predictable one is trivial to add to a public list; choose something unremarkable. Behaviour-based extensions are unaffected, and the health-check path lets anyone confirm a deployment.
Cookie lifetime does not move, which is where most write-ups go wrong. The tag is still JavaScript writing its identifier through document.cookie; Safari's seven-day cap covers cookies written that way whatever host delivered the script.
Extending a cookie needs an identifier issued in an HTTP response header, and issuing one is a server container's job. The gateway on its own extends nothing.
Fastly has published a 14% uplift figure, an average across advertisers; any one site's result follows its own browser mix and audience.
Setting it up: Cloudflare, Google Cloud, Akamai, Fastly and CloudFront
The gateway needs something in front of the origin that can rewrite a path, so existing infrastructure decides the route, not preference.
One click from the Google tag interface
The first route to ship and the least work where the domain is already on Cloudflare. Setup runs from the tag interface; a rollback control landed in June 2025. This is the route I have used. It takes minutes.
A global external Application Load Balancer
In beta from 5 January 2026, generally available on 1 June 2026. It uses the global external Application Load Balancer, not the classic one, and the domain's whole traffic passes through it. Prerequisites: a Cloud project, the Google Tag Gateway Admin role, and somebody from the platform side.
Zone detection driven from the tag interface
Akamai arrived on 29 January 2026 via Property Manager. Streamlined setup for Akamai and Fastly followed on 14 May 2026, with the zone detected and the routing rule injected from the tag interface. Amazon CloudFront followed on 3 June 2026, via Tag Assistant.
The documented rules, applied by hand
Anything else means writing the configuration by hand:
- Forward the path to the Google endpoint
- Override the Host header
- Allow cookies and query strings through
- Attach a geolocation header
An nginx block will do it. So will any other proxy that can be told where to send a prefix.
On a supported CDN the gateway is a configuration change with nothing further to procure. On Google Cloud the load balancer is a billed resource carrying the site's whole traffic, so the charge lands with platform engineering. Neither route adds a container image to keep patched.
What the gateway is not, and what it will never do
The gateway is a transport change. Google calls it deploying a tag from first-party infrastructure, and that description is precise. Everything here follows from it.
No event object
Nothing on the route parses the hit into a structure. The proxy handles a path and some headers; the body reaches Google as the browser composed it.
No transformation
Parameters cannot be added, renamed, trimmed or hashed in transit. No component in the chain reads the payload.
No redaction
An address or identifier in a query parameter travels as sent. No checkpoint removes a value before it leaves the business.
No other destinations
Meta's Conversions API, TikTok, LinkedIn, a warehouse, an internal endpoint: none are reachable. The gateway fronts Google properties and stops.
No custom clients
Payload shapes outside what the Google endpoints already accept have nowhere to be claimed and nothing to interpret them.
No consent logic
No part of the route reads or enforces consent state. That stays with the tag in the browser, where it sat before.
Google tag gateway and server-side GTM, compared
The two get set against each other constantly, usually by somebody selling one of them. They sit at two different depths of the same idea.
The gateway changes an address. One rewrite rule in front of the origin, and Google's script is requested and answered on the advertiser's domain. Nothing is inspected, nothing is decided, and no state is held.
Moving to a full server-side container changes the architecture. An incoming request is parsed into an event in memory, and separate tags make their own outbound calls to whichever destinations are set up. A container can:
- Drop a field or hash a value
- Correct a currency
- Decline to forward at all
- Issue an identifier in a response header
The useful question is whether the data needs handling before it goes. Where it does not, the gateway answers the delivery complaint and a container is overbuilt. Where it does, the gateway cannot help.
They also compose. Google documents the gateway fronting a server container, so the first-party path and the event handling apply at once. That is where a business tends to land once the container pays for itself.
When the gateway on its own is the right answer
Many setups described as needing server-side tagging are describing the problem the gateway solves. Four cases where it is the whole of the answer.
Google is the entire measurement stack
Where the tags amount to GA4 and a handful of Google Ads conversions, there is no second platform to feed and no payload anyone wants reshaped. The one genuine grievance, hits going missing, is what the gateway addresses.
The proxy is already paid for
A domain behind Cloudflare, Akamai or Fastly already has the component, and setup is a configuration screen. No procurement, no new invoice, nothing extra to remember.
No one internally will hold a container
A gateway route has no image to patch and no host to keep alive. Where nobody can take a live service on at handover, that absence counts for more than the capability given up.
The events themselves are sound
Clean events that occasionally fail to arrive are a delivery problem, and delivery is what gets fixed here. Confused events are a different problem; relocating them solves nothing.
When a server container earns the extra cost
Three situations make the container the correct call. Each reduces to needing somewhere to stand between the browser and the vendor.
- A second advertising platform. Meta's Conversions API, matched to the browser event on a shared ID, is the most common reason a business ends up with a container. The gateway contributes nothing towards it, or towards any other conversions API worth feeding properly.
- Cookie lifetime on Safari. An identifier in a response header from a host on the same registrable domain is treated differently from one a script wrote, and only a container can deliver one.
- The data itself. Where a data protection officer has asked what leaves the business, or a payload carries a field that was never meant to travel, something has to read the event and act on it. The gateway holds no such component.
Set against those: a recurring hosting charge, an ownership question at handover, and a build with real scope. Where the balance favours the container, scoping the tracking work is worth doing before anything gets bought.
Consent obligations are untouched, and the CMP needs retesting
Nothing about the gateway alters the consent position. The tag runs where it ran, and Consent Mode governs each Google tag on the terms it did before; Google's own material says the requirement remains. How the consent signals are wired is unchanged, and an implementation that was wrong beforehand is wrong afterwards.
One thing does need retesting. A consent platform that gates scripts by source URL will hold a rule for googletagmanager.com. Serve the script from the advertiser's domain and that rule no longer matches, so a tag previously held back may load straight away.
The remedy is a rule for the new path. Check the switch in each consent state rather than treating it as a transport detail. A visitor who declined is unaffected either way.
Where a gateway sits against the other tracking decisions is easier to judge alongside the rest of the guides. A CDN that rewrites paths can also refuse requests and decides which crawlers reach a site; that is covered in the explainer on AI search visibility.
Cost, coexistence, and life without Cloudflare
Is Google tag gateway free?
Google does not charge for the feature. On a domain already proxied by a supported CDN it amounts to a configuration change with no new line on any invoice. Google Cloud is the exception, because the load balancer it relies on is a billed resource in its own right.
Can Google tag gateway and a server container run together?
They can, and Google documents the combination. The gateway supplies the first-party route into the container, which does the parsing, reshaping and fan-out to each destination. It is the arrangement to aim at once a container is justified on its own merits.
Does the gateway work without Cloudflare?
It does. Akamai, Fastly, Amazon CloudFront and Google Cloud all have supported paths, and the manual route works on any proxy able to forward a prefix, override a Host header and attach a geolocation header. Cloudflare involves the least configuration.