> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
> Use this file to discover all available pages before exploring further.
# サンプル比の不一致
> 実験結果の整合性を確保するために、サンプル比の不一致(SRM)を検出してトラブルシュートする方法を学びます。
## サンプル比の不一致とは?
サンプル比の不一致(SRM)は、実験バリエーション間のテスト対象の実際の分布が意図された分布と一致しない場合に発生します。つまり、バリアントが期待よりも大幅に多い、または少ないトラフィックを受け取ります。SRMは、トラフィックを均等に分割したかどうかに関係なく、バリエーション間で不均等なトラフィック分布を引き起こします。
**例:** オリジナルに50%、バリエーションに50%のトラフィック配分でキャンペーンを開始します。データがオリジナルに50,000の訪問者、バリエーションに48,900の訪問者を示している場合、Kameleoonネイティブのアプリ内SRM検出テストは、結果をサンプル比の不一致に対して陽性としてフラグ付けします。
Kameleoonは[カイ二乗適合度検定](https://en.wikipedia.org/wiki/Goodness_of_fit)を実行してSRMを検出し、変数が指定された分布と一致するかどうかを判断します。Kameleoonはp値に0.001のしきい値を使用します。p値がこのしきい値を下回ると、実験はSRMに対して陽性となります。
*結果ページでのKameleoonネイティブのアプリ内SRM検出アラート*
## SRMはなぜ重要か?
SRMは、実験トラフィック割り当てメカニズムにバイアスがあることを示しています。このバイアスは、A/Bテスト統計計算の基礎となるコア仮説に反するため、実験結果を無効にする可能性があります。
この問題は、トラフィックの多いサイトで特に重要であり、小さな不一致でも結果に大きな影響を与え、誤った意思決定につながる可能性があります。Kameleoonのアプリ内SRMアラートにより、直感ではなく統計テストに基づいて意思決定できます。
## 実験がSRMに対して陽性の場合の対処方法
SRMを検出したときに、すぐに実験結果を無視する必要はありません。SRMの原因を特定し、問題のある訪問者をフィルタリングした後に不一致が消える場合、依然として有効な結論を導き出せます。
SRMは、バリエーションコードの非互換性のためにブラウザが訪問者を誤って分類した場合によく発生します。その結果、訪問者はバリエーションではなく参照を見て、システムは露出データを収集できません。この問題のトラブルシュートを行うには:
1. 実験の**結果**ページを開きます。さらにバイアスのあるデータ収集を防ぐために、まず実験を一時停止します。
2. ゴールまでスクロールし、**分割**をクリックします。
3. すべてのゴールに分割フィルタを適用します。
4. 分割レポートで、分割変数がトラフィック配分に影響しているかどうかを確認します。**デバイスタイプ**、**ブラウザ**、**オペレーティングシステム**、および利用可能なカスタムデータを確認します。レポートが不一致を示している場合、SRMの原因となっている変数を特定したことになります。そうでない場合は、原因を特定するまで分割フィルタを適用し続けます。
5. 誤った割り当ての影響を受けた訪問者を除外するためのフィルタを実験結果に適用します。フィルタリングされた結果で、勝者バリエーションを判断できます。
SRMの根本原因に対処した後、実験を再開できます。
## SRMの原因は何ですか?
SRMの根本原因は、実験、組織、ユーザーによって異なります。SRMに対して陽性の実験のトラブルシュートには、次のチェックリストを使用してください:
* **一意の識別子を確認:** 訪問者に強力な一意の識別子を使用していることを確認します。デフォルトでは、Kameleoonは一意の訪問者ID(Kameleoon `visitorCode`)を使用します。Kameleoonは[割り当てアルゴリズム](https://storage.googleapis.com/kameleoon-storage-documentation/user-manual/pdf/statistics-at-kameleoon.pdf)でこのコードをハッシュ化して、バリエーションをランダムに選択します。デフォルトの訪問者コードまたはユーザーIDをマップするカスタムデータを使用していない場合、IDは少なくとも16文字のランダムな文字(小文字と数字)で構成されている必要があります。
* **実行遅延を検証:** バリエーション実行に影響を与える遅延がないことを確認します。例えば、バリエーションがKameleoonがインストールされていないページにリダイレクトする可能性があります。
* **カスタム割り当てスクリプトを確認:** 実験が[カスタムバリエーション割り当て](../../../developer-docs/apis/activation-api-js/tutorials/managing-a-variations-allocation-according-to-specific-criteria)スクリプトを使用しているかどうかを判断します。これらのスクリプトは標準の割り当てアルゴリズムをバイパスし、SRMを引き起こす可能性があります。
* **構成変更を確認:** テスト偏差の更新、バリエーションの削除、トラフィックの再配分はSRMフラグをトリガーする可能性があります。
将来の実験で不一致を防ぐために、その起源を特定します。SRMに対して陽性の実験を異なる分割フィルタで分析して、根本原因を素早く特定します。さらに潜在的な原因については、この[原因の分類](https://www.lukasvermeer.nl/srm/docs/causes/)を参照してください。
## SRMはどのくらい頻繁ですか?
SRMテストは、潜在的な問題の幅広い範囲を検出できる強力なツールです。この範囲が広いため、テストは予想よりも頻繁に陽性結果を返すことがあります。平均して、Kameleoonで実施された実験の4.5%がSRMに対して陽性となります。
Microsoftは2020年9月に[SRM](https://www.microsoft.com/en-us/research/group/experimentation-platform-exp/articles/diagnosing-sample-ratio-mismatch-in-a-b-testing/)について次のインサイトを共有しました:
「LinkedInやYahooなどの企業からの最近の研究貢献、および当社の研究は、SRMが比較的頻繁に発生することを確認しています...LinkedInでは、ズームインされたA/Bテストの約10%がこのバイアスに悩まされていました。Microsoftでは、最近の分析で、A/Bテストの約6%にSRMがあることが示されました。」