English
Deutsch
PolskiGoogle Tag Gateway: What It Changes in a Measurement Request and How It Differs From Server-Side Tagging
Contents
- What Actually Moves
- What It Deliberately Does Not Do
- The Cookie Question, and How to Settle It
- Blockers See the Path, Not Only the Host
- Where It Sits Next to a Server Container
- The Uplift Figure Is a Claim, Not a Measurement
- Setting It Up by Hand: What the Forwarding Rule Must Carry
- Questions and answers
- Sources
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, unless the container serves the Google scripts itself. 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.
Setting It Up by Hand: What the Forwarding Rule Must Carry
The Cloudflare and Google Cloud integrations configure the route themselves. Where the gateway is set up manually on another CDN or load balancer, Google’s setup guide lists a handful of requirements, and each one breaks something specific when it is missing.
- Origin. The upstream host is derived from the tag ID:
G-12345.fps.googfor a Google tag,gtm-abcdef.fps.googfor a Tag Manager container. TheHostheader of the forwarded request is overwritten with that name, and cookies and query strings are forwarded in full. - Path. The serving path is free to choose within limits: not the root
/, no longer than 100 characters, and not already in use on the domain. - Location. Without the gateway, Google derives location from the visitor’s IP address. Behind it, Google’s backend receives the address of the CDN instead, so the CDN has to attach the location as headers: preferably
X-Forwarded-CountryRegionwith an ISO 3166-2 code such asUS-CA, otherwiseX-Forwarded-Countrytogether withX-Forwarded-Region. If both variants arrive, the combined header takes precedence. The real client IP is passed on unaltered in a standard header such asX-Forwarded-For.
Missing location headers do not stop measurement. The hits still arrive, and the damage appears later as inaccurate geography in the reports, which is why the route is worth checking directly after go-live rather than in the monthly report:
# both answer with the text "ok" when the route is correct
https://shop.example/metrics/healthy
https://shop.example/metrics/?validate_geo=healthyThe first address confirms the route, the second that the location headers arrive. In Tag Assistant, the hits sent should then show the site’s own path. One element stays outside the gateway: the <noscript> snippet of Tag Manager is not supported and keeps pointing to www.googletagmanager.com.
Questions and answers
Why does the gateway drop every first-party cookie except Google’s?
Because the browser attaches every cookie that matches the domain and path to each request on the site’s own domain, including the shop’s login, basket or session cookies. Now that the measurement hits run through /metrics/ on the same host, those cookies travel along as far as the gateway. Forwarding them to Google would send data out of the site’s own infrastructure that has nothing to do with measurement; dropping them prevents exactly that.
Does the gateway change anything about consent or the consent banner?
Nothing about whether consent is required. That depends on access to the device and on the processing of the data, not on the hostname the script comes from. The tag still runs in the browser, reads and writes the same cookies and sends the same payload to Google, so nothing changes in the logic of Consent Mode either.
The banner, on the other hand, may well be affected, namely where it blocks scripts itself. Some consent tools recognise tags by their address and hold back anything served from googletagmanager.com until consent is given. Under /metrics/gtag/js on the site’s own domain that rule no longer matches. The tag may then load before the decision, even though the banner looks exactly as before.
After the switch it is therefore worth checking the network requests in the browser’s developer tools, both with consent refused and with consent still pending. If a request to the new path appears there that was missing before, the blocking rule needs the new path. It is the same logic as with the filter lists, only in the opposite direction.
How can it be checked whether common filter lists already block the path?
With a browser running a widely used ad blocker on its default lists. The network view in the developer tools then shows whether the request to /metrics/gtag/js or /metrics/g/collect goes through or is intercepted by the blocker; Chrome marks such requests with net::ERR_BLOCKED_BY_CLIENT. Because the lists are updated continuously, the result only describes the state at the time of the check and is worth repeating at regular intervals.
What does the gateway change in a Content Security Policy?
It moves the entries the tag needs to the site’s own origin. Script and hits now come from the same host as the page, and 'self' covers both in script-src and connect-src.
Whether the existing entries for googletagmanager.com and the measurement hosts can go, however, only becomes clear in operation. As long as any other tag or another Google service still addresses a Google host directly, its requests are blocked without those entries, and nothing on the page shows it. A trial run with a policy in the Content-Security-Policy-Report-Only header reports such violations without blocking anything, and only once nothing more appears there can the list be shortened.
Related articles
