LPのABテストの始め方｜仮説と評価指標を決めて改善する手順

仮説が「冒頭で対象者が伝わらない」なら、見出しを具体化した案を用意します。同時に料金表やフォームまで大幅に変えると、どの変更が結果に関係したのか分かりにくくなります。

一度に複数の要素を変更すること自体が誤りではありません。ページ全体の案を比較する目的なら可能ですが、その場合に分かるのは案全体の差です。個別の要素の効果まで断定しないようにします。

記録には、対象ページ、仮説、変更箇所、変更しない箇所、期待する行動を残します。こうしておくと、結果が予想と違ったときも検証内容を振り返れます。

問い合わせ獲得が目的なら、ボタンのクリック率だけで勝敗を決めず、問い合わせ完了率を主指標にする方法があります。完了率の分母を訪問者数にするかセッション数にするかも事前に決め、両案でそろえます。

クリック率は高くなっても、内容を誤解した問い合わせが増えている可能性があります。そのため、有効な問い合わせの割合など、事業に関係する品質も確認します。品質の判定に時間がかかるなら、その期間を含めて評価する計画が必要です。

主指標をたくさん設定し、後から良かった数字だけを選ぶと、都合のよい解釈になりやすくなります。主指標は絞り、フォームエラーや表示速度などを補助的な確認項目として整理しましょう。

テストでは、同じ利用者が訪れるたびに別案を見ることがないよう、利用するツールの割り当て方法を確認します。社内アクセス、ボット、計測の重複などの扱いもそろえます。

必要な訪問数は、通常の成果率、検出したい差、採用する統計手法などによって変わります。「100件集まれば十分」「一週間で決める」と一律には言えません。使用するツールの仕様に沿って、必要なサンプルと判定方法を事前に設定します。

途中の数字だけを見て、良い結果が出た日に止めると判定を誤ることがあります。途中判定に対応する統計手法を使う場合を除き、当初の終了条件を守ります。一方、フォームが送れないなどの重大な不具合は、検証より利用者への影響を優先して停止します。

先週のA案と今週のB案を比較する方法では、広告、曜日、季節要因なども変わります。変更前後の観察としては役立ちますが、同時に無作為に割り当てるABテストと同じ強さで、変更が原因だと結論付けることはできません。

検索から流入するLPで別URLを使う場合は、検索エンジン向けの処理にも注意します。ユーザーと検索エンジンに意図的に異なる内容を見せる設計を避け、canonicalや一時的な転送の扱いを実装担当者が確認します。テスト終了後は不要な設定を残さず、採用した案へ整理します。

十分なデータを集めるまで長期間かかるサイトでは、最初にフォームの不具合、広告との内容のずれ、スマートフォンでの読みにくさを確認します。利用者へのヒアリングやヒートマップも、仮説を作る材料になります。

明らかな誤記や壊れたリンクは、ABテストを待たずに修正すべき内容です。一方、どちらの訴求がよいか判断が分かれる変更は、データを集められる条件が整ってから検証します。実施したテストと判断理由を蓄積すると、毎回同じ案を試すことも避けられます。