Die Cookies und die DSGVO (2020)

01

Tag Manager richtig konfigurieren

Tag Manager (z.B. der Google Tag Manager oder der Matomo Tag Manager) erfreuen sich großer Beliebtheit bei Website-Verantwortlichen. Ihr Vorteil liegt auf der Hand: Website-Verantwortliche und Marketingteams benötigen nur anfänglich die Unterstützung eines Webentwicklers, um den Tag Manager auf der Website zu installieren. Danach können über den Tag Manager – weitgehend ohne Programmierkenntnisse – andere Dienste wie ein Webanalyse-Tool oder das Conversion-Tracking differenziert eingebunden werden.

Tag Manager müssen aber, wie alle Tools, die in eine Website integriert sind, DSGVO-konform verwendet werden. In der Praxis treffen wir immer wieder auf Konfigurationen, die dies nicht gewährleisten. Der Grund dafür liegt zumeist darin, dass die Funktionsweise des Tag Managers nicht in allen Konsequenzen berücksichtigt und verstanden wurde.

Ein auf einer Website implementierter Tag Manager verhält er sich wie ein kontinuierlicher Beobachter der Website. Dies wird technisch über JavaScript-Listener-Funktionen realisiert, die auf bestimmte Events lauschen. Dies können Custom-Events sein, die im Tag-Manager explizit in einem benutzerdefinierten Trigger (beim Matomo Tag Manager auch Impuls genannt) angelegt und mit einem individuellen Event-Namen ausgestattet werden. In der Regel werden jedoch Standard-Events des DOM (Domain Object Model) verwendet, von denen einige im Tag Manager bereits komfortabel in einer Reihe verfügbarer Trigger-Typen vorangelegt sind. Vielverwendete Vertreter dieser Standard-Events sind beispielsweise click (wird nach einem Klick auf ein Element ausgelöst) oder load (wird ausgelöst, sobald eine Ressource und die von ihr abhängigen Ressourcen geladen sind).

Gerade die vorangelegten Event-Trigger machen Tag Manager so praktisch, weil der Anwender kein Programmierwissen benötigt, um sie zu nutzen. Sie werden in der Regel mit ebenfalls vorangelegten Tag Typen verwendet, um weitere Tools (z.B. Google Analytics oder die Tracking Schnittstellen von Werbeplattformen) mit Informationen über ausgelöste Events zu versorgen.

Ist ein Tag Manager einmal auf einer Website installiert, werden die genutzten Trigger oft automatisch beim entsprechenden Event ausgeführt und die mit ihnen verbunden Tags gefeuert. Hier liegt der Hase im Pfeffer. Stellen Sie sich folgende typische Konfiguration eines Cookie-Consent-Tools mit derzeit üblichen Cookie-Gruppen (Notwendige Cookies, Statistik-Cookies und Marketing-Cookies) vor:

• Der Tag Manager wird unter Statistik-Cookies angegordnet.
• Cookies für das Werbe-Tracking werden unter Marketing-Cookies einsortiert.
• Der User erlaubt Statistik-Cookies (also auch die Installation des Tag-Managers).
• Aber er verweigert seine Zustimmung zu Marketing-Cookies.

In dieser Konstellation werden Trigger und Tags, die Marketing-Tools mit Daten versorgen automatisch ausgelöst. Es sei denn, sie sind mit einer Bedingung gesichert, die dafür sorgt, dass das fehlende Opt-in des Users für Marketing-Tools auch im Tag Manager berücksichtigt wird. Ansonsten hat der User nur den falschen Eindruck, den Datenfluss an die Marketing-Tools unterbunden zu haben, obwohl weiterhin Daten über den Tag Manager geliefert werden.

Fazit:

Bei den komfortablen Möglichkeiten eines Tag Managers, vorangelegte Trigger- und Tag-Typen zu nutzen, um weitere Tools mit Daten zu versorgen, ist Vorsicht geboten. Die Verwender eines Tag Managers sollten sich mit den durch ihn gegebenen Möglichkeiten des Bedingungsmanagement im Detail auseinandersetzen. Über entsprechende Bedingungen muss sichergestellt werden, dass die Trigger und Tags für die verschiedenen über den Tag-Manager versorgten Tracking-Tools nur dann ausgelöst werden, wenn der User im Cookie-Consent-Dialog seine Zustimmung für diese Tools auch tatsächlich erteilt hat.

02

Cookies nach Opt-out löschen

Ein Opt-out liegt vor, wenn der User sein zuvor gegebenes Einverständnis für die Verwendung bestimmter Cookies widerruf. Folgende Prozess-Schritte sind dafür typisch:

• Aufruf der Website: Der User ruft eine Website im Browser auf und der Cookie-Consent-Dialog erscheint.
• Opt-in: Der User gibt sein Einverständnis für die Verwendung bestimmter Cookies.
• Cookies: Die erlaubten Tools werden integriert, ihre entsprechenden Cookies werden gesetzt.
• Opt-out: Zu späterem Zeitpunkt ruft der User den Cookie-Consent-Dialog nochmals auf und widerruft sein zuvor gegebenes Einverständnis.

Viele der derzeit im Markt verwendeten Cookie-Consent-Lösungen sehen bei einem Opt-out lediglich vor, dass ein bestimmtes JavaScript Code-Snippet (welches der Installation eines Tools oder der Datenübermittlung dient) nicht mehr ausgeführt wird. Sie sorgen aber nicht unbedingt dafür, dass die zuvor gesetzten Cookies auch wieder gelöscht werden. Das kann dazu führen, dass dem betroffenen User später immer noch Nutzungsdaten über die nicht gelöschten Cookies zugeordnet werden. Je nach Browser und Browserkonfiguration kann dies etwa der Fall sein, wenn die Cookies in einem Third-Party-Kontext mitgesendet werden, also dann, wenn sich der User auf anderen Websites bewegt, die ebenfalls Ressourcen (z.B. Tracking-Pixel oder Skripte) von der Domain laden, die den Third-Party-Cookie gesetzt hat. Und zwar obwohl der User zuvor die Opt-out Funktion genutzt hat.

Wir gehen daher davon aus, dass es für eine datenschutz-konforme derzeit notwendig ist, die zuvor gesetzten Cookies bei einem Opt-out wieder zu löschen. Insofern es sich um Cookies handelt, deren HttpOnly-Attribut nicht aktiviert (also auf false gesetzt) ist, kann dieser Schritt über entsprechende auf der eigenen Website implementierte JavaScript-Funktionen ausgeführt werden.

Handelt es sich jedoch um einen Third-Party-Cookie, dessen HttpOnly-Attribut aktiviert (also auf true gesetzt) ist, kann der Cookie nur nur über einen Mechanismus auf dem Server der Third Party gelöscht werden, die ihn ursprünglich gesetzt hat. (Oder natürlich über die Löschfunktionen des Browsers, auf die der User Zugriff hat, aber nicht der Website-Betreiber.) Hier muss also die Opt-out-Funktion des Tool-Anbieters genutzt werden, um diese Art von Cookies wieder loszuwerden. Sieht der Tool-Anbieter diesen umfassenden Opt-out nicht vor, bleiben nur zwei Möglichkeiten: Entweder man verzichtet auf das Tool oder aber man weist den User darauf hin, dass er den Cookie über den Browser selbst entfernen kann bzw. sollte. Ob letzteres eine rechtssichere Lösung darstellt, sollte im Einzelfall mit einem Anwalt besprochen werden.

Fazit:

Gesetzte Cookies sollten unserer Meinung nach beim einem Opt-out nach Möglichkeit wieder gelöscht werden. Cookie-Consent-Tools, die diese Funktion nicht vorsehen, sollten ergänzt oder durch andere Lösungen ersetzt werden.

03

Direkte Auswahl der Cookie-Gruppen

Derzeit kommt ein bestimmtes Design bei Cookie-Consent-Dialogen vermehrt zum Einsatz, dass Sie sicher schon einmal gesehen haben. Dabei bietet das Cookie-Consent-Tool bereits auf der ersten Ebene, also ohne weiteren Klick des Users, die Möglichkeit an, bestimmte Cookie-Gruppen (z.B. per Checkbox) anzuwählen. Unten sieht man dann in der Regel mindestens zwei Buttons: Erstens „Auswahl speichern“ und zweitens „Alle akzeptieren“, manchmal ergänzt durch einen dritten Link oder Button „Nur Notwendige“, womit gemeint ist, dass nur die technisch notwendigen Cookies erlaubt werden.

Mit einem Klick auf einen weiteren Link – typischerweise „Details“ oder „Einstellungen“ benannt – kann man mehr über die Cookies und Tools erfahren, für die um Erlaubnis gefragt wird. Dieses etwas transparentere Design verdrängt zunehmend die zuvor gängige Lösung, in der man die Cookie-Gruppen erst nach diesem Klick auf „Details“ oder „Einstellungen“ gesehen hat und dort auch erst deaktivieren konnte. In dieser älteren Design-Variante war außerdem der Zustimmungsbutton oft mit einem allgemeineren „OK“ oder „Ich stimme zu“ beschriftet.

Wir haben bisher keine wirklich klare Antwort darauf erhalten, ob die neue transparentere Variante rechtlich unbedingt notwendig ist. Wer sich mit auf den Datenschutz spezialisierten Anwälten austauscht, wird höchstwahrscheinlich bereits einmal mit den Begriffen der „Risikoabwägung und „individuelle Sachlage konfrontiert worden sein. Man muss eben immer schauen, um welche Tools und Daten es sich handelt. Mit der transparenteren Lösung ist man dabei aber schon einmal eher auf der sicheren Seite als mit der intransparenteren. Dem User gegenüber fairer ist sie allemal. Unsere Statistiken zeigen, dass oftmals dennoch genügend User zustimmen, um aussagekräftiges Tracking zu ermöglichen.

Fazit:

Transparente Cookie-Consent-Dialoge können unserer Einschätzung nach rechtliche Risiken vermindern. Sie erhöhen außerdem die Fairness gegenüber dem User. Aussagekräftiges Tracking ist auch mit ihnen möglich.

04

Keine Vorauswahl nicht notwendiger Cookies

Worüber hingegen nach unserem Eindruck weitgehend Konsens herrscht: Die nicht-notwendigen Cookie-Gruppen sollten nicht vorausgewählt sein. So jedenfalls werden die entsprechende Entscheidung des Europäische Gerichtshofs (EuGH) vom 1. Oktober 2019 und das anschließende Urteil des Bundesgerichtshofs (BGH) 28.5.2020 oft interpretiert.

Fazit:

Besser keine anderen Cookie-Gruppen als die notwendigen Cookies vorauswählen.