Optimizely Web Experimentation Cookie-Einwilligungsintegration: A/B-Tests unter der DSGVO im Jahr 2026
Optimizely nimmt in der Einwilligungsdiskussion eine seltsame Position ein. Eine vernünftige Person, die Experimentierwerkzeuge betrachtet, könnte davon ausgehen, dass es sich um eine risikoarme Kategorie handelt — der Test dreht sich darum, welche Schaltflächenfarbe mehr Klicks erzeugt, nicht darum, wer der Besucher ist. Die Realität unter dem Rahmen, den die DSGVO gesetzt hat und den der EDPB seit 2023 aktiv stärkt, ist, dass Experimentieren genau dieselben Verarbeitungskategorien einschließt wie Analysen oder Marketing, sobald die Plattform einen persistenten Identifikator schreibt und experimentelle Varianten daran bindet. Das Optimizely Web Experimentation SDK tut genau das: Es weist einem Besucher eine Variante zu, indem es einen persistenten Identifikator hasht, schreibt die Zuweisung in ein First-Party-Cookie, damit der Besucher sitzungsübergreifend dieselbe Variante sieht, und emittiert Expositions- und Konversionsereignisse, die an diesen Identifikator gebunden sind. Jeder dieser Schritte aktiviert ein Einwilligungstor. Die gute Nachricht ist, dass Optimizely mit einer der durchdachtesten Einwilligungsintegrationen in der Experimentkategorie geliefert wird, einschließlich eines dedizierten Einwilligungsattributs und der Möglichkeit, im reinen Anonymmodus zu arbeiten. Die Arbeit besteht darin, es tatsächlich zu nutzen.
Warum Optimizely Web Experimentation eine Einwilligung erfordert
Eine Standard-Optimizely-Initialisierung erledigt beim ersten Rendern der Seite mehrere Dinge. Sie setzt ein First-Party-Cookie unter optimizelyEndUserId mit dem persistenten Besucher-Identifikator, bewertet den Besucher gegenüber den aktiven Experimenten, schreibt die Variantenzuweisungen in ein zweites Cookie unter den optimizelyOptOut-Namespace-Markierungen, feuert ein Entscheidungsereignis an logx.optimizely.com und wendet die Variantenänderungen auf die gerenderte Seite an. Wenn der Betreiber eine Analyseintegration verbunden hat — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap oder die Optimizely Data Platform — feuert das SDK auch Variantenexpositionsereignisse in die Analyseschicht, die dann die Variante mit dem umfassenderen Analyseprofil des Besuchers verknüpft.
Jede dieser Aktivitäten aktiviert ein separates Einwilligungstor. Das Persistieren des Besucher-Identifikators ist eine Speicher- und Zugriffsoperation nach Article 5(3) der ePrivacy-Richtlinie und erfordert eine vorherige, frei erteilte, spezifische, informierte und eindeutige Einwilligung im EEA, im Vereinigten Königreich und in jeder Rechtsordnung, die denselben Standard übernommen hat. Die sitzungsübergreifende Verknüpfung von experimentellen Variantenzuweisungen mit diesem Identifikator ist eine Verarbeitung personenbezogener Daten nach der DSGVO, da die Kombination aus Identifikator, IP-Adresse und Variantenexposition ausreicht, um eine Person zu identifizieren und ihre Interaktion mit dem Experimentierprogramm zu charakterisieren. Die Tool-übergreifende Weitergabe von Variantendaten — z. B. wenn Optimizely die Variantenzuweisung an Google Analytics offenbart — fügt das Analysetor zur Kette hinzu. Die Leitlinien des EDPB von 2023 haben ausdrücklich klargestellt, dass Experimentieren, das persistente Identifikation einschließt, denselben Einwilligungsregeln unterliegt wie Analysen; CNIL war in diesem Punkt der lautstärkste Regulierer, ist aber nicht der einzige.
Was Optimizely vor der Einwilligung schreibt — und was unterdrückt werden muss
Das Standard-Optimizely-Snippet installiert das JavaScript SDK direkt in den Seitenkopf und initialisiert sich sofort beim Laden. Das ist der dokumentierte Schnellstart und die Quelle des häufigsten Compliance-Fehlers: Das SDK läuft, bevor das Cookie-Banner gerendert wurde, das optimizelyEndUserId-Cookie wird innerhalb von Millisekunden geschrieben, die Variantenzuweisung erfolgt, und das Entscheidungsereignis wird gefeuert, unabhängig davon, was der Besucher später entscheidet. Jede europäische Aufsichtsbehörde, die zu diesem Muster entschieden hat, hat auf dieselbe Weise geurteilt: Cookies, die vor der Einwilligung gesetzt werden, sind rechtswidrig, die vor der Einwilligung erfasste Variantenzuweisung ist rechtswidrige Verarbeitung, und der Herausgeber trägt die Haftung.
Eine konforme Integration muss daher verhindern, dass Optimizely den persistenten Identifikator schreibt und Entscheidungsereignisse feuert, bis die relevante Einwilligungskategorie erteilt wurde. Optimizely unterstützt dafür zwei Muster. Das erste ist das dedizierte Einwilligungsattribut — übergeben Sie OPTIMIZELY_OPT_OUT=true als Query-String oder setzen Sie das optimizely.opt_out-Cookie vor der SDK-Initialisierung — was das SDK in den Opt-out-Modus versetzt, in dem kein Identifikator geschrieben und keine Ereignisse gefeuert werden. Das zweite ist der reine Anonymmodus, der in der SDK-Konfiguration unterstützt wird, bei dem das SDK in einem sitzungslosen Modus läuft, der Varianten nur auf Basis sitzungslokaler Identifikation zuweist, ohne persistente Identifikation über Besuche hinweg. Der Anonymmodus ermöglicht es dem Experimentierprogramm, auf Basis eines berechtigten Interesses für die Renderentscheidung zu laufen, während persistente Identifikation bis zur Einwilligung aufgeschoben wird.
Die Cookies und der Speicher, den Optimizely schreibt
Das Optimizely Web Experimentation SDK schreibt bei der Initialisierung die folgenden Identifikatoren, die alle nicht wesentlich sind und eine Einwilligung erfordern: optimizelyEndUserId mit einem mehrjährigen Ablauf, der den persistenten Besucher-Identifikator enthält, optimizelyOptOut-Markierungen, die den Opt-out-Status verfolgen, optimizelyDomainTestCookie für subdomänenübergreifendes Experimentieren sowie zusätzliche Namespace-Cookies, wenn der Betreiber domänenübergreifende Identifikation aktiviert hat. Das Widerrufen der Einwilligung muss daher sowohl die Cookies ablaufen lassen als auch das SDK über optimizely.push({ type: 'user', attributes: { opt_out: true } }) in den Opt-out-Modus versetzen, um weitere Ereigniserfassungen zu stoppen.
Optimizely auf Einwilligungsrahmen abbilden
Optimizely implementiert weder IAB TCF noch die IAB Global Privacy Platform nativ — es ist eine First-Party-Experimentierplattform, kein AdTech-Anbieter — aber es stellt eine native Opt-out-API bereit, unterstützt eine dokumentierte Consent-Mode-Integration über die Optimizely Data Platform und respektiert das CMP des Herausgebers über das OPTIMIZELY_OPT_OUT-Attribut. Das Muster, das eine regulatorische Prüfung übersteht, behandelt jede Optimizely-Fähigkeit als separates Tor, das an ein bestimmtes CMP-Signal gebunden ist.
- Anonymes Experimentieren kann auf Basis eines berechtigten Interesses mit sitzungslokaler Identifikation betrieben werden, was für Renderentscheidungen geeignet ist, die keine persistente Identifikation über Besuche hinweg erfordern und nicht an nachgelagerte Analysen weitergegeben werden. Dieser Modus ist an die strikt notwendige oder funktionale Kategorie gebunden.
- Persistentes Experimentieren mit einem stabilen Identifikator ist an den Analysezweck gebunden. In TCF-Begriffen entspricht dies Zweck 8 in Kombination mit Zweck 1; für den Consent Mode entspricht dies analytics_storage.
- Tool-übergreifende Integration — Variantenexpositionsereignisse, die an Google Analytics, Amplitude oder die Optimizely Data Platform weitergeleitet werden — erbt das Analysetor vom empfangenden Tool und darf nicht feuern, wenn dieses Tool-Tor nicht erteilt wurde.
- Personalisierung und zielgruppenbasiertes Targeting, das auf Experimentieren aufgebaut ist, aktiviert das Marketing-Tor, da es von experimenteller Messung zu benutzerbezogenem Targeting übergeht.
Das Integrationsmuster, das funktioniert
Die Referenzimplementierung hat vier Teile: ein CMP, das ein Echtzeit-Einwilligungsänderungsereignis bereitstellt, ein verzögertes Bootstrap, das das Optimizely SDK mit aktiviertem Opt-out oder aktivem Anonymmodus initialisiert, einen Einwilligungs-Listener, der das SDK aus dem Opt-out kippt und persistente Identifikation startet, wenn das Analysetor öffnet, und einen Rückzugspfad, der das SDK zurück in den Opt-out-Modus versetzt, die optimizely-Cookies über document.cookie ablaufen lässt und den Rückzug an nachgelagerte Analyseintegrationen weitergibt.
Web-Implementierung mit dem verzögerten Bootstrap
Im Web ist das sauberste Muster, das Optimizely-Snippet mit window.optimizelyOptOut = true vor der SDK-Initialisierung zu laden. Abonnieren Sie das Einwilligungsänderungsereignis des CMP. Wenn die Analysekategorie auf true wechselt, rufen Sie window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) auf und lassen Sie das SDK normal initialisieren. Wenn das Tor widerrufen wird, pushen Sie das Opt-out-Attribut zurück auf true, lassen Sie das optimizelyEndUserId-Cookie ablaufen und geben Sie die Änderung über die jeweiligen Einwilligungs-APIs an alle integrierten Analyseplattformen weiter.
Serverseitiges Experimentieren über den Decision Service
Optimizely unterstützt auch serverseitiges Experimentieren über die Decision Service API. Serverseitige Entscheidungen sind nicht von der Einwilligung befreit — die Rechtsgrundlage folgt den Daten — aber serverseitige Ausführung gibt dem Herausgeber die volle Kontrolle darüber, welche Identifikatoren weitergegeben werden. Das funktionierende Muster besteht darin, einen ephemeren Sitzungsidentifikator an den Decision Service zu übergeben, wenn das Analysetor geschlossen ist, und nur dann zum persistenten Identifikator zu wechseln, wenn das Tor offen ist. Die vom Decision Service zurückgegebenen Variantenzuweisungen können weiterhin auf die gerenderte Seite angewendet werden; was sich ändert, ist, ob sie an einen stabilen Besucherdatensatz gebunden sind.
Die Integration und den Prüfpfad validieren
Der Validierungsschritt ist das, was Regulierer prüfen und was Herausgeber bei Experimentierwerkzeugen am häufigsten überspringen. Eine korrekt integrierte Optimizely-Implementierung muss sequenziell vier Tests bestehen. Erstens muss eine saubere Browsersitzung mit angezeigtem Banner, aber ohne getroffene Wahl, null Anfragen an logx.optimizely.com über den SDK-Dateiaufruf hinaus und null optimizely-Cookies in document.cookie erzeugen. Zweitens muss das Ablehnen von Analysen diesen Zustand aufrechterhalten — kein persistenter Identifikator, kein Entscheidungsereignis, keine Variantenzuweisung, die an einen stabilen Datensatz gebunden ist. Drittens muss das Akzeptieren von Analysen das erwartete optimizelyEndUserId-Cookie und Entscheidungsereignis-Traffic mit korrekt angewendeter Variantenzuweisung erzeugen. Viertens muss das Widerrufen der Einwilligung sofort weitere Entscheidungsereignisse stoppen, die Cookies ablaufen lassen und das Opt-out an nachgelagerte Analyseintegrationen weitergeben.
Die Erwartung an den Prüfpfad gemäß den Cookie-Banner-Leitlinien des EDPB von 2023 und den erneuerten Taskforce-Prioritäten für 2026 ist, dass der Herausgeber für jede spezifische experimentelle Exposition im Optimizely-Projekt beweisen kann, dass der Besucher zum Zeitpunkt der Exposition eine gültige Einwilligung erteilt hatte. Das Standardmuster besteht darin, die Einwilligungsversion und den Zeitstempel als benutzerdefiniertes Attribut im Optimizely-Besucherprofil über die Attribut-API des SDK zu setzen, damit jede individuelle Exposition auf einen spezifischen Einwilligungslog-Eintrag zurückverfolgt werden kann. Eine korrekt abgesicherte Implementierung, gepaart mit der Anonymmodusbehandlung für Renderentscheidungen vor der Einwilligung und einem Rückzugspfad, der nachgelagert weitergegeben wird, ist das, was Optimizely von einer versteckten Experimentiereben-Haftung in einen verteidigbaren Teil des Produkt- und Wachstumsstacks eines Herausgebers verwandelt.