Debug sGTM in Chrome DevTools

What sGTM traffic looks like

Server-side GTM has no fixed hostname to look for. That is the point of it; the browser sees GA4's wire format aimed at the site's own domain.

Endpoint pattern

A first-party host like metrics.example.com/g/collect or sst.example.com/g/collect, set client-side via the GA4 config's server_container_url / transport URL; the same host often also serves the gtag loader itself; managed services (Stape, Addingwell, TAGGRS, Cloudflare Zaraz) sit behind a customer-chosen subdomain, so the URL alone rarely names the supplier

Key parameters

The familiar measurement-protocol parameters: tid=G-XXXXXXX measurement ID · en event name · cid client ID · dl page URL

Consent signals

gcs/gcd Consent Mode signals ride the browser-to-server request just as they do on Google's own endpoints; the server container is expected to honor them downstream

Payload

The browser only sees the first hop: whatever the server container forwards to afterward (GA4, Meta Conversions API, other destinations) happens between servers and never appears in DevTools; client-side debugging verifies that first hop is correct and consented, the fan-out is verified in the server container's own preview

Debugging sGTM with Event Watcher

• No hostname pattern to match (the catalog entry's pattern list is empty), so sGTM is identified by protocol shape: GA4 measurement-protocol markers (the /g/collect path, a tid=G-*) arriving at a first-party domain are flagged as server-side forwarding, most commonly sGTM.
• Each hit appears in the stream with its query and body parameters parsed.
• The per-event Cookies section with its direction badges is particularly useful here, since server containers commonly manage first-party cookies (such as FPID) via response headers rather than JavaScript.

sGTM and consent

Event Watcher checks sGTM hits against the analytics consent category.

The platform-specific nuance is the persistent misconception that first-party collection is outside consent scope. It is not; moving the endpoint to your own domain changes the transport, not the legal basis.

A /g/collect hit leaving the browser before the user consents is still a pre-consent hit, and Event Watcher marks it accordingly. See GA4 fires before consent and debugging Google Consent Mode v2.

Common debugging scenarios

• Verifying a migration to server-side. Confirm hits now target the first-party endpoint instead of google-analytics.com. The Grouped view pivoted by Endpoint shows the split at a glance.
• Duplicate collection. Mid-migration setups often send the same events to both the first-party endpoint and Google's endpoint; pivot by Event Name to spot the doubles.
• "It's first-party, so consent doesn't apply." Show the pre-consent verdicts on the first-party hits; the violations counter totals them.
• Consent Mode signals missing on the server hop. Inspect the parsed parameters for gcs/gcd. If they are absent on the browser-to-server request, the server container cannot forward correct consent state.
• Cookie behavior looks different after migrating. Use the Cookies section per event to see which cookies the endpoint sets versus receives. Server-managed cookies are the usual explanation.