OneTrust Cookie Consent – eine kommerzielle DSGVO Consent-Lösung

Die Cookie-Consent-Lösung von OneTrust ist eine kostenpflichtige Software. Die Lizenz kann auf monatlicher oder jährlicher Basis erworben werden. Sie kostet pro Domain, unabhängig von der Unternehmensgröße 45 EUR / Monat. Die OneTrust Cookie-Lösung wird in der EU gehostet. 

OneTrust bietet in dieser Software-Lösung laut Hersteller folgende Merkmale an: 

• Unbegrenzte Anzahl von Subdomains und Seiten
• Unbegrenzte Einwilligungs-Aufzeichnungen
• Automatisiertes Website-Scanning
• Cookie-Kategorisierung basierend auf Cookiepedia (eigene Cookie-Datenbank von OneTrust, in der alle über das Tool erfassten Cookies aufgelistet und kategorisiert sind)
• Anpassbare Banner und Voreinstellungen des Präferenz-Centers
• Konfigurierbare Einwilligungs-Modelle
• Vorherige Einwilligung und Do Not Track
• Automatische Spracherkennung
• Dynamisches Cookie-Listen-Skript
• Integration mit CMSs, Website-Buildern, Tag-Managern
• Erweitertes Scannen (hinter Login- und Abfrageparametern)
• Mehrseitige Vorlagen
• Geo-Targeting nach Ländern
• Domänenübergreifende Einwilligung
• IAB Europe TCF Support
• Lokale JavaScript Hosting Option
• Mehrere Sprachen
• Branding "Powered by OneTrust" entfernen

Die Vorteile der Consent-Cookie-Lösung von OneTrust.

Die gesetzlichen Vorgaben müssen zwingend erfüllt werden. Teilweise stehen auch nicht die technischen Möglichkeiten zur Verfügung, den Entwicklungsaufwand umzusetzen. Ein weiterer Vorteil der  Cookie-Consent-Lösung von OneTrust ist die Möglichkeit, ohne Deployment das Cookie Layer einzubinden. Dies setzt jedoch ein Tag Management voraus.

OneTrust bietet nicht nur eine europäische Lösung an, sondern auch Consent-Lösungen analog zu den jeweiligen Ländern. Dies ist hilfreich bei einer internationalen Ausrichtung. 

Custom-Lösung versus kommerzieller Lösung.

Die Vorteile einer individuell erstellten Cookie-Lösung sind generell diese:

• Keine laufenden Lizenzkosten,
• Individuelle technische Lösungen ermöglichen spezielle Einbindungen,
• Design / UX kann ganz genau dem Corporate Design entsprechen.

Der Nachteil sind primär die hohen initialen Entwicklungskosten. 

Dem gegenüber stehen diese Vorteile der kommerziellen Consent Lösung:

• Rasch umgesetzt und
• niedrige Initialkosten.

Jedoch fallen bei der kommerziellen Lösung konstante Lizenzkosten an. Diese fällt bei OneTrust pro Domain an. Der Look and Feel sollte übernommen werden und entspricht meist nicht dem Corporate Design der Website. 

Grundsätzlich müssen vor der Einbindung diese Punkte geklärt und definiert sein:

• Die Cookies der Domain müssen mittels Cookie-Scan erfasst werden. 
• Die UX / das Design muss geklärt sein.
• Spezielle Einbindungen von Cookies wie bspw. Iframe muss analysiert werden.
• Es sollte geklärt werden, ob manuelles oder automatisches Cookie Blocking erfolgen soll.

Dazu müssen die rechtlichen Anforderungen geklärt sein, wie 

• die Cookie-Kategorien (streng notwendig, Marketing, Targeting, Leistung, ...),
• das Einverständnis-Modell (OptIn / AlwaysOn) pro Cookie-Kategorie,
• die Erstellung der Texte für die Cookie-Banner, das Preference Center, etc.

Es gibt drei Möglichkeiten, die Lösung einzubinden:

• Tag Management System,
• CMS und
• direkt in den Code der Seite.

Wir möchten mit Euch die Einbindung mittels des Tag Managements teilen. 

Verwendet wurde Google Tag Manager. 

Generell gibt es die Möglichkeit, die Software testweise auf einem Entwicklungssystem einzubinden. Leider gibt es hier zwei Nachteile. Ein Nachteil ist, dass die Dokumentation erst verfügbar ist, wenn die Lizenz bereits erworben wurde. Man kann also nicht wirklich fundiert die Cookie-Consent-Lösung von OneTrust einbinden, sondern muss den öffentlich zugänglichen Quellen vertrauen. Im Web gibt es einige Anleitungen, aber die meisten Implementierungs-Empfehlungen sind nicht konform der empfohlenen OneTrust-Einbindung. 

Zudem muss man alle Einstellungen nach dem Kauf der Lizenz noch einmal machen, da die Test-Einstellungen nicht in die lizenzierte Lösung übernommen werden können. 

OneTrust scannt zunächst die Seite hinsichtlich der verwendeten Cookies. Die Cookies können in der OneTrust Cookie Library „Cookiepedia“ eingesehen werden.

Dort werden sie – falls bekannt – nach Verwendungszweck aufgeführt und eine Erklärung geboten, was für Daten das Cookie beinhaltet. Es wird ebenso aufgelistet, auf welchen Seiten das jeweilige Cookie noch verwendet wird.  

OneTrust ordnet die bekannten Cookies (Auto Scan) automatisch ein oder bietet an, eine manuelle Einordnung der Cookies vorzunehmen.

Auto-Blocking Funktionalität.

Die Auto-Block-Funktion klingt zunächst elegant. Nach dem Scan der Cookies auf der angegebenen Domain ordnet OneTrust die Cookies vorausgewählten Kategorien zu und blockt diese entsprechend.

Gemäß unserer Erfahrung wird jedoch durch die Einbindung des Autoblock Scripts das Ladeverhalten der Seite langsam. Das Autoblock-Script ist größer als 600 kb.

Ein weiterer Gesichtspunkt ist, dass Auto-Block nur die Cookies blockiert, die vom Crawler gefunden werden. Das ist insofern wichtig, als der OneTrust Crawler nur  auf passwortgeschützte Testsysteme, die mit normalen Formular-Logins geschützt sind, kommt. Der Crawler kommt nicht auf Seiten, deren Login in Basic Auth umgesetzt ist. Das Testen der Cookies auf Testsystemen ist dann möglich, wenn der Crawler die Seite vorher scannen konnte. Wird die Consent-Lösung auf Produktivsystemen live geschaltet, kann es sein, dass Module des Produktivsystems mit dem OT Consent Banner eine Wechselwirkung haben. Das OT Auto-block Script blockiert dann auch Cookies, die für eine essentielle Funktionalität der Website notwendig sind (Suchfunktion). Man muss also gewährleisten, dass man bei der Einbindung des Auto-block Scripts immer alle Cookies des Produktivsystems testet und nicht nur einen kleinen Teil davon. 

Man kann die Zuordnung auch manuell in die vorgesehenen Kategorien vornehmen. 

Meist werden drei Cookie Kategorien verwendet:

• Technisch notwendige Cookies,
• Cookies zu statistischen Zwecken und
• Cookies für Marketingzwecke.

Sämtliche Texte im Consent Banner oder im Preference Center können in mehreren Sprachen gepflegt und ausgegeben werden. Standardmäßig wird dabei die Spracheinstellung im Browser des Besuchers berücksichtigt. Es ist aber auch möglich, die Ausgabesprache des Consent Banners an jene der Website zu koppeln. Je nach Sprache sind die Texte bereits durch OneTrust vorgefertigt oder müssen durch den Website-Betreiber definiert werden.

Um das Setup zu testen, kann ein Test Script eingebunden werden. Dieses unterscheidet sich vom Produktivscript formal nur durch einen minimalen Zusatz (“-test”) nach der Lizenznummer im Script. Der Vorteil des Testscripts ist, dass die Änderungen sofort zu sehen sind. Die Produktivscripts  brauchen bis zu vier Stunden bis Anpassungen publiziert sind, da die Scripte auf den Produktivservern geändert werden müssen, was in der Cloud etwas länger dauern kann.  Der Grund dafür ist, dass die Daten im CDN gecached sind.

Leider ist das Testscript fehleranfällig. Die Anpassungen sind zwar zu sehen, aber andere Effekte treten auf wie beispielsweise die fehlende Abdeckung der Seite mit einem transparenten Hintergrund. Nach einer unterschiedlich langen Wartezeit war dieser Fehler wieder behoben.

Das Script wird per Tag auf der Seite integriert und lädt das OneTrust Script. Das Tag Management System ist immer aktiv, aber lädt vor Einwilligung durch den Nutzer keine Tags. Wenn der Nutzer für bestimmte Cookie-Kategorien seine Einwilligung gibt, speichert OneTrust die Consent-Einstellungen des Users. Ein Custom Event wird gepusht. Das Tag Management System hört auf das Custom Event und fragt hier den Consent des Users ab. Die für die bestätigte Cookie-Kategorie freizugebenden Tags werden aktiviert. 

Relevant hierbei ist, die Trigger für den allgemeinen PageView Tag anzupassen, so dass dieser nicht vor der Bestätigung durch den Nutzer feuert. Da die Cookies, die die gewählte Cookie-Kategorie durch den Nutzer anzeigen in der Ladereihenfolge nach dem PageView geladen werden, muss der Trigger entsprechend angepasst werden.

Alle anderen Tags müssen entweder durch ein aktives Setzen der Cookie-Kategorie feuern oder durch einen Ausschluss. Das heißt, bei der ersten Variante feuert ein Tag nur, wenn eine bestimmte Cookie-Kategorie ausgewählt ist. Beim Ausschluss feuert der Tag nur, wenn eine Cookie-Kategorie nicht vorhanden ist.

Wird ein Cookie in einem Iframe gesetzt, kann dieses nicht per Tag Management System verhindert werden. Dies ist beispielsweise bei eingebundenen Youtube-Filmen der Fall. 

Um zu verhindern, dass das Iframe geladen wird, wird das Markup angepasst und um OneTrust-spezifische CSS-Klassen ergänzt. Eine Meldung weist den Besucher darauf hin, dass zuerst gewisse Cookie-Kategorien akzeptiert werden müssen, damit das Video geladen werden kann. Ein Klick auf den entsprechenden Link öffnet dazu gleich das Cookie Preference Center.

Der Nutzer soll hier die Möglichkeit bekommen, direkt zur Cookie-Kategorie “Cookies für Marketingzwecke” zu gelangen. Hier kann er das entsprechende Cookie-Level auswählen und den Film sofort ansehen. 

Diese Umsetzung erfordert Frontend-Kapazitäten und UX-Know-How, um eine eindeutige Kommunikation für das Vorgehen der Cookie-Auswahl zu ermöglichen.

Das Tool von OneTrust hat einige Besonderheiten, auf die man achten muss. Man sollte vorab analysieren, in welchen Komponenten welche Cookies verwendet werden. Daraus kann man die Aufwände der jeweiligen Spezialisten ableiten. Man sollte auf jeden Fall genug Zeit zum Testen einplanen. 

Generell benötigt man für die OT Implementierung sicherlich meist auch Tech-Kapazitäten wegen einiger Spezialfälle. Ein Deployment war bisher zudem auch nötig. 

Sie stehen aktuell vor der Herausforderung eine passende Consent-Lösung für Ihr Unternehmen zu evaluieren und umzusetzen? Wir unterstützen Sie gerne dabei!