How to debug server-side GTM

Server-side tagging moved the interesting part of the pipeline out of the browser. That is good for performance and data control, and inconvenient for everyone trying to debug it: the hits you used to read in the network tab now go to a domain you own, in a shape most tools do not recognise.

Why most debuggers go blank

Almost every tag inspector identifies traffic by hostname. It keeps a list — google-analytics.com, facebook.com, bat.bing.com — and ignores everything else. The moment your GA4 client sends to sst.yoursite.com instead of google-analytics.com, the hostname no longer matches, and the request is dropped before anything looks at it.

The fix is to match on the path first and treat the host as a secondary signal. A request to /g/collect?v=2&tid=G-XXXX is a GA4 hit whether it lands on Google's servers or on a subdomain of your own shop. Tag Master classifies this way, which is why proxied traffic still shows up, decoded, with a server-side badge next to it.

Four signals that a site runs sGTM

You rarely get a single definitive answer. Score the evidence instead:

1. Collection paths on a first-party host. /g/collect, /mp/collect, or /gtm.js?id=GTM-XXXXXX served from a subdomain of the site itself rather than googletagmanager.com. Same registrable domain as the page is the strongest version of this signal.
2. An HttpOnly FPID cookie. JavaScript cannot set HttpOnly cookies, so an FPID written that way came from a server. Its companion FPLC is usually visible too. This is close to conclusive.
3. A declared endpoint in the tag config. Look for server_container_url or transport_url in the page's gtag configuration — that is the setup telling you where it sends data.
4. Silence where you expect noise. GA4-shaped requests leaving the page but nothing at all going to google-analytics.com means the traffic is being relayed somewhere else first.

Connecting to a server preview session

Detection tells you sGTM exists. To see what the server container actually does with a hit, you need its preview session, and that session is keyed to a header: X-Gtm-Server-Preview.

Open your server container in GTM, click Preview, and copy the token it gives you. In Tag Master, open the GTM tab, paste the token and your endpoint domain into the sGTM preview box, and switch it on. From then on, requests from your browser to that domain carry the header, and they appear in the preview session alongside the tags they trigger. Turn the toggle off when you are done — the rule is removed immediately.

What to check once you can see the traffic

• Does the client claim the request? An unclaimed request means your GA4 client is not configured for the path the browser is using.
• Are consent signals surviving the hop? The gcs and gcd parameters should arrive at the server container, not be dropped on the way.
• Is the event name intact? Renaming in transit is a common cause of "the event fires but the report is empty".
• Which vendors are being relayed? A Meta or TikTok event with an event_id and no matching browser pixel usually means the server is sending it — check for duplicates on the other side.

A short checklist

1. Reload the page with the panel open so you catch the first request.
2. Look for the server-side badge on GA4 hits — that confirms path-based classification found your endpoint.
3. Check the cookie list for HttpOnly FPID.
4. Paste your preview token to connect the server session.
5. Compare browser events against what the server reports; the gap is where your data loss lives.

Doing this in the panel →

The rest of this group: GA4, server-side and attribution

• Debugging GA4 when DebugView shows nothing
• GA4 counting everything twice
• Google Tag Gateway: checking that it actually works
• When GA4 says the traffic came from somewhere else
• The email that left in plain text

More in GA4, server-side and attribution