A/B-Tests — Widget-Varianten vergleichen

Statt zu raten welcher Greeting-Text besser konvertiert, lass deine Besucher entscheiden. Zwei Widget-Konfigurationen laufen parallel; die Hälfte der Besucher sieht Variante A, die andere Variante B. Nach ein paar Wochen zeigt das Dashboard welche Variante statistisch signifikant gewinnt.

Wie ein Experiment funktioniert

1. Du legst zwei (oder mehr) Widgets an — z.B. einen Klon deines Standard-Widgets mit anderem Greeting-Text. Andere Config-Werte (Farben, Position) bleiben gleich.
2. Im Tab Einstellungen → A/B-Tests legst du ein Experiment an: Name + welche zwei Widgets verglichen werden + Aufteilung (z.B. 50/50).
3. Klick auf Starten → ab dann wird jedem neuen Besucher per deterministischem Hash eine Variante zugewiesen. Derselbe Besucher landet beim nächsten Visit wieder in derselben Variante.
4. Pro Konversation persistiert SilentChat das variant_assignment ({group_id, label} JSONB). Damit bleibt die Statistik attribuierbar, auch wenn das Experiment später endet.

Wer landet in welcher Variante?

Die Zuweisung ist deterministisch: sha256(visitor_fingerprint + group_id) mod 100 ergibt einen Bucket 0-99. Bei 50/50 landen Visitor mit Bucket 0-49 in Variante A, 50-99 in Variante B.

Eigenschaften dieses Vorgehens:

• Same visitor → same variant über Page-Reloads und sogar zwischen Sessions (solange der Fingerprint stabil ist).
• Group-ID als Salt isoliert Experimente voneinander: ein Besucher, der in Experiment X in "A" landete, hat eine unabhängige 50/50-Chance auf "A" oder "B" in Experiment Y. Kein Bias-Leak.
• Als zusätzliche Sicherung speichert das Widget das Ergebnis in localStorage (sc_variant_<public_key>, Wert {group_id, label}). Bei Init sendet das Widget diesen Wert mit; der Server bevorzugt ihn vor einem neuen Hash-Pick. Das schützt vor Fingerprint-Drift (Browser-Update, Privacy-Extension).

Statistik & Winner-Vorschlag

Das Dashboard zeigt pro Variante:

• Konversationen — wie viele Visitor in dieser Variante gelandet sind
• Nachrichten — Engagement-Signal (chatty visitors)
• Conversions — Konversationen die (a) mindestens eine Visitor-Nachricht haben UND (b) einen Status closed/resolved/assigned erreicht haben oder einem Agent zugewiesen wurden. Dieses Conversion-Signal deckt Lead-Capture, Ticket-Erstellung und Live-Handoff ab.
• Rate — Conversions / Konversationen
• ≥ Konfidenz (95%) — die untere Grenze des Wilson-95%-Konfidenz-Intervalls. Das ist die Zahl auf die du schaust wenn du einen Winner deklarierst — nicht die rohe Rate (rohe Raten lügen bei kleinen N).

Winner-Badge erscheint nur wenn beide Bedingungen erfüllt sind:

1. Min. 200 Visitor pro Variante (sample-size-floor)
2. Confidence-Lower des Leaders > Confidence-Upper des Runners-Up (non-overlapping intervals — strikter als „Rate ist höher")

Das schützt vor verfrühten Entscheidungen. Wenn die Rate für A z.B. bei N=50 dramatisch höher als B ist, kann das pures Rauschen sein — Wilson erkennt das und gibt keinen Winner aus.

Wann beenden?

Tenant entscheidet manuell — kein Auto-Stop. Sobald die Winner-Card grün ist, klickst du Beenden. Status wechselt zu completed, der Picker hört auf zu laufen, neue Besucher bekommen wieder das Standard-Widget.

Wenn du nach dem Beenden die Winner-Variante als Default haben willst, kopiere die Config-Werte (Greeting etc.) ins ursprüngliche Widget — das ist v1 noch ein manueller Schritt; ein Ein-Klick-Promote ist auf der Roadmap.

DSGVO

Das Widget schreibt einen localStorage-Eintrag im Browser des Besuchers:

• Schlüssel: sc_variant_<public_key>
• Wert: { "group_id": "<uuid>", "label": "A" } (kein personenbezogenes Datum — nur Gruppen-ID und Buchstabe)
• Speicherdauer: bis der Besucher den Browser-Storage löscht oder das Experiment endet

Was du in deine Datenschutzerklärung packen solltest:

Wir setzen einen lokalen Speicher-Eintrag (sc_variant_<id>), um Besucher konsistent in derselben Test-Variante zu halten. Der Eintrag enthält ausschließlich eine Test-ID und einen Variantennamen (z.B. "A"). Zweck: korrekte Funktionsweise unseres A/B-Tests; Rechtsgrundlage: berechtigtes Interesse an der Optimierung unserer Webseite (Art. 6 Abs. 1 lit. f DSGVO).

Der Hash-Picker selbst nutzt den Fingerprint — der ist bereits durch deine bestehende Visitor-Tracking-Sektion abgedeckt.

Häufige Fragen

Mehr als zwei Varianten? In v1 nur klassisches A/B. Multi-Variant (A/B/C/D) ist als Folge-Plan #167b geplant — Tenant-Bedarf abwartend.

Was passiert mit laufenden Konversationen wenn ich beende? Sie behalten ihren variant_assignment-Stempel und werden in der finalen Statistik mitgezählt — auch wenn der Besucher Tage später zurückkommt.

Picker ist deterministisch — wozu dann der localStorage? Layered Defence: der Hash bleibt stabil solange der Fingerprint stabil ist. localStorage springt ein wenn der Browser den Fingerprint ändert (Update, Datenschutz-Erweiterung) — sonst würde ein Visitor in dem Fall zur "anderen" Variante umkippen.

Brauche ich Consent für den localStorage? Das hängt von der Cookie-Banner-Strategie deines Tenants ab. Da der Wert keine personenbezogenen Daten enthält und ausschließlich der Test-Funktionalität dient, ist berechtigtes Interesse (Art. 6 Abs. 1 lit. f DSGVO) in der Regel ausreichend. Sprich im Zweifel mit deinem Datenschutzbeauftragten.

API-Referenz

Die Picker-Logik läuft auf jedem POST /api/v1/widget/init — der Visitor sieht 0 zusätzliche Latenz, weil der Pick ein indexed DB-Lookup + Hash ist.