サンプルサイズ:A/Bテストでよく見落とされがちな計算

サンプルサイズ:A/Bテストでよく見落とされがちな計算

ほとんどのA/Bテストは、訪問者が一人も目にする前に失敗に終わる。仮説が弱かったり、デザインが悪かったりするからではなく、そもそもテストによって何らかの結果が得られるのかどうかを誰も検討していないからだ。

よくあるパターンだ。チームがバリアントをリリースし、ダッシュボードを監視し、10日後にチャレンジャーが6%上昇し、p値が0.14になっているのを確認する。誰かが「良い傾向にあるから、もう1週間様子を見よう」と言う。さらに1週間が経過する。今度は4%上昇し、p値は0.09になる。テストは「方向性のある勝利」と判断されてリリースされるか、あるいは結論が出ないとして中止される。どちらにしても、3週間のトラフィックから何も知見は得られず、その結果は誰も確認しなかった4つの数値によって、リリース前に完全に決定されていたのだ。

この記事は、その4つの数字についてです。

4つの入力

サンプルサイズは判断に委ねられるものではありません。それは4つのパラメータから導き出されるものであり、真剣な実験プログラムでは、開始後ではなく開始前にこれらのパラメータを決定します。

入力その意味標準値
ベースラインコンバージョン率テスト対象の指標の現在のレート(テストが実行される正確なページとオーディエンスで測定)データが何を言おうと
最小検出可能効果(MDE)テストで検出できる最小の変化交通量に応じて5~20%の相対的な減少
有意水準(α)実在しない勝者を宣言することに対するあなたの寛容さ0.05
統計的検出力(1−β)効果を検出する確率 is リアル0.80

電卓にその4つを入力すると、必要な訪問者数が返されます。 バリアントごと。 私たちの 無料A/Bテスト計算ツール まさにこの作業は30秒ほどで完了する。それが重要な点だ。チームがこの手順を省略する理由は、難しいからではない。答えが往々にして望ましくないものだからだ。

MDEは誰もが間違える入力です

最小検出可能影響とは、その名前が示唆するようなものではなく、最も大きな損害を引き起こすパラメータのことである。

MDEは 期待される効果です。これは予測でも、目標値でも、予報でもありません。検出可能性の下限値、つまりテストで検出できる最小の真の効果です。MDEを5%に設定すると、「実際の改善が5%未満の場合、このテストではおそらく見逃してしまうだろう」と言っていることになります。

その結果、2つの重大な結果が生じる。

テストは、あなたが設定した質問にしか答えることができません。 MDE(最小検出可能効果)を20%に設定してテストを行った結果、実際の効果が7%だった場合、テスト結果は「有意差なし」となる可能性が高いでしょう。これは、その変異が全く効果がないという証拠ではありません。テストではその規模の効果を検出できなかったという証拠であり、全く異なる意味合いを持ちます。しかし、多くのチームはこれを「テストしたが効果がなかった」と誤解しがちです。

相対的MDEと絶対的MDEは互換性がありません。 ベースラインは2.5%で、10% 相対 MDEとは、2.75%への動きを検出すること、つまり 絶対の 0.25パーセントポイントの差です。絶対パーセントポイントを期待して計算機のフィールドに10を入力すると、2.5%から12.5%への変化を検出するように要求したことになり、ツールは400人の訪問者で十分だと陽気に答えます。計算機がどの表記法を使用しているかを確認してください。このたった一つの混乱が、私たちが目にする他のどのエラーよりも多くのテスト計画を無効にしています。

具体的な例

あるeコマース企業は、新しい商品詳細ページのレイアウトをテストしたいと考えています。そのページのベースラインコンバージョン率は2.5%です。彼らは、コンバージョン率が10%向上し、2.75%になることを検出したいと考えています。

α = 0.05、検出力 80% の場合、要件はおおよそ 各バリエーションにつき64,000万人の訪問者つまり、合計で約12万8000人。

そのページには毎月4万人の訪問者があります。つまり、このテストが想定していたサンプルサイズに達するには、3か月強かかるということです。

この数字こそが議論の方向性を変える。3ヶ月という期間が不可能だからではなく、発売前にトレードオフを明確にした上で、公然と決定を下したからこそ、21日目になってようやく気づくような、じわじわとした失望感から解放されるのだ。

次に、入力値を1つ変更します。ベースラインは同じままで、相対的な上昇率が10%ではなく20%になるようにサイズを設定します。

MDE(相対的)絶対差バリアントごとの訪問者数月収40万ドルの時
5%0.125 pp〜256,000〜13ヶ月
10%0.25 pp〜64,000〜3.2ヶ月
20%0.5 pp〜16,800〜25日
30%0.75 pp〜7,700〜12日

MDEを半分にすると、サンプルサイズは約4倍になります。この関係はこれらの数値特有のものではなく、サンプルサイズは効果量の2乗に反比例します。これは実験設計において最も重要な理解事項であり、どこにレバレッジをかけるべきかを教えてくれます。 変更規模を拡大する方が、トラフィックを増やすよりもはるかに安上がりだ。

ボタンを2ピクセル移動させるだけの控えめな変更では、中規模サイトでは到底提供できないほどのサンプルサイズが必要となる。一方、ページ構造を再構築するような変更であれば、成功する可能性は十分にある。慎重なテストプログラムが行き詰まるのは、アイデア自体が間違っているからではなく、サンプルサイズが小さすぎて効果を測定できないからだ。

交通量が実際にどこにあるのか

計算に隠されたもう一つの要素は、基準率である。基準率が上昇するにつれて、必要なサンプルサイズは急激に減少する。

同じ10%の相対MDEを、チェックアウトの配送ステップに適用してみましょう。このステップでは、到着した商品の40%が支払いに進みます。

  • 基準値 2.5% → バリアントあたり約64,000
  • 基準値 40% → バリアントあたり約2,400

同じMDE、同じ自信、同じパワー。交通量は26分の1に減少。

もちろん、そのページへの訪問者数は商品詳細ページ(PDP)よりはるかに少ない。しかし、トラフィックの減少よりも需要の減少の方が速いため、中程度のトラフィックのサイトでは、ディープファネルテストが実際に完了できる唯一のテストとなることが多い。サイト全体のコンバージョン率が2%の場合、ホームページのテストには1年間の取り組みが必要となり、チェックアウトページのテストは2週間で済む。

実践的なアドバイス:計算機が不可能な数値を返した場合、MDE(最小検出可能範囲)を広げる前に、ファネルのさらに下流で、同じ仮説をより高い基準値に対して検証できる段階があるかどうかを確認してください。

それをスキップすると実際に何が問題になるのか

ここには2つの故障モードがあり、2つ目のモードは1つ目のモードよりもあまり知られていない。

あなたは真の改善点を見逃している。 検出力が不十分なテストでは、実際に効果のある変更に対して「有意差なし」という結果が出てしまう。チームはアイデアが悪かったと結論付け、本来なら利益を生むはずだった方向性を放棄してしまう。これは誰もが知っている失敗例であり、2つの失敗例のうち、費用がかからない方である。

当選者数が水増しされている。 これは、プログラムの数値を静かに歪めるものです。検出力の低いテストでは、結果が有意水準を超える唯一の方法は、ランダムノイズがたまたまそれを十分に押し上げる場合です。つまり、 do 重要な数値として宣言されるものは、概して真実よりも大きい。数値が低いほど、誇張の度合いは大きくなる。

つまり、性能の低いプログラムは単に成果を見逃すだけではありません。過大評価された効果を上げた成功事例ばかりのテストログを作成し、それをトラフィックで乗算して、決して実現しない収益予測を立ててしまうのです。半年後、なぜこれらの成功事例の合計が最終的な収益に反映されないのかと誰かが疑問に思うのですが、大抵の場合、これがその答えです。

これは解析段階で修正できる問題ではありません。設計段階で未然に防ぐ必要があります。

バリアントごと(合計ではなく)

計算機の出力が要件です 各腕ごとに テストの。2つのバリアントは、数が2倍になることを意味します。これは当たり前のことのように聞こえますが、常に誤解され、たいていは楽観的な方向に解釈されます。

複数のバリアントは問題を2倍に複雑化させる。A/B/C/Dテストでは、単一群の図の4倍のサンプルが必要となる。 (NAIST) と 対照群との同時比較を3つ行うと、少なくとも1つの偽陽性が発生する確率が、名目上の5%をはるかに超えてしまいます。それを補正すると、要求される精度はさらに高くなります。

ほとんどのサイトにとって、実用的なルールはこうです。トラフィックに余裕がない限り、2つのテストモードを実行するべきです。2つのテストモードすらまともに実行できないページで4つのテストモードを実行しても、学習効果は4倍にはなりません。学習効果はゼロで、しかも結果が出るのに時間がかかります。

期間は別の制約です

必要なサンプルサイズを達成することは必要条件ではあるが、十分条件ではない。

4日間で目標値に達したテストは、4日間の行動をサンプリングしたものです。平日と週末のトラフィックはコンバージョン率が異なります。eコマースでは給料日サイクルが重要です。テストの途中で開始される有料キャンペーンは、その下にあるオーディエンス構成を変えてしまいます。新しいデザインは目新しさを生み出しますが、その効果は徐々に薄れていきます。見慣れないレイアウトへの初期のエンゲージメントは、安定したパフォーマンスの推定値にはなりません。

サンプルサイズの計算結果に関わらず、少なくとも1週間、できれば2週間は運用してください。サンプルサイズと景気循環のうち、より長い方の制約が適用されます。また、毎朝チェックして数字が良さそうになったら停止するのではなく、終了日を事前に設定してください。これは、誤った勝者を生み出す非常に効果的な方法の一つです。

その数字が不可能な場合

正直に言うと、テストは実行できない場合もあります。これは有益な情報であり、それに対する妥当な対応策が5つあります。

より大きな変更を試してみる。 二次関数的な関係性から、これは圧倒的に最も効果的な選択肢となる。ボタンではなく、フローを再設計すべきだ。

より高い基準指標に移行する。 購入ではなく、カートへの追加やチェックアウトへの入力に対してテストを実施してください。効果量はより大きなベースで測定され、必要なサンプルサイズは削減されます。測定対象が代理指標であることを受け入れ、収益との関連性は別途検証してください。

ファネルのさらに下流でテストする上記のとおり。

類似ページをグループ化する。 単一のカテゴリページではなく、すべてのカテゴリページに対して1つのテストを実行することで、利用可能なトラフィックを増やすことができます。ただし、ページ間の動作が十分に類似していて、トラフィックの集約が妥当である場合に限ります。

テストをやめて、研究を始めよう。 サイトが実験を行うのに十分なパワーを備えていない場合、A/Bテストは適切な手段ではありません。ユーザビリティテスト、セッション記録、ヒューリスティックレビューの方が、問題点をより迅速かつ安価に発見できます。定量的な検証は、変化が測定可能なほど大きくなった後に行います。これは恥ずべきことではありません。厳密さを装うためにパワー不足のテストを実施することは、テストを実施しないよりも悪い結果を招くでしょう。

飛行前チェックリスト

テスト開始前に:

  • [ ] ベースラインは、サイト全体ではなく、テストが実行される実際のページとオーディエンスに基づいて測定されます。
  • [ ] MDEは、相対値または絶対値を指定して、書面で明示的に述べられている。
  • [ ] サンプルサイズが計算されました バリアントごと そして腕の数を掛け合わせる
  • [ ] 必要な所要時間と利用可能なトラフィックを比較し、起動前に回答を承認する
  • [ ] 終了日は事前に決定済み
  • [ ] サンプル計算が何を示していようとも、最低でも1回のビジネスサイクル全体
  • [ ] ランダム化単位は分析単位(訪問者レベルの割り当て、訪問者レベルの指標)と一致します
  • [ ] トラフィックの分割は最初の数時間で確認されました。50/50のテストで53/47という結果が出た場合、計測機器に問題があることを意味し、問題が見つかるまで結果は使用できません。

バリアントを作成する前に数値を計算してください

計算全体はわずか30秒で完了し、構築するものに大きな変化をもたらします。テストの規模を最初に把握するチームは、より大胆なテスト案を設計できます。なぜなら、控えめなテスト案ではどれだけのコストがかかるかを把握できるからです。

基準となるコンバージョン率、検出したい効果、信頼度と検出力の設定を入力してください。返された数値がトラフィック量よりも大きい場合でも、それはキャンペーンを開始する理由にはなりません。むしろ、テスト結果からプランを変更する必要があると判断されるでしょう。

よくある質問

A/Bテストを実施するには、何人の訪問者が必要ですか? 普遍的な数値はありません。これは、ベースラインのコンバージョン率、検出したい最小効果、選択した有意水準と検出力によって異なります。コンバージョン率が2.5%のページでは、10%の相対的な改善を検出するために、バリエーションごとに約64,000人の訪問者が必要です。一方、コンバージョン率が40%のチェックアウトステップでは、同じ相対的な効果を検出するために約2,400人の訪問者が必要です。

適切な最小検出可能効果とは何ですか? トラフィックが妥当な期間内に処理できる最小値。利用可能なトラフィックと2~4週間の目標期間から始め、それに合った最小実行可能値(MDE)を逆算します。そのMDEが、テスト対象の変更によって実際に発生する可能性のある値よりも大きい場合は、テストを再設計してください。

明らかに勝っている場合、テストを途中で中止してもいいですか? 標準的な固定期間テストではそうはいきません。繰り返しチェックを行い、最初の有意な結果が得られた時点で停止すると、偽陽性率が5%をはるかに超えてしまいます。早期停止が必要な場合は、逐次テストやベイズフレームワークなど、そのための専用手法を使用し、ローンチ前に決定してください。ローンチ中に決定してはいけません。

サンプルサイズが満たす前に検定結果が有意水準に達した場合はどうなりますか? 疑ってかかるべきであり、計画通りの結末まで走り続けなければならない。十分な検出力がない状況で早期に有意な結果が出るのは、まさに誇張された、再現性のない勝者を生み出すパターンである。

80%の出力で十分でしょうか? これは一般的なデフォルト設定であり、妥当な出発点ではありますが、実際の効果を見逃す可能性が20%あることを意味します。チェックアウト画面の再設計や価格変更といった重大な決定の場合は、90%の検出力があれば追加のサンプル数を取る価値があります。低コストで元に戻せる変更であれば、80%で十分です。

あなたのテストプログラムが本当に正しい結果を出しているかどうか、確信が持てませんか?

テストログに小さな成功事例が多数含まれているにもかかわらず、それが最終的な数値に反映されない場合、問題は通常、分析の上流段階にあります。当社は実験プログラムを精査し、設計上の問題点を明確にお伝えします。

CROサービスについてもっと詳しく知りたいですか? 


チャグダシュ・ポラット
著者

チャグダシュ・ポラット

チャグダシュ・ポラットはSwitasの共同創業者であり、eコマース、旅行、ヘルスケア、公共部門など幅広い分野のブランドに対し、テクノロジーと成長に関するコンサルティングを提供しています。コンピュータサイエンスの学位を取得後、過去10年間でソフトウェア開発からマーケティング、製品、戦略の上級職へとキャリアを積み、現在はCRO(コンバージョン率最適化)、アナリティクス、そして測定に耐えうる成長システムの構築について企業にアドバイスを行っています。


関連記事

スウィタス

Magnify: Engin Yurtdakul によるインフルエンサー マーケティングの拡大

Microsoft Clarityのケーススタディをご覧ください

Microsoft Clarityは、Switasのような企業が直面する課題を理解している、実際のプロダクト担当者によって、実用的で現実的なユースケースを念頭に構築された製品として高く評価されました。レイジクリックやJavaScriptエラー追跡といった機能は、ユーザーの不満や技術的な問題を特定する上で非常に役立ち、ユーザーエクスペリエンスとコンバージョン率に直接影響を与える、的を絞った改善を可能にしました。