A/Bテスト（スプリットテスト）は、二つの案を実際の利用者に提示し、行動の違いを比較するテストです。
例えば分かりやすいところではデザインやUIですね。ボタンの色、見出し、フォーム、料金の見せ方など、どちらが良いかを担当者の感覚だけで決めず、データを判断材料にできます。
当然ですが、新しい案が成果を悪化させれば、テスト期間中に売上や問い合わせの機会を失うかもしれません。差を判断できるほどのデータが集まらなければ、制作費と計測期間だけを使って結論が出ない場合もあります。
良くなることもあれば悪くなることもある。
もちろん、負の結果や差が出なかった結果を、全て無駄と考える必要はありません。事前に仮説と判断基準を決め、条件と結果を記録していれば、「この案では改善しなかった」という知見が残りますよね。それの積み重ねが企業のノウハウになります。そしておそらくそれが一番と言っていいほど大事なものです。
そうです、本当に避けたいのは、結果が望ましくなかった実験ではなく、何を確かめたのか分からず、次の判断にも使えない実験です。
この記事では、A/Bテストが時間とリソースの無駄になりやすい場面と、学びを残すための設計を説明します。
A/Bテストを単発で終わらせず、問題発見から仮説、実行、結果確認へつなげる流れは、Web解析から改善施策・効果検証までの流れで確認できます。
A/Bテストが時間とリソースの無駄になるとき
A/Bテストを行っても、必ず成果が改善するわけではありません。実験である以上、次の結果はいずれも起こり得ます。
- 新しい案が元の案を上回る
- 新しい案が元の案を下回る
- 観測できるほどの差が出ない
- 計測や実験条件に問題があり、判断できない
新しい案が下回った場合でも、仮説が誤っていたと分かれば次の改善に生かせます。差が出なかった場合も、その変更だけでは利用者の行動を変えられなかった可能性が見えてきます。
時間とリソースの無駄になりやすいのは、次のような実験です。
| 状態 | 起きる問題 | 残らないもの |
|---|---|---|
| 仮説を決めずに始める | 結果を後から都合よく解釈する | 何を検証したのか |
| アクセス数が足りない | 偶然の差と施策の効果を分けにくい | 判断可能な結果 |
| 複数箇所を同時に変える | どの変更が影響したか分からない | 次の施策へ使える知見 |
| 途中で条件を変える | AとBを同じ条件で比較できない | 実験の一貫性 |
| 結果を記録しない | 同じ実験を繰り返す | 組織の学習 |
ざっくりいえば「とりあえずやってみた」です。
テスト中には機会損失も生じる
B案がA案より悪かった場合、B案を見た利用者の一部は、本来なら購入や問い合わせに進んでいた可能性があります。テストには、制作や設定に使う人件費だけでなく、改悪案を提示することによる機会損失も含まれます。
そのため、明らかな不具合をわざわざA/Bテストで確かめる必要はありません。ボタンを押せない、文字を読めない、フォームが送信できないといった問題は、比較実験を待たずに修正すべきです。
A/Bテスト＝2つの見た目から選ぶ、ではない
A/Bテストでは、元の案であるAと、新しい案であるBを、できるだけ同じ条件の利用者へ提示します。その上で、あらかじめ決めた指標を比較します。
英国政府のA/Bテストガイドは、問題を特定して仮説または目標を作り、対照案と変更案を用意した上で、標本数と実施期間を決める流れを示しています。また、対象者は均等かつ無作為に分けることを求めています。
重要なのは、画面の違いだけではありません。次の条件も比較できる状態にそろえる必要があります。
- テストを行う期間
- 流入元や広告キャンペーン
- デバイスや利用環境
- 対象となる利用者
- テスト箇所以外のページ内容
- 計測方法とコンバージョンの定義
先月のA案と今月のB案を比較しただけでは、季節、広告、競合、ニュース、在庫などの影響を分けられません。時期をずらした比較は改善前後の確認には使えますが、同時期に条件をそろえるA/Bテストとは区別したほうがよいでしょう。
開始前に決めておくこと
テストの設定画面を開く前に、最低限、次の項目を書き出します。
| 項目 | 決める内容 | 例 |
|---|---|---|
| 問題 | 現在、誰がどこで困っているか | 料金が分からずフォームへ進まない |
| 仮説 | なぜ問題が起きていると考えるか | 費用感が分からず相談をためらっている |
| 変更 | 仮説を確かめるために何を変えるか | 料金目安と見積もり条件を追加する |
| 主指標 | 最も重視する結果 | フォーム到達後の送信率 |
| 補助指標 | 悪影響がないか見る結果 | 対象外相談の割合、商談化率 |
| 対象 | 誰を実験へ含めるか | 初回訪問者、特定の流入元 |
| 期間 | いつまで実施するか | 必要標本数と曜日差を考慮して決める |
| 停止条件 | どの条件で終了するか | 予定期間、重大な悪化、計測障害 |
仮説は「変更内容」ではない
「ボタンを赤くする」は変更内容であり、仮説ではありません。
仮説では、「主要なボタンが背景に埋もれ、次の行動に気づかれていない。視認しやすくすればクリック率が上がるはずだ」のように、問題、原因、予想する変化を主眼にしてください。
そうすれば、クリック率が変わらなかった時も、色以外に原因があるのか、ボタン自体が見られていないのか、と目的ベースで次の検討へ進めます。
メインの指標を一つ決める
テスト後に、クリック率、滞在時間、離脱率、フォーム到達率、問い合わせ数を順番に眺め、良くなった数字だけを成果とするのは危険です。
開始前にまずこれをみる！というメイン指標を決めましょう。補助指標は、主指標の改善と引き換えに別の問題が起きていないかを見るために使います。
例えば、フォーム送信率が上がっても、対象外の相談ばかり増えていれば、事業にとって望ましい改善とは言えません。問い合わせ後の商談化や受注まで見て、Web上の数値と事業成果を結び付けます。
誤判定を招きやすい運用
有意差が出るまで毎日見続ける
A/Bテストの結果を毎日見て、有意差が表示された瞬間にテストを止めたくなることがあります。しかし、従来のp値や信頼区間を前提にしたまま結果を継続監視すると、推論の信頼性が損なわれる場合があります。
KDD 2017で発表された「Peeking at A/B Tests」は、実験中に結果を継続監視する利用実態を取り上げ、継続監視に対応する統計手法を提案しています。
利用しているテスト基盤が継続的な判定へ対応しているか分からない場合は、事前に期間と停止条件を決め、途中の数字だけで終了しないほうが安全です。
少ないアクセス数で勝敗を決める
必要な標本数は、現在のコンバージョン率、検出したい差、許容する誤判定、実験方法によって変わります。「100件あれば十分」のような一律の基準は設けられません。オンライン比較実験の統計的課題を扱った2023年のレビューも、標本数、複数指標、継続的な判定などを含む実験設計上の課題をまとめています。
アクセス数が少ないサイトでは、小さな差を検出するために長い期間が必要になります。期間を延ばす間に、市場や流入条件が変われば、比較の前提も崩れかねません。
始める前に、現実的な期間で判断可能なデータを集められるかを見積もります。集められない場合は、A/Bテスト以外の方法を選ぶべきでしょう。
複数の変更を一度に入れる
見出し、画像、料金、導線、フォームを同時に変更し、B案の成果が上がったとします。この結果だけでは、どの変更が良かったのか分かりません。
ページ全体を作り直す必要がある場合もあります。その場合は、個々の要素の効果を確認するテストではなく、「旧ページと新ページの総合的な比較」と位置付けます。何を確かめられる実験なのかを、実際の変更範囲に合わせることが重要です。
同時期の別施策を記録しない
テスト期間中に広告予算を増やした、値引きを始めた、テレビで紹介された、競合が休業した。このような出来事があれば、AとB以外の要因が結果へ影響します。
外部要因を完全に取り除くことはできません。ただし、施策と出来事を記録しておけば、結果を解釈する際に考慮できます。
統計的に有意でも、事業上有益とは限らない
統計的に差があることと、その差が事業にとって重要であることは別です。
大量のアクセスがあるサイトでは、わずかな差でも統計的に検出される可能性があります。しかし、実装や運用にかかる費用を上回る改善でなければ、採用する価値は低いかもしれません。結構ありますね…。
反対に、問い合わせ数のように件数が少ない指標では、事業上は大きな変化でも、統計的に明確な差を示せない場合があります。数字だけで機械的に決めず、次の観点も含めて判断します。
- 売上や粗利がどう変わったか
- 対象となる顧客からの相談が増えたか
- 商談前の理解が深まったか
- 顧客対応や営業の負担が変わったか
- 長期的な信頼を損なう表現になっていないか
短期的なクリック率を上げるために、誤解を招く見出しや過度に強い表現を使えば、クリック後の離脱や企業への不信につながります。主指標だけでなく、守るべき事業指標も決めておきましょう。
十分なデータが集まらないサイトではどうするか
中小企業のWebサイトでは、月間の問い合わせ数が数件という場合もあります。この状態で問い合わせ率のわずかな差を検出しようとすると、テスト期間が長くなりすぎます。実質的に、ノイズが大きく判断できないケースもあります。
A/Bテストを行えないからといって、改善できないわけではありません。他のデータも組み合わせながら、示唆を得る方向性です。例えば、次の方法を組み合わせるのがよいでしょう。
ユーザーテストを組み合わせる
実際の利用者や対象者に近い人へ目的を渡し、サイトを使ってもらいます。どこで迷ったか、何を誤解したか、なぜクリックしなかったかを観察すれば、少ない人数でも改善の仮説を作れます。
顧客対応と営業記録も参考資料にする
問い合わせ前に繰り返し聞かれる質問、失注理由、相談をためらった理由には、サイトに不足している情報が表れます。GA4の数字だけでは分からない理由を、現場の記録で補います。
結果をもとに次のテストを行う
A/Bテストは、一回ごとの勝敗より、組織が判断材料を蓄積できるかどうかに価値があります。
実験後は、次の内容を残します。
- 実験の目的と仮説
- A案とB案の変更点
- 対象者と割り当て方法
- 実施期間
- 主指標と補助指標
- 停止条件
- 同時期に行った別施策
- 結果と判断
- 判断できなかった点
- 次に確かめる仮説
数字は、仮説を立てる代わりではなく、仮説の答え合わせに使います。結果を見てから都合のよい物語を作るのではなく、実験前の見立てと照合しましょう。
まとめ
A/Bテストには、時間、制作費、計測作業に加えて、改悪案を利用者へ提示する機会損失もあります。十分なデータが集まらない場合や、実験条件が崩れた場合は、結論を得られないまま終わるかもしれません。
一方、望ましくない結果が出ても、仮説、条件、判断基準が明確なら知見は残ります。「改善しなかった」「この条件では判断できなかった」という結果も、次の施策を選ぶ材料です。
無駄を避けるために必要なのは、全てのテストを成功させることではありません。何を確かめるのか、いつ判断するのか、事業上何を守るのかを先に決め、結果を次の判断へ引き継ぐことです。1つ2つの違いは偶然かもしれません。思い切って広告でアクセスを集めるなどしないと判断は難しいことが多いでしょう。それを前提に、できることを進めるのが現実的です。
参考文献
- GOV.UK “A/B testing: comparative studies”
https://www.gov.uk/guidance/ab-testing-comparative-studies - Walsh, David, Ramesh Johari, and Leonid Pekelis. “Peeking at A/B Tests: Why it matters, and what to do about it.” KDD 2017.
https://www.kdd.org/kdd2017/papers/view/peeking-at-ab-tests-why-it-matters-and-what-to-do-about-it - Larsen, Nicholas, Jonathan Stallrich, Srijan Sengupta, Alex Deng, Ron Kohavi, and Nathaniel T. Stevens. “Statistical Challenges in Online Controlled Experiments: A Review of A/B Testing Methodology.” The American Statistician, 2023.
https://doi.org/10.1080/00031305.2023.2257237
