Zum Hauptinhalt springen
Im Benutzerhandbuch finden Sie Anweisungen zur Einrichtung der Einwilligungsverwaltungsrichtlinie bei der Verwendung von Kameleoon in Ihrer Web-App.
Kameleoon bietet native eingebaute Integrationen mit Einwilligungsverwaltungsplattformen.

Einwilligungsrichtlinien

Für einen bestimmten Besucher wird die rechtliche Einwilligung zur Nutzung von Kameleoon entweder als erteilt, verweigert oder unbekannt betrachtet (ein spezieller Status, der verwendet wird, wenn die Einwilligung nicht definiert ist, da der Besucher sie weder erteilt noch verweigert hat). Zunächst sollten Sie wählen, wie Kameleoon die rechtliche Einwilligung behandelt:
  • Einwilligung nicht erforderlich: Mit dieser Richtlinie ist die Einwilligung für diese Website und dieses Modul nicht ausdrücklich erforderlich. Kameleoon geht davon aus, dass sie automatisch erteilt wird, und startet sofort im voll funktionsfähigen Modus.
  • Einwilligung erforderlich: Mit dieser Richtlinie muss die Einwilligung ausdrücklich vom Besucher eingeholt werden. Bis sie erteilt wird, gilt die rechtliche Einwilligung als „unbekannt”, und Kameleoon arbeitet nicht normal.
Um Kameleoon zu informieren, wenn die rechtliche Einwilligung eingeholt wurde, müssen Sie entweder die Methode der Kameleoon Activation API verwenden, was die Implementierung von benutzerdefiniertem JS-Code erfordert, oder eines der SDKs, wenn Sie Feature Flags ausführen. Weitere Informationen zu diesem Thema finden Sie im Benutzerhandbuch.
Um alle möglichen Anwendungsfälle abzudecken, kann das Verhalten von Kameleoon Web Experimentation weiter angepasst werden, wenn die Einwilligung als unbekannt gilt oder vom Benutzer verweigert wird. Um mehr über die verfügbaren Optionen zu erfahren, lesen Sie den Artikel zum Verhalten, wenn die Einwilligung unbekannt ist.

Lesen des aktuellen Einwilligungsstatus für einen Besucher

Dieser Abschnitt gilt nur für die Kameleoon Web Experimentation-Lösung.
Um den aktuellen rechtlichen Einwilligungsstatus für einen Besucher zu ermitteln (lesen), verwenden Sie das Objekt Kameleoon.API.Visitor:
  • Kameleoon.API.Visitor.experimentLegalConsent: gibt true, false oder null zurück, wenn der Status unbekannt ist (Einwilligung ist erforderlich, wurde aber noch nicht erteilt oder verweigert).
  • Kameleoon.API.Visitor.personalizationLegalConsent: gibt true, false oder null zurück, wenn der Status unbekannt ist (Einwilligung ist erforderlich, wurde aber noch nicht erteilt oder verweigert).
Während die Methoden Kameleoon.API.Core.enableLegalConsent() und Kameleoon.API.Core.disableLegalConsent() es Ihnen ermöglichen, den Status der rechtlichen Einwilligung für diesen Besucher zu ändern (schreiben), wird der aktuelle Status über Kameleoon.API.Visitor ermittelt (gelesen).
Wenn Sie eine Richtlinie „Einwilligung nicht erforderlich” gewählt haben, kann die rechtliche Einwilligung niemals in einem unbekannten Zustand sein. Kameleoon.API.Visitor.experimentLegalConsent oder Kameleoon.API.Visitor.personalizationLegalConsent geben standardmäßig immer true zurück und werden nur auf false gesetzt, wenn die Methode Kameleoon.API.Core.disableLegalConsent() aufgerufen wird.

Betriebsmodi für die Kameleoon Web Experimentation Engine

Dieser Abschnitt gilt nur für die Kameleoon Web Experimentation-Lösung.
Die Engine von Kameleoon arbeitet je nach Betriebsmodus unterschiedlich. Um den Betriebsmodus zu bestimmen, berücksichtigt Kameleoon den aktuellen Einwilligungswert in Kameleoon.API.Visitor.experimentLegalConsent und Kameleoon.API.Visitor.personalizationLegalConsent. Wenn der Wert null (unbekannter Status) oder false ist, berücksichtigt Kameleoon den entsprechenden Konfigurationswert in den Projekteinstellungen für Verhalten, wenn die Einwilligung unbekannt ist oder Verhalten bei Opt-out. Der folgende Abschnitt beschreibt alle möglichen Modi für die Engine:

Aktiver Modus

Dies ist der normale Betriebsmodus. Kameleoon sendet Daten an Tracking-Server und schreibt bei Bedarf Daten auf das Gerät. Der Besucher hat vermutlich der Nutzung von Kameleoon zugestimmt. Dieser Modus ist betriebsbereit, wenn Kameleoon.API.Visitor.experimentLegalConsent oder Kameleoon.API.Visitor.personalizationLegalConsent true ist.

Deaktivierter Modus

In diesem Modus tut Kameleoon überhaupt nichts – Daten werden weder an Remote-Server gesendet noch auf das lokale Gerät geschrieben. Experimente und Personalisierungen werden niemals angezeigt. Für alle Zwecke ist es so, als ob Kameleoon für diesen bestimmten Besucher nicht existierte. Dieser Modus ist betriebsbereit, wenn:
  • Kameleoon.API.Visitor.experimentLegalConsent oder Kameleoon.API.Visitor.personalizationLegalConsent null ist und Sie die Option „Kameleoon vollständig blockieren” gewählt haben, wenn die Einwilligung unbekannt ist.
  • Kameleoon.API.Visitor.experimentLegalConsent oder Kameleoon.API.Visitor.personalizationLegalConsent false ist und der Kunde „Kameleoon vollständig blockieren” für das Opt-out-Verhalten gewählt hat.

Verzögerter Modus

In diesem Modus sendet Kameleoon keine Daten an Tracking-Server und schreibt keine Daten auf das Gerät. Es zeigt jedoch weiterhin normal Experimente (oder Personalisierungen) an, wenn der Besucher das zugehörige Segment auslöst. Darüber hinaus werden alle Daten, die geschrieben oder an einen Remote-Server gesendet werden sollten, im Speicher gehalten. Wenn Kameleoon später in den aktiven Modus wechselt (in der Regel, weil die Einwilligung zu einem bestimmten Zeitpunkt erteilt wird), werden alle bisher gesammelten Daten (im Kontext dieser Seite) auf einmal geschrieben und gesendet. Daher der Name „verzögert”: Wenn die vollständige Einwilligung irgendwann eingeholt wird, ist das Endergebnis, dass sich Kameleoon fast wie im aktiven Modus verhalten hat. Dieser Modus ist betriebsbereit, wenn Kameleoon.API.Visitor.experimentLegalConsent / Kameleoon.API.Visitor.personalizationLegalConsent null ist und Sie die Option „Kameleoon nicht blockieren” gewählt haben, wenn die Einwilligung unbekannt ist.

Eingeschränkter Modus

In diesem Modus sendet Kameleoon keine Daten an Tracking-Server und schreibt keine Daten auf das Gerät. Es zeigt jedoch weiterhin Experimente (oder Personalisierungen) an, die in Kameleoon mit dem Tag „Technical” markiert wurden. Alle anderen Experimente/Personalisierungen werden nicht angezeigt. Dies ist ein sehr nützlicher Modus, der es ermöglicht, die meisten Kameleoon-Operationen zu deaktivieren, wenn ein Besucher seine Einwilligung nicht erteilen möchte, der es aber dennoch ermöglicht, kritische Experimente und Personalisierungen für diesen Besucher auszuführen. Sehr häufig wird Kameleoon als schnelle Lösung für die Bereitstellung von Bugfixes und kleinen Verbesserungen in der Produktion verwendet. In diesem speziellen Kontext gelten Datenschutzvorschriften wie die DSGVO ausdrücklich nicht, und Kameleoon kann für solche Anwendungsfälle ohne Einwilligung verwendet werden. Der eingeschränkte Modus entspricht dem verzögerten Modus, ist aber restriktiver. Da er als Ergebnis einer endgültigen rechtlichen Einwilligungsentscheidung (einer Ablehnung) gewählt werden kann, wird erwartet, dass in diesem Fall wahrscheinlich nie Daten geschrieben oder gesendet werden (während der verzögerte Modus normalerweise nur ein „Übergangsmodus” ist). Dieser Modus ist betriebsbereit, wenn:
  • Kameleoon.API.Visitor.experimentLegalConsent oder Kameleoon.API.Visitor.personalizationLegalConsent null ist und Sie die Option „Kameleoon teilweise blockieren” gewählt haben, wenn die Einwilligung unbekannt ist.
  • Kameleoon.API.Visitor.experimentLegalConsent oder Kameleoon.API.Visitor.personalizationLegalConsent false ist und Sie die Option „Kameleoon teilweise blockieren” für das Opt-out-Verhalten gewählt haben.
Es ist durchaus möglich, dass Kameleoon unterschiedliche Betriebsmodi für AB-Experimente und Personalisierungen hat. In diesem Fall funktioniert alles wie erwartet. Zum Beispiel werden Experimente angezeigt und Tracking-Daten gesammelt, aber für Personalisierungen passiert nichts.

Erweiterte Überlegungen

Die Entscheidung, eine explizite Einwilligungsrichtlinie im Kontext von AB-Tests zu implementieren, führt in der Regel zu komplexen Problemen, und es gibt keine ideale Lösung. Die beiden Hauptprobleme werden hier beschrieben. Das Erste, was zu beachten ist, ist, dass wenn Sie ein striktes Verhalten (deaktivierter Modus) wählen, während die Einwilligung unbekannt ist, Experimente/Personalisierungen im Kontext des ersten Seitenaufrufs eines völlig neuen Besuchers „spät” ausgelöst werden. Mit dieser Einrichtung können sie tatsächlich erst angezeigt werden, nachdem die rechtliche Einwilligung erteilt wurde, was in der Regel nach einigen Sekunden der Fall ist. Dies kann leider je nach den zugrunde liegenden Experimenten und Personalisierungen zu ernsthaften UX-Problemen führen und sollte berücksichtigt werden. Der verzögerte Modus kann dieses Problem entschärfen, da die Anzeige sofort erfolgt und nur das Schreiben verzögert wird. Es gibt jedoch ein zweites Problem, das auftritt, wenn ein Besucher über mehrere Seiten hinweg mit einem unbekannten rechtlichen Einwilligungsstatus „verweilt”. Da Kameleoon keine Daten auf das Gerät schreibt, nicht einmal den Kameleoon-visitorCode-Identifikator, wird dieser auf jeder Seite zufällig (neu) generiert, solange die endgültige Einwilligung nicht festgelegt ist. Dies bedeutet, dass für Experimente die Variationszuteilung bei jedem neuen Seitenaufruf erfolgt und keine Konsistenz in diesen Zuteilungen gewährleistet ist. Es ist daher wichtig, Maßnahmen zu ergreifen, um zu verhindern, dass diese Situation eintritt. Mehrere Optionen sind möglich (blockierendes Einwilligungsbanner, automatische Ablehnung der Einwilligung nach X Sekunden…), aber ein Besucher sollte niemals dauerhaft im Status unbekannter rechtlicher Einwilligung verbleiben. Entweder wird die Einwilligung erteilt oder verweigert.
Aus demselben technischen Grund (permanente Variationsneuzuteilung) wird erwartet, dass, wenn der eingeschränkte Modus für das Opt-out-Verhalten gewählt wird, nur Personalisierungen oder Experimente mit einer 100 %-Traffic-Abweichung zu einer Variation mit dem Tag „Technical” markiert werden. Andernfalls kann das Navigationserlebnis der Benutzer, die abgelehnt haben, erheblich beeinträchtigt werden, da sie in derselben Sitzung mehreren verschiedenen Variationen ausgesetzt sein könnten.