A/B-Testing und Cookies: testen ohne die DSGVO zu verletzen

TL;DR

A/B-Testing basiert häufig auf Cookies, um Besucher zu identifizieren und ihnen eine Variante zuzuweisen. Sobald diese Cookies es ermöglichen, einen Nutzer über die Zeit zu verfolgen oder Verhaltensdaten zu verknüpfen, fallen sie in den Anwendungsbereich der DSGVO und erfordern eine vorherige Einwilligung. Die entscheidende Unterscheidung ist die zwischen einem für den Test unbedingt erforderlichen Cookie (mögliche Ausnahme) und einem Cookie, das ein Analytics- oder Marketingprofil speist (Einwilligung erforderlich). Um zu testen, ohne gegen die Vorschriften zu verstossen, müssen Sie diese Grenze verstehen, Ihre CMP entsprechend konfigurieren und Tools wählen, die mit dem europäischen Rahmen kompatibel sind.

Was ist A/B-Testing und warum sind Cookies beteiligt?

A/B-Testing ist eine Methode, bei der zwei Varianten einer Seite oder eines Elements verschiedenen Besuchergruppen präsentiert werden, um zu messen, welche die besten Ergebnisse erzielt. Damit der Test korrekt funktioniert, muss sichergestellt werden, dass derselbe Besucher während der gesamten Testdauer immer dieselbe Variante sieht.

Hier kommen Cookies ins Spiel. Die meisten A/B-Testing-Tools setzen ein First-Party-Cookie im Browser des Besuchers. Dieses Cookie speichert die zugewiesene Varianten-ID, manchmal eine Benutzer-ID, und gewährleistet die Konsistenz der Anzeige über Seiten und Sitzungen hinweg.

Das rechtliche Problem entsteht, wenn dieses Cookie über die einfache Variantenzuweisung hinausgeht. Wenn das Tool auch Navigationsdaten, Konversionsereignisse erfasst oder die Test-ID mit einem Analytics- oder Werbeprofil abgleicht, verlässt das Cookie den Bereich „unbedingt erforderlich“ und fällt in den Bereich der DSGVO-Einwilligung.

Was Datenschutzbehörden als A/B-Test-Cookie betrachten

Datenschutzbehörden unterscheiden zwei Situationen. Ein Cookie, das ausschliesslich dazu dient, die angezeigte Variante zu speichern, ohne Daten an Dritte zu übermitteln und ohne Abgleich mit anderen Trackern, kann als für den Betrieb der Website unbedingt erforderlich angesehen werden. In diesem Fall profitiert es von der in den ePrivacy-Vorschriften vorgesehenen Einwilligungsausnahme.

Wenn das Test-Cookie jedoch ein Drittanbieter-Tool (historisch Google Optimize, VWO, AB Tasty, Optimizely) speist, das Verhaltensdaten sammelt, Ergebnisse mit einer Analytics-ID abgleicht oder Daten mit Partnern teilt, erfüllt es die Ausnahmekriterien nicht mehr. Die Einwilligung wird vor dem Setzen des Cookies obligatorisch.

Wie stellen Sie fest, ob Ihre A/B-Testing-Cookies eine Einwilligung erfordern?

Die Antwort hängt von drei konkreten Kriterien ab: der Art der erfassten Daten, dem Ziel der Daten und der Lebensdauer des Cookies.

Art der erfassten Daten

Wenn das Cookie nur eine Varianten-ID speichert (z. B. ab_variant=B) ohne Benutzer-ID, Navigationsdaten oder Konversionsereignisse, bleibt es im Ausnahmebereich. Sobald es eine Besucher-ID, einen Sitzungs-Timestamp, Seitenaufrufe oder Klicks auf Elemente erfasst, wird es zu einem einwilligungspflichtigen Tracker.

Datenziel

Ein Cookie, das lokal im Browser verbleibt und dessen Wert nur vom Frontend-Code der Website gelesen wird, um die richtige Variante anzuzeigen, ist unproblematisch. Ein Cookie, dessen Wert an einen Drittanbieter-Server (A/B-Testing-SaaS, Analytics-Plattform) zur Speicherung und Analyse gesendet wird, erfordert eine Einwilligung.

Cookie-Lebensdauer

Ein Sitzungscookie, das beim Schliessen des Browsers verschwindet, ist weniger aufdringlich als ein persistentes Cookie von 6 oder 12 Monaten. Datenschutzbehörden empfehlen eine maximale Dauer von 13 Monaten für einwilligungspflichtige Cookies. Ein Test-Cookie, das ohne technische Begründung über eine Sitzung hinaus bestehen bleibt, verstärkt die Einwilligungspflicht.

Gängige A/B-Testing-Tools und ihre DSGVO-Konformität

Jedes Tool hat seinen eigenen Cookie- und Datenerfassungsmechanismus. Hier ist, was Sie vor dem Start eines Tests prüfen sollten.

Die meisten SaaS-A/B-Testing-Tools erfordern eine Einwilligung, weil sie Verhaltensdaten erfassen und an ihre Server übermitteln. Die Ausnahme ist nur bei eigenen serverseitigen Implementierungen realistisch, bei denen sich das Cookie auf die Speicherung der Variante ohne jegliche analytische Datenerfassung beschränkt.

So konfigurieren Sie Ihre CMP für A/B-Testing

Die Konfiguration Ihrer CMP (Consent Management Platform) bestimmt, ob Ihre A/B-Tests die DSGVO einhalten oder nicht. Der häufigste Fehler ist die Einordnung des A/B-Testing-Skripts in die falsche Cookie-Kategorie.

Schritt 1: die richtige Kategorie identifizieren

Ihr A/B-Testing-Tool muss in die Kategorie eingestuft werden, die seinem tatsächlichen Verhalten entspricht. Wenn das Tool Verhaltensdaten erfasst und an Dritte sendet, gehört es in die Kategorie „Analytics“ oder „Leistungsmessung“ Ihrer CMP. Stufen Sie es niemals als „unbedingt erforderlich“ ein, es sei denn, Sie haben überprüft, dass keine Daten den Browser verlassen.

Um die verschiedenen Cookie-Kategorien und ihre Auswirkungen zu verstehen, lesen Sie den Leitfaden zu den 4 DSGVO-Cookie-Kategorien.

Schritt 2: das Skript vor der Einwilligung blockieren

Ihre CMP muss das Laden des A/B-Testing-Skripts blockieren, bis der Besucher die entsprechende Kategorie akzeptiert hat. Das bedeutet, dass Besucher, die Analytics-Cookies ablehnen, keinen A/B-Test sehen werden. Das ist eine reale Einschränkung, aber es ist die Anforderung der DSGVO.

Die Blockierung von Skripten vor der Einwilligung ist ein Grundprinzip der Cookie-Compliance. Ihre CMP muss diese Blockierung zuverlässig handhaben.

Schritt 3: Consent Mode v2 verwalten

Wenn Sie Google-Tools (GA4, Google Ads) neben Ihrer A/B-Testing-Lösung verwenden, ermöglicht der Consent Mode v2 das Senden von cookielosen Pings, wenn die Einwilligung verweigert wird. Einige A/B-Testing-Tools bieten bereits Integrationen an, die mit dem Consent Mode kompatibel sind. Prüfen Sie, ob Ihr Tool dies unterstützt.

Schritt 4: in Ihrer Cookie-Richtlinie dokumentieren

Ihre Cookie-Richtlinie muss die von Ihrem A/B-Testing-Tool gesetzten Cookies, ihren Zweck, ihre Lebensdauer und den zugreifenden Dritten aufführen. Dies ist eine Pflicht, die von Growth-Teams oft übersehen wird.

Auswirkungen auf Ihre Tests: Was passiert, wenn Besucher ablehnen?

Das ist die Frage, die Product Manager und Growth Marketer am meisten beschäftigt. Wenn das A/B-Testing-Skript für Besucher blockiert wird, die Cookies ablehnen, wird ein Teil des Traffics von den Tests ausgeschlossen.

Selektionsbias

Besucher, die Cookies akzeptieren, sind nicht identisch mit denen, die sie ablehnen. Datenschutzbewusste Nutzer haben oft ein anderes Surfverhalten: Sie konvertieren anders, navigieren anders und reagieren anders auf Interfaces. Das Ausschliessen dieses Segments führt zu einem Bias in den Testergebnissen.

Dieser Bias ist real, aber er ist kein Argument, um die DSGVO zu umgehen. Er muss in der Ergebnisanalyse berücksichtigt und die statistische Signifikanz entsprechend angepasst werden.

Alternativen zur Reduzierung der Auswirkungen

Mehrere Ansätze helfen, den Verlust an testbarem Traffic zu begrenzen und gleichzeitig konform zu bleiben.

Serverseitiges A/B-Testing weist die Variante auf dem Server zu, ohne Cookie im Browser, basierend auf einer Sitzungs-ID. Wenn keine personenbezogenen Daten erfasst werden und die Ergebnisse intern bleiben, kann dieser Ansatz von der Einwilligungsausnahme profitieren.

Serverseitiges Feature Flagging (LaunchDarkly, Unleash, Flagsmith) verwendet keine Browser-Cookies. Die Zuweisung erfolgt im Backend. Die Ergebnismessung erfolgt über interne Daten (Datenbank, serverseitige Events) ohne Drittanbieter-Tracker.

Die Optimierung Ihrer Einwilligungsrate ist ebenfalls ein direkter Hebel. Je klarer und besser gestaltet Ihr Banner ist (ohne Dark Patterns), desto höher ist der Anteil der Besucher, die Analytics-Cookies akzeptieren, und desto grösser ist Ihre testbare Basis.

Häufige Fehler

Das A/B-Testing-Skript als „unbedingt erforderlich“ einstufen. Dies ist der häufigste Fehler. Tools wie AB Tasty, VWO oder Optimizely erfassen Verhaltensdaten und senden sie an Drittanbieter-Server. Sie sind für den Betrieb der Website nicht unbedingt erforderlich. Eine solche Einstufung birgt das Risiko von Sanktionen bei einer behördlichen Prüfung.

Einen Test starten, ohne zu prüfen, ob das Skript vor der Einwilligung blockiert ist. Viele Growth-Teams installieren das A/B-Testing-Skript ohne über die CMP zu gehen oder ordnen es der Kategorie „erforderlich“ zu, damit es ohne Einwilligung geladen wird. Der FlowConsent Cookie-Scanner ermöglicht es, zu überprüfen, welche Skripte vor der Einwilligung geladen werden.

Cookies des Testing-Tools in der Cookie-Richtlinie ignorieren. Jedes Cookie muss deklariert werden. A/B-Testing-Tools setzen oft mehrere Cookies (Variante, Besucher-ID, Sitzung). Alle müssen in der Richtlinie erscheinen.

Testdaten mit Werbe-IDs verknüpfen. A/B-Testergebnisse an Google Ads, Meta Ads oder eine DMP ohne ausdrückliche Marketing-Einwilligung zu senden, ist ein DSGVO-Verstoss. Die Analytics-Einwilligung deckt kein Werbe-Targeting ab.

Keinen Einwilligungsnachweis erheben. Im Falle einer Prüfung müssen Sie nachweisen können, dass der Besucher vor dem Setzen des Test-Cookies eingewilligt hat. Ohne zeitgestempelten Nachweis kann die Konformität nicht belegt werden.

Einen A/B-Test verwenden, um das Cookie-Banner selbst zu ändern. Varianten Ihres Einwilligungsbanners (Farben, Texte, Buttons) mit einem Tool zu testen, das selbst eine Einwilligung erfordert, erzeugt eine zirkuläre Abhängigkeit. Um Ihr Banner zu testen, nutzen Sie Methoden, die keine Cookies erfordern: Nutzertests, serverseitige Tests oder in Ihre CMP integrierte Funktionen.

Serverseitiges A/B-Testing: die standardmässig konforme Lösung?

Serverseitiges A/B-Testing weist die Variante auf dem Server zu, bevor die Seite an den Browser gesendet wird. Der Besucher erhält direkt Version A oder B, ohne dass ein Client-Skript ausgeführt oder ein Drittanbieter-Cookie gesetzt wird.

Vorteile für die Compliance

Kein Drittanbieter-Skript im Browser, also keine Blockierung durch die CMP. Kein Tracking-Cookie, also keine Einwilligung erforderlich (wenn die Ausnahmebedingungen erfüllt sind). Kein Flicker (der Flackereffekt zwischen Varianten), der die Benutzererfahrung und die Core Web Vitals beeinträchtigt.

Bedingungen für die Ausnahme

Damit ein serverseitiger A/B-Test von der Einwilligung befreit ist, muss das gesetzte Cookie (falls ein Sitzungscookie verwendet wird) ausschliesslich dazu dienen, die Konsistenz der angezeigten Variante aufrechtzuerhalten. Die Ergebnisdaten müssen intern bleiben, ohne Übermittlung an Dritte. Es darf keine persönliche Kennung im Cookie gespeichert werden. Die Cookie-Dauer darf die Testdauer nicht überschreiten.

Wenn eine dieser Bedingungen nicht erfüllt ist, wird die Einwilligung wieder erforderlich, auch bei serverseitigem Testing.

Checkliste: DSGVO-konformes A/B-Testing

1. Alle von Ihrem A/B-Testing-Tool gesetzten Cookies identifizieren (Name, Dauer, Zweck).
2. Feststellen, ob diese Cookies Daten an einen Drittanbieter-Server übermitteln.
3. Das Skript in die richtige Kategorie Ihrer CMP einordnen (Analytics, nicht „erforderlich“).
4. Sicherstellen, dass das Skript vor der Einwilligung für ablehnende Besucher blockiert ist.
5. Alle Test-Cookies in Ihrer Cookie-Richtlinie deklarieren.
6. Testergebnisse nicht ohne Marketing-Einwilligung mit Werbe-IDs verknüpfen.
7. Bei Nutzung des Consent Mode v2 die Kompatibilität Ihres Testing-Tools prüfen.
8. Die serverseitige Option für kritische Tests evaluieren, bei denen die Traffic-Abdeckung Priorität hat.
9. Einwilligungsnachweise für in Tests einbezogene Besucher aufbewahren.
10. Ihre Website nach der Installation scannen, um sicherzustellen, dass kein Skript vor der Einwilligung geladen wird.

Fazit

A/B-Testing und Cookie-Compliance sind nicht unvereinbar, erfordern aber eine sorgfältige Konfiguration. Die meisten SaaS-Testing-Tools setzen Cookies, die eine vorherige Einwilligung erfordern. Die robusteste Lösung für Teams, die die Abdeckung ihrer Tests maximieren wollen, ist die Migration zu serverseitigem Testing oder Feature Flagging, bei dem die Cookie-Einwilligung kein limitierender Faktor mehr ist.

Um zu prüfen, welche Skripte und Cookies auf Ihrer Website vor und nach der Einwilligung geladen werden, starten Sie einen kostenlosen Scan mit FlowConsent.