Floodlight im serverseitigen Tag Manager: Einwilligung, Attribution und praktische Prüfung

Floodlight misst Werbekonversionen in Campaign Manager 360, also erfasste Aktionen wie Käufe oder abgeschickte Anfragen. Ein Tag im Servercontainer verändert den Übertragungsweg, beseitigt aber nicht die Pflicht, Einwilligungsentscheidungen zu übermitteln und umzusetzen. Zwei getrennte Google-Änderungen sind relevant: Server-zu-Server-Anfragen aus einer Mitteilung vom Juli 2025 und eine verbesserte Zuordnung von Konversionen aus dem Juni 2026.

Zwei Termine, zwei unterschiedliche Änderungen

Die Tag-Manager-Versionshinweise vom 28. Juli 2025 kündigen Anfragen ohne Einwilligung von Floodlight-Tags zwischen Servern zur Unterstützung der Konversionsmodellierung an. Dabei werden nicht direkt beobachtete Konversionen geschätzt. Der Eintrag vom 22. Juni 2026 behandelt fehlenden Browserkontext: Bei vorhandener GCLID lassen sich Serverdaten mit parallelen Browsersignalen zusammenführen. GCLID bezeichnet Googles Kennung eines Werbeklicks. Der zweite Eintrag betrifft die Attribution, also die Zuordnung einer Konversion zu einem Werbekontakt.

Keiner der beiden Einträge garantiert eine allgemeine Vermeidung doppelter Zählungen oder nennt eine gemessene Quote zurückgewonnener Konversionen.

Einwilligungssignale können den Server erreichen

Im dokumentierten Google-Aufbau übergibt die Einwilligungsplattform die Auswahl an das Google-Tag. Das Tag ergänzt Anfragen an den Servercontainer um Einwilligungsparameter; der GA4-Client als Empfangsbaustein im Servercontainer nimmt die Anfragen entgegen, und geeignete Google-Tags berücksichtigen die Signale. Consent Mode ist somit nicht auf den Browser beschränkt. Eigene Sender und eigene Tags benötigen eine gesonderte Prüfung: Eine Browsereinstellung steuert nicht automatisch eine unabhängige Backend-Anfrage.

Die Dokumentation enthält allerdings einen wesentlichen Widerspruch. Beim Abgleich am 24. Oktober 2026 nennt Googles Anleitung zum serverseitigen Consent Mode für Floodlight bei ad_storage: denied weiterhin gesperrte HTTP-Anfragen. Der Versionshinweis vom Juli 2025 kündigt dagegen Anfragen ohne Einwilligung an. Daraus folgt keine verlässliche Universalregel für jeden aktuellen Container. Entscheidend bleibt eine Prüfung der eingesetzten Tag-Version und der tatsächlich ausgehenden Übertragung.

Speicherung, Werbedaten und Personalisierung

• ad_storage betrifft die Speicherung für Werbezwecke.
• ad_user_data betrifft die Übermittlung von Nutzerdaten an Google für Werbung.
• ad_personalization betrifft personalisierte Werbung.
• analytics_storage betrifft die Speicherung für Analysezwecke.

Eine verweigerte Speicherfreigabe bedeutet nicht, dass jede Anfrage leer oder anonym ist. Googles allgemeine Consent-Mode-Dokumentation beschreibt cookielose Pings, beispielsweise mit Zeit- und Referrerinformationen. Angaben zu Werbeklicks hängen zusätzlich vom Produkt und den Einstellungen zur Entfernung von Klickkennungen ab. Deshalb zählt der tatsächlich übertragene Inhalt; ein fehlendes Werbecookie allein ist kein ausreichender Nachweis.

Attribution ist keine Entdopplung

Zusätzlicher Klickkontext kann die Zuordnung verbessern. Die doppelte Zählung eines Kaufs zu verhindern, ist eine andere Aufgabe. Googles Floodlight-Anleitung empfiehlt nach erfolgreicher Migration das Entfernen gleichwertiger Floodlight-Tags aus dem Webcontainer, um Doppelzählungen zu vermeiden. Dieselbe Anleitung verlangt einen Conversion Linker im Servercontainer.

Ein gesondertes Beispiel sind Multi-Source-Konversionen in Campaign Manager 360: Ein Onlinetag und ein Offlineimport über die Data Manager API benötigen übereinstimmende, eindeutige Transaktionskennungen. Dieser Mechanismus folgt nicht aus der GCLID-Mitteilung vom Juni. Vor einem parallelen Übertragungsweg gehört deshalb eine Bestandsaufnahme aller Sender, Konversionsaktivitäten, Zählmethoden und Bestellkennungen zur Einrichtung.

Praktische Prüfungen für jeden Einwilligungszustand

1. Vor einer Auswahl: Eine neue Testsitzung öffnen und den anfänglichen Einwilligungsstatus vor dem Start der Messtags erfassen.
2. Nach Zustimmung: Aktualisierung im Tag Assistant, Eingang am Server, zuständigen Client, ausgelöste Tags und ausgehende Ziele prüfen.
3. Nach Ablehnung: Den Ablauf mit verweigerter Werbespeicherung wiederholen. Verweigerte Werbedatenfreigabe und verweigerte Personalisierung zusätzlich getrennt testen; nur ein vollständiges Ablehnungsszenario kann Zuordnungsfehler verdecken.
4. Nach Widerruf: Nachfolgende Ereignisse und Seitenaufrufe prüfen. Ein früherer Zustimmungsstatus darf nicht unbemerkt weiterwirken.
5. Außerhalb des Browserwegs: Eigene Backend-Sender, fehlende Einwilligungsfelder und regionale Voreinstellungen testen. Fehlende Signale dürfen in eigener Logik nicht stillschweigend zu einer Freigabe werden.

Je Prüffall gehören Container- und Tag-Version, Einwilligungswerte, Ereigniszeit, Triggerergebnis und tatsächlich gesendete Felder ins Protokoll. Servervorschau und Browser-Netzwerkansicht zeigen unterschiedliche Abschnitte; Serverantworten können außerdem Browseranfragen auslösen. Diagnoseexporte benötigen keine echten Kundendaten oder Zugangsschlüssel. Ein ausgelöstes Tag oder eine erfolgreiche HTTP-Antwort beweist weder korrekte Attribution noch Rechtmäßigkeit oder fehlende Doppelzählungen in späteren Berichten.

Die rechtliche Prüfung betrifft den gesamten Datenweg

Die Übertragung zwischen Servern schafft keine rechtliche Ausnahme. In Deutschland unterliegt das Speichern oder Auslesen von Informationen auf Endgeräten § 25 TDDDG mit den dort geregelten Ausnahmen. Eine anschließende Verarbeitung personenbezogener Daten benötigt zusätzlich eine datenschutzrechtliche Prüfung. Relevant sind unter anderem Zweck, Datenfelder, Empfänger, Rechtsgrundlage und Aufbewahrung. Ein technisches Signal granted belegt keine wirksam eingeholte Einwilligung.