Home / Guides

Google Tag Gateway: checking that it actually works

Tag Gateway serves Google's scripts from your own domain. What changes on the wire, how it differs from server-side GTM, and the four ways it quietly half-works.

Published 10 August 2026

Tag Gateway moves the delivery of Google's measurement onto your own domain. Instead of the browser fetching gtag.js from googletagmanager.com and posting to google-analytics.com, both go through a measurement path on your host — something like example.com/metrics/… — which your CDN forwards to Google.

It is not server-side GTM, and the difference matters

These get conflated constantly, and they fail in completely different ways.

• Server-side GTM moves tag execution to a container you run. The browser sends one request to your server; your server decides what to forward and to whom. You can rewrite, enrich or drop events there.
• Tag Gateway moves only the transport. The tags still execute in the browser, the payload is unchanged, and your infrastructure is a pipe rather than a participant.

You can run both, either, or neither. If you are debugging a missing event, knowing which one is in play tells you whether to suspect a container configuration or a routing rule.

What changes on the wire

Nothing inside the request. tid, en, cid, the event parameters, the items, the consent flags — all identical. What changes is the host and the path prefix. That single fact explains why so many debugging tools go blank: they recognise Google hits by hostname, and the hostname is now yours.

Reading the requests by path instead — a /g/collect anywhere, on any host — keeps them visible, which is the same trick that makes server-side GTM hits readable.

Four ways it half-works

1. The script is first-party but the hits are not. A partial configuration serves gtag.js from your domain while collection still goes to Google. Everything looks fine in reports and you have none of the durability you set this up for. Check the host on the /g/collect request, not on the script.
2. The measurement path collides with an application route. If your app already answers on that prefix, or your router has a catch-all, the CDN rule never gets a chance and requests come back as your own 404 page. A 404 on a collect request is not a tracking bug you will find in GA4; it is only visible in the network.
3. A cache rule catches the endpoint. Measurement paths sit on the same domain as your pages, so a broad caching rule can apply to them. A cached collect response does not lose the hit — the request still leaves — but a cached gtag.js can pin visitors to an old configuration for as long as the TTL says.
4. Consent is unchanged and people assume otherwise. First-party delivery does not alter what you are allowed to collect, when Consent Mode signals are read, or whether a banner has to appear. The gcs and gcd parameters travel exactly as before, and they are the thing to check.

The part worth being deliberate about

Some of the reported uplift from first-party serving comes from requests that a content blocker would have stopped on a Google hostname and does not stop on yours. That is a real effect and worth understanding rather than discovering later: it is a decision about how you treat visitors who have chosen to block tracking, and it is separate from whether your consent implementation is correct.

A routine

1. Load a page and find the gtag.js request. Note its host.
2. Find a /g/collect request. Note its host too. If the two disagree, the configuration is half-done.
3. Check the status code. A gateway misroute shows up as a 404 or a redirect, never as missing data in a report.
4. Open the hit and confirm tid, the event name and gcs are what they were before the migration. The payload should be untouched.
5. Walk a conversion end to end and compare the numbers with the previous setup before you decommission it.

Related guides

• When GA4 says the traffic came from somewhere else
• Tracking inside an embedded widget
• How to debug server-side GTM