English
Deutsch
PolskiFloodlight in Server-Side Tag Manager: The June 2026 Change and Where the Consent Check Sits
Contents
Most changes to a measurement interface are dull, and the release notes about them are duller. One from June 2026 is not: Floodlight tags in server-side Tag Manager begin transmitting requests without consent, server to server.
The stated reason is the accuracy of modelled conversions, and that reason holds. What stands out is where the sentence sits: in a release note, between base image updates, rather than in an announcement with a page of its own.
What the release note actually says
Three statements sit inside it. First: the change is meant to recover conversions that were undercounted in server-side setups because the browser’s cookie context was missing. Second: Floodlight tags in server-side Tag Manager will now transmit unconsented requests server to server. Third: the server-side data is joined with parallel browser signals when a GCLID is present.
The third statement is the technically interesting one and the first is a genuine improvement. The second is the one that changes the setup.
Why the consent in the browser does not reach the server path
Consent mode acts where it sits: in the browser. A tag denied ad_storage sends no hit, or one without identifiers. A server-side container, by contrast, runs on infrastructure of one’s own, and what leaves it is decided by the template inside the container – not by the gate on the page.
For the server to know how the decision went at all, the consent signal has to be forwarded to it and evaluated there. That is exactly where the change bites: the request now goes out even when the signal says refused.
Two paths, one gate
browser -> Google gate: consent mode
ad_storage denied hit is withheld or arrives without identifiers
browser -> own server -> Google
ad_storage denied request goes out (new since June 2026)
joined only where a GCLID is present
The gate stands on the upper path. The lower one runs past it,
and that is not a loophole but the architecture: the server is
one's own, and whoever sends from it set it up.What the join genuinely achieves
The GCLID part is worth having regardless of everything else. A conversion reported both through the browser and through the server used to be hard to resolve: without a shared anchor the receiving side sees two events and has to guess whether they are two conversions. The click identifier is such an anchor, and joining on it is precisely what ends a double count.
Anyone reporting server-side and in the browser in parallel therefore gets cleaner figures. That is an improvement without an aftertaste, and it concerns the seven arcs in the picture.
The question the release note does not answer
For the five requests without an arc the legal basis stays open, and it does so in both directions. Article 5(3) of the ePrivacy Directive governs access to terminal equipment – a transmission between two servers touches no terminal equipment, which is why the gate of that provision genuinely does not necessarily reappear on the lower path. The GDPR, on the other hand, applies unchanged, and the data did originally come from terminal equipment.
Two readings worth taking seriously therefore stand side by side, and both have advocates. One says that without access to the device there is no hook for the consent requirement. The other says that a refusal disposed of by a detour through one’s own infrastructure is not a refusal. Which prevails is not decided, and this article does not decide it. What stands here is a description of the mechanism and not legal advice.
The note likewise leaves unanswered whether the behaviour can be switched off. That is the first question answerable on a running setup, and it can be answered without waiting for an interpretation.
What can be checked in one’s own container
Three things, in this order. First: whether there are any Floodlight tags in the server-side container at all – without them the change does not touch the setup. Second: whether the consent signal reaches the server, because a server that never receives it could not distinguish on that basis before either. Third: what the tag template offers for not sending on refusal.
The finding is readable in a preview. Running a session with advertising storage refused through the server-side container’s debug mode and reading along with the outgoing requests shows immediately what leaves. That check costs half an hour and is the only ground on which the question can be discussed at all – everything else is a guess about one’s own setup.
Questions and answers
With basic consent mode, does an unconsented request reach the server at all?
Usually not. In basic mode the Google tags only load after consent; anyone who refuses produces no measurement request in the browser at all, and the server-side container has nothing a Floodlight tag could pass on. In such a setup the June 2026 change comes to nothing, as long as no other tags send data to the site’s own server without consent.
In advanced mode the tags load immediately and, on refusal, send requests without cookies or identifiers. These reach the site’s own server, and they are precisely the unconsented requests that, according to the release note, a Floodlight tag in the container will now pass on. The same applies to requests that a custom script sends to the container regardless of consent.
Which mode a site runs therefore helps decide whether the change touches the setup at all. It can be read in the browser’s network tab: if requests to the site’s own tagging server still go out after a refusal, advanced mode or another path is involved.
Does the change also affect other Google tags in the server-side container?
The release note only mentions Floodlight tags, and nothing more can be derived from it. Whether other tags in the same container, for example for Google Ads or GA4, behave similarly is shown by the same check as in the article: running a session with advertising storage refused through debug mode and looking at the outgoing requests tag by tag.
Related articles
