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 routes for switching it on, and the point at which it stops. I have set one up through Cloudflare, and I run Google Tag Manager server containers in production, so the comparison here comes from operating both.
Google tag gateway for advertisers, defined
Google tag gateway for advertisers is Google's name for serving its measurement scripts, and the requests those scripts go on to make, from a path on a domain the advertiser already owns. Google's documentation describes it as deploying a Google tag using first-party infrastructure, set up through an existing content delivery network, load balancer or web server. The tag executes in the browser exactly as before. What moves is the address it is fetched from and the address it posts to.
The scope is the Google estate and nothing beyond it: Google Ads, Google Analytics, Campaign Manager 360, and web containers in Google Tag Manager. No provision exists for any other measurement vendor. That is worth establishing early, because the phrase "first-party" is used loosely in sales material.
The feature spent its first weeks under a different name. Google opened it in beta on 19 March 2025 as first-party mode, then retitled it on 8 May 2025 with a release note reading "First-party mode is now Google tag gateway for advertisers". Plenty of agency write-ups and internal documentation still say first-party mode. It refers to the same thing, and searching for the old name now mostly returns pages about the new one.
How the gateway works, in the proxy and on the page
Two changes make it run, and both are small enough to fit on a page. One lives in whatever sits in front of the origin; the other is an edit to the tag snippet.
The measurement path
A path chosen on the advertiser's domain, written as /metrics in Google's examples. It must be unused, it cannot be the root path, and it is capped at 100 characters.
The origin endpoint
Traffic on that path is forwarded to an endpoint of the form G-XXXXXXX.fps.goog, with the Host header overridden to match. Cookies and query strings are passed through. A container uses gtm-xxxxxx.fps.goog instead.
Geolocation headers
The proxy has to attach approximate location: X-Forwarded-CountryRegion as a single ISO 3166-2 code, or X-Forwarded-Country as ISO 3166-1 alpha-2 with X-Forwarded-Region alongside it. X-Forwarded-Geolocation carries latitude, longitude and city, and is optional.
The snippet edit
The gtag.js source becomes the measurement path. A Tag Manager container becomes that path with ?id= and the container ID appended. Everything else in the snippet is untouched.
The noscript exception
Google documents the Tag Manager noscript snippet as unsupported through the gateway. Sites relying on it for anything measurable should know that before switching over.
The health check
Appending /healthy to the path returns "ok" once the route is live, and ?validate_geo=healthy confirms the location headers are arriving. Tag Assistant then shows hits on the new path.
On Cloudflare none of that is typed out. The reverse proxy already in front of the domain intercepts a call to the first-party path, rewrites it back to the Google endpoint with the query string intact and the Host header set to the one Google expects, fetches the script, and sends every measurement payload afterwards down the same route. Nothing is deployed and no CNAME record is created.
What improves for measurement, and what stays exactly as it was
Two things genuinely improve. The tag request and the measurement hits 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 on them. And the script arrives over a connection to infrastructure the business already pays for, which takes a third-party dependency out of page load. Google's wording is that some measurement requests move, not that all of them do, so a network tab remains the only way to see what a given site actually ends up with.
The blocking gain is partial, and it is not permanent. The path is picked by the site, which means a predictable one is trivial to add to a public list; Google's advice to choose something unused reads better as advice to choose something unremarkable. Extensions that judge a script by its behaviour are unaffected either way, and the documented health-check path lets anyone outside the business confirm a deployment.
Cookie lifetime does not move at all, and this is where most write-ups on the subject go wrong. The Google tag is still JavaScript running in the visitor's browser, and it still writes its identifier through document.cookie. Safari's seven-day cap covers cookies written that way whatever host delivered the script. A gateway deployment on its own extends no cookie by a single day. Doing that needs an identifier issued in an HTTP response header, and issuing one is a server container's job.
Fastly has published a 14% uplift figure for the feature. It is an average across advertisers, and the result on any one site follows that site's own browser mix and audience.
Setting it up: Cloudflare, Google Cloud, Akamai, Fastly and CloudFront
The gateway needs something in front of the origin capable of rewriting a path, so the existing infrastructure decides the route, not preference.
One click from the Google tag interface
The first route to ship and still the least work, provided the domain is proxied through Cloudflare already. Setup runs from the tag interface, and a rollback control landed in June 2025 so the configuration can be backed out from the same screen. This is the route I have used, and it takes minutes.
A global external Application Load Balancer
In beta from 5 January 2026 and 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 that balancer. A Cloud project, the Google Tag Gateway Admin role and somebody from the platform side are all prerequisites.
Zone detection driven from the tag interface
Akamai arrived on 29 January 2026, configured through Property Manager. Streamlined setup covering both Akamai and Fastly followed on 14 May 2026, with the CDN zone detected and the routing rule injected from the Google tag interface. Amazon CloudFront followed on 3 June 2026, configured through Tag Assistant.
The documented rules, applied by hand
Anything else means writing the configuration: forward the path, 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.
The cost shape follows the route. Where a supported CDN already fronts the domain, the gateway is a configuration change with nothing further to procure, which is most of why the Cloudflare option gets taken. On Google Cloud the load balancer is a billed resource carrying the site's entire traffic, so the charge lands with platform engineering and has little to do with any tagging budget. Neither arrangement introduces a container image to keep patched.
What the gateway is not, and what it will never do
The gateway is a transport change. Google describes it as a way to deploy a tag from first-party infrastructure, and that description is precise. Everything below 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 request body reaches Google in the form the browser composed it.
No transformation
Parameters cannot be added, renamed, trimmed or hashed in transit, because no component in the chain is reading the payload in order to change it.
No redaction
An address or an identifier sitting in a query parameter travels as sent. There is no checkpoint at which a value can be removed 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 a consent state. That decision 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 that sits in memory where configuration can read it, and separate tags then make their own outbound calls to whichever destinations are set up. That container can drop a field, hash a value, correct a currency, decline to forward at all, and issue an identifier in a response header.
The useful question is whether the data needs handling before it goes. Where it does not — the Google tags are correct, the payloads are right, and the only real complaint is that a share of them never land — the gateway answers the complaint and a container is overbuilt for it. Where it does, the gateway has nothing in the chain able to do it.
They also compose. Google documents a setup in which the gateway fronts a server container, so the first-party path and the event handling both apply at once. That is where a business tends to land after deciding, separately, that the container pays for itself.
When the gateway on its own is the right answer
A good number of the setups that get 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 single genuine grievance is that a proportion of those hits go missing, and that is the grievance the gateway addresses.
The proxy is already paid for
A domain sitting behind Cloudflare, Akamai or Fastly has the necessary component in place, and the setup is a configuration screen. No procurement, no new invoice, and no additional thing running that somebody has to remember.
No one internally will hold a container
A gateway route has no image to patch and no host to keep alive. Where the business has nobody to take a live service on at handover, that absence counts for more than the capability given up.
The events themselves are sound
A clean set of events that occasionally fails to arrive is a delivery problem, and delivery is what gets fixed here. A confused set of events is a different problem, and relocating it solves none of it.
When a server container earns the extra cost
Three situations turn the container into the correct call, and each of them reduces to needing somewhere to stand between the browser and the vendor.
The first is 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 at all, and the gateway contributes nothing towards it. The same applies to every other conversions API worth feeding properly.
The second is cookie lifetime on Safari, for the reason set out further up. An identifier delivered in a response header from a host on the same registrable domain is treated differently from one a script wrote, and only a container is in a position to deliver one.
The third is the data itself. Where a data protection officer has asked what leaves the business, or where a payload carries a field that was never meant to travel, something in the chain has to be able to read the event and act on it. The gateway holds no such component, and no setting adds one.
Set against those: a recurring hosting charge, an ownership question that has to be answered before handover, and a build with a real scope. Where the balance comes out in favour, scoping the tracking work is a separate conversation, and one worth having 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, the consent state is read where it was read, and Consent Mode governs what each Google tag may do on exactly the terms it did before. Google's own material is clear that the requirement remains.
So how the consent signals are wired is unchanged by a gateway deployment, and an implementation that was wrong beforehand is wrong afterwards in precisely the same way.
One thing does need retesting, and it is easy to skip. A consent platform that gates scripts by matching a source URL will hold a rule for googletagmanager.com. Serve the same script from a path on the advertiser's domain and that rule no longer matches, so a tag that was previously held back until permission arrived may start loading straight away. The remedy is a rule for the new path. The wider point is that the switch has to be checked in each consent state and not assumed to be a transport detail.
A visitor who declined is unaffected by a gateway deployment in either direction.
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, which is most of why the Cloudflare route gets taken so often. 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, and the container does the parsing, the reshaping and the fan-out to each destination. It is the arrangement to aim at once a container has been 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 of the supported routes.