1. Tag Manager richtig konfigurieren

 

Tag Manager (z.B. der Google Tag Manager oder der Matomo Tag Manager LINKS) 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.

2. 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.

3. 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.

4. 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.

 

5. Nach dem Privacy-Shield-Urteil: Abwarten und ...?

 

Maximilian „Max“ Schrems ist ein österreichischer Jurist, Autor und Datenschutzaktivist, der in den letzten Jahren recht ansehnlichen Erfolg mit einigen Klagen gegen die Datenpraxis großer amerikanischer Tech-Giganten gefeiert hat. Zunächst hatte er die sogenannte Save-Habour-Entscheidung der EU zu Fall gebracht, mit der die Europäische Kommission es europäischen Unternehmen ermöglichen wollte, personenbezogene Daten in Übereinstimmung mit der europäischen Datenschutzrichtlinie in die USA zu übermitteln.

Jetzt hat ein aktuelles Urteil des EuGH vom 16.7.2020 in einer weiteren von Max Schrems angestrebten Klage (welches unter dem Spitznamen Schrems II die Runde macht) auch die Nachfolge-Regelung – den sogenannten Privacy-Shield – gekippt.

Eigentlich, so hört man es derzeit von einigen Datenschützern und Anwälten, ist damit dem Transfer von personenbezogenen Daten in die USA, die rechtliche Grundlage entzogen. Die Nutzung von Tools wie Google Analytics, aber auch das Facebook Tracking, mit denen Daten an amerikanische Server gesendet werden, die natürlich amerikanischem Recht unterliegen, muss daher neu bewertet werden. Einige Rechtsberater sind daher der Meinung, dass diese Tools im Moment streng genommen deaktiviert werden müssten. Schrems nächste Klage läuft bereits und zielt genau auf diesen Punkt: Sie richtet sich gegen 101 europäische Unternehmen, die Google Analytics und/oder Facebook Tracking immer noch einsetzen, obwohl der Privacy Shield dafür keine rechtliche Grundlage mehr bietet.

Wie nun gehen die Datenschutzbeauftragten mit der aktuellen Situation um? Unser Eindruck: eher abwartend. Bei unseren Kunden und den Kunden unserer Partneragenturen nehmen wir derzeit keine Hektik wahr. Ob das angemessen ist, wird sich mit der Entscheidung in Schrems aktueller Klage zeigen. Die meisten Fachleute gehen derzeit offenbar davon aus, dass Google, Facebook und andere betroffene Player schnell eine rechtssichere Lösung finden werden. Eine häufig geäußerte Vermutung geht in die Richtung, dass die Konzerne auf rechtssicherem Wege Server in der EU betreiben werden und daher der Datentransfer in die USA entfällt. Bleibt abzuwarten, was genau passieren wird.

Kunden, die jetzt schon aktiv werden möchten, empfehlen wir bei der Webanalyse und beim Tag Management von den Google Produkten (Google Analytics und Google Tag Manager) auf das Tool Matomo umzusteigen. Siehe den nächsten Punkt unseres Erfahrungsberichts.

 

Fazit:

Der Privacy Shield bietet keine Rechtsgrundlage mehr für den Datenversand in Drittstaaten außerhalb der EU. Wer derzeit Tools wie Google Analytics und das Facebook Tracking nutzt, nimmt in Kauf, dass personenbezogene und andere Daten unter Umständen ohne rechtliche Grundlage in die USA gesendet werden. Für vorsichtige Kunden kann Matomo eine Alternative sein.

 

6. Mehr Datenschutz mit Matomo

 

Matomo ist ein Webanalyse-Tool, das derzeit noch weit weniger verbreitet als Google Analytics ist, aber sich zunehmender Beliebtheit erfreut. Der Grund hierfür ist denkbar einfach: Matomo kann auf einem eigenen Server gehostet werden. Das bedeutet, dass für die Website-Analyse zunächst einmal keine Daten an Dritte weitergegeben werden müssen. Zumindest für die Analyse der eigenen Website, aber auch für das Tag Management, welches ebenfalls in Matomo integriert ist, sind Website-Betreiber nicht mehr auf eine Privacy-Shield-Regelung wie für die Nutzung von us-amerikanischen Diensten von Google und Co. angewiesen. Die Vorteile von Matomo im Überblick:

  • Detailierte Webanalyse (Feature-Umfang ähnlich Google Analytics)

  • Conversion Tracking
  • Integrierter Tag Manager (vergleichbar dem Google Tag Manager)
  • Als On-Premise-Version kostenlos verfügbar und auf einem eigenen Server zu hosten (Die Installation ist recht einfach und sollte für einen Webentwickler oder Admin kein größeres Problem darstellen.)
  • Alternativ kann auch eine Cloud-Lösung gegen moderate Gebühr genutzt werden (ebenfalls DSGVO konform möglich)
  • Einfaches Setup pro Website

 

Fazit:

Matomo hat sich als leistungsfähige und datenschutzfreundliche  Alternative zu Google Analytics etabliert.