{"id":10609,"date":"2026-09-30T12:30:00","date_gmt":"2026-09-30T10:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10609"},"modified":"2026-09-25T10:49:12","modified_gmt":"2026-09-25T08:49:12","slug":"floodlight-im-server-side-tag-manager-die-anderung-vom-juni-2026-und-wo","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/data-privacy-de\/floodlight-im-server-side-tag-manager-die-anderung-vom-juni-2026-und-wo\/","title":{"rendered":"Floodlight im Server-Side Tag Manager: Die \u00c4nderung vom Juni 2026 und wo die Einwilligungspr\u00fcfung sitzt"},"content":{"rendered":"

Die meisten \u00c4nderungen 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<\/em> Einwilligung von Server zu Server zu \u00fcbertragen.<\/p>\n

Begr\u00fcndet wird das mit der Genauigkeit modellierter Abschl\u00fcsse, und die Begr\u00fcndung tr\u00e4gt. Bemerkenswert ist, wo der Satz steht: in einer Release Note, zwischen Basisimage-Aktualisierungen, nicht in einer Ank\u00fcndigung mit eigener Seite.<\/p>\n

\n\"Ein
Sieben Anfragen finden ein Gegenst\u00fcck und werden damit zusammengef\u00fchrt. Die f\u00fcnf ohne Bogen sind die, f\u00fcr die nie ein Browsertreffer entstand – und sie sind der neue Teil.<\/figcaption><\/figure>\n

Was die Anmerkung w\u00f6rtlich sagt<\/h2>\n

Drei Aussagen stecken darin. Erstens: Die \u00c4nderung soll Abschl\u00fcsse zur\u00fcckholen, die in serverseitigen Aufbauten zu niedrig gez\u00e4hlt wurden, weil der Cookiekontext des Browsers fehlte. Zweitens: Floodlight-Tags im serverseitigen Tag Manager \u00fcbertragen k\u00fcnftig auch Anfragen ohne Einwilligung von Server zu Server. Drittens: Die serverseitigen Daten werden mit vorhandenen Browsersignalen zusammengef\u00fchrt, sobald eine GCLID vorliegt.<\/p>\n

Die dritte Aussage ist die technisch interessante und die erste eine echte Verbesserung. Die zweite ist die, die den Aufbau \u00e4ndert.<\/p>\n

Warum die Einwilligung im Browser den Serverweg nicht erreicht<\/h2>\n

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

Damit der Server \u00fcberhaupt wei\u00df, wie die Entscheidung ausfiel, muss das Einwilligungssignal an ihn weitergegeben und dort ausgewertet werden. Genau an dieser Stelle greift die \u00c4nderung: Die Anfrage geht k\u00fcnftig auch dann hinaus, wenn das Signal Ablehnung sagt.<\/p>\n

Zwei Wege, ein Tor\n\n  Browser -> Google              Tor: Einwilligungsmodus\n    ad_storage denied   Treffer bleibt aus oder kommt ohne Kennungen\n\n  Browser -> eigener Server -> Google\n    ad_storage denied   Anfrage geht hinaus (neu seit Juni 2026)\n                        Zusammenführung nur, wenn eine GCLID vorliegt\n\n  Das Tor steht auf dem oberen Weg. Der untere führt daran vorbei,\n  und das ist keine Lücke, sondern die Bauart: der Server ist der\n  eigene, und wer dort sendet, hat es selbst eingerichtet.<\/code><\/pre>\n
Was die Zusammenf\u00fchrung tats\u00e4chlich leistet<\/h2>\n
Der Teil mit der GCLID lohnt sich, unabh\u00e4ngig von allem anderen. Ein Abschluss, der \u00fcber den Browser und \u00fcber den Server gemeldet wird, war bisher schwer aufzul\u00f6sen: Ohne gemeinsamen Anker sieht die Gegenseite zwei Ereignisse und muss raten, ob es zwei Abschl\u00fcsse sind. Die Klickkennung ist ein solcher Anker, und die Zusammenf\u00fchrung dar\u00fcber ist genau das, was eine Doppelz\u00e4hlung beendet.<\/p>\n
Wer serverseitig und im Browser parallel meldet, bekommt damit sauberere Zahlen. Das ist eine Verbesserung ohne Beigeschmack, und sie betrifft die sieben B\u00f6gen im Bild.<\/p>\n
Die Frage, die die Anmerkung nicht beantwortet<\/h2>\n
F\u00fcr die f\u00fcnf 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\u00e4t – eine \u00dcbertragung zwischen zwei Servern ber\u00fchrt kein Endger\u00e4t, weshalb sich das Tor dieser Vorschrift auf dem unteren Weg tats\u00e4chlich nicht zwangsl\u00e4ufig wiederfindet. Die DSGVO gilt dagegen unver\u00e4ndert, und die Daten stammen urspr\u00fcnglich sehr wohl vom Endger\u00e4t.<\/p>\n
Damit stehen zwei ernst zu nehmende Lesarten nebeneinander, und beide haben Vertreter. Die eine sagt, ohne Zugriff auf das Ger\u00e4t fehle der Ankn\u00fcpfungspunkt f\u00fcr die Einwilligungspflicht. Die andere sagt, eine Ablehnung, die sich durch einen Umweg \u00fcber 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.<\/p>\n
Ebenfalls unbeantwortet l\u00e4sst die Anmerkung, ob sich das Verhalten abschalten l\u00e4sst. Das ist die erste Frage, die sich an einem laufenden Aufbau kl\u00e4ren l\u00e4sst, und sie l\u00e4sst sich kl\u00e4ren, ohne auf eine Auslegung zu warten.<\/p>\n
Was sich am eigenen Container nachsehen l\u00e4sst<\/h2>\n
Drei Dinge, in dieser Reihenfolge. Erstens: ob \u00fcberhaupt Floodlight-Tags im serverseitigen Container liegen – ohne die betrifft die \u00c4nderung 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.<\/p>\n
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\u00fcfung kostet eine halbe Stunde und ist die einzige Grundlage, auf der sich die Frage \u00fcberhaupt besprechen l\u00e4sst – alles andere ist eine Vermutung \u00fcber den eigenen Aufbau.<\/p>\n
\n
Fragen und Antworten<\/h2>\n
Kommt im einfachen Consent Mode \u00fcberhaupt eine Anfrage ohne Einwilligung beim Server an?<\/h3>\n
In der Regel nicht. Im einfachen Modus (Basic) laden die Google-Tags erst nach der Einwilligung; wer ablehnt, erzeugt im Browser gar keine Messanfrage, und der serverseitige Container hat nichts, was ein Floodlight-Tag weitersenden k\u00f6nnte. Die \u00c4nderung vom Juni 2026 l\u00e4uft in diesem Aufbau ins Leere, solange keine anderen Tags ohne Einwilligung Daten an den eigenen Server schicken.<\/p>\n
Im erweiterten Modus (Advanced) laden die Tags sofort und senden bei Ablehnung Anfragen ohne Cookies und Kennungen. Diese erreichen den eigenen Server, und genau sie sind die Anfragen ohne Einwilligung, die ein Floodlight-Tag im Container nach der Anmerkung k\u00fcnftig weitergibt. Dasselbe gilt f\u00fcr Anfragen, die ein eigenes Skript ohne R\u00fccksicht auf die Einwilligung an den Container schickt.<\/p>\n
Welcher Modus auf einer Seite l\u00e4uft, entscheidet damit mit dar\u00fcber, ob die \u00c4nderung den Aufbau \u00fcberhaupt ber\u00fchrt. Ablesen l\u00e4sst es sich im Netzwerk-Tab des Browsers: Gehen nach einer Ablehnung weiter Anfragen an den eigenen Tagging-Server hinaus, ist der erweiterte Modus oder ein anderer Weg im Spiel.<\/p>\n
Betrifft die \u00c4nderung auch andere Google-Tags im serverseitigen Container?<\/h3>\n
Die Anmerkung nennt nur Floodlight-Tags, und mehr l\u00e4sst sich aus ihr nicht ableiten. Ob sich andere Tags im selben Container, etwa f\u00fcr Google Ads oder GA4, \u00e4hnlich verhalten, zeigt dieselbe Pr\u00fcfung wie im Artikel: eine Sitzung mit abgelehnter Werbespeicherung im Debug-Modus durchspielen und die ausgehenden Anfragen Tag f\u00fcr Tag ansehen.<\/p>\n<\/div>\n
\n
Quellen<\/h2>\n