小規模サイトのA/Bテストはどう計画する?成果数と停止条件の考え方

Web改善 · 実務ガイド
小規模サイトのA/Bテストはどう計画する?成果数と停止条件の考え方
問い合わせが2件から3件へ増えたら新案を採用してよいか迷う経営者へ。A/Bテストは2案を条件をそろえて比べる方法ですが、成果が少ないと偶然の差を見分けにくくなります。
架空の企業サイトで、成果数と対象数、検出したい差、計測方法、期間、停止条件を整理します。必要人数を一律に決めず、担当者へ算出条件を渡せる試験計画を作ります。

この記事でできるようになること
- 成果率の差と、成果件数の少なさを分けて説明できる
- 必要数を算出する前提と停止条件を記入できる
- 実験が難しいときの観察と判断の方法を選べる
01 / Web改善
何を変え、どの成果を比較する?
ボタンの色ではなく、顧客の行動がどう変わるかを仮説にします。

架空の保守会社では、製品ページの「送信」を「保守の相談を送る」へ変える案を考えます。顧客が押した後を理解しやすくなり、有効な相談を完了する人が増えるという仮説です。文章、位置、入力項目を同時に変えると、何を比較したかが曖昧になります。
主指標は「比較対象として割り付けたユーザーのうち、有効な相談を完了した割合」とします。ボタンのクリックだけを成功にすると、押した後で迷って戻った人も成功へ含まれます。広告、紹介、社員の確認アクセスをどう扱うかも試験前に決めます。
同じ人が何度も訪れる場合には、訪問回数と人の数が違います。2案を同じ人に交互に出すと経験が混ざる場合もあります。ユーザー単位の割付と集計、必要な同意や計測の条件を担当者が確認します。経営者は測りたい成果と禁止したい不具合を決めます。
比較する単位も先に決めます。同じ人が複数回訪問して両方の案を見る設計と、人ごとに案を固定する設計では、データの扱いが異なります。試験担当は割付方法、対象外にする訪問、同じ人の再訪の扱いを記録します。ユーザー単位とセッション単位を途中で変えたり、繰り返したイベントを新しい成果として足したりしないようにします。
経営者と試験担当が、変える1点・主な成果・守る条件を計画へ書いてください。
02 / Web改善
2件と3件の差で、勝ったと言える?
割合と母数を並べ、少数の成果だけで結論を急ぎません。

架空の記録で案Aは200ユーザー中2件、案Bは200ユーザー中3件の相談です。成果率は1%と1.5%ですが、これだけで案Bの効果が確定したとは言えません。「50%改善」という比率だけを大きく見せると、実際の差が1件であることが伝わりません。
NISTの2つの割合の比較は、成果と非成果、各群の標本数を扱います。大きな標本と小さな標本では、適した検定や近似の条件も異なります。専門担当は、データが独立した比較になっているか、採用する分析が適切かを確認します。
少ない成果に合う検定を選べば、必ずはっきりした結論が出るわけではありません。不確実な結果は不確実と記録します。今回の例は説明用で、p値や信頼区間を算出した検証結果ではありません。実データの結論は担当者の分析と前提を確かめます。
| 案 | 相談完了 | 相談未完了 |
|---|---|---|
| A | 2ユーザー | 198ユーザー |
| B | 3ユーザー | 197ユーザー |
計測担当へ、成果件数・対象数・成果率を同じ表へ残し、勝敗未判定と記してもらってください。
この章の根拠:出典1
03 / Web改善
必要人数を計算する前に何を決める?
現状の成果率と、検出したい差を具体的にします。

「各案100人なら十分」と一律に決めることはできません。必要数は現状の割合、検出したい差、有意水準、検出力、比較方向や分析方法などの前提に依存します。検出力は、ある大きさの差が実際にあるときに、それを見つける確率の考え方です。
経営者は、わずかな差まで確かめたいのか、事業上意味のある差を確かめたいのかを担当者へ伝えます。月に比較対象が100人なら、必要数が数千人の試験を短期間で終える前提にはできません。参加数だけでなく、成果が発生するまでの時間も確認します。
NISTの標本数の説明は前提によって必要数が変わることを示しますが、1標本の式を2群のWebテストへそのまま当てはめません。計算担当、方法、入力条件と結果を記録します。自動計算器を使う場合も、片側・両側、群ごとの人数などの意味を確認します。
必要数を算出する担当へ、基準割合・検出したい差・期間の条件を渡してください。
04 / Web改善
途中で数字が良くなったら止めてよい?
結果を何度も見て有利な日だけ選ばないよう、判定方法を決めます。

毎日結果を見て、案Bが上がった瞬間に終了すると、都合のよい揺れを選ぶことがあります。試験前に必要数、最低期間、判定方法を決め、途中の確認を行う分析方式ならその方式も明記します。期間を終えれば人数不足でも勝敗が分かる、とは考えません。
一方、フォームが送れない、誤った窓口へ送られるなどの不具合は、試験を続ける理由になりません。顧客の操作を止める条件と、成果を評価する終了条件を分けます。不具合で中止した試験の数字を、通常の勝敗判定として発表しないようにします。
GA4のキーイベントをイベントごとに数えるか、セッションごとに数えるかでも値が変わります。試験中に数え方を変えると比較が壊れます。正常な発火、重複、未発火を架空の試験情報で確認し、計測変更が必要なら試験の継続可否を担当者と判断します。
試験担当が、不具合の中止と成果判定の条件を別の欄へ記入してください。
05 / Web改善
必要数が集まらないサイトでは何をする?
顧客の操作観察でつまずきを探し、効果の大きさとは区別します。

少数のサイトでは、2案の統計比較を続けても判断に必要なデータが集まらない場合があります。そのときは顧客に近い参加者へ製品を探して相談へ進む課題を依頼し、どの説明で迷うかを観察します。営業やサポートに届いた質問も、仮説を作る材料になります。
GOV.UKの調査計画は、答えたい質問に合う方法を選ぶことを勧めています。操作観察の少人数で見つけた障壁は、全訪問者の何%が困るかを測った結果ではありません。「相談という言葉が何の相談か分からない」といった理由を、次に変える1点へ使います。
修正を採用する場合は「A/Bで有意に勝った」ではなく、「観察した障壁を取り除いた」と理由を書きます。変更後の送信失敗、相談の内容、流入条件を追い、悪化が見つかれば見直します。小さい会社でも、分かったことと未確定な効果を分ければ意思決定できます。
経営者と調査担当が、必要数が集まらない場合の代替調査を決めてください。
この章の根拠:出典2
06 / Web改善
まとめ:小さい差を断定せず、次の判断を残す
仮説・母数・分析条件・停止条件をそろえて試験計画を作ります。

小規模サイトのA/Bテストでは、成果数の少なさが判断を難しくします。割合の上昇だけでなく、何人のうち何件だったかを示してください。主指標と比較単位を先に決め、必要数の算出に使った条件を残すと、担当者と同じ意味で結果を読めます。
期間の終わりに必要数が足りなければ、結果は未確定です。さらに続けるか、実施条件を変えて新たな試験にするか、操作観察へ移るかを選びます。未確定を失敗として隠す必要はなく、次に何を確かめるかを記録します。
まず下の試験計画を埋め、「案Bを採用したい理由」と「まだ分からないこと」を別に書きます。数字を良く見せるより、顧客の相談を終えやすくする判断に使うことが目的です。計測と統計の専門確認が必要な項目は、具体的な質問として担当者へ渡してください。
計画の未確認欄を試験担当へ渡し、開始できる条件を確認してください。
仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。


