Sample Ratio Mismatch: Verteilungen im A/B Test prüfen

Ein Test zeigt mehr Umsatz pro Besucher (ARPU), doch die Besucher verteilen sich unerwartet auf Kontrolle und Variante. Dann kann ein Sample Ratio Mismatch das gesamte Ergebnis entwerten. Das Problem fällt im Dashboard leicht durch, weil Conversion Rate, Umsatz und Signifikanz weiterhin plausibel aussehen. Ohne eine feste Prüfung riskierst du, einen technischen Fehler zum nachgewiesenen Gewinner zu erklären.

Sample Ratio Mismatch vor jeder Auswertung prüfen

Ein Sample Ratio Mismatch, kurz SRM, liegt vor, wenn die beobachtete Verteilung deutlich von der geplanten Verteilung abweicht. Bei einem Test mit gleichmäßiger Zuteilung erwartest du langfristig jeweils 50 Prozent der Besucher in Kontrolle und Variante.

Kleine Abweichungen gehören zum Zufall. Bei 10.000 Teilnehmern wären 5.030 Besucher in der Kontrolle und 4.970 in der Variante unauffällig. Eine Verteilung von 5.700 zu 4.300 deutet dagegen klar auf ein Problem hin.

Ein SRM Test prüft, ob der Zufall die Abweichung noch plausibel erklärt. Dafür eignet sich bei zwei oder mehr Varianten ein Chi Quadrat Test. Er vergleicht die beobachteten Teilnehmerzahlen mit den erwarteten Zahlen.

Chi Quadrat = Summe aus (beobachtet minus erwartet)² geteilt durch erwartet

Ich prüfe den SRM vor der eigentlichen Ergebnisanalyse. Wenn die Zuteilung fehlerhaft ist, helfen auch saubere ARPU Berechnungen oder lange Laufzeiten nicht weiter. Der Test gehört dann nicht zu den vollständig auswertbaren Tests.

Warum ein SRM wirtschaftliche Entscheidungen verzerrt

Ein falsches Verhältnis allein verändert noch keinen Umsatz. Die Ursache hinter dem Verhältnis kann jedoch bestimmte Besucher bevorzugt einer Variante zuordnen. Genau daraus entsteht das wirtschaftliche Risiko.

Angenommen, eine Variante lädt auf älteren Smartphones langsamer. Das Testing Tool erfasst einige dieser Besucher erst nach einem erfolgreichen Skriptaufruf. Dadurch fehlen in der Variante überproportional viele mobile Besucher. Wenn mobile Besucher einen niedrigeren ARPU haben, erscheint die Variante besser, obwohl ihre Änderung keinen positiven Effekt erzeugt.

Ähnliche Verzerrungen entstehen, wenn eine Variante Fehler in bestimmten Browsern verursacht, ein Consent Status die Erfassung beeinflusst oder ein Redirect Besucher verliert. Das Dashboard vergleicht dann Gruppen mit unterschiedlichen Eigenschaften.

Statistische Signifikanz löst dieses Problem nicht. Sie beantwortet eine andere Frage und setzt eine korrekte Randomisierung voraus. Mehr Traffic verstärkt bei einem systematischen Fehler oft nur die scheinbare Sicherheit.

Die häufigsten Ursachen in Shopify Tests

Bei der Fehlersuche beginne ich mit der Zuteilung und arbeite mich anschließend bis zum Kaufereignis vor. Diese Ursachen treten besonders häufig auf:

• Das Testing Skript lädt in einer Theme Vorlage später oder gar nicht.
• Ein Redirect verliert Besucher, bevor das Tool die Teilnahme speichert.
• Consent Einstellungen blockieren eine Variante häufiger als die andere.
• Eine Theme Änderung überschreibt Cookies oder Einträge im Local Storage.
• Mehrere Tests greifen gleichzeitig auf dieselben Seiten oder Elemente zu.
• Ein Browserfehler verhindert das Exposure Event in einer Variante.
• Interne Besucher, Bots oder Monitoring Systeme landen bevorzugt in einer Gruppe.
• Das Reporting zählt Besucher nach dem Event statt direkt nach der Zuteilung.

Die letzte Ursache verdient besondere Aufmerksamkeit. Wenn das Tool einen Besucher erst nach einem Klick oder Seitenaufruf zählt, hängt die Stichprobe bereits vom Verhalten nach der Zuteilung ab. Für eine belastbare Analyse muss die Teilnahme möglichst nahe am tatsächlichen Exposure beginnen. Mein Beitrag zum A/B Test Exposure erklärt diese Abgrenzung genauer.

Auch Bots können das Verhältnis verschieben. Eine getrennte Prüfung nach User Agent, Region und ungewöhnlicher Sitzungsaktivität hilft bei der Diagnose. Weitere Prüfschritte findest du im Beitrag zu Bot Traffic im A/B Test.

SRM Schritt für Schritt untersuchen

Die Prüfung gehört in jede standardisierte Auswertung. Ich nutze dafür diesen Ablauf:

1. Ich notiere den geplanten Traffic Split. Bei drei Varianten kann er zum Beispiel 50, 25 und 25 Prozent betragen.
2. Ich exportiere die Zahl der eindeutig zugeordneten Besucher je Gruppe. Sessions eignen sich dafür meist nicht, weil ein Besucher mehrere Sessions erzeugen kann.
3. Ich berechne die erwarteten Teilnehmerzahlen aus Gesamtzahl und geplantem Split.
4. Ich führe einen Chi Quadrat Test mit den beobachteten und erwarteten Zahlen aus.
5. Ich markiere starke Abweichungen mit einem vorab definierten Grenzwert. Für automatische Warnungen nutze ich häufig einen konservativen Wert von p < 0,001.
6. Ich segmentiere die Teilnehmer nach Gerät, Browser, Land, Theme Vorlage und Testtag.
7. Ich vergleiche Zuteilung, Exposure und Kauftracking als getrennte Stufen.
8. Ich dokumentiere Ursache und Entscheidung, bevor ich den Test neu starte oder verwerfe.

Der Grenzwert ersetzt keine Diagnose. Er sorgt dafür, dass das Team nach einer konsistenten Regel arbeitet. Bei vielen parallelen Tests verhindert ein konservativer Grenzwert außerdem zu viele Fehlalarme.

Ein A/A Test hilft dir, wiederkehrende Fehler im gesamten Setup zu erkennen. Ein einzelner sauberer A/A Test beweist jedoch nicht, dass jeder spätere Test korrekt läuft. Deshalb prüfe ich den SRM bei jeder Auswertung erneut.

Mini Case mit 20.000 Testteilnehmern

Ein Shopify Shop plant einen gleichmäßigen Split. Nach zwei Wochen enthält die Kontrolle 10.650 Besucher und die Variante 9.350 Besucher. Insgesamt nahmen 20.000 Personen teil.

Bei einem Verhältnis von 50 zu 50 erwarten wir 10.000 Personen pro Gruppe. Beide Gruppen weichen jeweils um 650 Personen vom Erwartungswert ab.

Kontrolle: 650² geteilt durch 10.000 = 42,25
Variante: 650² geteilt durch 10.000 = 42,25
Chi Quadrat gesamt = 84,50

Bei einem Freiheitsgrad liegt der p Wert weit unter 0,001. Zufällige Schwankungen erklären diese Verteilung praktisch nicht. Ich stoppe deshalb die inhaltliche Bewertung des ARPU Effekts und suche zuerst nach der technischen Ursache.

Die Segmentierung zeigt anschließend, dass Safari Besucher in der Variante deutlich fehlen. Das Testskript kollidiert dort mit einer neuen Consent Konfiguration. Ein Vergleich der bisherigen Umsätze wäre unfair, weil Safari Besucher im Shop einen anderen Warenkorbwert und eine andere Conversion Rate zeigen.

Nach der Korrektur startet der Test mit neuen Besucherzuordnungen. Ich vermische die alten Daten nicht mit dem neuen Lauf. So erhält das Team wieder eine Stichprobe, die zur geplanten Randomisierung passt.

Welche Entscheidung nach einem SRM sinnvoll ist

Ein klarer SRM bedeutet nicht automatisch, dass du jeden Test sofort löschen musst. Die richtige Entscheidung hängt von Ursache, Zeitpunkt und betroffener Metrik ab.

• Bei einem Fehler in der Randomisierung starte ich den Test nach der Korrektur vollständig neu.
• Bei fehlenden Exposure Events prüfe ich, ob eine unabhängige Datenquelle die tatsächliche Teilnahme zuverlässig abbildet.
• Bei einem reinen Dashboard Filter korrigiere ich den Bericht und wiederhole die Prüfung mit Rohdaten.
• Bei einem kurzen Tracking Ausfall verwerfe ich keine Zeiträume ohne vorherige Prüfung. Ein Ausschluss kann selbst neue Verzerrungen erzeugen.
• Bei unklarer Ursache behandle ich das Ergebnis nicht als nachgewiesenen Gewinner.

Diese Entscheidung braucht direkte Verantwortung. Eine Person muss den SRM prüfen, die Diagnose dokumentieren und den Neustart freigeben. In meinem Managed A/B-Testing gehört diese Kontrolle deshalb fest zur laufenden Auswertung. Teams mit eigenem Programm sollten sie als Pflichtschritt in ihr Testing System aufnehmen.

Häufige Fragen

Ist eine Verteilung von 51 zu 49 bereits ein SRM?

Das hängt von der Stichprobengröße ab. Bei wenigen hundert Besuchern ist diese Abweichung meist harmlos, bei mehreren Millionen Teilnehmern kann sie statistisch auffällig sein. Prüfe deshalb Teilnehmerzahlen statt gerundeter Prozentwerte.

Kann ich einen Test mit SRM trotzdem auswerten?

Erst wenn du die Ursache eindeutig kennst und zeigen kannst, dass sie den Vergleich nicht verzerrt. Bei Fehlern in Randomisierung oder Exposure verwerfe ich das Ergebnis in der Regel. Ein hoher scheinbarer Uplift rechtfertigt keine Ausnahme.

Welche Daten soll ich für den SRM Test verwenden?

Nutze eindeutig zugeordnete Besucher, die den Test tatsächlich sehen konnten. Käufe, Klicks oder Sessions eignen sich nicht als Grundlage, weil das Verhalten nach der Zuteilung diese Zahlen beeinflusst.

Wann soll ich den SRM prüfen?

Eine automatische Prüfung kann täglich laufen, sobald genug Teilnehmer vorliegen. Die verbindliche Kontrolle erfolgt vor jeder Ergebnisentscheidung und vor dem Rollout eines Gewinners.

Beweist ein sauberer SRM Test korrektes Tracking?

Nein. Ein korrektes Verhältnis zeigt lediglich, dass die Gruppengrößen zur geplanten Verteilung passen. Fehler bei Umsatz, Bestellungen oder wiederkehrenden Besuchern können trotzdem bestehen, weshalb du das A/B Test Tracking separat validieren solltest.

Du willst in deinem Shop testen statt raten? Wenn du eine D2C-Brand ab 200.000 EUR Monatsumsatz führst, zeige ich dir in einem kostenlosen Testing-Audit in 30 Minuten, wo dein größter Hebel liegt. Termin buchen. Wenn du noch nicht so weit bist, starte mit meinen kostenlosen Frameworks und Checklisten.