Begriff
A/B Testing
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Du streitest mit deinem Designer. "Der Kaufen-Button muss ROT sein!" "Nein, BLAU!" Wer hat recht? Niemand. Die Daten haben recht. Du zeigst 50% der User den roten Button (Variante A). Du zeigst 50% der User den blauen Button (Variante B). Dann misst du: Wo klicken mehr Leute? Das ist A/B Testing. Statt zu raten (HiPPO - Highest Paid Person's Opinion), lässt du die User entscheiden.
Merksatz: Ein Verfahren zum Vergleichen von zwei Versionen einer Webseite oder App, um festzustellen, welche Version besser abschneidet (z. B. mehr Klicks oder Verkäufe generiert).
Tools: Optimizely, Google Optimize (RIP), VWO. Wichtig: Statistische Signifikanz. Wenn 10 Leute klicken (5 rot, 5 blau) ist das Zufall. Du brauchst 1000 Leute, um sicher zu sein. Nicht zu viele Tests gleichzeitig machen ("Interferenz").
1. Multi-Armed Bandit
A/B Testing ist "dumm". Du schickst 50% Traffic auf die schlechte Variante B, bis der Test vorbei ist (Geldverschwendung). Ein "Bandit"-Algorithmus lernt live. "Oh, B scheint schlecht zu sein? Ich schicke nur noch 10% auf B und 90% auf A." Er optimiert während des Tests (Explore vs. Exploit).
2. P-Hacking
Wenn man so lange testet, bis zufällig ein Ergebnis rauskommt. "Wochenende war rot besser, Dienstag blau..." Man muss vorher festlegen: "Wir testen 7 Tage mit 5000 Usern." Und sich daran halten.
1. Bayesian A/B Testing
Frequentistisches A/B-Testing (das Standard-Modell mit $p$-Werten) ist extrem starr. Man darf den Test nicht abbrechen ("Peeking Problem"), sonst droht Alpha-Fehler-Kumulierung.
Die Alternative: Bayesianisches A/B-Testing. Statt eines harten $p$-Werts liefert es Wahrscheinlichkeiten: "Zu 92% ist Variante B besser, und der erwartete Uplift liegt zwischen 1.2% und 3.4%." Das erlaubt es Product-Teams, Entscheidungen unter Unsicherheit sehr viel früher zu treffen.
Code-Sicht: Libraries wie PyMC3 (Python) rechnen mit Markov Chain Monte Carlo (MCMC), um die Posterior-Verteilung der Conversion Raten zu ziehen.
2. Network Effects & Spillover
Was, wenn dein Test-Feature ein Chat-System ist? Wenn du User A in die Testgruppe packst (hat Chat) und User B in die Kontrollgruppe (hat keinen Chat), können sie nicht miteinander reden. Die Testerfahrung ist also von der Gruppenzuweisung anderer abhängig (SUTVA-Verletzung - Stable Unit Treatment Value Assumption). Lösung: Graph Cluster Randomization. Anstatt individuelle User randomisiert zuzuweisen, identifiziert man via Graph-Algorithmen eng vernetzte Communities (z.B. Schulklassen auf einer Social-Media-Plattform) und weist ganze Cluster A oder B zu. So minimiert man Spillover.
3. SRM (Sample Ratio Mismatch)
Der gefährlichste Bug in Production-Tests. Wenn du einen 50/50-Test machst, aber in Variante A 10.000 User landen und in B 9.800. Der Unterschied scheint klein, aber ein Chi-Quadrat-Test sagt: Wahrscheinlichkeit fast null. Ein $p$-Wert von $10^{-6}$ bedeutet: Dein Tracking-Stack ist kaputt. Vielleicht crasht Variante B auf alten Android-Handys vor dem Logging, oder ein CDN-Caching-Problem leitet falsch weiter. Ein SRM macht jedes Versuchsergebnis sofort komplett ungültig (vgl. "Trustworthy Online Controlled Experiments", Kohavi et al., 2020).
Quick-Check
Nur für Farben?
Nein. Für Preise ("Reagieren Kunden auf 9,99€ besser als auf 10€?"), Algorithmen (Netflix Empfehlungen) oder ganze Layouts.Was ist Multivariate Testing?
Du testest Button-Farbe (Rot/Blau) UND Überschrift (Groß/Klein) gleichzeitig. 2x2 = 4 Kombinationen. Braucht viel mehr Traffic für Signifikanz.Ist es ethisch?
Meist ja. Aber Facebook experimentierte mit "traurigen Newsfeeds", um zu sehen, ob User dann trauriger posten. Das war ein Skandal ("Emotional Contagion").