Konfiguration wechselseitig ausschließender Experimentgruppen in Optimizely

Wenn wachstumsstarke Produkt- und Experimentierteams mehrere A/B-Tests gleichzeitig auf derselben Seite, im Checkout-Trichter oder entlang kritischer Nutzerpfade durchführen, drohen Traffic-Kollisionen. Wird ein Besucher gleichzeitig mehreren überlappenden Tests zugewiesen, führen Interaktionseffekte (Interaction Effects) dazu, dass Konversionsveränderungen nicht mehr eindeutig einer Maßnahme zugeordnet werden können. Zudem können dynamische Verschiebungen im Traffic eine Stichprobenverhältnis-Diskrepanz (Sample Ratio Mismatch, SRM) auslösen.

In Optimizely lösen Teams dieses Problem durch die Konfiguration von Exklusionsgruppen (Exclusion Groups). Eine Exklusionsgruppe dient als übergeordneter Traffic-Container, der mehrere parallele Tests bündelt und den Besucher-Traffic über einen gemeinsamen, deterministischen Hash-Seed aufteilt. Ein Nutzer, der in Experiment A eingeteilt wird, wird innerhalb derselben Gruppe niemals mit Experiment B in Berührung kommen.

Wann Exklusionsgruppen eingesetzt werden sollten (und wann nicht)

Der wechselseitige Ausschluss schützt die statistische Integrität der Daten, hat jedoch einen entscheidenden geschäftlichen Preis: Traffic-Verdünnung. Wenn eine begrenzte Zielgruppe auf mehrere unabhängige Tests aufgeteilt wird, verringert sich die Stichprobengröße pro Experiment drastisch, was die Laufzeit bis zum Erreichen statistischer Signifikanz erheblich verlängert.

Teams sollten daher differenziert abwägen:

Die interne Funktionsweise des wechselseitigen Ausschlusses in Optimizely

Im Standardverhalten berechnet Optimizely jedes Experiment unabhängig. Für jedes Experiment wird die Nutzerkennung (User ID oder Bucketing ID) mit der Experiment-ID verknüpft und über den deterministischen Hash-Algorithmus MurmurHash3 auf 10.000 Traffic-Buckets (0 bis 9.999) verteilt.

Da unabhängige Experimente unterschiedliche Hash-Werte erzeugen, kann derselbe Nutzer gleichzeitig in aktiven Buckets mehrerer paralleler Tests landen.

Sobald Experimente einer Exklusionsgruppe (Exclusion Group) zugeordnet werden, ändert Optimizely das Zuweisungsverfahren:

1. Gemeinsame Hash-Basis: Der Hash-Algorithmus verknüpft die Nutzerkennung primär mit der ID der Exklusionsgruppe.
2. Deterministische Bereichsaufteilung: Die 10.000 Buckets werden anhand der festgelegten Prozentsätze exklusiv auf die beteiligten Experimente aufgeteilt.
3. Strikte Isolation: Fällt ein Besucher in den Bucket-Bereich von Experiment A, ist er ausschließlich für Experiment A qualifiziert und wird für Experiment B oder C innerhalb dieser Gruppe gar nicht erst evaluiert.

Evaluierungsreihenfolge und Prioritäten (Evaluation Order)

In Optimizely Feature Experimentation und Web Experimentation folgt die Entscheidung einer strengen Hierarchie mit vorzeitigem Abbruch (Short-Circuiting):

1. Regelstatus-Prüfung: Stellt sicher, dass das Experiment bzw. die Flag-Regel aktiv ist.
2. Erzwungene Varianten (Forced Variations): Höchste Priorität (für QA und interne Tests).
3. Positivliste (User Allowlisting): Feste Zuweisungen für definierte Nutzer-IDs.
4. Nutzerprofil-Dienst (User Profile Service, UPS): Liest persistierte Zuweisungen früherer Sitzungen aus.
5. Zielgruppen-Targeting (Audience Targeting): Prüft die Übereinstimmung der Nutzerattribute mit den Zielgruppenkriterien.
6. Exklusionsgruppen-Bewertung (Exclusion Group Evaluation): Prüft, ob der Nutzer bereits einem anderen Experiment der Gruppe zugeordnet ist; falls ja, erfolgt der Ausschluss.
7. Traffic-Zuweisung und Varianten-Hash (Traffic Allocation): Weist den Nutzer gemäß den Prozentsätzen einer konkreten Variante innerhalb des Experiments zu.

Schritt-für-Schritt-Anleitung: Optimizely Web Experimentation

Für Teams, die clientseitige Tests oder Edge-Experimente auf Webseiten durchführen:

1. Exklusionsgruppe erstellen

1. Navigieren Sie im Optimizely Web Experimentation Dashboard zu Experiments.
2. Wählen Sie den Reiter Exclusion Groups. (Hinweis: Falls Optimizely Personalization aktiviert ist, navigieren Sie stattdessen zu Optimizations > Exclusion Groups).
3. Klicken Sie auf Create New Exclusion Group.
4. Vergeben Sie einen eindeutigen Namen (Name) (z. B. Checkout_Funnel_Q2_Exclusion) und eine optionale Beschreibung (Description).

2. Experimente hinzufügen und Traffic-Anteile zuweisen

1. Wählen Sie die Entwurfs-Experimente aus, die in die Exklusionsgruppe aufgenommen werden sollen.
2. Definieren Sie die Verteilung des gesamten Gruppen-Traffics auf die Experimente:
   • Bei zwei Tests beispielsweise jeweils 50%;
   • Alternativ kann ein nicht zugewiesener Kontrollbereich (Holdout) reserviert werden (z. B. 40% für Experiment 1, 40% für Experiment 2 und 20% Reserve).
3. Klicken Sie auf Create Exclusion Group zum Speichern.

3. Auslösebedingungen prüfen

Stellen Sie sicher, dass alle Experimente der Gruppe identische URL-Bedingungen oder Event-Trigger aufweisen, um eine gleichmäßige Verteilung sicherzustellen.

Schritt-für-Schritt-Anleitung: Optimizely Feature Experimentation

Für Entwicklungsteams im Backend-, Mobil- und Full-Stack-Bereich:

1. Exklusionsgruppe im Flags-Dashboard anlegen

1. Öffnen Sie den Bereich Flags und wechseln Sie zum Reiter Exclusion Groups.
2. Klicken Sie auf Create New Exclusion Group.
3. Geben Sie Gruppenname und Beschreibung ein.
4. Wählen Sie die Zielumgebung (Environment, z. B. Production oder Staging). Exklusionsgruppen sind strikt an Umgebungen gebunden.
5. Klicken Sie auf Create Exclusion Group.

2. Experiment-Regeln der Gruppe zuweisen

1. Kehren Sie zur Flag-Übersicht zurück und öffnen Sie das Feature Flag, das die gewünschte Experiment-Regel enthält.
2. Wählen Sie die Umgebung aus und klicken Sie auf die entsprechende Experiment Rule.
3. Suchen Sie im Bereich Configure Rule das Dropdown-Menü: "Add this experiment to the following exclusion group".
4. Wählen Sie die zuvor erstellte Exklusionsgruppe aus.
5. Geben Sie den Prozentsatz des Gruppen-Traffics an, der diesem Experiment zusteht.
6. Klicken Sie auf Save Experiment.
7. Wiederholen Sie diesen Vorgang für alle parallel laufenden Experiment-Regeln, die voneinander getrennt werden müssen.

3. Automatisierte Konfiguration via REST-API

Für CI/CD-Pipelines und automatisierte Rollouts steht die Optimizely REST-API zur Verfügung:

• Gruppe anlegen: POST /v2/groups mit {"name": "Cart_Redesign_Group", "environment_key": "production"}.
• Regeln verknüpfen: PATCH /v2/groups/{group_id} unter Angabe der rule_id.
• Konfiguration prüfen: GET /v2/groups zum Auditieren bestehender Exklusionsstrukturen.

4. Kein zusätzlicher Code im SDK erforderlich

Die Exklusionslogik wird über das Datafile (Ruleset) bereitgestellt und vom SDK im Arbeitsspeicher aufgelöst. Wenn die Anwendung client.decide(user_key, flag_key) aufruft, erfolgen Ausschlussprüfung und Zuweisung lokal in Millisekunden, ohne zusätzliche Netzwerkanfragen.

Vier unverzichtbare Governance-Regeln für Experimentierteams

Um Datenverfälschungen, statistische Verzerrungen und irreleitende Metriken zu vermeiden, müssen Teams vier Grundregeln beachten:

1. Alle Experimente einer Gruppe synchron starten

Starten Sie Experiment 1 nicht heute, um Experiment 2 erst nächste Woche derselben Gruppe hinzuzufügen. Wenn Nutzer bereits auf Gruppenebene zugewiesen wurden, führt das nachträgliche Hinzufügen von Experimenten zu einer Verschiebung der Hash-Grenzen. Dies kann bestehende Nutzer umverteilen und die Zufälligkeit der Stichprobe zerstören.

2. Niemals aktive Gruppen im laufenden Betrieb verändern

Sobald ein Experiment innerhalb einer Exklusionsgruppe aktiv Traffic empfängt:

• Fügen Sie keine neuen Experimente hinzu.
• Entfernen Sie keine laufenden Experimente aus der Gruppe. Nachträgliche Änderungen zerstören die erwarteten Traffic-Verhältnisse, lösen Alarme wegen Stichprobenverhältnis-Diskrepanz (SRM) aus und machen statistische Ergebnisse wertlos. Muss ein Test vorzeitig beendet werden, pausieren Sie dessen Regel, anstatt die Gruppe zu verändern.

3. Konsistente Zielgruppendefinitionen wahren

Richtet sich Experiment A an alle Desktop-Nutzer, während Experiment B ausschließlich mobile Besucher anspricht, führt eine gemeinsame Exklusionsgruppe zu massiver Traffic-Verschwendung. Da die Aufteilung auf Gruppenebene erfolgt, erhalten Desktop-Nutzer, die Experiment B zugewiesen werden, keine Änderung, wodurch Experiment A wertvolle Stichproben entzogen werden.

4. Prioritätsübersteuerung durch den User Profile Service (UPS) beachten

Kommt ein User Profile Service (UPS) zum Einsatz, um Varianten über mehrere Sitzungen hinweg stabil zu halten, wird der UPS vor der Exklusionsgruppe ausgewertet. Hatte ein Nutzer vor der Einbindung in die Exklusionsgruppe bereits eine Variante aus einem isolierten Test gespeichert, liefert der UPS diesen Altwert zurück und durchbricht die Exklusionslogik. Nutzen Sie in solchen Fällen OptimizelyDecideOption.IGNORE_USER_PROFILE_SERVICE.

Referenzen

• Use mutual exclusion - Feature Experimentation docs
• How bucketing works - Feature Experimentation docs
• Optimizely's automatic sample ratio mismatch detection