Tag Gateway Changes the Host, Not the Payload
Contents
Google tag gateway for advertisers began on Cloudflare, reached general availability on Google Cloud on 1 June 2026 through an external application load balancer, and gained an Amazon CloudFront setup path in the same month. It is now a routine option rather than an experiment, and it is routinely described as a lighter alternative to server-side tagging.
It is not an alternative to it. The two change different things, and reading the request itself makes the difference obvious in about a minute.
What Actually Moves
The gateway is a reverse proxy on a path of the site’s own domain. Both the script and the measurement hits go through it – the tag is loaded from something like /metrics/gtag/js instead of googletagmanager.com, and the hits go to /metrics/g/collect on the same host. The CDN, load balancer or web server rewrites the path and forwards the request to Google.
From the browser’s point of view every one of those requests is now first-party. That is the entire mechanism. Nothing about the request body changes on the way through, and nothing is meant to: the documentation states that only Google first-party cookies pass, and that any other first-party cookies forwarded through the gateway are dropped rather than processed.
What It Deliberately Does Not Do
The tag still runs in the browser, builds the payload in the browser, and sends the payload it built. There is no place in this arrangement to remove a parameter that should not have been collected, to look up a customer value from an internal system, or to decide on the server that a hit should not be forwarded at all. Those are the things a server container exists for, and the gateway has no opinion about any of them.
| Tag gateway | Server-side GTM | |
|---|---|---|
| Host in the request | Own domain | Own domain |
| Where the tag runs | In the browser | On the server |
| May alter the payload | No | Yes |
| Redaction and minimisation | No | Yes |
| Enrichment from own systems | No | Yes |
| What has to be operated | A routing rule | A container with a lifecycle |
The Cookie Question, and How to Settle It
The claim most often attached to first-party serving is that it restores cookie lifetime under Safari. That depends entirely on which mechanism writes the cookie, and the distinction is sharp. A cookie written by JavaScript is capped at seven days by Intelligent Tracking Prevention regardless of which host served the script, while a cookie written by the server in a Set-Cookie response header keeps the lifetime it asks for.
Google’s page on tag gateway cookie handling describes which cookies pass and which are dropped. It does not state which of the two mechanisms writes them. That is not a reason to guess in either direction – it is a reason to look, and looking takes one request.
# what the browser now requests, first party throughout
GET https://shop.example/metrics/gtag/js?id=G-XXXXXXX
GET https://shop.example/metrics/g/collect?v=2&tid=G-XXXXXXX&...
# the question the documentation leaves open
curl -sI 'https://shop.example/metrics/g/collect?v=2&tid=G-XXXXXXX' \
| grep -i '^set-cookie'
# no line → the script writes it, seven days under ITP
# a Set-Cookie line → the server writes it, the Max-Age holdsThe same answer is visible in the browser under Application, by checking whether the cookie appears before or only after the tag has run. Whichever way it comes out, the result is a fact about that installation rather than a general property of the product, and it belongs in the notes for whoever inherits the setup.
Blockers See the Path, Not Only the Host
A first-party path defeats the crudest form of blocking, which is a hostname list. It does not defeat a rule that matches the path segment, the script contents or the shape of the request body, and the widely used filter lists gained path-based rules for exactly this pattern soon after it appeared.
The realistic expectation is therefore a recovery rather than a restoration – some share of previously blocked traffic reappears, the share depends on which lists the audience runs, and it decays as lists are updated. Choosing an inconspicuous path name buys a little time and is not a strategy.
Where It Sits Next to a Server Container
Google’s own recommendation is to do both, and the reason is that they solve adjacent problems: the gateway fixes the delivery path, the container fixes what travels along it. A site with a server container and no gateway still loads its tag from a third-party host. A site with a gateway and no container has a first-party path carrying an unexamined payload straight to Google.
If only one can be built, the order follows from what the site actually needs. Where the problem is data protection – a parameter that must not leave, a value that must be hashed before it does – only the container solves it, and a gateway in front of an unfiltered payload solves nothing. Where the problem is measurement loss on a site with nothing sensitive in the payload, the gateway is far cheaper and does the whole job.
The Uplift Figure Is a Claim, Not a Measurement
Vendors report conversion uplifts in the region of nine to eighteen per cent after a gateway deployment. Those numbers come from the parties selling the deployment, they are averages over unnamed sites, and they conflate three effects that move in the same direction – fewer blocked requests, longer-lived cookies where the cookie is server-set, and the ordinary seasonal drift of whatever period the comparison used.
The honest test is a holdout: leave a share of traffic on the old path, run both for a fortnight, and compare the two arms rather than two time periods. That is more work than reading a case study, and it is the only version of the number that will survive a question about it.
Related articles
