If your GA4 traffic flows through a server-side Google Tag Manager container on one of your own subdomains, ConsentGuard previously couldn't see it. A request to gtm.example.com doesn't touch google-analytics.com, so it slipped past the URL filters our validator used. Sites running sGTM looked like they were doing no analytics at all, and we reported zero consent-mode violations even when there were plenty.
That changes today. ConsentGuard now detects server-side GA4 traffic and runs the full Google Consent Mode check (gcs, gcd, dma, npa, the lot) against it.
A quick recap of what server-side tracking actually means here
In a classic client-side setup, your gtag fires straight from the browser to google-analytics.com. The browser carries the consent signals (gcs, gcd) as URL parameters, Google's edge reads them, and that's the request we validate.
In a server-side setup, the browser sends the hit to a first-party endpoint you control, usually a subdomain like gtm.example.com or a path like example.com/sst/. That endpoint runs an sGTM container (Cloud Run, Stape, Tagual, Taggrs, Addingwell). The container then forwards the hit to Google over its own server-to-server connection.
People deploy this for good reasons: you can bypass Apple's ITP and ad blockers, extend cookie lifetime, and keep control over what the outbound payload contains.
The trade-off for compliance is that the request leaving the browser no longer mentions google-analytics.com, so naive validators look at it and see nothing. Your consent-mode plumbing still has to be correct, though. The browser still has to carry gcs and gcd to your tag endpoint, and your tag endpoint still has to receive them honestly. That browser-to-server handoff is the part we validate.
What you'll see in your report
Once a server-side GA4 hit is detected, the same Google Consent Mode rules run against it as against a normal client-side hit. You may now see:
- Consent Signal Missing (Before User Interaction) and Invalid Consent Signal (Initial) on tag-endpoint requests that previously appeared invisible to us.
- Invalid Google Consent Data (Before User Interaction / After User Rejected / After User Accepted) on hits with malformed consent default strings.
- Forbidden Cookies Set Before User Consent and Forbidden Cookies Set After User Rejected on
_ga*/FPID/FPLCcookies dropped on your own domain before the user has consented.
The reported service shows up under its own name in the report so you can tell at a glance whether a violation came from the client-side path or the server-side one.
What we still can't see (and won't pretend to)
ConsentGuard is an external headless browser. It validates what leaves your visitors' browsers and what cookies are set on your domain. That's the slice we have access to.
We don't see what your sGTM container does after it receives the hit. The outbound call from your server to Google, the transformations the container applies, what gets stripped or rewritten on the way: all of that is server-internal, and an external validator has no honest way to observe it. If you forward a hit with gcs=G111 from the browser, we'll tell you that. What your container then does with it before forwarding to Google sits inside your tag config.
The honest framing is this: we validate the browser-to-tag-endpoint hop. If the consent signals leave the browser correctly, and the cookies on your domain behave correctly, the visible part of your sGTM compliance story is in good shape.
Who should re-run their check
If you already have a ConsentGuard account, there's nothing for you to do. Your scheduled checks will pick up server-side GA4 traffic on your monitored sites automatically, and any new violations will surface in your usual report.
If you previously only ran a one-off free check, and the GA4 section came back suspiciously clean despite the site running sGTM, it's worth a fresh scan now.
If you'd like ongoing monitoring across all your sites, with notifications when something breaks, you can start a 14-day free trial. No credit card required.
If you spot a false positive (or a real positive we should have caught and didn't), let us know. The fingerprint thresholds are tuned from real reports, so the more weird-in-the-wild setups we see, the better the next round gets.
—
Mihai
Cofounder, ConsentGuard.io