%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
A/Bテストは、ページやメールの変更案を同じ指標で比較する手法です。何を変え、どの結果なら採用するかを決めてから始めることで、得られた差を次の判断に使えます。
A/Bテストは、ページやメールの変更案を同じ指標で比較する手法です。何を変え、どの結果なら採用するかを決めてから始めることで、得られた差を次の判断に使えます。
「CTAの文言を変えたが、効果を判断できない」「結果が出る前に次の変更を入れてしまった」「上司の意向で判定が覆される」。こうした状態を防ぐには、変更の根拠、比較する対象、終了条件、判定する担当者を計画に残す必要があります。
現行版と変更版を用意して対象者を振り分けても、観測された差だけでは採否を決められません。計測が正しく動いたか、予定した対象数に届いたか、採用する意味のある差かを順に確認します。HubSpotでページのテストを設定する場合は、公式のページA/Bテスト案内も確認してください。
本記事は「CVR（コンバージョン率）改善の基本と実践施策15選｜BtoB企業向け完全ガイド」シリーズの一部です。
この記事でわかること
課題を見つけてから変更の採否を記録するまで、担当者が同じ順序で進められるように整理します。
- A/Bテストの基本と他手法との違い — 確かめたい変更の範囲と、必要な対象数を確保できるかから手法を選びます
- 仮説設計の進め方 — 観察した行動を変更内容と主指標に結びつけ、試す理由を明確にします
- 実施から判定までの手順 — 計測の確認、対象数の見積もり、終了後の判定を順に進めます
- 失敗パターンと回避策 — 途中結果や予定外の変更が生じたとき、判定を続けられるか見直します
読み進めながら、自社の対象ページ、変更案、判定条件を計画に記入できます。各節で次に進む条件も確認し、対象数や計測が足りない場合には検証方法を見直してください。
A/Bテストの基本知識
最初に決めるのは、どの変更について答えを得たいかです。要素を一つ変える場合とページ全体を作り替える場合では、結果から説明できる範囲が異なります。
A/Bテストとは
A/Bテスト（スプリットテスト）は、現行版と変更版を別々の対象者に表示し、あらかじめ決めた指標で比較する手法です。変更の理由を特定したい場合は、比較する要素を一つに絞ります。
たとえばCTAの文言を調べるなら、色や配置、リンク先は揃えます。複数の要素を同時に変える場合は、ページ案全体の比較として扱い、どの要素が差に寄与したかまでは結論づけません。どちらの設計でも、比較対象、主指標、採用条件を先に記録できたら実施準備に進みます。
他のテスト手法との違い
| テスト手法 | 変更要素数 | 必要トラフィック | 複雑度 | 適した場面 |
|---|---|---|---|---|
| A/Bテスト | 1要素 | 中 | 低 | CTA文言、見出し、画像の変更 |
| 多変量テスト | 複数要素 | 大 | 高 | 複数要素の組み合わせ最適化 |
| リダイレクトテスト | ページ全体 | 中 | 中 | LP全体の構成変更の検証 |
| バンディットテスト | 1要素 | 少 | 中 | 勝ちパターンへの自動配信 |
表のトラフィック量と複雑度は手法を比べるための相対的な整理であり、実施に必要な対象数を保証するものではありません。バンディットテストも、流入が少なくても優劣を判定できるという意味ではありません。
選ぶ際は、まず知りたいことを「一つの要素の影響」か「ページ案全体の比較」かに分けます。次に、対象者の流入と成果率から判定に必要な対象数を見積もります。一つの要素を比べる条件が揃えばA/Bテストへ進みます。ページ全体を比べる場合は、要素ごとの効果を切り分けられないことを計画に明記します。どの方法でも対象数を見込めなければ、観察やユーザーテストで課題を絞る段階に戻ります。
検証対象にできる要素
| カテゴリ | テスト対象の例 |
|---|---|
| コピー | ヘッドライン、サブコピー、本文の冒頭 |
| CTA | 文言、ボタンの色、サイズ、配置位置 |
| フォーム | 項目数、必須/任意の設定、入力方式 |
| ビジュアル | メイン画像、動画の有無、アイコン |
| レイアウト | セクションの順序、カラム構成 |
| 社会的証明 | 事例の掲載位置、ロゴの並び |
| フォーム | 項目数、レイアウト、入力方式 |
| 社会的証明 | 事例の種類 |
変更案は、離脱や入力の停滞など、観察できた行動とのつながりから選びます。CTAまで到達していないなら、文言より先にページ内での見つけやすさを調べます。CTAには到達しているのにクリックされない場合は、文言と周囲の説明が判断に必要な情報を示しているかを確認します。
フォーム入力中に止まっている場合は、CTAを変える前に停止箇所を確かめます。観察した行動と変更案のつながりを説明できれば仮説に進みます。原因を示す情報が足りなければ行動データを追加で確認し、見た目だけを理由に変更箇所を決めないようにします。
仮説設計のフレームワーク
仮説は「観察した課題・変更内容・予測する結果と理由」を一組で記録します。結果が予測と異なったときに、課題の見立てと変更内容のどちらを見直すか判断するためです。
ステップ1：データから課題を特定する
| データソース | 確認ポイント | 課題の例 |
|---|---|---|
| GA4 | 直帰率・離脱率 | ファーストビューでの離脱が多い |
| ヒートマップ | クリック・スクロール範囲 | CTAまで到達するユーザーが少ない |
| フォーム分析 | 項目別の離脱状況 | 特定の入力項目で離脱が集中する |
| ユーザーテスト | 行動観察 | 価格情報を見つけられずに離脱する |
まず対象ページの流入元、成果地点、計測期間を揃え、どこで行動が止まっているかを調べます。表の課題は調査の着眼点です。離脱が見えても、原因が文言にあるとは限りません。CTAのクリックが少なければ、表示位置、到達状況、クリック後の遷移を順に確認します。
行動データだけで原因を絞れないときは、ヒートマップやユーザーテストで利用者の動きを確認します。「CTAに到達した人が少ない」は観察、「CTAが見つけにくい」は原因の推測というように分けて記録します。推測を確かめる情報が得られたら変更案を作り、得られなければ観察を続けます。
ステップ2：仮説を構造化する
仮説は次の4要素で記述します。
- 【観察】対象ページで確認した行動や指標を書く
- 【変更】比較する要素と変更内容を具体的に書く
- 【予測】どの指標が、どちらの方向に動くと考えるかを書く
- 【根拠】観察と変更案がつながる理由を書く
たとえば、フォームの特定項目で入力が止まっているなら、「その項目の入力方法を見直すと、フォーム完了率が上がる可能性がある」と記述します。主指標をフォーム完了率とし、途中で計測すべき行動も決めます。完了率が変わらなければ、項目の操作に問題があったという見立てを改めて確認します。
次に、どの程度の差なら採用する意味があるかを、変更に伴う作業や後続の成果も踏まえて決めます。その差を判定できるだけの対象数を確保できなければ、対象ページ、変更の範囲、検証方法を見直します。主指標が改善しても後続の成果が悪化した場合の扱いまで決められたら、計画を確定します。
ステップ3：テストの優先順位を決める
複数の仮説は、変更内容と確かめる指標を揃えてから、Impact（期待する影響）、Confidence（根拠への確信）、Ease（実施しやすさ）を同じ基準で評価します。次のICEスコアリング表は計算方法を示す仮の記入例であり、各変更の効果を実測した値ではありません。
| 仮説 | Impact（1-10） | Confidence（1-10） | Ease（1-10） | ICEスコア |
|---|---|---|---|---|
| CTA文言の変更 | 7 | 8 | 9 | 504 |
| フォーム項目の削減 | 9 | 7 | 6 | 378 |
| ヘッドラインの変更 | 8 | 6 | 8 | 384 |
| ページ構成の変更 | 8 | 5 | 4 | 160 |
実際の順位は自社の観察結果で付け直します。スコアが高くても、成果地点との関係が薄い案は先に進めません。根拠があり、計測でき、必要な対象数を確保できる案から選びます。
判断が分かれたら、点数だけを比べず、各評価の理由を確認します。影響を期待する根拠が弱ければ追加の観察へ、計測が難しければ指標の定義へ、制作や承認が難しければ変更範囲の確認へ戻ります。対象数が足りない案については、実施頻度を上げる前に別の検証方法へ切り替えるかを決めます。
A/Bテストの実施手順
仮説を選んだら、主指標、変更してよい範囲、終了条件、承認者を開始前の計画に固定します。準備中に計測を確かめ、実施中の出来事を記録し、終了後に計画と結果を照合します。
ステップ1：テスト対象と目標指標を決める
| 項目 | 記入例 |
|---|---|
| テスト対象ページ | 問い合わせLP |
| テスト要素 | CTAボタンの文言 |
| 目標指標 | CTAクリック率 |
| 判定ルール | 有意差が出た時点で勝ちパターンを採用、出なければ次の仮説へ |
表は記入項目の例です。判定ルールの行は、そのまま採用せず、実際の計画では終了時点と必要な対象数を先に決めて書き換えます。途中で有意差が見えたことだけを理由に採用すると、結果を見た時点に判定が左右されます。
CTAクリック率を主指標にする場合は、クリックの対象者と集計範囲を定義し、フォーム送信など後続の成果も確認します。クリックが増えても送信が減ったときは採用を保留するのか、追加調査に進むのかを開始前に承認者と合意しておきます。主指標の定義、対象者、集計する期間を担当者間で同じように説明できたら、変更版の作成に進みます。
ステップ2：バリエーションを作成する
変更の理由を切り分けたい場合は、一つの要素だけを変えます。現行版と変更版を用意したら、表示、計測、フォームへの遷移をそれぞれ確認します。次の表はCTA文言を比べるための記入例です。
| パターン | 内容 |
|---|---|
| A（コントロール） | 現状のまま：「お問い合わせ」 |
| B（バリエーション） | 変更案：「専門家に無料で相談する」 |
表の文言は比較方法を示す例です。実際の案内で約束する内容は、提供する相談の内容と一致させます。文言以外の色、配置、リンク先が変わっていないかを公開前に確認します。両パターンで主指標と後続の成果を取得でき、想定した対象者に表示されることを確かめてから開始します。流入元や表示環境に偏りが見つかれば、振り分けと計測の設定を見直します。
ステップ3：必要なサンプルサイズを把握する
必要な対象数は、現在のコンバージョン率、検出したい最小の差、有意水準、検出力を使って事前に見積もります。まず対象ページで実測した成果率を確認し、事業上採用する意味がある差を決めてから計算します。ページ全体の流入数ではなく、実際に振り分けの対象となる人数を基に見込みを立てます。
| パラメータ | 説明 |
|---|---|
| 現在のCVR（ベースライン） | テスト前のコンバージョン率（実測値を使用） |
| 最小検出可能効果（MDE） | 検出したい最小の改善幅 |
| 統計的有意水準 | 偽陽性のリスク許容度（高めに設定） |
| 検出力 | 偽陰性のリスク許容度（十分な水準を確保） |
表は見積もりに使う項目の説明です。有意水準を「高め」にすればよいという意味ではありません。差があると誤って判断するリスクと、意味のある差を見逃すリスクを踏まえ、採用判断に使う設定を計画時に決めます。結果を見てから都合よく変えません。
見積もるときは、成果率の分母がテストの対象者と一致しているかを先に確認します。次に、各パターンに必要な対象数と流入見込みを比べ、予定期間内に届くかを調べます。届かなければ、流入のある別ページで同じ課題を調べられるか検討します。採用する意味のある差の設定も実際の判断と照合しますが、判定しやすくするためだけに基準を変えません。それでも難しければ観察調査に切り替えます。メールのA/Bテストでは、対象リストや配信設定をHubSpotのメールA/Bテスト案内で確認してください。
ステップ4：テストを実施する
設定した方法で対象者を振り分け、両パターンの表示と成果計測を確認してから開始します。実施中は対象ページへの別の変更を控え、キャンペーンや流入元の変化を記録します。想定と異なる配信や計測値を見つけた場合は、その時点の状況を保存して原因を調べます。
計測不良や表示不具合が見つかったら、発生時点、影響したパターン、対象者、指標を調べます。影響を切り分けられないデータを含めて勝敗を決めず、計画どおり判定できるかを見直します。影響範囲を特定できなければ判定を保留し、条件を整えてから再計画します。
ステップ5：テスト期間を設定する
期間は一律の目安で決めず、必要な対象数に届く見込みと、対象者の行動周期を踏まえて設定します。次の表は期間を決める際の確認欄です。
| 条件 | 期間の目安 |
|---|---|
| 最低期間 | 曜日変動を平均化できる短期間 |
| 推奨期間 | 標準的な検証期間 |
| 最長期間 | これを超えたら条件を見直す目安 |
表の「短期間」「標準的な検証期間」は固定の日数ではありません。開始前に、曜日などの変動を観察できる期間と対象数の到達見込みを確認し、終了時点を決めます。対象者の行動が成果に反映されるまでの流れも確認し、十分に観察できない見込みなら対象や方法を見直します。
終了時点で対象数が足りなければ勝敗を保留します。期間を延ばすかどうかは、流入条件を揃えたまま判定できるか、追加で必要な対象数を見込めるかを確かめて決めます。対象数を満たしても採用する意味のある差が見つからなければ、その結果を記録して次の仮説を検討します。
ステップ6：統計的有意差を判定する
| 判定基準 | 一般的な目安 | 意味 |
|---|---|---|
| p値 | 0.05未満 | 差が偶然である確率が低い |
| 信頼区間 | 0をまたがない | 改善方向がぶれていない |
| 必要サンプル数 | 達成済み | 判定に十分なデータ量がある |
表の数値は判定条件の記入例であり、すべてのテストに適用する基準ではありません。表のp値の説明は簡略化したものです。
まず計測と振り分けに問題がなかったかを確認し、次に計画した対象数と終了条件を照合します。そのうえで主指標の差と、その差の信頼区間を読みます。信頼区間が差のない値をまたぐかに加え、採用する意味があると事前に決めた差と比べて、どこまで判断できるかを確認します。統計上の条件を満たしても、実務上必要な差には届かない場合があります。反対に、対象数が不足して差を絞り込めない場合は、効果がないと断定しません。
後続の成果に望ましくない変化があれば採用を保留して原因を調べます。判定条件を満たさない場合は、計測上の問題、対象数の不足、観測された差の小ささを分けて記録します。どの条件が不足したかを明確にしてから、追加の観察、再計画、別の変更案のいずれに進むか決めます。
メールのA/Bテストについては、HubSpotのメールA/Bテスト案内を参照してください。
ステップ7：結果を反映して次のテストへ
事前の判定条件を満たし、主指標と後続の成果に矛盾がなければ、変更版の採用を検討します。採用後も同じ指標を確認し、テスト時と異なる流入や運用条件で結果が変わっていないかを見ます。変化が見られたら、対象者や計測条件が変わっていないかを先に確かめます。
判定できなかった場合は「差がない」と言い換えず、対象数、観測期間、差の大きさ、計測上の問題を残します。次のテストでは、その記録から追加で確かめる点を選びます。採用、保留、再計画のどれを選んだかと、その理由を承認者と共有して一区切りにします。
主要A/Bテストツールの整理
ツールは機能一覧だけで決めず、自社の対象ページ、計測方法、承認手順で実際に使えるかを確認します。次の表を比較の出発点とし、利用時点の機能と提供条件は各社の案内で確かめます。
ツール比較の観点
| ツール | 位置づけ | 向いている状況 |
|---|---|---|
| HubSpot Marketing Hub | LP・メール・CTAのA/BテストをCRMと一体で運用 | リード獲得後の商談化まで追いたい |
| Optimizely | エンタープライズ向けの実験基盤 | 大規模サイトで頻繁にテストを回す |
| VWO | テストとヒートマップの一体型 | 課題特定からテストまで一括で行いたい |
| AB Tasty | パーソナライズとの組み合わせ | セグメント別の出し分けも視野に入れる |
| KAIZEN PLATFORM | 日本語対応、運用代行あり | 日本語での運用支援を検討したい |
| DLPO | 日本製、多変量テスト対応 | 多変量テストを検討したい |
表の位置づけは比較の入口です。まず試したいページやメールで変更版を作れるか、同じ定義の指標で結果を読めるかを確かめます。次に、担当者が公開前の確認と承認を進められるかを試します。セグメント別の配信が必要なら、対象条件を設定できるかに加え、全体と各セグメントの結果をどう確認するかを調べます。AB Tastyは公式ターゲティング資料を確認先にできます。
次の企業規模の区分は、比較対象を整理するための目安です。規模だけで製品は決めず、予定するテストの種類、担当者、計測要件で絞り込みます。
| ツール | 対象企業規模 |
|---|---|
| HubSpot Marketing Hub | 中〜大 |
| Optimizely | 大 |
| VWO | 小〜中 |
| AB Tasty | 中〜大 |
Google OptimizeとOptimize 360は2023年9月30日をもって利用できなくなり、同日時点で実施中だったテストとパーソナライズも終了しました。詳しくはGoogle Optimize のサポート終了に関する案内を参照してください。
料金と機能は、同じ表の中でも確認先を分けて扱います。機能の案内だけでは料金を確認できないため、費用欄は利用時点の提供条件を確認する項目とします。導入判断では、自社が使うテストの種類、計測方法、必要な支援範囲と合わせて確かめてください。
| ツール名 | 月額費用 | 特徴 | 対象企業規模 |
|---|---|---|---|
| DLPO | 提供条件を確認 | A/Bテスト・多変量テストに対応 出典 | 公式サイトに規模の記載なし |
ツール選定の確認項目
- 対象ページと計測環境で、必要な指標を取得できるか
- 実施したいテストの種類に対応しているか
- 振り分け、終了条件、結果の確認方法を設定できるか
- 担当者が変更版を作成し、公開前に確認できるか
- 想定する流入規模と運用頻度に対して、利用条件と費用が見合うか
条件を確認したら、実際に試すページを一つ選び、変更版の作成から結果の記録まで担当者が進められるかを確かめます。主指標を取得できない、または承認手順に組み込めない場合は、導入を決める前に運用方法を見直します。複数のツールで条件を満たすなら、同じ対象ページと判定手順で比較してから選びます。
よくある失敗パターンと回避策
失敗を防ぐには、開始前に防げる問題と、実施中に発見して対処する問題を分けます。次の表で自社の運用に起こりそうな項目を確認し、担当者と対処方法を計画に記入してください。
失敗パターン一覧
| 失敗パターン | 起きること | 回避策 |
|---|---|---|
| 早すぎる結論 | サンプル不足のまま勝敗を決める | 開始前にサンプル数と期間の終了条件を決める |
| 複数要素の同時変更 | 効果の切り分けができない | 1テスト1要素を徹底する |
| テスト中の追加変更 | 条件が汚染される | テスト期間中は対象ページの変更を凍結する |
| ピーキング | 途中結果を見て中止・採用する | 終了条件を事前に固定し、途中結果は記録のみ |
| HiPPO問題 | 上位者の意向で結果が覆る | 判定基準をテスト前に合意しておく |
| 勝者なしの放置 | 有意差なしで記録が残らない | 「差なし」も結果として記録し次の仮説へ進む |
表の「差なし」は、計画した条件では採用を支持する差を確認できなかったという記録として扱います。効果が存在しないと証明できたことにはなりません。対象数が足りなかった場合は、判定できなかった理由も併記します。
途中結果を見ること自体より、その結果を理由に予定外の採用や終了を決めることが問題です。予定外の変更が必要になったら、変更の内容と時点を記録し、前後のデータを一つの条件として扱えるか確認します。扱えなければ勝敗を保留し、条件を整えて計画し直します。承認者の判断が計画と異なる場合も、判断理由と追加で必要な情報を残してから採否を決めます。
結果の解釈で押さえる点
- 最初に、事前に決めた主指標と終了条件を確認します
- デバイス別・流入元別の違いは、事前に判定対象としたかを区別して読みます
- クリック率が改善しても、その後のフォーム送信などに望ましくない変化がないか確認します
- 期間中のキャンペーンやメディア掲載など、流入条件の変化を結果と一緒に保存します
後から見つけたセグメント差は次の仮説に使えますが、その差だけで全体の採用判断を覆さないようにします。レポートには指標の値だけでなく、対象期間、対象者、変更内容、判定できなかった条件も残します。次の画像は、数値を確認する画面の例です。自社の計画では、画面上のどの指標を主指標とし、どの指標を後続の成果として確認するかを先に対応づけます。
A/Bテストの運用体制
開始前の成果地点、承認手順、判断理由と、終了後の結果、見直し点を同じ様式で対にして残します。担当者が変わっても「なぜその判断をしたか」をたどれる状態にするためです。
テスト計画のテンプレート
| 項目 | 記入例 |
|---|---|
| テスト名 | LP_CTA文言テスト |
| 仮説 | CTA文言の変更でクリック率が改善する |
| テスト対象 | 問い合わせLP |
| パターンA | 現行の文言 |
| パターンB | 変更後の文言 |
| 目標指標 | CTAクリック率 |
| 終了条件 | 必要サンプル数の達成、または設定期間の経過 |
| 判定基準 | p < 0.05 かつ信頼区間が0をまたがない |
| 必要サンプル数 | 基準値・検出したい差・信頼水準から各パターンの必要人数を算出する（出典） |
計画には表の項目に加え、後続の成果、採用する意味のある差、計測担当者、判定者、公開前の確認結果を記録します。表の数値と終了条件は記入例です。終了条件の「または」に達しても、対象数が不足していれば勝敗を確定しません。また、統計上の条件を満たすことだけで採用を決めず、事前に定めた実務上の差と後続の成果を照合します。予定した条件と実際に満たした条件を並べ、判定できなかった理由を残します。
終了後は同じ計画に「計測の状態」「対象数の到達状況」「主指標と後続の成果」「採否とその理由」「次に確認する点」を追記します。これにより、変更版を採用した場合も保留した場合も、次の担当者が判断を再確認できます。
次の頻度表は、運用計画を考えるための仮の記入例です。PVだけから実施頻度を決める根拠にはせず、対象ページごとの成果数、必要な対象数、変更案を準備できる体制から計画を立てます。
| 企業規模（月間PV） | 推奨テスト頻度 |
|---|---|
| 〜50,000 PV | 月1回程度 |
| 50,000〜200,000 PV | 月2回程度 |
| 200,000 PV以上 | 月3〜4回程度 |
必要な対象数に届かない場合は頻度を上げず、対象ページや検証方法を見直します。計測と承認に無理なく対応できる件数から始め、結果を次の計画に反映します。企業様によって最適な形は異なります。
運用が向かないケース
対象ページの流入では予定期間内に必要な対象数へ届かない場合、A/Bテストだけで結論を出すのは難しくなります。その場合はヒートマップやユーザーインタビューで課題を絞り、変更後は流入条件の違いに注意して結果を観察します。観察で変更案を具体化でき、判定に必要な対象数も見込めるようになったら、テスト計画に戻ります。
変更のたびに法務確認が必要なら、承認できる変更範囲と手順を先に確かめます。計測を揃えられない場合は、振り分けを始める前に計測方法を整えます。どちらも満たせた時点で、判定まで進められる変更案を選びます。
HubSpotでの進め方
HubSpotでページのテストを行う場合は、まず対象ページと主指標を決め、公式のページA/Bテスト案内で利用中の環境に該当する設定手順を確認します。変更版を作成したら、意図した要素だけが異なることと、両パターンで成果を計測できることを公開前に確かめます。設定や計測を確認できない場合は、公開前に担当者と確認箇所を整理します。
終了後は事前の判定条件に沿って結果を読み、変更の採否と理由を記録します。CTAの文言や配置を検討する際は「HubSpot CTAボタンの作成・設置方法｜クリック率を高めるデザインと配置の最適化ガイド」も参照できます。
あわせて読みたい
テスト対象の課題を絞りたい場合はGA4の記事で確認する指標を整理し、フォームでの離脱を調べたい場合はEFOの記事で入力時の行動を見直せます。LP全体の構成を検討する場合はLPの記事を参照し、どの箇所を変更するか決めてから判定方法を選んでください。
- GA4をBtoBサイトで活用する方法｜見るべき5指標と探索レポート活用術
- EFO（入力フォーム最適化）とは？離脱率を半減させる20の施策チェックリスト
- BtoB向けLP最適化の完全ガイド｜構成・CTA・フォーム設計のベストプラクティス
まとめ
A/Bテストでは、観察した課題から変更案を作り、必要な対象数と終了条件を決めてから比較を始めます。結果は統計上の判定だけでなく、採用する意味のある差か、計測や流入条件に問題がなかったかを合わせて確認します。
最初のテストを計画するなら、次の順に進めてください。
- 対象ページの流入と成果地点を確認し、行動が止まる箇所を特定する
- 【観察】【変更】【予測】【根拠】を書き、主指標と後続の成果を決める
- 必要な対象数と終了条件を見積もり、公開前に表示と計測を確認する
- 終了後は計画した条件と結果を照合し、採否または判定保留の理由を残す
対象数や計測条件が揃わない場合は勝敗を急がず、足りない条件を記録して対象ページや検証方法を見直します。CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。
よくある質問（FAQ）
Q1. A/Bテストにはどのくらいのサンプル数が必要ですか？
一律の件数では決められません。対象ページで実測したCVR、採用する意味のある最小の差、有意水準、検出力を決めて見積もります。その結果をテスト対象となる人の流入見込みと比べ、予定期間内に届かなければ対象ページや検証方法を見直します。メールのテストでは、対象リストと設定条件をHubSpotのメールA/Bテスト案内で確認してください。
Q2. テスト期間はどのくらいに設定すればよいですか？
必要な対象数に届く見込みと、対象者の行動周期から開始前に決めます。終了時点で対象数が足りなければ勝敗を保留し、流入条件を揃えて続けられるか確認します。対象数を満たしても採用する意味のある差が見つからなければ、確認できた差の範囲とともに結果を記録して次の仮説に進みます。
Q3. 複数の候補から、どのテストを先に実施すべきですか？
まず観察した課題と変更案のつながりを確認します。そのうえで、期待する影響、根拠への確信、実施しやすさを同じ基準で比較します。順位が高くても必要な対象数を確保できない案は保留し、計測から判定まで進められる案を選びます。評価が分かれた場合は、判断に足りない観察結果を確認してから順位を決めます。
Q4. A/Bテストで最も多い失敗は何ですか？
自社でどの失敗が多いかは、過去のテスト記録を見なければ判断できません。特に注意したいのは、対象数が足りない段階での結論、途中結果に応じた終了、テスト中の追加変更です。開始前に判定条件を固定し、条件から外れた場合に判定を保留する基準も決めておきます。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
