LPOとは？ランディングページ最適化の分析・改善・A/Bテスト手順

監修: 菊地 将（リブランディング株式会社）

LPへの流入はあるのに、問い合わせや資料請求が増えない場合、ページ全体を感覚で作り直す前に「どこでユーザーが止まっているか」を確認する必要があります。LPOは、ランディングページを分析し、コンバージョン率（CVR）を高めるために改善と検証を繰り返す取り組みです。重要なのは、ファーストビューやCTAを思いつきで変更することではありません。計測を整え、ボトルネックを特定し、改善仮説に優先順位を付け、A/Bテストなどで結果を確かめることです。この記事では、公開済みLPを対象に、分析から改善、検証までの一連の進め方を整理します。

LPOとはLP全体のCVRを継続的に改善する取り組み

LPOは「Landing Page Optimization」の略で、ランディングページ最適化を意味します。広告や検索結果などから訪れたユーザーに対し、ページ内の訴求、情報の順序、CTA、信頼材料、表示速度などを改善し、問い合わせ・資料請求・購入といった成果につながる割合を高める取り組みです。

LPOで対象にするのは、単独のボタンや入力フォームだけではありません。LPに着地してから目的の行動へ進むまでの流れを一つのページとして捉え、どこに障害があるかを確認します。

Google Adsは、ランディングページの体験について、ページ内情報の有用性・関連性、操作のしやすさ、広告をクリックしたユーザーの期待との一致などを要素として挙げています。広告とLPで伝えている内容がずれていれば、ページ内だけを細かく調整しても改善しにくい場合があります。

LPOと似た言葉には、CRO、EFO、SEOがあります。担当範囲を分けると、改善対象を広げすぎずに済みます。

LPOはCROの一部として扱えますが、この記事ではLPという1ページの分析・改善・検証に範囲を限定します。フォーム内部の項目設計やエラー仕様が主因の場合は、EFOとして別に深掘りする方が適切です。

LPOをサイト全体の改善サイクルの中で位置づける場合は、CROの考え方・KPI・改善サイクルを確認してください。

LPOは「直す場所」より先に「止まっている場所」を特定する

LPOで最初に行うべきことは、デザイン案を作ることではありません。現在のLPで、ユーザーがどの段階まで進み、どこで大きく減っているかを確認することです。

たとえば、次のようにLP内の行動を分けます。

1. LPに到達した
2. ファーストビューを閲覧した
3. 主要な説明セクションまで到達した
4. CTAをクリックした
5. フォームへ到達した
6. 問い合わせ・資料請求などを完了した

LP全体のCVRだけで判断せず、到達から完了までを段階に分けると、優先して確認すべき離脱地点を見つけやすくなります。

Google Analyticsでは、事業上重要なアクションを「キーイベント」として計測できます。最終的な送信完了だけでなく、CTAクリックやフォーム到達などをイベントとして取得しておくと、LP内でどこまで進んでいるかを分解しやすくなります。

CVRだけを見ると、問題の位置は分かりません。CVRが低い原因は、ファーストビューで離脱している場合もあれば、CTAは押されているのにフォームで止まっている場合もあります。改善箇所を決める前に、行動を段階に分けることが重要です。

流入元とデバイスを分けて確認する

LP全体の平均値だけで判断すると、改善対象を誤ることがあります。少なくとも、広告・自然検索などの流入元と、PC・スマートフォンなどのデバイスは分けて確認します。

たとえば、PCではCVRが安定している一方、スマートフォンだけCTA到達率が低い場合、訴求そのものよりも画面内の情報量や表示崩れ、スクロールの長さが影響している可能性があります。逆に、特定の広告キャンペーンだけ離脱が多い場合は、広告文とLPの訴求が一致しているかを先に確認します。

ヒートマップと録画は原因仮説を作る材料にする

数値で離脱区間を特定した後は、ヒートマップやセッション録画を使うと原因仮説を作りやすくなります。Microsoft Clarityでは、クリック、スクロール、エリア、注目などのヒートマップを確認でき、セッション録画ではクリックやスクロールなどの行動を追えます。

ただし、「よくクリックされている」「途中までしかスクロールされていない」という事実だけで原因を断定しないことが重要です。ヒートマップは改善案を決めるための答えではなく、「なぜそこで止まるのか」を考える材料として使います。

Microsoft Clarityでヒートマップや録画を具体的に使う場合は、Microsoft Clarityの使い方を確認してください。

LPOで優先して確認する5つの改善領域

ボトルネックが見えたら、その区間に関係する要素を確認します。LP全体を同時に直すのではなく、影響が大きい領域から絞り込みます。

ファーストビューは「見た目」より期待との一致を確認する

ファーストビューでは、訪問者が「自分向けのページか」「探している答えがありそうか」を判断できる状態を目指します。

広告で「導入費用を比較できる」と伝えているのに、LPの冒頭が会社紹介から始まっていれば、ユーザーが期待した情報まで距離があります。逆に、広告の訴求と同じテーマを主見出しで示し、対象者と得られる結果を明確にすると、次の情報を読む理由を作れます。

訴求は機能説明だけでなく判断材料まで用意する

見込み客は、企業側が伝えたい機能だけで意思決定するとは限りません。導入条件、費用、実績、他の選択肢との違い、導入後の流れなど、比較時に必要な情報が不足すると、ページを読んでも判断できない状態が残ります。

Webサイト設計と購入意向に関する研究では、デザイン品質や情報の質、信頼がオンライン上の判断と関連することが報告されています。ただし、研究対象はECなど特定条件のものが多く、すべてのBtoB LPに同じ影響が出るとは限りません。自社LPでは、ユーザーが比較時に必要とする情報を仮説として整理し、実際の行動データで確かめることが必要です。

CTAはボタンだけでなく押す前の不安まで確認する

CTAの改善では、色やサイズだけを変更しがちですが、押されない理由がボタン自体にあるとは限りません。

「問い合わせ後に営業電話が増えそう」「何がもらえるのか分からない」「対象企業か判断できない」といった不安が残っていれば、ボタンの直前に説明を追加する方が有効な場合があります。CTAクリック率と最終CVRを分けて確認し、クリック後に離脱が増えていないかも確認します。

表示速度と操作性はLP改善の土台として確認する

内容が適切でも、表示が遅い、タップ後の反応が遅い、読み込み中にレイアウトが動くと、ユーザーの判断を妨げます。

GoogleのCore Web Vitalsでは、読み込みの体感をLCP、操作への反応をINP、レイアウトの安定性をCLSで評価します。Web.devでは、良好な目安としてLCP 2.5秒以内、INP 200ミリ秒以下、CLS 0.1以下を示しています。これらはCVRを直接保証する数値ではありませんが、LPの表示・操作上の問題を確認する基準として利用できます。

LPOの実務手順は分析から再測定まで6段階で回す

LPOは、修正そのものより「どの根拠で何を変え、どう評価するか」を決めることが重要です。実務では次の6段階で進めると整理しやすくなります。

LPOは修正して終わりではなく、仮説と結果を記録しながら次のボトルネックを再測定するサイクルで進めます。

1. 成果地点とKPIを固定する

まず、LPの最終成果を一つ決めます。資料請求、問い合わせ、購入など、LPの役割に合わせて主KPIを設定します。そのうえで、CTAクリック率、フォーム到達率などを途中指標として置きます。

途中指標だけを改善すると、最終成果が変わらないことがあります。CTAクリックが増えても、送信完了が増えていなければLPOの成功とは判断できません。

2. ボトルネックを数値で特定する

LP到達から最終成果までを段階に分け、どこで大きく減っているかを確認します。期間を変える場合は、広告出稿量やキャンペーン、季節要因などの条件が大きく変わっていないかも確認します。

3. 原因仮説を一文で書く

改善案を先に決めず、「誰が、どこで、何に迷っているため、どの指標が下がっているのか」を一文にします。

例：
「広告から来た初回訪問者に対象サービスの違いが伝わらず、ファーストビュー直後の離脱が増えている」

この形にすると、変更する要素と評価指標を結び付けやすくなります。

4. 改善案を影響度と検証しやすさで並べる

改善案は、すべて同時に実施せず、影響度と検証しやすさで優先順位を付けます。

たとえばファーストビュー直後の離脱が大きいのに、ページ最下部のCTA色からテストしても、影響を受けるユーザーは限られます。最も大きく減っている区間に近い要素から検討します。

5. A/Bテストで変更の効果を比較する

A/Bテストは、現行版Aと改善版Bを比較し、主KPIに差が出るかを確認する方法です。テスト前に、次の項目を固定します。

• 検証する仮説
• 変更する要素
• 主KPI
• 現在の基準値
• 検出したい改善幅
• 必要なサンプル数
• テスト終了条件
• 対象デバイス・流入条件

特に重要なのは、結果を見ながら都合のよい時点でテストを止めないことです。Optimizelyの固定期間型A/Bテストの説明でも、テスト開始前に必要サンプルサイズを決める考え方が示されています。サンプルサイズは現在のCVR、検出したい改善幅、統計的有意水準、バリエーション数などで変わります。

一度に複数の要素を変えると、結果が改善しても何が効いたか判断しにくくなります。大幅なリニューアルを比較したい場合を除き、原因仮説に対応する変更単位を明確にして検証します。

6. 結果を記録し、次のボトルネックを再測定する

テスト終了後は、勝敗だけでなく、実施条件と結果を残します。

• 何を変えたか
• どのユーザーを対象にしたか
• 何を主KPIにしたか
• 期間とサンプル数
• 結果
• 次に確認する課題

改善版が勝った場合も、LP全体の課題がなくなったわけではありません。次に大きな離脱区間を確認し、同じ流れを繰り返します。

流入が少ないLPではA/Bテストを無理に実施しない

A/Bテストは有効な方法ですが、すべてのLPに向いているわけではありません。コンバージョン数が少ないLPでは、わずかな改善差を判定するために長い期間が必要になることがあります。

流入が少ないLPでは、無理にA/Bテストを長期化させず、行動データやユーザーの声を組み合わせて改善仮説を絞る方法もあります。

その場合は、小さな文言変更を何度もテストするより、次の方法を組み合わせます。

• GA4で離脱区間を分解する
• ヒートマップや録画で行動を確認する
• 営業・問い合わせ内容から不安や比較軸を整理する
• ユーザーインタビューや簡易テストで理解しにくい点を探す
• 大きな仮説を一つ選び、変更前後を比較する

変更前後の比較は、広告量、季節、流入元などの条件が変わると結果を誤認しやすいため、A/Bテストと同じ精度では扱えません。流入が少ない場合は「確実な勝者を決める」より、複数の情報から次の改善仮説を絞ることを優先します。

LPOでは見込み客が比較するときの情報不足も確認する

企業側は「サービスの特徴を伝えた」と考えていても、見込み客が比較時に必要とする情報が足りなければ、問い合わせには進みません。

LPOではページ内の見た目だけでなく、見込み客が比較時に必要とする情報がLP内に揃っているかも確認します。

LPを見るユーザーは、必ずしもそのページだけで判断しているわけではありません。広告、検索結果、競合サイト、口コミ、事例などを行き来しながら比較する場合があります。LPOでは、ページ内の見た目だけでなく、見込み客が判断に必要とする情報が揃っているかを確認します。

自社LPを確認するときは、次の質問が役立ちます。

• 誰向けのサービスかがすぐ分かるか
• 自分の課題に合う理由が分かるか
• 他の選択肢との違いを判断できるか
• 導入条件や費用の考え方が分かるか
• 実績や事例などの信頼材料があるか
• 問い合わせ後の流れが分かるか
• 今行動する理由があるか

これらの不足が原因なら、CTAの色を変えるより、判断材料を追加・再配置する方が改善仮説として優先されます。

LPOの改善チェックリスト

最後に、公開中のLPを確認するときの順序をまとめます。

• 最終CVが正しく計測できている
• CTAクリック、フォーム到達など途中行動も確認できる
• 流入元とデバイス別にCVRを見ている
• 広告・検索意図とLPの主訴求が一致している
• ファーストビューで対象者と提供価値が分かる
• 比較・判断に必要な情報が不足していない
• CTA前の不安や疑問が解消されている
• モバイルで表示・操作しにくい箇所がない
• 表示速度やレイアウト安定性に大きな問題がない
• 改善案ごとに原因仮説と評価指標がある
• A/Bテスト前に終了条件を決めている
• 実施結果と次の課題を記録している

一つでも未確認の項目があれば、デザイン変更前に計測や診断から進める方が、改善理由を説明しやすくなります。

まとめ

LPOは、LPの見た目を整える作業ではなく、ユーザーがどこで止まっているかを確認し、原因仮説を立て、改善して、結果を再測定する取り組みです。

まずは最終CVと途中行動の計測を整え、流入元・デバイス別にボトルネックを特定します。そのうえで、ファーストビュー、訴求、情報設計、CTA、ページ体験のうち、原因に最も近い要素から改善します。十分な流入がある場合はA/Bテストで検証し、流入が少ない場合は行動データやユーザーの声を組み合わせて大きな仮説を絞ります。

LPへの流入はあるのに成果が伸びない場合は、まず「どこを直すか」ではなく「どこで止まっているか」を一枚に整理することが出発点です。CV改善の確認項目や分析観点を整理した資料は、資料ダウンロードページから確認できます。

参考文献・データ元

‹ 親記事: CROとは？コンバージョン率最適化の考え方・KPI・改善サイクル