LPのA/Bテストは、見た目の好みを投票で決める作業ではありません。同じ条件の訪問を比較対象と変更案へ分け、あらかじめ決めた指標で「この変更が問い合わせ行動に影響したか」を確かめる実験です。仮説、配信単位、主指標、必要数、終了条件を開始後に変えると、数字が良く見える時点だけを選びやすくなります。
この記事では、LP改善を担当する事業責任者・マーケティング担当・制作担当が、実施可否から判定、反映、学習記録までを一枚の実験票で進める方法を整理します。問い合わせ不足の原因がまだ分からない場合は、先に問い合わせが来ない原因を切り分ける診断を行い、検証対象を狭めます。
A/Bテストで決めるのは「変更案」ではなく「次の行動」
実験の出力は、単純な勝ち負けだけではありません。「変更案を全体へ反映する」「差が小さく保留する」「計測不備で無効にする」「仮説を修正して再試験する」のどれを選ぶかです。先に次の行動を定義すると、担当者の期待や制作費に引っ張られにくくなります。
NISTの実験計画の解説も、目的、変える要因、観測する応答を事前に定めることを基本にしています。LPでは「誰の、どの不安に、何を変えると、どの行動が変わるか」を一文にし、結果に応じた処置まで実験票へ残します。サイト全体の改善工程との位置づけはCROの進め方と分け、この記事では比較実験の品質に集中します。
まず実施可否を判定し、テストしない選択も残す
| 状況 | 先に行うこと | A/Bテストの扱い |
|---|---|---|
| 主要イベントが欠落・重複する | 計測仕様と実送信を直す | 開始しない |
| 広告、価格、対象者、フォームを同時変更中 | 影響を分離できる期間を決める | 延期または対象を限定 |
| 訪問・成果件数が少ない | ユーザー調査、ログ、問い合わせ内容で仮説を絞る | 必要数と期間が現実的な場合だけ実施 |
| 法令、誤表示、操作不能など明白な問題 | 通常改修として直し受入確認する | 改善をテスト対象にしない |
| 比較可能な安定流入と一つの意思決定がある | 実験票と停止条件を承認する | 実施候補 |
小さなLPなら、調査と通常改修の方が速いこともあります。ページ内の離脱箇所を実装単位で直したい場合はLPOの損失診断と改善手順、入力完了を妨げる要因はEFOの投資判断へ役割を分けます。
仮説は実験票に固定し、変更点と根拠を対応させる
「ボタンを目立たせれば増える」だけでは再利用できません。対象者、観察した事実、障壁、変更、期待する行動をつなげます。例えば架空の仮説なら「初回訪問者は相談後の流れが分からず送信をためらう。CTA直前に対応範囲と相談後3段階を示すと、フォーム到達率が上がる」です。これは実績ではなく、検証前の予想です。
| 実験票の項目 | 開始前に記録する内容 |
|---|---|
| 対象 | LP、流入元、端末、地域、新規・再訪、除外条件 |
| 仮説 | 観察事実、利用者の障壁、変更、期待する行動 |
| 比較 | Aの識別子、Bの識別子、差分、実装版、担当者 |
| 指標 | 主指標1つ、補助指標、悪化を止める安全指標 |
| 判定 | 最小検出差、誤判定リスク、検出力、必要数、最短期間 |
| 処置 | 反映、保留、無効、再試験の条件と決定者 |
企画段階で対象外と受入条件も決める場合は、Web制作の要件定義と同じく、未決事項を勝手に実装へ流さない形にします。
配信単位と割付を固定し、同じ人の行き来を防ぐ
割付単位は利用者、ブラウザ、セッションなどから選びます。複数回訪問して判断する問い合わせLPで、同じ人がAとBを行き来すると体験も計測も混ざります。Cookie削除、別端末、同意状態、社内アクセス、ボット、テスト担当者をどう扱うかも先に決めます。流入元や曜日が一方へ偏らない配信を行い、予定した50:50などの比率から大きく外れていないかを確認します。
Microsoft ResearchのSRM研究は、予定比率と観測比率の不一致が、割付やデータ品質の問題を示す重要な兆候だと整理しています。理由が分からない配分異常を補正値だけで隠さず、実験を止めて原因を調べます。
勝敗の主指標は一つ、安全指標は別に置く
問い合わせ獲得が目的なら、主指標は有効問い合わせ完了率など事業判断へ近い値にします。CTAクリック率とフォーム到達率を同時に勝敗へ使うと、都合の良い指標を後から選べます。クリック率は診断用の補助指標、エラー率、直帰に近い離脱、低品質送信、ページ速度、キャンセルなどは安全指標として分けます。
売上まで時間がかかる事業では、LP上の送信だけでなく有効商談や受注との接続を別期間で追います。計測全体の責任とキーイベントを整理する場合はGA4コンバージョン計測設計、費用判断はSEOと広告の予算配分のように粗利と総コストへつなぎます。
計測はvariant_idとexperiment_idまで送信確認する
Google Analyticsのイベント設定資料は、利用者の操作をイベントとして送信し、必要な文脈をパラメータで持たせる方法を案内しています。実験ではexperiment_id、variant_id、割付時刻、LP識別子を、個人を直接識別しない設計で送ります。主イベント、重複防止、クロスドメイン、同意前後、完了ページ再読み込みも仕様に含めます。
公開前はGoogle Analyticsの検証・トラブルシューティング資料に沿って、DebugViewや通信でA/Bそれぞれのイベントとパラメータを確認します。管理画面に数字が出たことだけで合格にせず、テスト送信1件の画面操作、通信、受信、保存先の対応を証拠にします。
割付の仕組みだけを確かめたいときは、表示内容を変えないA/A確認や社内限定の試運転を使えます。ただしA/Aを長く続ければ本番実験が自動的に正しくなるわけではありません。実験IDごとに、版番号、配信設定、タグの公開版、テスト時刻、受信画面、担当者を一組で保存し、本文・フォーム・計測のどれを変更した証拠か分かるようにします。
必要数と期間は流入量だけでなく検出したい差から決める
「2週間回す」「各100件で判断する」という一律基準は置けません。基準CVR、事業上見逃したくない最小差、誤って勝ちとするリスク、差を検出できる確率、配信比率から必要数を計算します。NISTの必要サンプル数の解説でも、必要数は検出したい差とα・βなどの前提に依存します。
必要数が現実の月間流入を大きく超えるなら、対象流入を増やす、より大きな差を生む仮説へ変える、定性調査と通常改修へ切り替える、のいずれかを選びます。期間は必要数に加え、平日・休日、広告配信、営業日、繁忙の周期を含めます。開始後に毎日勝敗を見て、良く見えた日に終了する運用はしません。
予定終了日までに必要数へ届かない場合も、「有意になるまで延長」ではなく、開始前に決めた処置へ戻します。延長するなら、延長を許す条件と新しい終了日を結果を見る前に承認し、途中の判断を記録します。季節や広告キャンペーンをまたいだデータは、単純に件数を足す前に利用者構成と提供条件が比較可能か確認します。
公開前にA・B・制御不能条件を同じ手順で受入確認する
| 確認面 | AとBで確認すること | 不合格時 |
|---|---|---|
| 表示・操作 | 主要幅、実機、キーボード、フォーカス、エラー、完了 | 開始しない |
| 割付 | 同一利用者の固定、除外、予定比率、キャッシュ | 配信設定を修正 |
| 計測 | variant_id、主指標、安全指標、重複、欠落 | データを無効化 |
| 事業 | 価格、提供条件、在庫、受付、返信体制 | 事業責任者へ戻す |
| 復旧 | 停止操作、元版、担当、判断期限 | 復旧不能なら公開しない |
変更の申請・承認・反映・再確認を分けるにはホームページ更新の実行手順を使い、実験ツールだけでなく元のLP、タグ、フォーム、通知、CRMまで通して確認します。
SEO・アクセシビリティ・プライバシーを勝敗の外へ追い出さない
Google Search Centralのウェブサイトテスト指針は、Googlebotだけに別内容を見せないこと、別URL方式では適切なcanonicalや一時リダイレクトを使うこと、必要以上に長くテストを続けないことを示しています。検索流入LPでは、タイトルや本文の大幅変更、テストURL、インデックス状況を実験票へ残します。
B案だけ操作不能になれば、CV差は説得力ではなく欠陥の差です。W3CのWCAG 2.2を参照し、認知・操作・理解・堅牢性をA/B双方で確認します。また、割付にCookie等を使う場合、個人情報保護委員会のガイドラインQ&Aも確認し、取得項目、利用目的、第三者提供、同意・拒否時の挙動を自社の法務・プライバシー方針と整合させます。
実験中は勝敗より先にデータ品質と停止条件を見る
日次で見るのは、予定比率、配信停止、イベント欠落・重複、極端な速度悪化、フォーム障害、苦情、法務・在庫・受付条件の変更です。勝敗指標は事前に決めた終了条件まで判定しません。障害や重大な安全指標悪化は止めますが、その停止を「Bの負け」と数えず、実験無効または運用品質の不合格として記録します。
広告文、入札、配信先、価格、営業体制など制御外の変更が起きたら、時刻と対象を残します。分析で都合よく除外するのではなく、開始前の除外基準に照らして継続・中止・再試験を決めます。セグメント別の差は次の仮説づくりには使えますが、後から細分化して見つけた差をそのまま勝利判定にしません。
判定は効果の大きさ、幅、事業価値、再現条件で行う
| 結果 | 判断 | 次の行動 |
|---|---|---|
| 主指標が事前基準を満たし安全指標も許容 | 反映候補 | 段階展開し、計測と事業結果を再確認 |
| 差が小さい、または不確実性が大きい | 保留 | 元版を維持し、必要数か仮説を見直す |
| 主指標は改善したが安全指標が悪化 | そのまま反映しない | 悪化理由を修正し再試験 |
| SRM、欠測、重複、同時施策の混入 | 無効 | 原因を直し、新しい実験IDで開始 |
| 悪化が事前基準を超える | 停止・不採用 | 元版へ戻し、学習を記録 |
統計的な差があっても、増分の有効問い合わせが実装・運用費を下回るなら反映しない判断があります。逆に「有意でない」を「差がない」と断定せず、検出したかった差と推定幅を確認します。実験ID、版、期間、配信数、欠測、主指標、安全指標、判断、承認者、反映後確認を残すことで、失敗した仮説も次回の資産になります。
架空の計算例として、月1,000訪問、基準の有効問い合わせ率2%、粗利寄与が1件5万円、追加運用費が月10万円なら、反映判断には「率が上がったか」だけでなく、推定される増分件数と幅、費用、受付可能数を並べます。数字は自社実績へ置き換え、都合の良い上限値だけで投資効果を説明しません。
まとめ：開始前に判定と停止を決められるかが品質を分ける
LPのA/Bテストは、仮説の良さだけでなく、比較可能な割付、主指標と安全指標、必要数、実装・計測QA、停止条件、判定後の処置がそろって初めて意思決定に使えます。まず実験票を1件作り、A/B双方の完了動作とイベントを確認し、品質点検を通過した実験だけを開始してください。
外部へ相談する場合は、LPのURL、月間対象訪問、基準CVR、有効問い合わせの定義、流入内訳、変更中の施策、タグ・フォーム・CRMの管理者、Cookie・同意の扱い、止められない事業条件を共有します。「何日で勝てるか」ではなく、必要数の前提、無効条件、復旧手順、反映後の再確認まで説明できる提案かを見極めます。
