LP改善は「数値→仮説→デザイン」の順番で——1回に1つだけ変える理由

LPの改善を頼まれたとき、私が最初に開くのはデザインツールではなく、アクセス解析の画面です。順番は数値→仮説→デザイン。そして1回の改善で変えるのは、原則として1か所だけにしています。デザインから入ると見た目は確実に良くなりますが、成果が動いたときも動かなかったときも「なぜか」が残りません。次の打ち手を決める材料がなくなるのが、いちばん大きな損失だと考えています。

数値で「どこで詰まっているか」を先に決める

最初にやるのは、LPの中で人が離れている場所の特定です。見る数字は多くなくてかまいません。私は次の3つから始めます。

• ファーストビューから先に進んだ割合（スクロールの深さ）
• CTAボタンのクリック数
• フォーム到達から送信完了までの割合

Google アナリティクス 4 では、重要な操作を「キーイベント」として設定しておくと、レポート上で追いやすくなります（キーイベントについて | アナリティクス ヘルプ）。フォーム送信完了を最低1つ、キーイベントにしておくのが出発点です。

ここで大事なのは、「全体の成約率が低い」で止めないことです。ファーストビューで半分以上が離れているのか、フォームまで来てから離れているのかで、打ち手はまったく違います。前者なら見出しや訴求の問題、後者なら入力項目や安心材料の問題です。詰まっている場所を1つに絞ってから、次に進みます。

仮説は「誰が・何に・なぜ」の1行で書く

場所が決まったら、仮説を1行で書きます。書式は固定しています。

「（誰が）は、（何に）つまずいている。なぜなら（理由）。だから（変更）すれば（指標）が上がるはず」

たとえば「スマホで来た人は、フォームの項目数の多さで離れている。なぜなら入力に3分以上かかるから。だから必須項目を5つから3つに減らせば、送信完了率が上がるはず」。

この1行があると、クライアントとの会話が変わります。「デザインを変えたい」ではなく「この理由でこの数字を動かしたい」という相談になるので、判断が速くなります。反対に、1行で書けない案は、まだ変える段階にないと判断しています。

デザインは最後に、1か所だけ変える

ようやくデザインです。ここで私が守っているのは、1回の改善で変える要素を1つにすることです。

見出しとボタンの色とフォームを同時に変えて数字が上がった場合、どれが効いたのか分かりません。下がった場合はもっと困ります。3つのうちどれかは良い変更だったかもしれないのに、まとめて元に戻すことになるからです。

変え方	数字が上がったとき	数字が下がったとき
3か所同時	何が効いたか不明	良い変更も一緒に戻す
1か所ずつ	効いた要素が残る	その1つだけ戻せる

A/Bテストの考え方を体系的にまとめた本に、Ron Kohavi・Diane Tang・Ya Xu による Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing（Cambridge University Press, 2020）があります。中小規模のLPでは、統計的にきちんと差を見られるだけのアクセスが集まらないことも多いのが実感です。その場合でも、「変更は1つ・期間を決めて前後を比べる・結果を記録する」という最小限の形は守れます。

なお、以前よく使われていた Google Optimize は2023年9月30日で提供が終了しています（Google Optimize の提供終了について）。ツールを選び直すときも、先に仮説の書き方と記録の形を決めておくと、道具が変わっても改善の履歴は途切れません。

結果は「効かなかった」も残す

改善の記録は、スプレッドシート1枚で十分です。列は「日付・場所・仮説・変更内容・期間・結果・次の一手」。

効かなかった変更も必ず残します。半年後に別の担当者が「ボタンを大きくしてみては」と言ったとき、「それは3月に試して変化がなかった」と答えられるのは、記録があるときだけです。LP改善は1回の大きな作り直しより、小さな検証の積み重ねのほうが、説明できる成果になりやすいと感じています。

明日から試せる一手

担当しているLPについて、「どこで一番人が離れているか」を1つだけ数字で確認してください。そのうえで、仮説を「誰が・何に・なぜ」の1行で書いてみる。デザインを触るのはその後で十分です。1行が書けた時点で、次の改善はもう半分決まっています。