Platform
Resources
サンプル比率の不一致（SRM）に関する簡単ガイド
注記：これは英語で公開されたブログの日本語訳です。原文はこちらでご覧いただけます：https://statsig.com/blog/sample-ratio-mismatch
「コイントスで決めよう - 先に50回勝った方の勝ち」
公正なコインを何回か投げて、表が8回、裏が2回出たとします。（公正なコインとは、バランスの取れたコインで、マジシャンの手品で使われたことがないものです。）
表と裏が半々になることを期待しますが、単に変な結果が出ただけかもしれません。コインを100回投げ続けて、表が80回、裏が20回出た場合、このコインの「公正さ」についてはるかに疑わしくなるでしょう。
このコイントスを使って、実験のテストグループまたはコントロールグループにユーザーをランダムに割り当てている場合、この「公正さ」の欠如はサンプル比率の不一致（SRM）と呼ばれます。
この公正さの欠如を、私たちが見ている80/20の結果と、公正なコインから期待される50/50の結果を比較するカイ二乗検定で評価します。このカイ二乗検定のp値は、真に公正なコインで繰り返し試行した場合に、観察された結果と同じかそれ以上に極端な結果が見られると期待される割合です。
直感はSRMのp値に対応する
コイントス実験からの直感は、これらの各事例のカイ二乗検定のp値に反映されています。10回のコイントス実験で80%が表という結果を見ることのp値は0.058ですが、100回のコイントス実験で80%が表になることのp値は実質的に0です。
なぜSRMは悪いのか？
サンプル比率の不一致は選択バイアスの証拠
ランダム実験の基本的な前提の1つは、コントロールグループまたはテストグループへの個人のランダムな割り当てがあることです。そうでなければ、割り当てから独立していない他の変数があり、それが私たちが観察する処理とコントロール間の違いの真の原因である可能性があります。
実装の問題を示している
SRMがあるという事実は、実験の実装に何らかの問題がある可能性が高いことを意味しますが、それはユーザーが処理グループに割り当てられる方法、またはデータが事後的に測定または処理される方法のいずれかで発生する可能性があります。Statsigを使用している場合は、これらの潜在的な原因の多くをおそらく除外できます！
調査すべきいくつかの原因：
一部のユーザーは一部のバリアントの対象外：あなたの超クールな新機能のコードが、特定のユーザーセグメントを特定の処理グループに強制的に入れてしまうかもしれません。
Statsigを使用している場合、これは起こりません。なぜなら、私たちのSDKは対象外のユーザーをすべての実験グループ間で均等にフィルタリングするからです
登録と露出が分離されている：おそらくユーザーは特定のウェブページで実験に登録されますが、関連する体験に到達した場合にのみ処理グループに露出されます。しかし、コントロールグループの露出がページの上部で起こるのに対し、テストグループはスクロールする必要がある場合、これはSRMを引き起こす可能性のあるメカニズムです。
Statsig SDKは、デフォルトで露出を自動的にログに記録することで、割り当てと露出を自動的に結合しますが、必要に応じて分離することもできます。
ランダム化手順がランダムではない：ユーザーを処理に「ランダムに」割り当てるために使用している関数が実際にはランダムではなく、バイアスを導入している可能性があります。
Statsigを使用している場合、これは起こりません - 私たちはSHA256ハッシュアルゴリズムを使用して、ユニットIDと実験IDを与えられた処理グループを決定論的に割り当てます
テストグループとコントロールグループ間のクラッシュ率の違い：新しいコードがクラッシュを導入または解決する場合、これはSRMをもたらす可能性があります。テストグループでクラッシュが多い場合、テストグループのより多くのユーザーが露出を送信できなくなり、SRMを引き起こします。
データ処理の問題：このデータがコントロールまたはテストバリアントのみで削除または複製されるプロセスがある可能性があります。
Statsigを通じてすべてのデータを送信している場合、私たちがデータ処理を行うため、データ処理からSRMが発生することはありません
単に非常に不運だったのか？
おそらく違います。
これがp値が定量化していることです：同じ方法で実施された繰り返し試行で見ることが期待される、観察されたものと少なくとも同じくらい極端にグループが分割された結果の割合。これは本当にありそうもないことですが、起こっていることかもしれません。
StatsigコンソールでのSRM
Statsigでは、すべての実験に対してSRMを自動的にチェックします。診断の実験ヘルスチェックで、露出がバランスされているが緑色の場合、SRMを検出しなかったことを意味します。
SRMのp値が0.01未満の場合、露出がアンバランスであると見なします。
Statsigを使用していない場合で、実験にSRMがあるかどうかを確認したい場合は、おそらく手作業でカイ二乗検定を行いたくないでしょう。私は以前このSRM計算機を使用し、上記の(8, 2)と(80, 20)の例のp値を計算するために使用しました。
Statsigは時間の経過とともにSRMのp値を自動的に追跡するため、SRMの証拠をいつ/どこで見るかを特定できます。0.01未満のSRMのp値は、実験が露出がバランスされているヘルスチェックに失敗することを意味します。
これは、SRMを引き起こした可能性のある問題をデバッグするための出発点もあることを意味します。
SRMが検出され、根本原因が見つかった場合、実験を簡単に放棄して再割り当てできます。同じ設計の新しい実験では、ユーザーのグループをランダム化するために使用される異なる「ソルト」も持つため、ユーザーはこの実験の前回の反復でのグループとは独立してグループにランダムに割り当てられます。これは重要です。なぜなら、新しい結果が前回の実行での否定的または肯定的な経験の影響を受けないことを確実にするからです。
SRMがあるため、結果を破棄しなければならないのか？
実験にSRMが存在することを軽視したくありません。それは、実験に方法論的に何か間違っている可能性が非常に高いことを示しています。しかし、実行したばかりの実験を完全に無視したくない場合もあります。
重要なのは、これらの判断を下す際にSRMの根本原因を知る必要があることです。この重要な知識がなければ、実験バイアスの潜在的な原因と、結果を使用することに快適に感じる方法を検討することは不可能です。
SRMのある実験を見ているときに、実験から方向性のある洞察を得ることができるかどうかを判断するために考慮するいくつかの要因があります：
SRMを引き起こしているユーザーグループは他のユーザーとどれくらい異なるか？
例：私たちの実験では、新規ユーザーはすべてテストグループにいて、新規ユーザーは長期ユーザーとは非常に異なる行動をするため、実験結果を完全に無視して実験を再開します。
SRMを引き起こしているユーザー間の違いは、処理にも影響を与える可能性があるか？
例：私たちの実験では、新機能がより高いレイテンシを引き起こすInternet Explorerユーザーのすべてに重複したエントリがあります。これが全体的に見られる否定的な結果を推進しているようですが、他のブラウザを使用しているユーザーは新機能から小さな肯定的な影響を受けているようです。これにより、別の実験を実行する前に、すべてのウェブブラウザでレイテンシを削減するために製品を反復することになるかもしれません。
結局のところ、それは判断の問題です。
実験を再開し、SRMが存在した以前のバージョンから学習を得ないことには欠点があるかもしれませんが（意思決定の遅延、ユーザーに劣った体験を提供する）、最も科学的に厳密なアプローチは、SRMを引き起こしている問題が見つかったら、これらの実験を設計どおりに常に再実行することです。
SRMの存在にもかかわらず実験の結果を検討したい場合は、CUPEDを使用して実験前のバイアスを制御することがバイアスに対処するのに役立つかもしれません。