In den letzten Wochen habe ich mich umfassend mit dem schwierigen (und zugegebenermaßen bei mir zunächst auch eher ungeliebten) Thema des DSGVO-konformen Sitecore-Trackings befasst. 

Dabei ging es mir zunächst darum Sitecore-unabhängig zu verstehen, was erforderlich ist, um DSGVO-konform zu tracken, um das Erlernte dann auf Sitecore anzuwenden. Mit diesem ersten von zwei Blogartikeln möchte ich euch gerne auf meine Reise mitnehmen, um dem ein oder anderen von euch das Thema vielleicht schneller zugänglich zu machen.

Was ich lernen musste: Ich bekomme auf viele Fragen keine wirklich zufriedenstellende Antwort. Der Graubereich oder, positiv formuliert, “Spielraum” scheint groß. Es gibt viele Paragraphen, deren Auslegung ist aber häufig aufgrund fehlender Urteile noch nicht eindeutig geklärt. 

Als kleine Vorwarnung: Das führt natürlich dazu, dass es auch nicht DIE EINE technische Lösung gibt.

Disclaimer

Cookie-Consent

Etwas Theorie vorab: Bei der Entscheidung ob die Zustimmung eines Besuchers zu einem Cookie erforderlich ist, ist zunächst mal zu unterscheiden, ob ein Cookie technisch erforderlich ist oder nicht. Selbst wenn ein Cookie nicht zwingend technisch erforderlich ist, so kann er aber ggf. trotzdem im Projekt vom Kunden als erforderlich eingestuft und begründet werden. Zur Fragestellung ob ein Cookie erforderlich ist oder nicht, hat mir persönlich dieser Artikel  der Rechtsanwaltskanzlei Hiddemann ganz gut gefallen.

Geklärt scheint mir im Moment, dass die Zustimmung für nicht erforderliche Cookies explizit erfolgen muss (Stichwort Opt-In vs. Opt-Out). Ein Artikel dazu für uns Nicht-Juristen findet ihr hier beim Datenschutz-Guru. Bewährt hat sich hier der Einsatz sog. Consent Management Plattformen (CMP), in unserem Fall ist das dann häufig unser Partner Usercentrics. 

Sitecore-Cookies

Was heißt das für die Cookies in Sitecore-Projekten? 

Aber was ist jetzt mit dem Sitecore Analytics-Cookie? 

Sitecore Analytics-Cookie

Um den Sitecore Analytics Cookie einzuordnen, gilt es erst einmal zu verstehen, was Sitecore damit trackt und wofür es das tut:

Was wird getrackt?

Sitecore selbst schreibt dazu in der Doku:

“Web Tracker automatically collects metadata each time the visitor interacts with a channel such as a website, an app or an email exchange. The metadata includes explicit information about the visitor and visit such as the day of the week, time of day, the pages visited, the visitor’s IP address, their device and browser identification.”

Zwei Punkte fallen mir hier spontan hinsichtlich des Schutzes personenbezogener Daten (gemäß Begriffsbestimmungen in DSGV Art. 4/1) auf:

1. “Information about the visitor”: Welche Informationen des Besuchers entgegengenommen und weiterverarbeitet werden, hat der Kunde bzw. Implementierungspartner selbst in der Hand. Es gibt in Sitecore Forms keine standardisierte Submit-Action welche Daten aus Formularen am Tracker (und letztlich in der Analytics Datenbank) persistiert. 
2. „IP address”: Bezüglich der IP-Adresse kann ich schon mal vorweg nehmen, die kann konfigurativ genullt oder gehashed werden. 

Folglich sieht es für mich so aus, als dass man im Projekt sicherstellen kann, dass der Sitecore-Tracker anonym trackt und nicht ungewollt personenbezogene Daten verarbeitet.

Wofür werden die Tracking-Daten genutzt?

Analytics 

Zum einen stehen umfangreiche Sitecore Analytics-Tools zur Verfügung, zwecks Analyse und Auswertung des Surfverhaltens der Besucher im Allgemeinen. Ein Einstieg in das Thema aus Marketing-Sicht gibt Sitecore hier im Knowledge Center.

Personalisierung

Zum anderen können Inhalte der Webseite auf Basis der Historie (Seitenaufrufe, getriggerte Goals etc.) des Besuchers personalisiert werden. So könnte z.B. ein Teaser auf der Startseite ausgetauscht werden, sofern der Besucher den zuvor angeteaserten Artikel bereits gelesen hat. 

Hinzu kommt die Möglichkeit der Bildung von Besucherprofilen auf Basis der Seitenaufrufe. Das passiert aber nicht ohne explizite Konfiguration der Profile und Pattern Cards durch Redakteure in Sitecore. Die Personalisierungs-Features sind zwar vorhanden, der Einsatz im Projekt ist aber optional.

Ist der Sitecore Analytics-Cookie nun erforderlich?

Wenn ihr mich fragt, ganz eindeutig JEIN 😉

Die Entscheidung kann ich euch nicht (pauschal) abnehmen. Denn die Fragen, welche der oben aufgeführten Features im Projekt wofür genutzt werden, und ob diese dann in Summe einem im Sinne des Gesetzes erforderlichen Zweck dienen, kann nur am konkreten Projekt gemeinsam mit dem Kunden geklärt werden.

Beim Thema Sitecore Analytics (anonym) kann man sicherlich in manchen Kundenprojekten ein berechtigtes Interesse (Art. 6 Abs. 1 lit. f der DSGVO) ausarbeiten. Wichtig ist dann aber auch die tatsächliche Nutzung der Tools und der Daten. Die Daten einfach erstmal zu erheben, für den Fall, dass man sie irgendwann mal braucht, passt nicht zum Prinzip der Datensparsamkeit bzw. Datenminimierung (Art. 5 Abs. 1 lit. c der DSGVO).

Ein zu dem Thema passendes Zitat aus dem oben erwähnten Artikel der Kanzlei Hiddemann:

Beim Thema Personalisierung trifft m.E. auf jeden Fall den Begriff des Profilings gemäß Art. 4 Abs. 4 DSGVO zu. Da hätte ich als Laie Sorgen, je nach Anwendungsfall gegen Art. 22 DSGVO  “Automatisierte Entscheidungen im Einzelfall einschließlich Profiling” zu verstoßen.

Konfigurationsmöglichkeiten in Sitecore

Es gibt in Sitecore nicht nur einfach einen Schalter mit dem DAS Sitecore Tracking ausgeschaltet wird, sondern es gibt (etwas vereinfacht dargestellt) zwei Schalter, mit deren Kombination man das Tracking-Verhalten in Sitecore konfigurieren kann:

• Sitecore-Tracking: Das Tracking der Besucher kann aktiviert bzw. deaktiviert werden (Xdb.Tracking.Enabled).
• Sitecore Analytics: Die Persistierung der Tracking-Daten in der xDB (Tracking-Datenbank) kann aktiviert bzw. deaktiviert werden (Xdb.Enabled).

Details zu den Konfigurationsmöglichkeiten und den Auswirkungen der Kombinationen findet ihr hier in der Sitecore Doku.

Damit können m.E. drei in Frage kommende Szenarien konfiguriert werden:

Szenario 1: CMS-Only

Wenn man sowohl das Sitecore-Tracking als auch Sitecore Analytics deaktiviert, ist die Installation auf jeden Fall DSGVO-konform (da lehne ich mal ganz weit aus dem Fenster ;)).

Szenario 2: InSession-Tracking

Wenn Sitecore Analytics deaktiviert und das Sitecore-Tracking aktiviert wird, stehen selbstverständlich die Funktionen und Anwendungen, welche persistierte Tracking-Daten voraussetzen, nicht zur Verfügung. Aber Personalisierung basierend auf der aktuellen Session kann dennoch erfolgen. Welche Feature in diesem Setup insgesamt noch zur Verfügung stehen könnt ihr hier in der Sitecore Doku nachschlagen.

Szenario 3: Session-übergreifende (anonymes) Tracking

Das Sitecore-Tracking und Sitecore Analytics werden aktiviert. Sofern nur anonym getrackt werden soll, ist außerdem konfigurativ sicherzustellen, dass die IP-Adressen der Besucher geschwärzt oder gehashed werden.

Neben der Überprüfung der Szenarien hinsichtlich der DSGVO-Konformität, ist ein Abgleich mit den Kundenanforderungen im Projekt vorzunehmen. Denn insbesondere in den ersten beiden Szenarien geht die “Experience“ (oder ein Großteil) verloren. Das ist also m.E. eher für die meisten Sitecore-Kunden keine sinnvolle Lösung, denn die Lizenz wurde ja zumeist mit großen Erwartungen an die Personalisierungsfunktionen erworben.

UND/ABER

Sämtliche oben genannten Konfigurationen können im Sitecore-Standard nur global für die gesamte Applikation vorgenommen werden. Was in einem echten Projekt aber eigentlich erforderlich ist, ist die Möglichkeit, das Sitecore-Tracking erst im Verlauf der Session eines Besuchers zu aktivieren (oder auch wieder zu deaktivieren), nämlich nach der expliziten Zustimmung des Besuchers zum Tracking. Und das ist die eigentliche Herausforderung, dafür sieht Sitecore OOTB keinen (dokumentierten) Weg vor. 

D.h. sobald in einem Projekt das Session-übergreifende Tracking gewünscht ist und entschieden wurde, dass dafür die Zustimmung durch den Besucher erforderlich ist, dann muss zumindest eine projektspezifische Lösung gefunden werden, um das Tracking des ersten Aufrufs (für den der Besucher die Zustimmung ja noch nicht gegeben haben kann, Stichwort Opt-In) zu verhindern. 

Das könnte man kurzfristig lösen, indem man im IIS (konkret IIS Redirect Module) eine Regel einrichtet, die für den Fall, dass der Consent-Cookie (welcher die Zustimmung zum Analytics-Cookie dauerhaft persistiert) nicht vorhanden ist, auf eine statische Seite im wwwroot verweist, die dann die Zustimmung einholt. Der Nachteil dieser Lösung: ein Besuch der Webseite ohne Zustimmung ist gar nicht mehr möglich.

Die Implementierung einer optimalen Lösung im Sinne des Kunden und Projektes kann natürlich durch einen Sitecore-Partner erfolgen. Auf unseren diesbezüglichen Lösungsansätzen gehe ich dann im nächsten Artikel ein. 

Fazit

Es gibt beim Thema Sitecore Tracking und DSGVO-Konformität nicht die eine richtige Lösung für Sitecore. Natürlich ist gar nicht tracken auf jeden Fall DSGVO-konform und möglichst wenig zu tracken auch immer ein richtiger Rat. Aber es steht auch ein bisschen im Widerspruch zum Ansatz von Sitecore. 

Kunden von Sitecore haben ein Interesse daran, das Maximum an Experience auch ohne/ bzw. vor der Zustimmung zum Tracking durch den Besucher herauszuholen. Letztlich muss das Sitecore-Tracking-Setup im Projekt, mit dem Kunden und dessen zuständigen Datenschutzbeauftragten gemeinsam erarbeitet werden. Aber mit den richtigen Fragen und Know-how im Gepäck ist das eine lösbare Aufgabe, der man sich aber bewusst annehmen muss, idealerweise am Anfang eines Projektes. 

Also lautet auch meine klare Antwort “It depends”. Und trotzdem hoffe ich ein bisschen Licht ins Dunkel gebracht zu haben!

Bleibt gesund 🙂