Da Cookie Banner erheblichen Einfluss auf die Möglichkeiten zur Optimierung der Customer Journey, Durchführung von Marketingmaßnahmen etc. haben, sollten sie sogar zwingend getestet und optimiert werden.

Wir kennen Beispiele aus Gesprächen mit betroffenen Unternehmen, welche nach der Umsetzung des EuGh-Urteils von über 80 % auf unter 20 % Acceptance-Rate gerutscht sind, sich dann auf über 90 % hoch optimiert und mit der Umsetzung der TTDSG-Regelung wieder einen Drop um 20 – 30 % messen konnten.

Optimierung der Cookie Banner lohnt sich, und genau das haben wir 2021 ebenfalls getan und möchten dich an den Updates und den daraus resultierenden Learnings teilhaben lassen. Gleichzeitig werden wir auf die aktuelle Gesetzeslage des Telekommunikation-Telemedien-Datenschutzgesetz (TTDSG) blicken.

Die Themen

1. Was ist das TTDSG und warum für uns Optimierer:innen relevant?

2. Cookie Banner im Alltag: Datenverlust durch die neue Rechtslage

3. Cookie Banner im A/B-Test: Mythen und Irrtümer, die deine Leistung verringern

4. Update zum A/B-Test: Wie konnten wir unsere Acceptance Rate in den letzten Monaten um 53,25 Prozent steigern?

5. Ausblick und Fazit

5. Bonus: Beispiele für DSGVO-konforme Cookie Banner, die eine hohe Acceptance Rate versprechen

1. Was ist das TTDSG und warum ist es für uns Optimierer:innen relevant?

Der Bundestag hat am 20. Mai 2021 mit dem Gesetz zur Regelung des Datenschutzes und des Schutzes der Privatsphäre in der Telekommunikation und bei den Telemedien (kurz TTDSG) ein neues, datenschutzrelevantes Gesetz verabschiedet, welches das Ziel hat, die „Ungenauigkeit“ in der DSGVO durch die fehlende E-Privacy Regelung endlich in deutsches Recht zu überführen.

Allen, die sich mit dem Thema beschäftigen (müssen), ist sicherlich bekannt, dass die offizielle E-Privacy Regelung wohl noch einige Zeit auf sich warten lässt.

Bis jetzt liefen die DSGVO mit dem Telemediengesetz (TMG) und Telekommunikationsgesetz (TKG) parallel und konnten dadurch zu Unklarheiten im richtigen Umgang mit Daten und deren Erfassung führen. Mit dem neuen Gesetz kommt die Bundesregierung der europäischen E-Privacy Regelung zuvor, was aber auch bedeutet, dass diese wiederum – wenn sie denn mal irgendwann verabschiedet wird – zu weiteren Änderungen führen könnte.

Ein kurzer Exkurs zu Parallel-Gesetzen: Warum dieser Kuddelmuddel? 

2. Cookie Banner im Alltag: Datenverlust durch die neue Rechtslage

Mit jeder neuen gesetzlichen Regelung kommt die Frage auf, inwiefern das eigene Unternehmen betroffen ist und welche Änderungen konkret nötig werden. Hier verspricht der Gesetzgeber keine neuen komplexen Regelungen, sondern eine Zusammenführung der relevanten datenschutzrechtlichen Normen, die besondere Relevanz für Anbieter von Telekommunikationsdiensten und Telemedien haben. Ob das konkret auf E-Commerce und das Tracking von Nutzerverhalten zutrifft, klären wir nachfolgend.

Bereits mit Ablauf der Schonfrist zur DSGVO am 25. Mai 2018 waren Sicherstellung der Messbarkeit und des Datenschutzes ein heißes Thema, wurden jedoch im Sommer 2019 durch das EuGh Urteil bzgl. dem Opt-In statt Opt-Out für die Auswahl der Cookie Consent-Inhalte wieder neu entfacht.

Die E-Privacy – welche Status quo März 2022 immer noch nicht verabschiedet wurde – sollte diese Verarbeitung regulieren. Hier übernimmt jetzt das neue TTDSG in Deutschland, das seit dem 01.12.2021 in Kraft getreten ist.

Leider war diese Regulierung – soweit es von uns nachvollzogen werden konnte – teils sehr schwammig formuliert, sodass viel in der Auslegung interpretiert werden konnte. Zusätzlich wurde hier die Komplexität durch das TMG und TKG erhöht, und deshalb nicht selten als „unklare Rechtslage“ bezeichnet.

Das führt dazu, dass sich diverse Irrtümer und allerlei Interpretationen in Bezug auf DSGVO-konforme Cookie Banner hartnäckig halten und jetzt durch das neue Gesetz zusätzlich verschärft wurden.

Da Verantwortliche natürlich „auf Nummer sicher gehen“ wollen, leidet gezwungenermaßen die Tracking-Performance. Dazu kommt, dass durch aktuelle Verfahren zu diesen Gesetzen und Regelungen immer wieder neue Präzedenzfälle geschaffen werden und damit stetig Bewegung in die Sache kommt.

Die aktuelle Realität sind Debatten und Probleme beim Thema Cookie Consent Banner:

1. Die Designer:innen fragen: Interessieren sich unsere Besucher:innen eigentlich für das Cookie Banner, können wir das Consent Layer nicht kleiner machen? Die Besucher:innen kennen das doch längst…
2. Die Datenschutzbeauftragten: Wie gewährleisten wir die Rechtssicherheit? Insbesondere, weil sich die Lage wieder geändert hat?
3. Die Marketer: Wo sind meine Daten? So kann ich nicht arbeiten! Wenn ich noch weniger über das Nutzerverhalten erfahre, kann ich den Laden bald dicht machen…
4. Der Laie: Oh mein Gott, ich blicke gar nicht mehr durch, welches Gesetz jetzt relevant ist und welches Urteil gerade wieder eine Regelung verschärft oder entschärft hat…

Klar ist, wenn bspw. die Cookie bzw. letztlich Taging Acceptance-Rate von 80 % durch eine neue Regelung, wie unlängst durch das TTDSG, auf unter 50 % fällt, dann ist das ein Horrorszenario für das Onlinemarketing bzw. auch alle anderen On- und Offsite-Optimierungen.

„Wenn durch niedrige Cookie-Akzeptanzraten der verfügbare Traffic einbricht, werden Performance- und Marketingmaßnahmen stark beeinträchtigt.“

Als Optimierer:innen der Customer Experience benötigen wir Daten, um darauf aufbauend Maßnahmen ableiten und verproben zu können.

Es gibt auch einige Website-Betreiber:innen, die in der Vergangenheit teils kreative Lösungen gefunden haben, den Anforderungen gerecht zu werden, ohne den Besuchern:innen zu schaden und trotzdem das Onlinemarketing aufrechtzuerhalten.
Dazu in den Beispielen mehr.

Was hat sich konkret durch das TTDSG verändert?

Ohne jetzt zu tief in die Details zu gehen, hier die für uns Optimierer:innen wohl relevantesten Änderungen:

Der Paragraf § 25 besagt im Kern, dass eine Zustimmung der/des Besuchers:in zur Datenverarbeitung und Informationsverarbeitung grundsätzlich immer erforderlich ist!

„Die Speicherung von Informationen in der Endeinrichtung des Endnutzers oder der Zugriff auf Informationen, die bereits in der Endeinrichtung gespeichert sind, sind nur zulässig, wenn der Endnutzer auf der Grundlage von klaren und umfassenden Informationen eingewilligt hat. Die Information des Endnutzers und die Einwilligung haben gemäß der Verordnung (EU) 2016/679 zu erfolgen.“

Im Klartext bedeutet das, dass die Besucher:innen der Speicherung von Cookies – und auch allen anderen Formen der Speicherung und Verarbeitung von Daten auf dem Endgerät – aktiv zustimmen müssen, unabhängig davon, ob es sich dabei um personenbezogene Daten handelt oder nicht.

Ebenso finden sich zwei weitere Einschränkungen, die eine wichtige Rolle spielen:

1. Verfahren wie das sog. „Fingerprinting“ – also die Möglichkeit auf Basis von Systemvariablen (z.B. Device, User Agent, IP, pseudonymisierten IDs) generierte Identifier, die somit ohne Einverständnis und Kenntnis der Besucher:innen eine Wiedererkennung ermöglichten (wenn auch je nach Art des Fingerprintings mit mehr oder weniger Ungenauigkeit) ist nicht mehr gestattet.
2. Außerdem darf den Besuchern:innen das Ablehnen der Speicherung von Daten nicht erschwert werden, was im Klartext bedeutet, dass das „Ablehnen“ sich z.B. nicht als unkenntlicher Link in einem Fließtext „verstecken“ darf, sondern als Button erkennbar sein muss.

3. Cookie Banner Beispiele im A/B-Test: Mythen und Irrtümer, die deine Performance verringern

In Gesprächen mit Entscheidern sowie Leidtragenden der neuen Einschränkungen durch konforme Cookie Consent Layer sind immer wieder die gleichen Themen aufgetaucht, aber auch „allgemeine Irrtümer“ bezüglich des Einflusses der TTDSG und E-Privacy auf Tracking-Möglichkeiten und das Nutzerverhalten.
Nicht wenige Unternehmen scheinen bisher eher in folgendem Modus unterwegs gewesen zu sein:

Solange es auch andere (Marktbegleiter) so handhaben und sich niemand beschwert, lassen wir unsere Cookie Banner erst mal wie gehabt.

Zumindest war das unser Eindruck, wenn wir uns mit Verantwortlichen unterhalten bzw. uns die unterschiedlichen Versionen der Consent Layer, und wie diese das Recht umsetzen, angeschaut haben.

Nachfolgend kläre ich häufige Mythen und Irrtümer, die deine Leistung bremsen und zeige, was du dagegen tun kannst bzw. was wir gelernt haben.

Mythos #1: Wir dürfen ohne Nutzererklärung keine Daten mehr speichern oder verarbeiten

Es gibt wohl kein gutes Gesetz ohne entsprechende Ausnahmen.

Heißt im Klartext, nur für das, was die/der Besucher:in ausdrücklich wünscht, dürfen die notwendigen Daten gespeichert und verarbeitet werden. Hierunter fallen z.B. typische Cookies, wie:

• Authentifizierungs-Cookies, um eine reibungslose Anmeldung gewährleisten zu können.
• Cookies zum Speichern von Eingaben in Formularen oder um festzuhalten, welche Produkte bereits im Warenkorb sind, ob ein Overlay bereits angezeigt und beantwortet wurde usw.
• Sicherheits-Cookies, um fehlgeschlagene Anmeldeversuche und Co. festzuhalten.
• Cookies zur Speicherung von Nutzer-Präferenzen wie z.B. Sprache, Bezahlmethoden, Filter-Einstellungen usw., also auch, um Kernfunktionen in der Customer Journey bereitstellen zu können.
• Cookies zur Wiedergabe von nutzerseitig angeforderten Audio- oder Videoinhalten.
• und noch einige mehr.

Zusammengefasst also alles, was dem Zwecke des Besuchs auf der Website dienlich und dafür erforderlich ist.

Tools zur Webanalyse, A/B-Testing, Personalisierung und Marketing-Tools, insbesondere für Werbung, fallen leider nicht unter diese Beschreibung. Diesen muss weiterhin aktiv von Besuchern:innen zugestimmt werden, was tatsächlich nicht groß verwundert.

Natürlich hätten wir uns „Optimierer-freundliche“-Regelungen gewünscht, da es den Besuchern:innen – aus unserer Perspektive – sicher nicht schadet, wenn wir uns merken, dass sie schon einmal in einem A/B-Test waren und welche Variante dabei ausgespielt wurde, ohne dass sie dem aktiv zugestimmt haben. Aber wir begrüßen dennoch, dass die neue Regelung jetzt mehr Klarheit in viele Fragen bringen, deren Antworten sich sonst nur aus Urteilen ergeben hätten.

Mythos #2: Besucher:innen interessieren sich nicht für Cookie Banner

Die Hypothese:

Besucher:innen interessieren sich nicht für Cookie Banner-Einstellungen, denn sie haben völlig andere Ziele, wenn sie eine Website besuchen.

Und das kann schon als pauschale Annahme bezeichnet werden, unabhängig davon, um welche Art von Webangeboten – z.B. Onlineshop, Medienportal, Vermittlungsseite usw. – es sich dabei handelt.

Es wird sogar von Phänomenen wie „Cookie Banner Blindness“ gesprochen, weil die häufig als nervig angesehenen Pop-Ups, Banner und Leisten einfach inzwischen gelernt sind.

In Probandenbefragungen hören wir Aussagen wie:

„Diese Banner erscheinen auf jeder Website, sehen zwar teilweise unterschiedlich aus, kommen aber immer gleich um die Ecke und wollen, dass ich auf einen Button klicke.“

oder
„Durchlesen tue ich die Texte der Cookie Banner nie. Steht ja eh immer die gleiche langweilige Botschaft von wegen Statistik usw. drin.“
oder
„Interessiert mich nicht, klicke ich gleich weg.“

Was ist also dran an diesem Mythos?

Interessiert deine Besucher:innen wirklich nicht, was drin steht?

Interessieren sich die Besucher:innen überhaupt für Cookie Banner?

Wir wollten es genauer wissen und haben es einfach getestet.

Das A/B-Test Szenario

Im Rahmen eines A/B-Tests haben wir 3 verschiedene Beispiele eines Cookie Consent Layers getestet.
Bevor Vermutungen aufkommen: Die Button-Farbe hatte nichts mit dem Test-Szenario zu tun. 😉

Während der Tests hat sich unsere CI verändert, sodass die Screenshots der Varianten teilweise noch die alten, teilweise schon die neuen Farbcodes enthalten.

Auch der Default-Zustand war immer gleich, die Screenshots zeigen unterschiedliche Zustände. Zu Beginn waren in den Cookie Banner-Beispielen immer die Checkboxen leer und die primäre CTA „Alles auswählen“ hervorgehoben. Je nach Cookie-Variante und Auswahl der Besucher:in veränderte sich die CTA textuell.

1. V1 Fokus auf Business-Ziel (Control)
2. V2 Hybrid-Version
3. V3 Fokus auf die Customer Journey und das Nutzerziel

V1 Fokus auf Business-Ziel

In diesem Cookie Banner-Beispiel war das Banner nicht zu übersehen. Ein echter Störer als Modal.
Es gab also keine Möglichkeit, den Consent Layer wegzuklicken, ohne sich für „Alle akzeptieren“ als primäre CTA oder „Auswahl speichern“ als sekundäre CTA zu entscheiden. An dieser Stelle sei noch mal gesagt, dass dieses Banner vor dem TTDSG verprobt wurde (heute benötigt man den Ablehnen-Button).
Wurde „Auswahl speichern“ gewählt, so wurde die aktuelle Cookie-Wahl – EuGh / DSGVO-konform – ohne Vorauswahl gespeichert. Im Zweifel also gar nichts.
Aber die Besucher:innen mussten sich entscheiden, ohne Beantwortung ging es nicht weiter, die Website im Hintergrund konnte nicht bedient werden.

Diese Version entspricht der Empfehlung unseres Datenschutzbeauftragten und wurde vor dem A/B-Test live genommen. Sie ist somit gleichzeitig die Control-Variante.

V2 Hybrid-Version

In einer Hybrid-Version wurde dieses restriktive Verhalten aufgeweicht.

Der Cookie Consent Layer wurde optisch reduziert und zusätzlich mit einem Schließen-Button ausgestattet, sodass man ihn schnell – als gelerntes Verhalten – „weg-x-en“ konnte. Sofern dieses Verhalten zum „Ablehnen“ führt, wäre es – unserer Einschätzung nach – auch heute noch TTDSG konform. In unserem Fall zum damaligen Zeitpunkt entsprach das X = Auswahl speichern.

Ein weiterer Unterschied zur V1 war, dass die Website im Hintergrund bedienbar war und nicht ausgegraut wurde.

Außerdem wurde nur noch eine CTA angeboten, um es möglichst einfach zu halten.

Zu Beginn, ohne Vorauswahl der Kategorien, lautete diese „Alle auswählen“, sobald eine Kategorie per Checkbox gewählt wurde „Auswahl speichern“.

V3 Fokus auf Nutzerziele

In dieser Version wurde die Customer Journey der Besucher:in bzw. deren Ziel fokussiert:

In der Annahme, dass die/der Besucher:in andere Ziele hat als das Banner zu beantworten, wurde es nicht als Störer, sondern dezenter als Leiste am unteren Bildschirmrand eingeblendet. Um mehr Fokus auf das Element zu legen, wurde die Leiste verzögert eingeblendet.

Die/der Besucher:in konnte also völlig frei, ohne das Banner beantworten zu müssen, seinem Ziel folgen (z.B. Artikel zu lesen oder Tickets zu buchen) und das Banner ignorieren.

Technisch entspricht diese Version ansonsten der V2, mit dem Unterschied, dass in der mobilen Ansicht erst nach dem Klick auf den Link „Mehr“ die Konfiguration möglich war.

Beschreibung der KPIs
Neben den gewählten Kategorien sowie der Bestätigung der Auswahl haben wir die Bounce Rate und Zeit, bis eine Auswahl getroffen wurde, gemessen.

Was haben wir gelernt?
Damit wir einschätzen konnten, ob die Hypothese bestätigt oder widerlegt werden kann, haben wir Folgendes berücksichtigt:

• die Zeit, die ein(e) Besucher:in benötigt, um eine Auswahl zu treffen
• die Art, wie Besucher:innen das Cookie Banner schließen
• die Anzahl der Besucher:innen, die überhaupt mit dem Banner interagieren

Was wir dabei feststellen konnten, ist, dass Besucher:innen bei allen Varianten die Banner durchschnittlich nach 2 Sekunden schließen, bei V1 sogar unter 2 Sekunden.

Auch der schnellste Leser schafft es nicht, so schnell den Cookie Banner Text zu lesen.
Demnach schließen wir darauf, dass gar nichts gelesen wurde, nur kurz gescreent á la:
„Ah ja, Cookie Banner…und weg damit“.

In der V2 wurde das X sehr viel häufiger als die CTA geklickt.

Also auch hier unsere Interpretation „gleich weg damit“.

Die V3 wurde, wie erwartet, so gut wie gar nicht bearbeitet: 62 % weniger als die V1, 66 % weniger als die V2.

Mit anderen Worten: Freiwillig beschäftigt sich nur ein geringer Teil von Besuchern:innen mit Cookie Bannern.

Fazit: Mythos #2 bestätigt – Besucher:innen interessieren sich nicht für Cookie Banner

Die Besucher:innen unserer Websites interessierten sich tatsächlich nicht für den Cookie Banner, was wir an der Messung der Interaktion und „Time-to-Exit-Banner“ KPI bestätigen konnten.

Mythos #3: Business-Ziele stehen im Konflikt zur Customer Experience

Dieser Mythos steht im direkten Zusammenhang damit, dass (wie wir eben gelernt haben) Menschen sich nicht für Cookie Banner interessieren, und lässt sich davon ableiten.

Das Business-Ziel hinter einem Cookie Consent Banner ist in der Regel, dass Besucher:innen alle oder wie in unserem Fall zumindest „Statistik“ und „Personalisierung“ akzeptiert, damit Analysen zum Nutzerverhalten und Maßnahmen verprobt werden können. Die Kategorisierung ist übrigens nicht genormt. Sowohl was die Benennung angeht, als auch die Zuordnung. Häufig gibt es z.B. auch Kategorien wie Marketing, Werbung, Analyse, Funktional und wo letztlich das Cookie, bzw. das Tool / der zugeordnet wird, liegt im Auge des Datenschutzbeauftragten.

Unser Ziel als Blog ist Analytics und Personalisierung, je nach Businessmodell können natürlich andere Ziele verfolgt werden, am häufigsten wohl Marketingpixel, um die Werbemaßnahmen besser und zielgerichteter steuern zu können.

Die Hypothese:

Da sich Besuchern:innen nicht für Banner interessieren, scheint es plausibel, dass ein Zielkonflikt zwischen Website-Anbieter:innen und Besucher:innen besteht.

Auch das wollten wir genauer wissen, und haben es getestet.

Unser A/B-Test Szenario

Erneut wurde das bereits vorgestellte Test-Szenario angewendet.
Unser Ziel als Betreiber ist es, dass Besucher:innen alle Cookies akzeptieren, damit wir besser arbeiten können.

Das Ziel der Besucher:innen – im Fall unserer Plattformen – ist, Content zu erhalten bzw. Tickets für Veranstaltungen zu kaufen.

Somit war V1 voll auf unser Business-Ziel und V3 voll auf das Nutzer-Ziel ausgerichtet, V2 ein Kompromiss.

Beschreibung der KPIs

Für die Bewertung des Tests haben wir auch hier primär die Acceptance Rate gemessen, dabei vordergründig, welche Kategorien gewählt wurden.

Primäre KPI ist somit „Alles“, sekundär aus Business-Sicht zumindest „Statistik“. Außerdem haben wir uns die Bounce Rate angeschaut.

Was haben wir gelernt?

Grundsätzlich wollten die Besucher:innen das Cookie Banner schnell loswerden (siehe Mythos #2).

Insofern ging die Strategie auf, die primäre CTA „Alles Auswählen“ anzubieten, und die Formulierung „Auswahl speichern“ optisch zurückzunehmen.

Im weitesten Sinne könnte man das schon als „Dark-Pattern“ bezeichnen – worauf uns übrigens treue Leser hingewiesen haben.

Allerdings war diese Idee im Vergleich zu vielen anderen kreativen Beispielen, die wir im weiteren Verlauf noch vorstellen werden, eher harmlos.

Im Übrigen ist genau das im Kontext der TTDSG nicht mehr so ohne Weiteres möglich. Die Konfiguration kann zwar grundsätzlich per Text-Link erfolgen, sofern das Ablehnen der Cookies nicht über diese Konfiguration läuft. D.h. das Ablehnen muss wie eingangs beschrieben ohne Umwege oder Verschleierung möglich sein.

In diesem Mythos dreht es sich ja um den Konflikt zwischen Besucher:innen bzw. Customer Experience und Website-Betreiber:innen, und den haben wir anscheinend nicht gelöst.

Wenn man wirklich die Besucher:innen in den Vordergrund stellt und die Business-Ziele zurücknimmt, müsste V3 die Variante der Wahl sein.

Hier konnten wir im Test bestätigen, dass rund 3,2 % weniger Besucher:innen in V3 im Vergleich zu V1, bzw. 2,3 % weniger zu V2 abspringen, und dafür das Cookie Banner mehr oder weniger einfach links liegen lassen.
Dies bestätigt uns, dass das Ziel der Besucher:innen mit dem des/der Website-Anbieters:in im Konflikt steht.
Allerdings fallen diese Werte nicht besonders ins Gewicht.

Fazit: Mythos #3 bestätigt – Business-Ziele stehen im Konflikt zur Customer Experience

Auch diesen Mythos konnten wir bestätigen.

Die Varianten, die nicht auf das Business-Ziel einzahlten, sondern die/den Besucher:in und ihre Journey in den Fokus stellten, haben genau dieses Paradigma bestätigt. Besucher:innen interagieren weniger mit dem Banner (beachten es nicht) und bouncen (etwas) weniger.

Die naheliegende Lösung dieses Paradigmas lautet, der/dem Besucher:in die Beantwortung des Cookie Consent Layers möglichst einfach zu machen, damit der Konflikt nicht ins Gewicht fällt.

Unsere Cookie Banner Beispiele waren sehr unterschiedlich, und in dieser Testreihe ging es darum herauszufinden, welche Variante grundsätzlich besser akzeptiert wird.

Es gibt natürlich nicht nur Schwarz (Besucher:innen zwingen) und Weiß (Business-Ziel ignorieren).

Behält man dieses Paradigma im Hinterkopf, lässt sich ein Kompromiss finden, der beide Welten vereint. Unsere V2 konnte diesen Spagat noch nicht erreichen. Aber dafür testen wir einfach weiter, vor allem auch, um unsere Acceptance Rate zu erhöhen.

Wie wir die Acceptance Rate für unsere Business Ziele um 53,25 % – vor dem Inkrafttreten des TTDSGs – in Folgetests steigern konnten, zeigen wir euch im weiteren Verlauf.

Übrigens, wenn es um die Kategorien (Checkboxen) geht, wie Besucher:innen mit dem Cookie Banner interagieren, dann gewinnt in jeder Variante „Komfort“, weit vor „Statistik“ und „Personalisierung“.
„Personalisierung“ verliert tatsächlich sogar bei jeder Variante.

Sicherlich keine allgemeingültige Aussage, aber für unser Experiment (bezogen auf unsere Zielgruppe des Blogs) ein zusätzlicher Insight, der bei der Gestaltung zukünftiger Cookie Banner Varianten hilfreich sein kann.

Auch hierfür gibt es leider kein Patentrezept, es lohnt sich – sofern die/der Datenschutzbeauftrage mit sich reden lässt – auch das Wording der Kategorien zu verproben (z.B. Analytics vs. Statistik, Marketing vs. Werbung, Komfort vs. Funktional usw.).

Irrtum #1: Ohne Zustimmung der Besucher:in kann nichts getrackt oder ausgespielt werden

Dieser Irrtum hat vor allem rechtliche Hintergründe.
Denn, ohne dass Besucher:innen aktiv zustimmen, sollen weder Cookies, noch etwaige Tools (z.B. Web Analytics, Testing, usw.) auf dem Endgerät gespeichert werden.

Mit anderen Worten: solange Besucher:innen nicht aktiv zustimmen, gibt es kein Web Analytics und auch kein A/B-Testing etc.

Die Hypothese

„Ohne Einwilligung der Besucher:innen dürfen keinerlei Daten gespeichert werden, sodass auch keine Ausspielung von Tags erlaubt ist.“

Das konnten wir natürlich nicht einfach im Rahmen von A/B-Tests ausprobieren, weshalb wir uns dazu mit einem Experten ausgetauscht haben.

Wie man Tracking und A/B-Testing trotz Cookie Consent Layer erreicht, haben wir Dr. Schadowski, Sachverständiger für Datenschutz und IT-Sicherheit im Bundesverband BISG e.V., gefragt:

kK: Ist ein Einverständnis der Besucher:innen für eine lokale Speicherung auf dem Endgerät der Besucher:innen (unabhängig von der technischen Umsetzung, z.B. Cookie oder Local Storage) erforderlich?

Dr. Schadowski: …das TTDSG sagt im Wesentlichen aus, dass die Besucher:innen Kontrolle über ihre Daten haben müssen. Außerdem, dass Website- oder App-Anbieter:innen auch weiterhin Daten mit Einwilligung speichern und verarbeiten dürfen.

Allerdings sind die sogenannten TOM (Technisch Organisatorische Maßnahmen) deutlich gestrafft, bedeutet, dass auch eine Nutzung anonym möglich sein soll und dass jederzeit rückstandsfrei alle Daten auf Antrag der Betroffenen gelöscht werden müssen – also keine Cookies ohne Einwilligung. Anderes gilt nur dann, wenn die Cookies & Co. für die technische Bereitstellung des jeweiligen Dienstes „unbedingt erforderlich“ sind oder sie allein der Übertragung einer Nachricht über ein öffentliches Telekommunikationsnetz dienen.

kK: Wenn wir beim A/B-Testing die Browser-URL nicht persistent speichern und keine ID ohne Zustimmung generieren, wäre die Übertragung von Varianten-Kombinationen über die Browser-URL rechtlich ohne Zustimmung möglich?

Dr. Schadowski: Ja, das ist weiterhin möglich.

kK: Betrifft der Cookie Consent auch die Implementierung eines Tools (z.B. eines JavaScript-Tags)?

Dr. Schadowski: Sofern das Tool nicht außerhalb der eigenen Domain liegt, also kein fremdes System angefragt werden muss (das ansonsten durch den Request die IP-Adresse = personenbezogenes Datum erfahren würde), können beliebige Tools (z.B. Server-seitig) implementiert werden. Nur wenn z.B. ein System extern liegt, und alleine durch den Aufruf des Tags der Austausch von Daten stattfindet, dann ist auch die Implementierung erst nach Consent erlaubt.

kK: Wie sieht es mit der „Cookie-Less“ Zukunft aus, in dem z.B. nicht im Client / Browser der Besucher:innen Informationen gespeichert werden, sondern diese ausschließlich Server-seitig verarbeitet werden? Wäre dies auch nach der TTDSG noch legitim?

Dr. Schadowski: …das Unternehmen muss als Verantwortlicher jederzeit Auskunft an die/den Betroffenen geben können. Es muss nachweisbar sein, welche Dienstleister zu welchem Zweck wie eingebunden sind, dazu zählen z.B. auch Programmierer:innen oder Rechenzentren, die in den Datenfluss eingebunden sind, und wenn personenbezogene Informationen verarbeitet werden, dann geht das nur mit nachweislichen Consent.

kK: D.h. dass wir bereits pseudonymisierte und nicht personenbezogene Daten im System speichern können, bevor der/die Besucher:in einen Consent gegeben hat?
Konkret ist damit gemeint, dass wir z.B. uns die Session ID merken und mit dieser ID auch eine A/B-Testvariable verknüpfen. Beides hat keinen Personenbezug, reicht uns aber schon für die Ausspielung und Bewertung von Marketingmaßnahmen. Erst nach dem Consent können wir dann clientseitig ein Cookie speichern, dass es uns abseits der aktuellen Session ermöglicht, die Konsistenz der Customer Experience zu gewährleisten.

Dr. Schadowski:Technische Cookies ohne Personenbezug können ohne Consent gesetzt werden.

Fazit Irrtum #1: Technisch und rechtlich einwandfrei das Maximum herausholen

Technisch stellt es kein Problem dar, Experimente und Performance-Maßnahmen auch nach TTDSG schnell, synchron und flackerfrei beim ersten Seitenaufruf sicherzustellen. Eine 100 %-Ausspielung funktioniert immer, unabhängig von der Einwilligung.

Voraussetzung ist, dass das für die Ausspielung verwendete Tool keine Daten speichert. Also auch keine LogFiles über den Request mit der IP der Besucher:in und sich auch nicht in den USA befindet.

Letzteres steht allerdings im Kontext des Datenschutzabkommens, bzw. eher der Abwesenheit eines solchen, zwischen der EU und den USA. Aktuell ist es möglich, dass sich unter anderem Dritte (im Wesentlichen bezieht sich die Kritik auf die US-Geheimdienste) Zugriff zu personenbezogenen Daten – dazu zählen bekanntlich auch IP-Adressen – verschaffen können, ohne dass dies durch den Betreiber der Website oder die Besucher:innen beeinflusst werden kann.

Dennoch hat sich etwas Wesentliches geändert:
Alle Cookies und Datenspeicherungen – auch pseudonymisierte oder nicht personenbezogene Daten – müssen durch die Besucher:innen aktiv bestätigt werden. Die Ausnahme sind wie von Herrn Dr. Schadowski und die eingangs erwähnten „systemrelevanten“ Cookies oder solche Daten, die zwingend für den Auftrag erforderlich sind.

Die pure Einbindung eines Tools ist jedoch auch ohne Consent grundsätzlich möglich. Die Unterscheidung, dass Daten im System und nicht auf dem Gerät der Besucher:innen gespeichert werden, spielt in Bezug auf das TTDSG jedoch keine Rolle. Die Besucher:innen sollen die Kontrolle über ihre Daten erhalten. Ob diese nun im Client oder Server gespeichert werden ist nebensächlich. Die Daten ohne die Kenntnis serverseitig zu speichern verschleiert nur die Tatsache, ist aber nicht rechtskonform.

Irrtum #2: Der Cookie Consent Layer muss eine detaillierte Konfiguration der Cookies ermöglichen

Dieser Mythos geht etwas mehr ins Detail und beschreibt eher die Inhalte von Cookie Bannern, denn es existieren aktuell im Wesentlichen zwei Versionen von Cookie Consent Layern:

1. Einfache Textversionen mit einer oder mehreren Call-to-Actions
2. Konfigurierbare Layer mit Optionen, angefangen bei den Kategorien bis hin zu detaillierten Auswahlmöglichkeiten der Anbieter

Die Hypothese

„Es muss Besuchern:innen im Cookie Banner möglich sein, Umfang, Anbieter und Kategorie (direkt) wählen zu können.“

Um diesen Irrtum auszuräumen, haben wir uns die unterschiedlichen Banner angeschaut, sowie mit Betreibern und unseren Rechtsexperten gesprochen.

Hier ein Beispiel, wie wir das Cookie Banner vor dem EuGh-Urteil eingesetzt haben (Stand damals DSGVO, noch kein TTDSG).

Ein einfacher Hinweis, dass Cookies verwendet wurden. Ist die/der Besucher:in auf der Seite geblieben, so wurde dies als „stille Akzeptanz“ gewertet.

„Mehr erfahren“ führte zu den Datenschutzbestimmungen, mit der Möglichkeit, einzelne oder mehrere Anbieter per Opt-Out zu deaktivieren.

Dieses Beispiel zeigt eine ältere Version des Cookie Banners von mobilcom-debitel. Telekom verwendete damals einen ähnlichen Consent Layer.

Im Layer selbst gibt es nur eine CTA „Akzeptieren“ bzw. im Fall der Telekom „Zustimmen“. Damit werden alle Cookies akzeptiert.

Beide Banner sind DSGVO-konform, aber nicht mehr nach dem TTDSG. Bei mobilcom musste über Optionen, bei der Telekom über „Einstellungen“ oder „ablehnen“ die Konfiguration oder eine Ablehnung der Speicherung getroffen werden.

Das TTDSG schreibt jedoch vor, dass die Ablehnung auch ohne direkt möglich sein muss.

Völlig legitim ist aber auch heute noch, die Konfiguration unter „Zu den Optionen“ oder „Einstellungen“ in einem nachgelagerten Schritt unterzubringen.

Beide Cookie Layer-Beispiele folgen den auch von uns angewendeten Patterns: Kognitiv möglichst einfache Beantwortung und ermöglichen dennoch der/dem Besucher:in:

a) schnell das Banner loszuwerden und
b) für jene, die es wirklich entscheiden wollen, auch die Auswahl zu treffen

Um auch noch TTDSG-konform zu sein, muss es entweder einen zusätzlich Ablehnen-Button oder als Alternative eine Ablehnung durch das Speichern ohne vorausgewählten Cookie-Kategorien geben.

Heutige Consent Management Tools bieten umfangreiche Möglichkeiten, neben A/B-Testing der Cookie Banner auch, spezifische Konfigurationen.

Fazit Irrtum #2:

Es ist nach wie vor richtig, dass die Besucher:innen eine Option benötigen, um die Art der Speicherung wählen zu können.

Jedoch muss es ihnen jetzt ebenfalls ermöglicht werden, sich allgemein gegen Speicherung auszusprechen, und das nicht mehr nur gegen spezifische Inhalte.

Übrigens bleibt es bei letzterem nach wie vor beim Opt-In. Das heißt, es dürfen in der Konfiguration keine Kategorien oder Einstellungen vorausgewählt sein, sondern müssen proaktiv getroffen werden. Eine Komfortfunktion a lá „Wähle alle für mich aus“ ist weiterhin erlaubt. 😉

Das alles bedeutet jedoch nicht, dass sich diese Optionen in einem (komplizierten) Cookie Setup-Formular tummeln müssen. Und schon gar nicht direkt im ersten Dialog.

Irrtum #3: Cookie-Banner (Versionen) können nicht getestet werden

Da wir im Verlauf dieses Artikels einige der Mythen durch Testing auf die Probe stellten, haben wir diesen Irrtum im Prinzip schon widerlegt. Aber das TTDSG hat ja auch Einfluss auf die generelle Speicherung von Daten und Einbindung von Tools. Deshalb haben wir im Folgenden ein paar Tipps zusammengestellt, wie sich Cookie Banner auch heute noch testen lassen.

Die Hypothese

„Konforme Cookie Consent Banner kommen vor dem Testing, insofern kann ohne die Zustimmung der/des Besuchers:in kein Test ausgespielt werden.“

Ob und wie einfach Consent Layer getestet werden können, steht und fällt mit den verfügbaren Tools und deren Möglichkeiten. Könnte man zumindest meinen. Tatsächlich ist es jedoch auch möglich, das „Henne – Ei“-Problem (ohne Cookies kein Testing, ohne Testing keine Cookies) zu umgehen, unabhängig vom Testingtool.

Die einfachste Möglichkeit ist natürlich, wenn eine Consent Management Plattform verwendet wird, welche bereits A/B-Testing von Banner-Varianten mitbringt, was bei den meisten CMPs inzwischen Standard ist.

Steht eine solche Plattform jedoch nicht zur Verfügung, z.B. weil kein Consent Management eingesetzt und wie in unserem Fall das Tag Management auch hierfür verwendet wird, so können mit dem von uns gewählten Setup sehr einfach Varianten innerhalb des Cookie Layers getestet werden und grundsätzlich auch verschiedene Consent Management Tools gegeneinander.

Dazu stellen wir dir im folgenden 2 verschiedene Szenarien vor:

1. Session-basierte Ausspielung (unabhängig vom Testingtool)
2. Verzögerte Messung (abhängig vom Testingtool)

1. Session-basierte Ausspielung

Bei diesem Szenario, welches wir auch für unsere A/B-Tests gewählt haben, werden keinerlei personenbezogenen Daten über die Besucher:innen erhoben und auch nicht auf dem Endgerät gespeichert und stattdessen auf die „systemkritischen“ Cookies zurückgegriffen: Der Server benötigt zur Bereitstellung der Session eine Variable, welche eine Session ID erzeugt. Diese ID reicht uns bereits, um im Monitoring nachvollziehen zu können, ob eher Banner A oder B funktioniert.

Außerdem müssen wir den Zustand – also die Antwort auf das Banner – speichern, sonst würde die/der Besucher:in bei jedem Seitenwechsel und erneutem Besuch der Seite das Banner erneut sehen. Auch das zählt – unserer Definition nach – zu einem systemrelevanten Cookie.

Mit dieser Kombination haben wir alle relevanten Zutaten für einen simplen A/B-Test zusammen.

Der/dem kritischen Leser:in dürfte an dieser Stelle auffallen, dass das TTDSG vorschreibt, jegliche Speicherung von Daten in die Hände der Besucher:innen zu geben.

Wieso können wir also pseudonymisierte Daten wie Session IDs in Form eines Session-Cookies speichern?

Unserer Auslegung des Rechts nach ist das deshalb legitim, weil das System ohne Sessions nicht funktioniert und wir dabei eine ID als Unterscheidungsmerkmal nutzen, die zwangsläufig erzeugt und benötigt wird, um das Web-Angebot bereitzustellen (also Mandatory).

Der Personenbezug, die Wiedererkennung o.ä. ist darüber unter keinen Umständen möglich. Damit das Cookie Banner nicht erneut angezeigt und damit der A/B-Test wiederholt ausgespielt wird, ermöglicht uns die erlaubte Speicherung des Banner-Zustandes (Cookie Consent Cookie).

Wie funktioniert das Setup?

Bei jeder neuen Generierung eines Banners bei einem Besuch – diese Tatsache lässt sich einfach durch die Nicht-Existenz des „Cookie Consent“-Cookies erkennen – wird zufällig eine Variante „gewürfelt“.

Diese Variante und weitere, nicht personenbezogene Informationen, wie etwa Device, Referrer, etc., werden systemseitig gespeichert. In unserem Fall einfach in der bereits aktiven Datenbankverbindung in einer eigenen Tabelle.

Der letzte Schritt ist, dass die Interaktion mit dem Banner, welche je nach gewünschten KPIs, ebenfalls anhand der Session-ID, zugeordnet werden.

In unserem Fall:

• die Auswahl der Kategorien
• welche CTAs verwendet wurden
• ob eine Folgeseite besucht wurde
• wie viel Zeit von der Einblendung des Banners bis zur Interaktion mit einer der CTAs vergangen ist

Mit anderen Worten:

Dieses Szenario beschreibt die Programmierung eines eigenen kleinen Testingtools. Dies soll jedoch keinesfalls ein Plädoyer gegen den Einsatz von etablierten Lösungen und Plattformen sein.

Diese bieten natürlich weit mehr Möglichkeiten und Funktionen. Aber um vorgeschaltet (und nur für den Zweck der Entscheidung) zu testen, welche Cookie-Banner-Variante zum Erfolg führt, ein pragmatisches Szenario.

Denn der Aufwand dafür ist mit wenigen Zeilen Code in der Regel eher überschaubar.

Vorteile des Szenarios:

• Testingtool unabhängig (kein weiteres Tool erforderlich)
• maximale Flexibilität und Kontrolle (sowohl über die Inhalte als auch über die Daten)
• einfache Umsetzung (nativ im vorhanden Tech Stack)

Nachteile des Szenarios:

• manuelle Auswertung (z.B. bzgl. Bot-Traffic, Statistik etc.)
• keine weiteren Insights (nur das, was im Vorfeld bedacht wurde)
• keine Ready-to-Use Features (z.B. für Targeting, Analyse etc.)

2. Verzögerte Messung

Die verzögerte Messung nutzt die Widerlegung des Irrtums #1 – Ohne Zustimmung kann nichts getrackt werden.
Grundsätzlich kann das Testingtool in diesem Szenario sehr wohl vor dem Consent Layer verwendet werden, und diesen in verschiedenen Varianten darstellen – oder die Darstellung und Inhalte im Rahmen eines Experiments den Hypothesen folgend verändern.

Wichtig dabei ist, dass hier ebenfalls keine Daten über die Bersucher:innen erhoben und ohne ihr Einwilligung gespeichert werden. Dies darf dann erst nach dem Consent erfolgen (z.B. die eindeutige Visitor-ID, IP-Adresse etc.).

Sofern das Testingtool diese Möglichkeit bietet, lässt sich damit sehr umfangreich testen, und vor allem lassen sich auch die weiteren üblichen Funktionen der Tools nutzen. In diesem Zusammenhang ermöglicht es vordergründig die viel einfachere Analyse der Ergebnisse.

Vorteile des Szenarios:

• einfacheres Setup (z.B. bzgl. Targeting)
• IT unabhängig (die IT muss nichts am System ändern)
• weitere Features (z. B. Audience Analysis, Templates etc.)

Nachteile des Szenarios:

• keine, sofern das Testingtool / Plattform die genannten Anforderungen erfüllt
• unter Umständen muss lediglich die Implementierung des Tools angepasst werden

Fazit Irrtum #3:

Auch Cookie Banner lassen sich testen und Insights aus den Ergebnissen generieren. Am einfachsten, in dem ein Consent Management Tool eingesetzt wird, das das Verproben unterschiedlicher Banner Varianten – idealerweise nicht nur optisch, sondern auch inhaltlich – ermöglicht.

4. Update zum A/B-Test: Wie konnten wir unsere “Alles akzeptieren”-Rate in den letzten Monaten um 53,25 Prozent steigern?

Die Hypothese

Wenn wir den Besuchern:innen die Bedienung des Banners erleichtern, sodass jene, die sich nicht mit der Konfiguration beschäftigen wollen, einen schnellen Exit ohne Ablenkung ermöglichen, dann fördern wir Acceptance Rate.

Das neue A/B-Test Szenario
Control
Ausgangslage war die Banner-Variante, die für uns zuvor den größten Business-Impact hatte (die meisten „Alles akzeptieren“ und / oder „Statistik“ Opt-Ins).

Variante

Diese Variante haben wir für eine „kognitive Erleichterung“ weiterhin vereinfacht, in dem wir die Einstellungen hinter einem separaten Menüpunkt versteckten und stattdessen die Möglichkeit zum komfortablen „Zustimmen“ in den Vordergrund stellten.

Zusätzlich fügten wir per Textlink die Möglichkeit ein – zu diesem Zeitpunkt noch vor dem TTDSG Update – der Speicherung der Cookies grundlegend zu widersprechen.

Mit dem Klick auf „Einstellungen“ ließen sich wie gehabt vereinfacht und optional die Kategorien wählen, wobei hierbei die CTA-Auswahl bestätigen hinzukam, welche nur die gewählten Kategorien speicherte (im Zweifel keine) und die bestehende „Zustimmen“ CTA in „Alle auswählen“ umbenannte. Die Funktionalität war also letztlich die gleiche.

Ergebnisse des Banner-Updates

Mit diesem Update konnten wir die Acceptance-Rate um 53,25 % erhöhen.

Ob wir uns länger an dieser Acceptance-Rate erfreuen können, ist fraglich, da das oben kurz skizzierte TTDSG Update, unserer Erfahrung nach, bereits zu 2-stelligen Drops führte.

Ob das bei unserer neuen Version ebenfalls der Fall sein wird, teilen wir euch hier natürlich gerne beim nächsten Update mit.

We’ll never stop optimizing. 😉

5. Ausblick und Fazit

Das TTDSG ist raus und sorgt leider an vielen Stellen noch für Fragezeichen, sodass sich sogar Rechtsexperten:innen immer noch nicht sicher sind. Wirklich mehr Klarheit und eine Vereinfachung für unsere Branche konnten wir bedauerlicherweise, zumindest bisher, nicht feststellen. Wer das aus erster Hand erleben möchte, dem empfehle ich diesen Podcast von Rechtsbelehrung (extern).

Solange die E-Privacy nicht final verabschiedet und klarer geregelt ist, und das TTDSG dann doch irgendwie schwierig ist, obwohl es doch TMG und TKG vereinen und vereinfachen sollte, wird es weiterhin Spielraum für (Falsch-)Interpretationen geben.

Nichtsdestotrotz besteht nach wie vor die Möglichkeit, sowohl Business- als auch Nutzerziele in Einklang zu bringen und die Customer Journey zu optimieren, ohne dass sich das auf die Sicherheit der Daten auswirkt, und umgekehrt die Möglichkeiten der Unternehmen maßgeblich einschränkt. Aber es wird ehrlicherweise zunehmend schwerer.

Wo geht die Reise hin?

Ich wage einen Blick in die Glaskugel und sehe persönlich zwei mögliche Perspektiven:

1. Cookie-less und Serverside
2. ID + Login Services

Die Cookie-less Zukunft könnte für Unternehmen funktionieren, die sich mit ihren Daten und denen ihrer Besucher:innen mehr auf 1st-Party konzentrieren und dabei auch mehr den Kontext und den Content als das Cookie in den Vordergrund stellen. Kontext könnte sozusagen die neue Währung werden, auf welche sich Marketing-Entscheidungen, insbesondere im Advertising in Zukunft fokussieren.

Wenn es mit erschwerten Regelungen für die Speicherung von Daten und zusätzlich den Bestrebungen der Browser-Anbieter, Cookies per se schon im Browser zu blocken (siehe ITP, ETP, Cookie Prevention und Co. hier) so weitergeht, bleibt uns nur noch übrig, uns mehr darauf zu konzentrieren, den Nutzungskontext besser zu verstehen und den passenden Content anzubieten.

Rein technisch könnte ich mir vorstellen, dass es mehr in Richtung In-House Lösungen gehen wird, die entweder selbst Daten Richtlinienkonform verarbeiten, oder diese z.B. in Form von Proxys zumindest filtern und serverseitig koordinieren. Initiativen der Customer Data – und Data Management Plattformen und auch Tag Management Systeme gehen schon in diese Richtung (z.B. API-Gateways, die fast ohne Speicherung im Client auskommen und konform Daten austauschen).

Aber auch die ID + Login Services könnten eine vielversprechende Alternative sein. Hier ist es wie mit VHS und Video 2000 oder Blu-Ray vs. HD-DVD: Welcher Anbieter wird wohl das Rennen machen, denn eine kritische Masse ist hier wohl die Crux.

Ich selbst hatte damals auf Video 2000 und HD-DVD gesetzt, insofern traue ich mir keine Einschätzung zu. 😉

Aber es ist eine interessante Lösungsidee, Besucher:innen einen Service anzubieten, in welchen sie einmalig ihre Präferenzen einstellen, um dann bei den Web-Angeboten, die auf diesen Service zurückgreifen, keine Einstellungen mehr durchführen zu müssen – also nicht mit Cookie Bannern und Co. beschäftigen müssen.

Da bereits einige große Publisher, Media-Companies und Brands auf den ein oder anderen Anbieter (ID+, NetId, Axion und Co.) setzen, um weiterhin im Advertising handlungsfähig zu bleiben, könnte das ebenfalls eine Perspektive sein.

5. Bonus: Beispiele für DSGVO-konforme Cookie Banner, die eine hohe Acceptance Rate versprechen

Zu guter Letzt möchte ich dir gerne – weil du es bis zum Ende des Artikels geschafft hast – noch ein paar Beispiele als Inspiration mitgeben, wie man TTDSG, DSGVO, EuGh konforme Cookie Banner bauen kann, die eine hohe Acceptance Rate versprechen.

Du hast noch weitere Mythen und Irrtümer im Zusammenhang mit Cookie Consent erlebt oder andere Erfahrungen gemacht?

Ich freue mich auf dein Feedback hier im Blog, als PN oder im Rahmen unserer Growth Ambassador Community auf LinkedIn oder Slack. Mehr Infos zur Community findest du übrigens hier.