Products
Solutions
Resources
Ein kurzer Leitfaden zum Sample Ratio Mismatch (SRM)
Hinweis: Dies ist eine deutsche Übersetzung eines ursprünglich auf Englisch veröffentlichten Blogs, den Sie hier finden können: https://statsig.com/blog/sample-ratio-mismatch
"Lass uns einen Münzwurf entscheiden lassen – wer zuerst 50 erreicht, gewinnt."
Stellen Sie sich vor, wir werfen mehrmals eine faire Münze und erhalten 8-mal Kopf und 2-mal Zahl. (Eine faire Münze ist ausbalanciert und wurde noch nie in einer Zaubershow verwendet.)
Obwohl wir erwarten würden, zur Hälfte Kopf und zur Hälfte Zahl zu erhalten, könnten wir einfach seltsame Ergebnisse bekommen haben. Wenn wir die Münze für 100 Versuche weiterwerfen und 80-mal Kopf und 20-mal Zahl erhalten, werden wir viel misstrauischer bezüglich der "Fairness" dieser Münze sein.
Wenn wir diesen Münzwurf verwenden, um Nutzer zufällig der Test- oder Kontrollgruppe eines Experiments zuzuweisen, wird der Mangel an "Fairness" als Sample Ratio Mismatch oder SRM bezeichnet.
Wir bewerten diesen Mangel an Fairness mit einem Chi-Quadrat-Test, der die beobachteten 80/20-Ergebnisse mit den erwarteten 50/50-Ergebnissen einer fairen Münze vergleicht. Der p-Wert aus diesem Chi-Quadrat-Test ist die Rate von Ergebnissen, die mindestens so extrem sind wie das, was wir beobachtet haben und die wir bei wiederholten Versuchen mit einer wirklich fairen Münze erwarten würden.
Intuition entspricht dem SRM-p-Wert
Die Intuition aus unseren Münzwurf-Experimenten spiegelt sich im p-Wert der Chi-Quadrat-Tests für jeden dieser Fälle wider. Ergebnisse von 80% Kopf in einem 10-Wurf-Experiment zu sehen, hat einen p-Wert von 0,058, während 80% Kopf in einem 100-Wurf-Experiment einen p-Wert von praktisch 0 hat.
Warum ist SRM schlecht?
Sample Ratio Mismatch ist ein Beweis für Selektionsverzerrung
Eine der grundlegenden Annahmen von Zufallsexperimenten ist, dass es eine zufällige Zuweisung von Individuen zur Kontroll- oder Testgruppe gibt. Andernfalls könnten andere Variablen existieren, die nicht unabhängig von der Zuweisung sind und die wahre Ursache für beobachtete Unterschiede zwischen Behandlung und Kontrolle sein könnten.
Weist auf ein Implementierungsproblem hin
Die Tatsache, dass SRM vorliegt, bedeutet wahrscheinlich, dass es ein Problem in der Experimentimplementierung gibt, aber es könnte entweder in der Art und Weise auftreten, wie Nutzer ihrer Behandlungsgruppe zugewiesen werden, oder wie die Daten nachträglich gemessen oder verarbeitet werden. Wenn Sie Statsig verwenden, gibt es auch viele dieser potenziellen Ursachen, die wir wahrscheinlich ausschließen können!
Einige zu untersuchende Ursachen:
Einige Nutzer sind nicht für bestimmte Varianten berechtigt: Vielleicht zwingt der Code für Ihre super coole neue Funktion auch unbeabsichtigt ein bestimmtes Nutzersegment in eine spezifische Behandlungsgruppe.
Dies wird nicht passieren, wenn Sie Statsig verwenden, da unser SDK nicht berechtigte Nutzer gleichmäßig über alle Experimentgruppen herausfiltert
Die Einschreibung ist von der Exposition entkoppelt: Vielleicht werden Nutzer auf einer bestimmten Webseite in ein Experiment eingeschrieben, aber nur ihrer Behandlungsgruppe ausgesetzt, wenn sie die relevante Erfahrung erreichen. Wenn jedoch die Exposition der Kontrollgruppe oben auf der Seite erfolgt, aber die Testgruppe scrollen muss, ist dies ein Mechanismus, der SRM verursachen könnte.
Das Statsig SDK koppelt automatisch Zuweisung und Exposition, indem es standardmäßig automatisch Expositionen für Sie protokolliert, aber dies kann bei Bedarf auch entkoppelt werden.
Das Randomisierungsverfahren randomisiert nicht richtig: Die Funktion, die Sie verwenden, um Nutzer "zufällig" einer Behandlung zuzuweisen, ist tatsächlich nicht zufällig und führt möglicherweise Verzerrungen ein.
Dies wird nicht passieren, wenn Sie Statsig verwenden - wir verwenden den SHA256-Hashing-Algorithmus, um Behandlungsgruppen deterministisch basierend auf einer Einheits-ID und Experiment-ID zuzuweisen
Unterschiede in der Absturzrate zwischen Test- und Kontrollgruppen: Wenn der neue Code Abstürze einführt oder behebt, könnte dies zu SRM führen. Wenn die Testgruppe mehr Abstürze hat, würde dies dazu führen, dass mehr Nutzer in der Testgruppe keine Expositionen senden können, was SRM verursacht.
Datenverarbeitungsprobleme: Es kann einen Prozess geben, durch den diese Daten nur für die Kontroll- oder Testvariante gelöscht oder dupliziert werden.
Wenn Sie alle Ihre Daten über Statsig senden, übernehmen wir die Datenverarbeitung und es sollte kein SRM aus der Datenverarbeitung entstehen
Hatten Sie einfach nur super viel Pech?
Wahrscheinlich nicht.
Das ist es, was der p-Wert quantifiziert: die Rate von Ergebnissen, bei denen Gruppen mindestens so extrem aufgeteilt sind wie das, was wir beobachtet haben, und die wir bei wiederholten Versuchen auf die gleiche Weise erwarten würden. Dies ist wirklich unwahrscheinlich, könnte aber das sein, was passiert.
SRM in der Statsig-Konsole
In Statsig überprüfen wir automatisch auf SRM für jedes Experiment. In der Diagnostik, unter Experiment-Gesundheitschecks, wenn Sie sehen, dass "Expositionen sind ausgeglichen" grün ist, bedeutet das, dass wir kein SRM erkannt haben.
Wir betrachten Expositionen als unausgeglichen, wenn der SRM-p-Wert unter 0,01 liegt.
Wenn Sie Statsig nicht verwenden und überprüfen möchten, ob Ihr Experiment SRM hat, möchten Sie wahrscheinlich keinen Chi-Quadrat-Test von Hand durchführen. Ich habe diesen SRM-Rechner schon früher verwendet und ihn benutzt, um die p-Werte für unsere (8, 2) und (80, 20) Beispiele oben zu berechnen.
Statsig verfolgt automatisch Ihren SRM-p-Wert im Zeitverlauf, was es Ihnen ermöglicht zu identifizieren, ob/wann Sie Beweise für SRM sehen. Jeder SRM-p-Wert unter 0,01 bedeutet, dass das Experiment den Gesundheitscheck "Expositionen sind ausgeglichen" nicht besteht.
Das bedeutet, dass es auch einen Ausgangspunkt für die Fehlersuche bei Problemen gibt, die das SRM verursacht haben könnten.
Wenn SRM erkannt wird und die Grundursache gefunden wird, können Sie das Experiment einfach abbrechen und neu zuweisen. Dieses neue Experiment mit dem gleichen Design wird auch ein anderes "Salz" verwenden, um die Gruppe eines Nutzers zu randomisieren, was bedeutet, dass Nutzer unabhängig von ihrer Gruppe in der vorherigen Iteration dieses Experiments zufällig einer Gruppe zugewiesen werden. Dies ist wichtig, weil es sicherstellt, dass das neue Ergebnis nicht durch eine negative oder positive Erfahrung im vorherigen Durchlauf beeinflusst wird.
Muss ich meine Ergebnisse verwerfen, weil ich SRM habe?
Wir möchten die Existenz von SRM in einem Experiment nicht auf die leichte Schulter nehmen. Es zeigt an, dass sehr wahrscheinlich etwas methodisch falsch in Ihrem Experiment ist. Wir möchten jedoch möglicherweise das gerade durchgeführte Experiment nicht vollständig außer Acht lassen.
Wichtig ist, dass ich die Grundursache von SRM kennen muss, wenn ich diese Entscheidungen treffe. Ohne dieses entscheidende Wissen ist es unmöglich, die potenziellen Quellen experimenteller Verzerrung zu berücksichtigen und auf welche Weise wir uns wohl dabei fühlen, Ergebnisse zu verwenden.
Es gibt einige Faktoren, die ich berücksichtige, wenn ich ein Experiment mit SRM betrachte, um zu bestimmen, ob ich irgendwelche richtungsweisenden Erkenntnisse aus dem Experiment gewinnen kann:
Wie unterschiedlich ist die Gruppe von Nutzern, die SRM verursacht, von anderen Nutzern?
z.B. in unserem Experiment sind alle neuen Nutzer in der Testgruppe, und neue Nutzer verhalten sich sehr unterschiedlich von langjährigen Nutzern, also verwerfe ich die Experimentergebnisse vollständig und starte das Experiment neu.
Könnte der Unterschied zwischen Nutzern, der SRM verursacht, auch die Behandlung beeinflussen?
z.B. in unserem Experiment habe ich doppelte Einträge für alle Internet Explorer-Nutzer, für die meine neue Funktion höhere Latenz verursacht. Dies scheint die negativen Ergebnisse zu treiben, die ich insgesamt sehe, während Nutzer mit anderen Browsern einen kleinen positiven Einfluss von der neuen Funktion zu haben scheinen. Dies könnte mich dazu veranlassen, mein Produkt zu iterieren, um die Latenz über alle Webbrowser hinweg zu reduzieren, bevor ich ein weiteres Experiment durchführe.
Am Ende des Tages ist es eine Ermessensentscheidung.
Während es Nachteile geben kann, ein Experiment neu zu starten und keine Erkenntnisse aus der vorherigen Version zu ziehen, in der SRM vorhanden war (verzögerte Entscheidungsfindung, Bereitstellung einer minderwertigen Erfahrung für Nutzer), wäre der wissenschaftlich rigoroseste Ansatz, diese Experimente immer neu durchzuführen, wie sie entworfen wurden, sobald das Problem, das SRM verursacht, gefunden wurde.
Wenn Sie die Ergebnisse eines Experiments trotz des Vorhandenseins von SRM berücksichtigen möchten, kann die Kontrolle von Vor-Experiment-Verzerrungen mit CUPED helfen, Verzerrungen zu adressieren.