Google updated the Tag Manager release notes in the last two weeks with a change that didn't get a blog post, a press release, or a line in the Ads changelog. It's sitting in the standard release notes page, the one most teams check once a quarter if at all.
Here's the change: Floodlight tags in server-side Tag Manager now transmit unconsented requests server-to-server. Google's stated reason is "to enhance the accuracy of modeled conversions." In the same release, Google also fixed a related gap: server-side conversions that lacked browser cookie context were getting undercounted. Now, when a GCLID is present, server-side data gets joined with parallel browser signals like cookies, so Floodlight can attribute more of what's actually happening.
Why this matters
Before this change, "unconsented" meant one of two things depending on your setup. Client-side, it meant Consent Mode picked it up and Google modeled the gap using aggregated, anonymized signals, no raw hit involved. Server-side, it often meant the hit got dropped entirely at the container level if you built your consent gating correctly, because you didn't want unconsented data leaving your server.
That second path just changed. Server-side GTM is now forwarding unconsented Floodlight requests server-to-server specifically to feed the modeling pipeline. That's a different data flow than what most server-side consent architectures were built around.
If you're running a server container with a consent gate that assumes "denied means it stays local, gets dropped, or gets stripped down to nothing," check whether that assumption still holds. The release notes don't specify exactly what fields ride along in these unconsented payloads. That ambiguity is the problem. If a client's data protection team signed off on your server-side setup based on "no ad-cookie-consent data leaves the container," that sign-off may no longer describe what the container does. This is the same failure mode I see in broken Consent Mode v2 and server-side tracking builds: the dashboard says consent is configured, but the payload tells a different story.
The second piece, GCLID-based joining of server data with browser cookies, changes your numbers even if you never touch consent settings. Attribution outputs in Floodlight and CM360 will shift because conversions that used to sit uncounted (no cookie context, no join) now get matched and attributed. Any QA baseline you built comparing server-side conversion volume against client-side GA4 or Meta CAPI numbers is now comparing against a moving target.
This also sits inside a broader pattern: Google's push toward one unified "Google tag" behavior across GTM, which the same changelog documents alongside UI and container-ID changes. Client-side and server-side pipelines are being blended more aggressively, and Floodlight's unconsented-hit behavior is one visible piece of that.
What to do now
Pull the actual payload. Set up a test container, deny ad-cookie consent, fire a Floodlight tag, and inspect what the server container sends upstream. Check every parameter. Look specifically for anything that could function as an identifier: hashed emails, click IDs, session identifiers riding in custom parameters. If you need the longer checklist, start with the same payload review I use before an sGTM migration audit. "Unconsented" should mean de-identified. Verify it, don't assume it.
Re-read your consent gating logic in the server container. If you built tag firing rules around "block Floodlight entirely when consent is denied," those rules may now be irrelevant to what Google's own tag template does internally. Check whether your gating happens before or after the point where Google's Floodlight tag template decides to send the unconsented ping.
Update client documentation now, not after a data protection audit finds it. Any client-facing document that says "unconsented users generate no server-side conversion data" needs a rewrite. The accurate statement is closer to: "unconsented users generate a reduced, modeled data point that leaves the server specifically for Google's conversion modeling." Say that plainly. Clients relying on server-side GTM as a GDPR or CCPA control need to know the boundary moved.
Reset your QA baselines. Pull Floodlight/CM360 conversion counts from before and after this rolled into your containers. The GCLID-cookie join alone will move volume upward in accounts with meaningful cross-device or cross-session gaps. Don't flag that as a tracking break. Flag it as expected, then recalibrate whatever thresholds you use to catch actual anomalies.
Check consent mode configuration end to end. This change assumes Consent Mode is correctly signaling denial status to the server container in the first place. If your Consent Mode implementation has gaps (default states misconfigured, regional settings wrong, consent update events not firing before the Floodlight tag executes), this new behavior compounds those gaps instead of just modeling around them.
The bigger pattern here is one to watch, not just this one release. Google is not asking for permission before changing what "unconsented" data flow means inside server-side containers. It's disclosing it in a changelog most measurement teams don't monitor closely. If you run server-side GTM for clients who care about data minimization, this is now a recurring audit item, not a one-time check.
Related reading
- The complete guide to server-side tracking migration
- Consent Mode v2 and server-side tracking
- Audit your GTM container before an sGTM migration
Sources
- https://support.google.com/tagmanager/answer/4620708?hl=en