Consent Mode ist eine Schnittstelle. Er nimmt die Entscheidung, die ein Besucher im Banner getroffen hat, und übersetzt sie in ein Signal, das die Google-Tags auf derselben Seite lesen können. Mehr macht er nicht, und dieses Mehr wird ihm im Markt regelmäßig zugeschrieben.

Er ist kein Cookie-Banner, keine Consent-Management-Plattform und keine Rechtsgrundlage. Er ist auch kein Werkzeug, das aus einer nicht erteilten Einwilligung eine erteilte macht. Wer Consent Mode einbaut und das Banner unverändert lässt, hat die Datenlage von Google verbessert und an der Rechtslage nichts geändert.

Die Rechtsgrundlage für den Zugriff auf das Endgerät ist in Deutschland § 25 TDDDG. Was das genau bedeutet und wie ein Banner aussehen muss, das dieser Norm standhält, behandeln wir im Leitfaden zum Cookie-Banner nach TDDDG, und die Vorschrift selbst schlüsseln wir Absatz für Absatz auf in § 25 TDDDG: die Cookie-Regel, die jede Website betrifft. Consent Mode setzt dieses Banner voraus, er ersetzt es nicht.

Umgekehrt gilt aber auch: ohne Consent Mode ist ein sauber gebautes Banner in einem Google-Stack technisch halb wirksam. Die Tags erfahren dann nichts von der Entscheidung und verhalten sich so, wie sie standardmäßig konfiguriert sind. Genau diese Lücke schließt die Schnittstelle.

Dieser Artikel behandelt drei Ebenen getrennt, weil sie in Projekten dauernd vermischt werden. Erstens, was das Produkt technisch tut. Zweitens, was deutsche Aufsichtsbehörden dazu gesagt haben. Drittens, wie man beides in einer konkreten Umsetzung zusammenbringt und anschließend nachweist.

Consent Mode v2 arbeitet mit vier Einwilligungsparametern. Sie sind der eigentliche Kern des Ganzen, und wer sie sauber auseinanderhält, hat den größten Teil der Umsetzungsfehler bereits vermieden.

ad_storage steuert das Speichern von und den Zugriff auf Informationen im Endgerät für Werbezwecke. Praktisch entscheidet dieser Parameter, ob werbliche Cookies gesetzt und gelesen werden dürfen.

analytics_storage macht dasselbe für Analysezwecke. Ohne diese Einwilligung setzt Google Analytics keine Kennung im Endgerät und kann Sitzungen nicht über Aufrufe hinweg zusammenführen.

ad_user_data ist neu in v2 und betrifft nicht die Speicherung, sondern die Übermittlung. Er steuert, ob personenbezogene Daten an Google zu Werbezwecken übermittelt werden dürfen.

ad_personalization ist der vierte und regelt die personalisierte Werbung, also insbesondere Remarketing. Er entscheidet, ob die übermittelten Daten für Personalisierung genutzt werden dürfen.

Der Unterschied zwischen den ersten beiden und den letzten beiden ist der Punkt, an dem Umsetzungen scheitern. Die ersten beiden betreffen das Endgerät, die letzten beiden die Verwendung der Daten bei Google. Ein Projekt, das nur ad_storage und analytics_storage schaltet, hat v1 umgesetzt und v2 verpasst.

Jeder Parameter kennt genau zwei Werte, granted und denied. Es gibt keinen dritten Zustand für "unbekannt". Wenn kein Wert gesetzt ist, gilt der Standard, den Ihre Implementierung vorgibt, und in Deutschland muss dieser Standard für alle einwilligungsbedürftigen Parameter denied lauten.

Aus den vier Parametern ergibt sich eine Zuordnungsaufgabe, die niemand außer Ihnen lösen kann. Ihr Banner hat Kategorien, und diese Kategorien müssen auf die vier Signale abgebildet werden.

Eine typische Zuordnung sieht so aus: die Kategorie Statistik oder Analyse setzt analytics_storage, die Kategorie Marketing oder Werbung setzt ad_storage, ad_user_data und ad_personalization gemeinsam. Das ist eine gängige und meist tragfähige Aufteilung, aber es ist eine Entscheidung und keine Vorgabe.

Wer feiner unterscheiden will, kann ad_personalization an eine eigene Kategorie hängen und damit Messung von Personalisierung trennen. Das ist inhaltlich präziser und erhöht die Zahl der Kategorien im Banner, was wiederum die Abschlussquote beeinflusst. Diese Abwägung ist Ihre.

Was Sie nicht tun dürfen, ist eine Kategorie im Banner anzubieten und im Consent Mode einen anderen Parameter zu schalten, als der Nutzer erwarten durfte. Die Oberfläche und das Signal müssen dasselbe aussagen. Genau diesen Abstand prüft eine Aufsichtsbehörde mit den Entwicklerwerkzeugen nach.

Halten Sie die Zuordnung schriftlich fest, mit Datum und Verantwortlichem. Sie ist Teil der Rechenschaftspflicht, und sie ist das erste Dokument, das bei einer Beschwerde gebraucht wird.

Welche Kategorien im Banner überhaupt zulässig sind und wie granular sie sein müssen, entscheidet nicht dieses Werkzeug, sondern § 25 TDDDG. Der Leitfaden zum Cookie-Banner nach TDDDG geht die Anforderungen einzeln durch.

Consent Mode kennt zwei Betriebsarten, und die Wahl zwischen ihnen ist die folgenreichste Entscheidung der ganzen Umsetzung. Sie ist technisch, sie ist rechtlich, und sie wird in den meisten Projekten stillschweigend vom Standard des Werkzeugs getroffen.

Im basic-Modus werden die Google-Tags gesperrt, bis eine Einwilligung vorliegt. Vor der Einwilligung wird nichts geladen und nichts gesendet. Liegt die Einwilligung vor, laden die Tags und senden ihre Anfragen, ergänzt um den Einwilligungsstatus.

Im advanced-Modus laden die Tags sofort, aber sie verhalten sich unterschiedlich. Ohne Einwilligung setzen sie keine Kennung im Endgerät und senden stattdessen eine Anfrage ohne Identifikatoren, die den Status denied mitführt. Google nutzt diese Anfragen für die Modellierung.

Der Unterschied in der Datenqualität ist erheblich, und Google weist selbst darauf hin, dass die Modellierung im advanced-Modus deutlich besser trägt. Genau deshalb ist advanced in vielen Werkzeugen die empfohlene oder gar voreingestellte Betriebsart.

Der Unterschied in der rechtlichen Bewertung ist der Grund, warum man nicht einfach der Empfehlung folgt. Im advanced-Modus verlässt bereits vor der Entscheidung des Nutzers eine Anfrage den Browser und erreicht einen Server von Google, mit IP-Adresse, User-Agent und Referrer.

Wir sagen dazu klar, was Fakt ist und was unsere Lesart: eine veröffentlichte Position deutscher Aufsichtsbehörden speziell zum advanced-Modus ist uns nicht bekannt. Was bekannt ist, ist der Maßstab des § 25 TDDDG, der an den Zugriff auf das Endgerät anknüpft, und die Position der Datenschutzkonferenz zu Google Analytics, die wir gleich behandeln.

Unsere Lesart, als Lesart gekennzeichnet: wer im advanced-Modus arbeitet, sollte begründen und dokumentieren können, warum die Anfrage vor der Entscheidung keine einwilligungsbedürftige Speicherung oder keinen Zugriff im Sinne des § 25 darstellt. Wer diese Begründung nicht führen kann oder will, ist mit basic auf der sicheren Seite und verzichtet dafür auf Modellierungsqualität.

Zwischen dem Laden der Seite und dem Klick des Nutzers liegen Sekunden. In diesen Sekunden entscheidet ein einzelner Parameter, ob Ihre Umsetzung funktioniert oder nur so aussieht.

wait_for_update legt in Millisekunden fest, wie lange die Tags auf eine Aktualisierung des Einwilligungsstatus warten, bevor sie mit den Standardwerten arbeiten. Ist der Wert zu klein oder fehlt er, feuern die Tags mit denied, obwohl der Nutzer wenige Millisekunden später zugestimmt hat.

Das Ergebnis ist ein Datenverlust, der aussieht wie eine niedrige Einwilligungsquote. Teams optimieren dann monatelang das Banner, obwohl das Problem ein fehlender Parameter ist. Wir sehen diesen Fehler häufiger als jeden anderen.

Der umgekehrte Fehler ist ebenso real. Ein zu hoher Wert verzögert jede Messung um diese Zeit, auch bei Nutzern, die gar nichts anklicken, und kostet damit Seitenaufrufe in der Statistik.

Zwei weitere Einstellungen gehören in denselben Block. region erlaubt es, unterschiedliche Standardwerte je Region zu setzen, was für Unternehmen mit Verkehr außerhalb des Europäischen Wirtschaftsraums relevant ist. url_passthrough und ads_data_redaction steuern, wie mit Klickkennungen und Werbedaten umgegangen wird, wenn keine Einwilligung vorliegt.

Wichtig für Deutschland: wer mit region arbeitet, muss sicherstellen, dass der Standard für Besucher aus Deutschland und dem übrigen Europäischen Wirtschaftsraum denied ist. Eine Konfiguration, die global granted als Standard setzt und nur einzelne Regionen ausnimmt, ist ein bekanntes Muster und in dieser Form nicht tragfähig.

Sie müssen niemandem glauben, dass Ihre Umsetzung funktioniert. Das Signal steht in der Netzwerkanfrage, und Sie können es in wenigen Minuten selbst lesen.

Der Parameter gcs enthält den Einwilligungsstatus in einer kurzen Zeichenfolge. Sie beginnt mit G1 und trägt zwei Ziffern für ad_storage und analytics_storage, wobei 1 für erteilt und 0 für abgelehnt steht. G100 bedeutet also: Werbespeicherung nein, Analysespeicherung nein.

Der Parameter gcd ist ausführlicher und deckt alle vier Parameter aus v2 ab. Er ist die Zeichenfolge, die Sie prüfen müssen, wenn Sie wissen wollen, ob ad_user_data und ad_personalization überhaupt gesetzt werden.

Der Parameter dma_cps trägt die Signale, die im Zusammenhang mit dem Digital Markets Act übermittelt werden. Fehlt er vollständig, obwohl Einwilligung erteilt wurde, deutet das auf eine unvollständige v2-Umsetzung hin.

Die Prüfung selbst ist unspektakulär. Neues privates Fenster, Entwicklerwerkzeuge auf dem Netzwerk-Tab, Filter auf die Google-Domains, Seite laden, Anfragen vor dem Klick ansehen, dann klicken und die Anfragen danach vergleichen.

Was Sie sehen wollen: vor dem Klick keine Kennung im Endgerät und, im basic-Modus, gar keine Anfrage. Nach der Ablehnung ein Status, der die Ablehnung abbildet. Nach der Zustimmung ein Status, der alle vier Parameter als erteilt zeigt.

Dieselbe Beobachtung ist auch der erste Prüfschritt am Banner selbst, unabhängig von Google. Der Ablauf steht im Leitfaden zum Cookie-Banner nach TDDDG.

Consent Mode ist ein Produkt von Google, kein Rechtsakt. Die Frage, ob Ihre Umsetzung rechtmäßig ist, entscheidet deutsches Recht, und dort ist der Anknüpfungspunkt eng und klar.

§ 25 Absatz 1 TDDDG verlangt die Einwilligung, bevor Informationen im Endgerät gespeichert oder auf dort gespeicherte Informationen zugegriffen wird. Absatz 2 lässt zwei schmale Ausnahmen zu, die Übermittlung einer Nachricht und die unbedingte Erforderlichkeit für einen ausdrücklich gewünschten Dienst.

Zwei Konsequenzen ergeben sich daraus unmittelbar. Erstens ist berechtigtes Interesse keine gangbare Grundlage für Werbe- oder Analysezugriffe, unabhängig davon, wie gut die Abwägung geschrieben ist. Zweitens gilt § 25 auch dann, wenn dabei keine personenbezogenen Daten anfallen, weil die Norm an die Information im Endgerät anknüpft und nicht an ihre Personenbezogenheit.

Der Gesetzesname ist ein häufiger Stolperstein in älteren Anleitungen. Das Gesetz hieß bis zur Änderung TTDSG und trägt heute die Bezeichnung TDDDG. Der Inhalt des § 25 ist derselbe geblieben, der Verweis in Ihren Dokumenten sollte aktuell sein.

Wie sich § 25 TDDDG und die DSGVO zueinander verhalten, insbesondere bei der Frage, welche Verarbeitung nach dem Zugriff welche Grundlage braucht, behandeln wir ausführlich im DSGVO-Leitfaden für Deutschland.

Für die Frage, ob Google Analytics in Deutschland eine Einwilligung braucht, gibt es eine ausdrückliche Position der Aufsicht. Sie ist von Mai 2020, sie ist öffentlich, und sie ist der Bezugspunkt, den Sie zitieren sollten, statt auf Marktmeinungen zu verweisen.

Die Datenschutzkonferenz, das Gremium der unabhängigen deutschen Datenschutzaufsichtsbehörden, hat in ihrem Beschluss zum Einsatz von Google Analytics festgehalten, dass ein rechtmäßiger Einsatz in der Regel nur auf Grundlage einer wirksamen Einwilligung möglich ist. Berechtigtes Interesse trägt danach nicht.

Der Beschluss hält außerdem fest, dass Google und der Website-Betreiber beim Einsatz des Dienstes als gemeinsam Verantwortliche einzuordnen sind. Das ist keine Nebenbemerkung, sondern hat vertragliche Folgen, auf die wir im nächsten Abschnitt eingehen.

Und er enthält einen Satz, der viele ältere Konfigurationen entwertet: frühere abweichende Positionen deutscher Aufsichtsbehörden zum Einsatz von Google Analytics sind nach dieser Entscheidung überholt. Wer sich auf eine ältere Behördenaussage stützt, sollte prüfen, ob sie noch trägt.

Praktisch bedeutet das für Ihre Consent-Mode-Umsetzung: analytics_storage steht in Deutschland standardmäßig auf denied und wird nur durch eine bestätigende Handlung des Nutzers auf granted gesetzt. Eine Konfiguration, die Analytics als unbedingt erforderlich behandelt, widerspricht dieser Position.

Der Beschluss ist auf den Seiten der Datenschutzkonferenz abrufbar. Legen Sie ihn Ihrer Dokumentation bei, statt ihn zu paraphrasieren.

Die Einordnung als gemeinsame Verantwortlichkeit ist der Punkt, an dem die meisten Unternehmen eine Lücke haben, ohne davon zu wissen. Sie haben einen Vertrag zur Auftragsverarbeitung abgeschlossen und halten die Sache damit für erledigt.

Artikel 26 DSGVO verlangt bei gemeinsamer Verantwortlichkeit eine Vereinbarung, in der die Verantwortlichen festlegen, wer welche Pflichten erfüllt. Insbesondere geht es um die Information der betroffenen Personen und um die Wahrnehmung der Betroffenenrechte.

Die Norm verlangt zusätzlich, dass das Wesentliche dieser Vereinbarung den betroffenen Personen zur Verfügung gestellt wird. Praktisch gehört es also in die Datenschutzerklärung und nicht nur in eine Vertragsakte.

Prüfen Sie deshalb konkret, welche Vertragswerke Sie für die eingesetzten Google-Dienste tatsächlich akzeptiert haben, und ob darunter die für gemeinsame Verantwortlichkeit vorgesehenen Bedingungen sind. Diese Prüfung ist Aufgabe von Recht und Einkauf, nicht des Marketings.

Und formulieren Sie in der Datenschaufnahme präzise, welche Rolle für welchen Dienst gilt. Es ist verbreitet, dass in einem Haus derselbe Anbieter für einen Dienst Auftragsverarbeiter und für einen anderen gemeinsam Verantwortlicher ist.

Wie sich Verantwortlicher, Auftragsverarbeiter und gemeinsame Verantwortlichkeit voneinander abgrenzen, und was jede Rolle an Dokumentation verlangt, behandelt der DSGVO-Leitfaden für Deutschland.

Neben dem Gesetz gibt es eine vertragliche Ebene, die eigene Pflichten begründet. Google verlangt von Werbetreibenden und Publishern, die Nutzer im Europäischen Wirtschaftsraum, im Vereinigten Königreich und in der Schweiz erreichen, die Einhaltung einer eigenen Richtlinie zur Nutzereinwilligung.

Diese Richtlinie verlangt, dass für den Einsatz von Cookies und die Verarbeitung personenbezogener Daten zu Werbezwecken eine Einwilligung eingeholt wird, die den Anforderungen entspricht. Sie verlangt außerdem, dass Aufzeichnungen über die erteilten Einwilligungen aufbewahrt werden.

Das ist der Punkt, an dem viele Umsetzungen technisch vollständig und dokumentarisch leer sind. Ein Banner, das anzeigt und schaltet, aber nichts protokolliert, erfüllt weder die Nachweispflicht aus der DSGVO noch diese vertragliche Anforderung.

Was protokolliert werden muss, ist im Kern immer dasselbe: wann, für welche Zwecke, in welcher Version des Banners, mit welcher Entscheidung, und wie lange dieser Nachweis aufbewahrt wird. Details dazu stehen im Leitfaden zum Cookie-Banner nach TDDDG.

Der praktische Hebel liegt hier bei der Auswahl der Plattform. Fragen Sie einen Anbieter nicht, ob er Consent Mode unterstützt, das tun inzwischen alle. Fragen Sie, wie das Protokoll aussieht, wie Sie es exportieren und wie ein einzelner Datensatz zu einem konkreten Bannerstand zurückverfolgt wird.

Wer im Programmatic-Umfeld arbeitet, hat neben Consent Mode eine zweite Schicht, das Transparency and Consent Framework von IAB Europe. Die beiden sind nicht dasselbe und lösen unterschiedliche Probleme.

Consent Mode übersetzt die Entscheidung für die Google-Tags auf Ihrer Seite. Das TCF überträgt die Entscheidung an eine Kette von Anbietern in der Werbelieferkette, in einem standardisierten Format.

Für die Version gilt ein Datum, das man kennen muss: TCF v2.3 ist seit dem 1. März 2026 verbindlich. Wer auf einer älteren Version arbeitet, hat kein theoretisches Problem, sondern ein Anschlussproblem in der Lieferkette.

Für die meisten Unternehmen, die nicht als Publisher Werbeplätze verkaufen, ist das TCF nicht erforderlich. Die Frage ist damit nicht, ob man es haben sollte, sondern ob man in einer Kette steckt, die es verlangt.

Wenn Sie beides einsetzen, achten Sie darauf, dass die Zuordnung konsistent ist. Ein Nutzer, der im TCF-Dialog Zwecke ablehnt, muss im Consent Mode dieselbe Ablehnung erzeugen. Doppelte Oberflächen mit auseinanderlaufenden Signalen sind ein realer und schwer zu findender Fehler.

Consent Mode v2 wird im Markt oft als Folge des Digital Markets Act erklärt, und das ist verkürzt, aber nicht falsch. Die Verordnung richtet Pflichten an sogenannte Torwächter, nicht an Website-Betreiber, und Google gehört zu den benannten Torwächtern.

Zu den Daten ist die Chronologie hilfreich, weil sie im Markt regelmäßig durcheinandergeht. Die Verordnung ist am 1. November 2022 in Kraft getreten. Anwendbar wurde sie am 2. Mai 2023. Der 7. März 2024 war die Frist, bis zu der die benannten Torwächter ihre Pflichten erfüllen mussten.

Der für Sie relevante Punkt ist mittelbar. Weil Google für bestimmte Verarbeitungen eine Einwilligung nachweisen muss, verlangt Google diesen Nachweis von den Unternehmen, die seine Werkzeuge einsetzen. Die neuen Parameter ad_user_data und ad_personalization sind das technische Mittel dafür.

Eine Behauptung, die wir bewusst nicht aufstellen: dass Consent Mode v2 ab einem bestimmten Datum gesetzlich vorgeschrieben sei. Diese Verkürzung ist verbreitet. Was zutrifft, ist eine vertragliche Anforderung von Google mit einer Folge, nämlich dem Verlust von Funktionen im Werbekonto, nicht eine Pflicht aus dem Digital Markets Act.

Der wirtschaftliche Grund, warum Teams Consent Mode einbauen, ist die Modellierung. Wenn Nutzer ablehnen, versucht Google, die fehlenden Ereignisse aus dem Verhalten der einwilligenden Nutzer zu schätzen.

Es gibt dabei zwei Arten, und die Unterscheidung ist praktisch wichtig. Die allgemeine Modellierung nutzt eine breitere Datenbasis über Werbetreibende hinweg. Die werbetreibendenspezifische Modellierung nutzt die Daten Ihres eigenen Kontos und ist genauer, aber sie braucht mehr Volumen.

Was wir dazu nicht sagen: konkrete Schwellenwerte für die Zulässigkeit der Modellierung. In der offiziellen Dokumentation von Google haben wir keine belastbaren quantitativen Grenzen gefunden, die wir zitieren könnten, und geschätzte Zahlen gehören nicht in einen Compliance-Text.

Was Sie aber wissen sollten: modellierte Zahlen sind Schätzungen und keine gemessenen Ereignisse. Wer sie im Reporting nicht kennzeichnet, baut eine Berichtslinie, die niemand nachrechnen kann, und liefert Kennzahlen, die bei einer Prüfung nicht als Messung durchgehen.

Und ein Punkt, der eher Kultur als Technik ist: die Modellierung ist kein Ersatz für eine gute Einwilligungsquote. Ein Banner, das verständlich ist, sauber blockiert und ehrlich fragt, liefert bessere Daten als jede Schätzung darüber.

In den meisten deutschen Umsetzungen läuft der Weg über den Tag Manager, und dort ist die Reihenfolge entscheidend. Es sind vier Schritte, und der erste ist der, der am häufigsten übersprungen wird.

Zuerst setzen Sie die Standardwerte, bevor irgendein Google-Tag lädt. Alle einwilligungsbedürftigen Parameter stehen auf denied, und wait_for_update erhält einen bewusst gewählten Wert. Dieser Block muss zeitlich vor allem anderen stehen.

Dann verbinden Sie Ihre Plattform, damit sie beim Klick des Nutzers eine Aktualisierung sendet. Die meisten Plattformen liefern dafür eine fertige Vorlage oder eine Integration, und der Aufwand liegt in der Zuordnung der Kategorien, nicht in der Technik.

Anschließend prüfen Sie in jedem einzelnen Tag die zusätzliche Einwilligungsprüfung. Der Tag Manager erlaubt es, für ein Tag anzugeben, welche Einwilligung es benötigt, und diese Angabe fehlt in vielen Konten für genau die Tags, die sie am dringendsten brauchen.

Zuletzt prüfen Sie im Vorschaumodus und im Netzwerk-Tab. Der Vorschaumodus zeigt Ihnen den Status pro Tag, der Netzwerk-Tab zeigt Ihnen, was tatsächlich das Gerät verlässt. Beides ist nötig, weil der Vorschaumodus einen korrekten Zustand anzeigen kann, während ein hart im Quelltext eingebundenes Skript daneben unbemerkt feuert.

Manche Häuser binden die Tags direkt ein, und das funktioniert genauso, verlangt aber mehr Disziplin. Der Grundsatz ist derselbe: der Standardblock kommt zuerst, und die Aktualisierung folgt erst nach der Entscheidung des Nutzers.

Der typische Fehler in dieser Variante ist die Reihenfolge im Quelltext. Wird das Google-Tag vor dem Standardblock eingebunden, ist die Konfiguration wirkungslos, obwohl beide Codeblöcke vorhanden sind und in der Prüfung durch Sichtkontrolle vollständig aussehen.

Der zweite typische Fehler betrifft Einzelseitenanwendungen. Wenn die Anwendung Seitenwechsel ohne vollständiges Neuladen abbildet, muss die Einwilligung bei jedem dieser Wechsel korrekt weitergeführt werden, sonst gilt für einen Teil der Sitzung der Standard.

Der dritte betrifft Zustimmungslogik, die im Frontend hart verdrahtet ist. Wenn ein Entwickler die Kategorien im Code abbildet, statt sie aus der Plattform zu lesen, weichen Oberfläche und Verhalten mit jeder Änderung weiter auseinander.

Wenn Sie diesen Weg gehen, dokumentieren Sie die Einbindungsreihenfolge im Repository und lassen Sie sie in der Codeprüfung mitlaufen. Eine Reihenfolge, die niemand bewacht, wird beim nächsten Umbau der Seite geändert.

Server-side Tagging verschiebt einen Teil der Verarbeitung von Browser zu Server, und es wird gelegentlich als Weg beschrieben, die Einwilligung zu umgehen. Das ist falsch, und der Grund liegt im Anknüpfungspunkt der Norm.

§ 25 TDDDG knüpft an den Zugriff auf das Endgerät an. Wenn eine serverseitige Architektur weiterhin eine Kennung im Endgerät setzt oder liest, greift die Einwilligungspflicht unverändert, unabhängig davon, wo die Daten anschließend verarbeitet werden.

Was serverseitiges Tagging tatsächlich verbessert, ist die Kontrolle. Sie sehen, welche Daten an welchen Empfänger gehen, Sie können Felder entfernen, und Sie reduzieren die Zahl der Skripte im Browser des Nutzers.

Was es außerdem verändert, ist die Nachvollziehbarkeit für Prüfer. Ein Teil des Verhaltens ist nicht mehr im Browser sichtbar, was Ihre Dokumentationspflicht praktisch erhöht. Was man nicht am Netzwerk-Tab zeigen kann, muss man schriftlich zeigen können.

Unsere Einordnung: serverseitiges Tagging ist ein gutes Werkzeug für Datensparsamkeit und ein schlechtes Argument gegen Einwilligung. Wer es einsetzt, sollte im gleichen Zug beschreiben, welche Kennungen im Endgerät verbleiben.

Consent Mode betrifft Google. Ihr Stack besteht selten nur aus Google, und die anderen Anbieter haben eigene Mechanismen mit eigenen Namen.

Meta arbeitet mit einer eigenen Einwilligungslogik für das Pixel und die Conversions-Schnittstelle. Microsoft und LinkedIn haben ebenfalls eigene Parameter. Keiner dieser Mechanismen wird durch eine korrekte Consent-Mode-Umsetzung automatisch mitversorgt.

Praktisch heißt das: Ihre Plattform muss jeden dieser Empfänger einzeln sperren und einzeln freigeben. Der Standardweg dafür ist die Blockierung des Skripts, bis die zugehörige Kategorie freigegeben ist, nicht ein Signal an ein bereits geladenes Skript.

Die Prüfung ist dieselbe wie bei Google, nur mit anderen Domains im Filter. Laden, vor dem Klick nachsehen, klicken, vergleichen. Ein Pixel, das vor dem Klick eine Anfrage sendet, ist ein Befund unabhängig davon, wie gut Ihr Consent Mode konfiguriert ist.

Und ein organisatorischer Hinweis, der öfter hilft als jede technische Maßnahme: führen Sie eine Liste aller Skripte auf der Seite, mit Zweck, Empfänger und zugeordneter Kategorie. Diese Liste ist die Grundlage für Ihr Verzeichnis von Verarbeitungstätigkeiten und für jede Prüfung.

Die Sperrmechanik selbst, also die Frage, ob ein Skript geladen und dann gebeten wird oder ob es gar nicht lädt, ist Sache Ihrer Plattform. Der Unterschied ist in der Anatomie eines Banners, das hält beschrieben.

Diese Prüfung braucht keinen Dienstleister und keine Werkzeuglizenz. Nehmen Sie sich zehn Minuten und arbeiten Sie die sechs Schritte in dieser Reihenfolge ab.

Erstens, neues privates Fenster, Entwicklerwerkzeuge offen, Netzwerk-Tab aktiv, Seite laden und nichts anklicken. Notieren Sie jede Anfrage an eine Google-Domain und jede gesetzte Kennung.

Zweitens, im gleichen Zustand die Cookies ansehen. Vor dem Klick darf keine einwilligungsbedürftige Kennung vorhanden sein. Eine reine Sitzungs- oder Sicherheitskennung ist unproblematisch, eine Werbe- oder Analysekennung ist ein Befund.

Drittens, ablehnen. Danach dürfen keine neuen einwilligungsbedürftigen Kennungen entstehen, und die Anfragen müssen den Status als abgelehnt tragen.

Viertens, neues privates Fenster, zustimmen, und die Zeichenfolge in gcd prüfen. Alle vier Parameter müssen als erteilt erscheinen. Fehlen ad_user_data und ad_personalization, läuft die Umsetzung faktisch noch auf v1.

Fünftens, den Widerruf durchführen und prüfen, ob die Signale wieder auf abgelehnt wechseln und die Kennungen entfernt werden. Ein Widerruf, der die Oberfläche ändert und das Verhalten nicht, ist der teuerste der auffindbaren Fehler.

Sechstens, das Protokoll ansehen. Es muss für jede der drei Interaktionen einen Datensatz mit Zeitstempel, Zwecken und Bannerstand geben. Wenn Sie diesen Datensatz nicht finden, existiert Ihr Nachweis nicht.

Aus der Praxis, geordnet nach Häufigkeit und nicht nach Schwere. Alle sechs sind mit dem Ablauf im vorigen Abschnitt nachweisbar.

Fehlendes oder zu kurzes wait_for_update. Die Tags feuern mit denied, obwohl der Nutzer zugestimmt hat, und das Team hält das Ergebnis für eine schlechte Einwilligungsquote.

Standardwert granted. Die Konfiguration ist vorhanden, aber sie erlaubt vor dem Klick genau das, was sie verhindern soll. In Deutschland ist das der schwerste der einfachen Fehler.

Nur zwei Parameter gesetzt. ad_storage und analytics_storage sind konfiguriert, die beiden neuen Parameter fehlen, und die Umsetzung wird intern als v2 geführt.

Hart eingebundene Skripte neben dem Tag Manager. Der Tag Manager zeigt einen korrekten Zustand, während ein direkt im Quelltext eingebundenes Skript unabhängig davon feuert.

Kategorien, die nicht zu den Signalen passen. Der Nutzer lehnt Marketing ab, und ad_personalization bleibt auf erteilt, weil die Zuordnung nie überprüft wurde.

Kein Protokoll. Alles funktioniert im Browser, und es gibt keinen Datensatz, mit dem das an einem Stichtag in der Vergangenheit belegbar wäre.

Diese Umsetzung fällt in fast jedem Haus zwischen drei Zuständigkeiten, und genau dort bleibt sie liegen. Es hilft, die Aufteilung einmal explizit zu machen.

Das Marketing besitzt die Zwecke. Es entscheidet, welche Tags eingesetzt werden und wofür, und es muss diese Entscheidung in Worten liefern können, die in eine Kategorie im Banner passen.

Die Entwicklung besitzt die Reihenfolge und die Blockierung. Sie stellt sicher, dass der Standardblock zuerst läuft, dass kein Skript daran vorbei lädt und dass Seitenwechsel den Status korrekt weiterführen.

Der Datenschutz besitzt den Maßstab und den Nachweis. Er beurteilt die Zuordnung, dokumentiert die Wahl zwischen basic und advanced samt Begründung und prüft, ob das Protokoll die Nachweispflicht erfüllt.

Und eine Person besitzt den Termin. Ohne eine wiederkehrende Prüfung mit Datum und Verantwortlichem verfällt jede korrekte Umsetzung beim nächsten Umbau der Website, meist unbemerkt und meist in der Woche einer Kampagne.

Diese Aufteilung ist ein Ausschnitt der größeren Rollenverteilung im Datenschutz, die der DSGVO-Leitfaden für Deutschland mit Verzeichnis, Fristen und Betroffenenrechten zusammen beschreibt.

Zum Abschluss die Grenze des Werkzeugs, weil das Gegenteil im Markt verkauft wird. Consent Mode ist eine Schnittstelle, und Schnittstellen lösen keine inhaltlichen Fragen.

Er entscheidet nicht, welche Ihrer Tags unbedingt erforderlich sind. Das ist eine Bewertung pro Tag, und sie fällt bei Ihnen.

Er trägt keine Zwecke in Ihr Verzeichnis von Verarbeitungstätigkeiten ein und legt keine Speicherfristen fest. Beides sind Pflichten aus der DSGVO, die von der Messschicht unberührt bleiben.

Er beantwortet keine Betroffenenanfragen. Wenn eine Person Auskunft verlangt, brauchen Sie ein Verfahren und keine Konfiguration.

Und er heilt kein Banner. Ein Banner, das Ablehnen erschwert oder Tags vor dem Klick lädt, bleibt angreifbar, auch wenn die vier Signale technisch einwandfrei übertragen werden. Was ein tragfähiges Banner ausmacht, steht im Leitfaden zum Cookie-Banner.

Wenn Sie bei null beginnen, ist die Reihenfolge wichtiger als das Tempo. Fünf Schritte, in dieser Folge, und jeder liefert ein Ergebnis, das Sie zeigen können.

Erstens die Bestandsaufnahme. Listen Sie jedes Skript auf der Seite, mit Zweck, Empfänger und der Frage, ob es eine Kennung im Endgerät setzt. Diese Liste ist die Grundlage für alles Weitere.

Zweitens die Entscheidung basic oder advanced, schriftlich und mit Begründung. Wer das nicht entscheidet, entscheidet es über die Voreinstellung des Werkzeugs.

Drittens die Zuordnung der Kategorien zu den vier Parametern, ebenfalls schriftlich. Danach wird das Banner konfiguriert, nicht davor.

Viertens die Umsetzung mit dem Standardblock an erster Stelle und der Einwilligungsprüfung in jedem Tag. Dann die Prüfung aus dem Abschnitt oben, vollständig und nicht in Teilen.

Fünftens der Termin. Eine wiederkehrende Prüfung, ein Verantwortlicher, ein Protokollexport, der jederzeit lieferbar ist. Damit ist die Umsetzung nicht nur korrekt, sondern belegbar.

Schritt eins gehört dabei nicht dieser Umsetzung allein: die Skriptliste ist dieselbe, die Ihr Verzeichnis von Verarbeitungstätigkeiten braucht. Wie beides zusammenhängt, steht im DSGVO-Leitfaden für Deutschland.

Die Umsetzung endet nicht im Tag Manager. Artikel 13 DSGVO verlangt Information, und eine Consent-Mode-Umsetzung erzeugt Angaben, die dort auftauchen müssen, aber selten auftauchen.

Nennen Sie die Empfänger konkret. Nicht "Analyse- und Marketingdienste", sondern die eingesetzten Dienste mit Zweck. Eine Aufzählung, die niemand mit der Skriptliste aus der Bestandsaufnahme abgleichen kann, ist keine Information, sondern eine Formulierung.

Nennen Sie die Rolle. Wenn ein Dienst nach der Position der Aufsicht in gemeinsamer Verantwortlichkeit betrieben wird, gehört das Wesentliche der Vereinbarung nach Artikel 26 Absatz 2 DSGVO für die betroffenen Personen zugänglich gemacht, und die Datenschutzerklärung ist der übliche Ort dafür.

Nennen Sie den Weg zum Widerruf. Ein Satz mit einem Verweis auf die Stelle, an der die Auswahl jederzeit geändert werden kann, und zwar so, dass er ohne Suche funktioniert.

Und halten Sie die Speicherfristen für die Einwilligungsnachweise fest. Das ist der Punkt, an dem eine Erklärung von der Aufzählung von Werkzeugen zu einer nachvollziehbaren Beschreibung wird.

Weil die Modellierung Schätzung bleibt, ist die Quote der erteilten Einwilligungen die eigentliche Datenquelle. Vier Dinge bewegen sie, ohne die Anforderungen zu verletzen.

Ladezeit. Ein Banner, das nach einer Sekunde erscheint, wird häufiger bedient als eines, das nach vier Sekunden über einer schon gelesenen Seite auftaucht.

Verständlichkeit der Kategorien. "Statistik, damit wir sehen, welche Seiten gelesen werden" trägt weiter als "Performance-Cookies". Der Text im Banner ist kein juristischer Text, sondern eine Erklärung.

Anzahl der Kategorien. Jede zusätzliche Kategorie erhöht die Präzision und senkt die Abschlussquote. Drei bis vier sind in der Praxis der brauchbare Bereich.

Und der Verzicht auf Druckmittel. Gestaltung, die Ablehnen verstecken oder erschweren soll, ist nach der Orientierungshilfe der Aufsichtsbehörden angreifbar und wirkt auf wiederkehrende Besucher schlechter als eine klare Frage. Was zulässig ist und was nicht, behandeln wir im Leitfaden zum Cookie-Banner.

Es gibt keine gesetzliche Frist für die Nachprüfung einer Consent-Mode-Umsetzung. Es gibt aber vier Ereignisse, nach denen sie regelmäßig kaputt ist, und die taugen besser als ein Kalenderintervall.

Nach jedem Release, der das Frontend berührt. Eine geänderte Einbindungsreihenfolge fällt in keinem fachlichen Test auf, weil die Seite weiterhin funktioniert und nur die Sperre nicht mehr greift.

Nach jedem neuen Tag. Ein Tag ohne zugeordnete Einwilligungsprüfung feuert unabhängig von der Entscheidung des Besuchers, und neue Tags werden häufig unter Zeitdruck einer Kampagne eingebaut.

Nach jedem Versionswechsel der Plattform oder des Werkzeugs. Voreinstellungen ändern sich zwischen Versionen, und die riskanteste Änderung ist ein Standardwert, der von abgelehnt auf erteilt wechselt.

Und mindestens einmal je Quartal ohne Anlass, mit Datum, Verantwortlichem und abgelegtem Ergebnis. Diese anlasslose Prüfung ist die einzige, die Fehler findet, die niemand erwartet hat.

Denselben Rhythmus empfehlen wir für das Banner selbst, und aus demselben Grund. Die Zehn-Minuten-Prüfung dafür steht im Leitfaden zum Cookie-Banner.

Nein. Die Rechtspflicht folgt aus § 25 TDDDG und der DSGVO und verlangt eine wirksame Einwilligung vor dem Zugriff auf das Endgerät, nicht ein bestimmtes Produkt. Consent Mode v2 ist eine vertragliche Anforderung von Google für Werbetreibende und Publisher, die Nutzer im Europäischen Wirtschaftsraum, im Vereinigten Königreich und in der Schweiz erreichen. Die Folge einer Nichterfüllung ist der Verlust von Funktionen im Werbekonto, nicht ein Bußgeld nach dem Digital Markets Act.

Im basic-Modus verlässt vor der Entscheidung des Nutzers keine Anfrage den Browser, weshalb er nach unserer Lesart die einfacher zu begründende Variante ist. Im advanced-Modus wird bereits vorher eine Anfrage ohne Identifikatoren gesendet, was die Modellierung verbessert. Eine veröffentlichte Position deutscher Aufsichtsbehörden speziell zum advanced-Modus ist uns nicht bekannt. Wer advanced einsetzt, sollte die Begründung dokumentieren, warum darin keine einwilligungsbedürftige Speicherung oder kein Zugriff im Sinne des § 25 TDDDG liegt.

Nach dem Beschluss der Datenschutzkonferenz von Mai 2020 ist ein rechtmäßiger Einsatz in der Regel nur auf Grundlage einer wirksamen Einwilligung möglich, berechtigtes Interesse trägt nicht. Derselbe Beschluss ordnet Google und den Website-Betreiber als gemeinsam Verantwortliche ein und erklärt frühere abweichende Positionen deutscher Behörden für überholt. Für die Umsetzung bedeutet das, dass analytics_storage standardmäßig auf denied steht.

An der Zeichenfolge in gcd und am Parameter dma_cps in der Netzwerkanfrage nach erteilter Einwilligung. Sind nur ad_storage und analytics_storage gesetzt und fehlen ad_user_data und ad_personalization, arbeitet die Umsetzung faktisch weiter auf v1, unabhängig davon, welche Version im Werkzeug angezeigt wird. Prüfen Sie das in einem privaten Fenster und nicht im Vorschaumodus allein.

Nein. § 25 TDDDG knüpft an das Speichern von oder den Zugriff auf Informationen im Endgerät an, nicht an den Ort der späteren Verarbeitung. Solange eine Kennung im Endgerät gesetzt oder gelesen wird, bleibt die Einwilligungspflicht bestehen. Serverseitiges Tagging verbessert die Kontrolle über die übermittelten Felder und erhöht gleichzeitig Ihre Dokumentationslast, weil ein Teil des Verhaltens im Browser nicht mehr sichtbar ist.

• DSGVO in Deutschland: der vollständige Leitfaden für Unternehmen
• Cookie-Banner nach TDDDG: was die Aufsichtsbehörden wirklich verlangen

---

Eine Umsetzung, die im Vorschaumodus stimmt und im Netzwerk-Tab nicht, ist keine Umsetzung. Was zählt, ist das, was das Gerät vor dem ersten Klick nicht verlässt, und der Datensatz, der die Entscheidung des Besuchers belegt.

Wollen Sie prüfen lassen, welche Signale Ihre Website tatsächlich an Google sendet?

Vereinbaren Sie ein Gespräch mit unserem Team