Floodlight im Server-Side Tag Manager: Die Änderung vom Juni 2026 und wo die Einwilligungsprüfung sitzt

Die meisten Änderungen an einer Messschnittstelle sind langweilig, und die Anmerkungen dazu sind es auch. Eine vom Juni 2026 ist es nicht: Floodlight-Tags im serverseitigen Tag Manager beginnen, Anfragen ohne Einwilligung von Server zu Server zu übertragen.

Begründet wird das mit der Genauigkeit modellierter Abschlüsse, und die Begründung trägt. Bemerkenswert ist, wo der Satz steht: in einer Release Note, zwischen Basisimage-Aktualisierungen, nicht in einer Ankündigung mit eigener Seite.

Was die Anmerkung wörtlich sagt

Drei Aussagen stecken darin. Erstens: Die Änderung soll Abschlüsse zurückholen, die in serverseitigen Aufbauten zu niedrig gezählt wurden, weil der Cookiekontext des Browsers fehlte. Zweitens: Floodlight-Tags im serverseitigen Tag Manager übertragen künftig auch Anfragen ohne Einwilligung von Server zu Server. Drittens: Die serverseitigen Daten werden mit vorhandenen Browsersignalen zusammengeführt, sobald eine GCLID vorliegt.

Die dritte Aussage ist die technisch interessante und die erste eine echte Verbesserung. Die zweite ist die, die den Aufbau ändert.

Warum die Einwilligung im Browser den Serverweg nicht erreicht

Der Consent Mode wirkt dort, wo er sitzt: im Browser. Ein Tag, dem ad_storage verweigert ist, sendet keinen Treffer oder einen ohne Kennungen. Ein serverseitiger Container läuft dagegen auf eigener Infrastruktur, und was von dort hinausgeht, entscheidet die Vorlage im Container – nicht das Tor auf der Seite.

Damit der Server überhaupt weiß, wie die Entscheidung ausfiel, muss das Einwilligungssignal an ihn weitergegeben und dort ausgewertet werden. Genau an dieser Stelle greift die Änderung: Die Anfrage geht künftig auch dann hinaus, wenn das Signal Ablehnung sagt.

Zwei Wege, ein Tor

  Browser -> Google              Tor: Einwilligungsmodus
    ad_storage denied   Treffer bleibt aus oder kommt ohne Kennungen

  Browser -> eigener Server -> Google
    ad_storage denied   Anfrage geht hinaus (neu seit Juni 2026)
                        Zusammenführung nur, wenn eine GCLID vorliegt

  Das Tor steht auf dem oberen Weg. Der untere führt daran vorbei,
  und das ist keine Lücke, sondern die Bauart: der Server ist der
  eigene, und wer dort sendet, hat es selbst eingerichtet.

Was die Zusammenführung tatsächlich leistet

Der Teil mit der GCLID lohnt sich, unabhängig von allem anderen. Ein Abschluss, der über den Browser und über den Server gemeldet wird, war bisher schwer aufzulösen: Ohne gemeinsamen Anker sieht die Gegenseite zwei Ereignisse und muss raten, ob es zwei Abschlüsse sind. Die Klickkennung ist ein solcher Anker, und die Zusammenführung darüber ist genau das, was eine Doppelzählung beendet.

Wer serverseitig und im Browser parallel meldet, bekommt damit sauberere Zahlen. Das ist eine Verbesserung ohne Beigeschmack, und sie betrifft die sieben Bögen im Bild.

Die Frage, die die Anmerkung nicht beantwortet

Für die fünf Anfragen ohne Bogen bleibt die Rechtsgrundlage offen, und zwar in beide Richtungen. Artikel 5 Absatz 3 der ePrivacy-Richtlinie regelt den Zugriff auf das Endgerät – eine Übertragung zwischen zwei Servern berührt kein Endgerät, weshalb sich das Tor dieser Vorschrift auf dem unteren Weg tatsächlich nicht zwangsläufig wiederfindet. Die DSGVO gilt dagegen unverändert, und die Daten stammen ursprünglich sehr wohl vom Endgerät.

Damit stehen zwei ernst zu nehmende Lesarten nebeneinander, und beide haben Vertreter. Die eine sagt, ohne Zugriff auf das Gerät fehle der Anknüpfungspunkt für die Einwilligungspflicht. Die andere sagt, eine Ablehnung, die sich durch einen Umweg über eigene Infrastruktur erledigt, sei keine Ablehnung. Welche sich durchsetzt, ist nicht entschieden, und dieser Artikel entscheidet es nicht. Was hier steht, ist eine Beschreibung des Vorgangs und keine Rechtsberatung.

Ebenfalls unbeantwortet lässt die Anmerkung, ob sich das Verhalten abschalten lässt. Das ist die erste Frage, die sich an einem laufenden Aufbau klären lässt, und sie lässt sich klären, ohne auf eine Auslegung zu warten.

Was sich am eigenen Container nachsehen lässt

Drei Dinge, in dieser Reihenfolge. Erstens: ob überhaupt Floodlight-Tags im serverseitigen Container liegen – ohne die betrifft die Änderung den Aufbau nicht. Zweitens: ob das Einwilligungssignal den Server erreicht, denn ein Server, der es nie bekommt, konnte auch vorher nicht danach unterscheiden. Drittens: was die Tag-Vorlage anbietet, um bei Ablehnung nicht zu senden.

Der Befund ist in einer Vorschau ablesbar. Wer im Debug-Modus des serverseitigen Containers eine Sitzung mit abgelehnter Werbespeicherung durchspielt und die ausgehenden Anfragen mitliest, sieht unmittelbar, was hinausgeht. Diese Prüfung kostet eine halbe Stunde und ist die einzige Grundlage, auf der sich die Frage überhaupt besprechen lässt – alles andere ist eine Vermutung über den eigenen Aufbau.