A/B-Tests einrichten

Dieser Leitfaden beschreibt, wie man einen A/B-Test auf Anwendungsebene durchführt, indem zwei unterschiedliche Versionen der eigenen Anwendung gleichzeitig betrieben werden. Der Load Balancer von Codesphere übernimmt die Verteilung des Traffics nativ und stellt sicher, dass Nutzer einer Version zugewiesen werden und bei dieser bleiben.

Umgebungsisolierung​

Um einen Test durchzuführen, muss die „Control“ (aktuelle Produktion) von der „Variant“ (dem Experiment) isoliert werden.

1. Control bereitstellen (v1):
   • Den aktuellen stabilen, produktionsreifen Code auf einer Landscape in Codesphere bereitstellen.
   • Diese Landscape production-control nennen.
2. Variant bereitstellen (v2):
   • Eine doppelte Landscape erstellen (oder die erste klonen).
   • Diese Landscape production-variant nennen.
   • Den experimentellen Code (neue Funktionen, architektonische Änderungen usw.) auf diese spezifische Landscape pushen.

Analytics-Instrumentierung (Beispiel PostHog)​

Da beide Landscapes letztlich unter derselben öffentlichen URL laufen, weiß das Analytics-Tool nicht automatisch, welche Version ein Nutzer sieht. Die Nutzersession muss explizit über „Super Properties“ (oder „User Traits“) markiert werden.

Im Code der Control-Landscape​

Das Analytics-Initialisierungsskript aufsuchen (meist im Header oder in einer Konfigurationsdatei) und direkt nach der Initialisierung Folgendes hinzufügen:

// App v1 (Control)
posthog.register({
    experiment_group: "Control"
});

Im Code der Variant-Landscape​

Im experimentellen Codebase den Ausschnitt entsprechend der neuen Version anpassen:

// App v2 (Variant)
posthog.register({
    experiment_group: "Variant-A"
});

Traffic-Routing​

Nachdem nun zwei laufende Apps und Analytics eingerichtet sind, muss echter Traffic zu ihnen geleitet werden. Codesphere übernimmt dies nativ, ohne dass externe Tools wie Nginx oder HAProxy erforderlich sind.

Domain konfigurieren​

1. Zum Tab Domains in Codesphere navigieren.
2. Die öffentliche Custom Domain auswählen (z. B. app.example.com).
3. Beide Landscapes anhängen:
   • production-control
   • production-variant

Verifizierung​

Vor der Ankündigung des Updates sollte überprüft werden, ob die Aufteilung und Markierung korrekt funktionieren.

1. Ein Inkognito-Fenster öffnen​

Die öffentliche Domain aufrufen.

2. Die Konsole prüfen​

Die Entwicklertools des Browsers öffnen (F12) und Folgendes ausführen:

posthog.get_property('experiment_group')

3. Live-Events prüfen​

Dazu navigieren zu:

PostHog → Live Events

Sicherstellen, dass die eingehenden Ereignisse der eigenen Session die Eigenschaft experiment_group enthalten.

4. Routing testen​

• Das Inkognito-Fenster schließen.
• Ein neues öffnen.
• Mehrfach wiederholen.

Analyse & Entscheidung​

Sobald Traffic fließt, sollten die Daten durch Segmentierung analysiert werden, nicht durch komplexe Mathematik.

Die Analyse​

1. Das Dashboard öffnen (z. B. PostHog Insights).
2. Einen Trendgraphen oder Funnel erstellen (z. B. „User Signups“).
3. Eine Aufschlüsselung (Breakdown) nach der Eigenschaft anwenden:

experiment_group

4. Die Ergebnisse vergleichen.

Es erscheinen zwei unterschiedliche Linien:

• Control
• Variant-A

Der Rollout​

Basierend auf den Ergebnissen wird eines der folgenden Szenarien umgesetzt:

Szenario A: Die Variant gewinnt​

(höhere Konversion oder bessere Performance)

1. Zum Tab Codesphere Domains gehen.
2. production-control von der Domain entfernen.
   → 100 % des Traffics fließen jetzt zu production-variant.
3. Die alte Control-Landscape außer Betrieb nehmen.

Szenario B: Die Variant scheitert​

(Fehler oder niedrigere Konversion)

1. Zum Tab Codesphere Domains gehen.
2. production-variant von der Domain entfernen.
   → 100 % des Traffics gehen zurück zur stabilen production-control.
3. Die Variant-Landscape außer Betrieb nehmen und den Code offline untersuchen.