LP改善の進め方｜CVRの計測・仮説・検証と公開後の判断

広告からLPへ人は来ているのに、相談や申込みが増えない。そんなとき、見出しやボタンを変えたくなるかもしれません。しかし、計測が正しいか、来訪者の条件が変わっていないか、受付後に何が起きているかを確かめないままでは、修正の良し悪しを判断しにくくなります。LP改善は、画面を直す仕事と、何を根拠に直すか決める仕事をつなぐ必要があります。

この記事は、公開中のLPを見直す企業の担当者に向けた実務ガイドです。CVRの数え方、GA4と行動観察の使い分け、改善案の優先順位、A/Bテストと変更前後の比較、公開後の判断を順に整理します。Google、Microsoft、英国政府の一次資料に加え、楽天24が公表した検証事例を参照します。技術資料は2026年9月10日に確認しました。

特定の改善率を約束したり、一般的な平均値で自社LPの合否を決めたりする内容ではありません。計算表と相談場面の例は説明用の仮定で、Acquaやお客様の成果ではありません。読み終えたら、対象LP、確認できた事実、未確認の点、次の修正と評価方法を一枚にまとめられる状態を目指します。

1. CVRを比べる前に、成果と対象を定義する

問い合わせ・受注・売上を別々の出来事として扱う

CVRはコンバージョン率のことですが、何をコンバージョンと呼ぶかはサイトによって異なります。資料請求、相談送信、見学予約、購入では、その後の仕事も売上との距離も違います。まず「このLPでは何を増やしたいか」を具体的な行動で書き、画面上の操作と社内で確認する成果を分けてください。

法人向けサービスなら、送信された相談すべてが受注候補とは限りません。営業案内、重複送信、対応範囲外の相談もあり得ます。相談件数だけでなく、有効な相談と判断する条件、商談や受注を確認する担当者も決めます。判断が人によって変わる場合は、先に分類例を揃えないと前後の比較がぶれます。

LPの改善担当と営業担当が別なら、何件届いたかだけを月末に聞くのではなく、受付日、相談区分、その後の状態を同じ期間で集計できる形にします。個人情報を分析用の共有資料へそのまま転載する必要はありません。集計に必要な区分と件数を共有し、元の受付記録は管理を担当する人が照合します。

率の分子と分母を、名前と一緒に残す

Google Analyticsの指標定義では、セッションのキーイベント率は、キーイベントが発生したセッションの割合です。特定のキーイベントだけを対象にする指標もあります。イベントの発生回数をセッション数で割った値と、必ず同じになるわけではありません。使った指標名と対象イベントを記録してください。

説明用に、対象LPから始まった1,000セッションのうち、受付成功を記録したセッションが20あったとします。この割合は2%です。同じ20セッション内でイベントが合計30回発生していた場合、30÷1,000の3%はイベント回数を基にした別の値です。再送信や二重発火を確認せず、3%を20セッションの成果率として扱うことはできません。

分母についても、LPを一度でも見た人、LPから始まった訪問、広告クリックでは対象が違います。社内資料には「対象LPを入口とするセッションのうち、指定した受付成功イベントが発生した割合」のように書きます。数字を別のレポートへ転記するときも、この定義を一緒に残すと誤解を減らせます。

期間・流入元・端末を揃えて比較する

比較表には期間、対象URL、端末、流入元、除外条件、計測変更の有無を添えます。LPを公開した直後と、広告の配信対象を絞った後では、来る人が異なる可能性があります。全体の率だけを見てページの品質が変わったと結論づけず、まず集計対象が同じかを確認します。

率は元の件数と並べます。1件が2件になった場合と、100件が200件になった場合は、同じ倍率でも判断材料が異なります。データが少なければ、数字の差をそのまま安定した傾向と扱わず、確認できる範囲を明記します。費用や受注後の採算まで考える場合は、LP制作費と予算試算の考え方へ進んでください。

2. 画面を直す前に、計測と受付を照合する

イベント名だけで、成功した操作だと判断しない

GA4の拡張計測機能の説明には、フォームの最初の操作を扱うform_startと、送信を扱うform_submitが記載されています。一方、この機能を有効にしただけで、自社フォームの表示、サーバーでの受付、社内通知までが同じ意味で記録されるとは判断できません。必要な行動と、実際に記録される条件を照合します。

たとえば、送信ボタンを押した後に必須項目のエラーが出た場合と、正常に受付が完了した場合を分けて試します。どちらも同じ成功イベントとして数えられていれば、改善前の基準がずれます。受付完了ページの再読み込みで再計上されないか、別ページのフォームが集計へ混ざらないかも確認してください。

確認表には、操作、期待する画面、期待するイベント、実際の記録、受付側の結果を一行ずつ書きます。「送信成功を計測する」という依頼だけより、成功と失敗の境界を共有できます。外部フォームや予約サービスを使う場合は、どこまで自社で記録を確認でき、どこから先は管理画面で照合するかを明らかにします。

テスト用の操作を、実際の記録と突き合わせる

GoogleのDebugViewの案内では、デバッグモードで収集したイベントとパラメータを確認できます。確認用の端末で操作し、どのタイミングで何が発生したかを追う用途です。通常の集客レポートだけを眺めるより、操作と記録の対応を点検しやすくなります。

フォーム試験は、受信先の担当者と内容・時間を調整し、テストと分かる情報を使います。実在のお客様になりすましたり、無断で予約枠を押さえたりしないでください。解析にイベントが見えたこと、画面に完了が出たこと、社内で受付できたことを別々に確認し、試験記録を通常の相談件数へ混ぜないようにします。

同意の状態やブラウザーの制限によって、解析側に見えない操作もあります。イベントが見えないときは、直ちに送信失敗と決めず、設定と受付側の記録を確認します。反対に、記録があるだけで実際の受注や入金まで完了したとも判断できません。計測の対象外があることを、担当者間で共有しておきます。

比較できない期間は、無理につながない

イベントの定義や発火条件を修正した日は、画面変更の日とは別に記録します。前月は送信ボタンのクリック、今月は受付成功を数えているなら、率の増減をLPの効果として比較できません。変更前の値を消すより、どこで定義が変わったかを注記し、新しい基準の集計を始めます。

計測が整っていない期間でも、壊れたリンクや送信できないフォームを放置する必要はありません。利用を妨げる不具合は修復し、修復した事実と成果の推定を区別します。「受付不能を直した」は動作確認で確かめられますが、「修正で受注が何倍になった」は別の証拠が必要です。フォーム全体の設計は問い合わせフォーム改善ガイドで整理しています。

3. ヒートマップと録画は、改善仮説の材料にする

スクロール到達と、理解・納得を区別する

Microsoft Clarityのスクロールマップは、ページ上のどの深さまで到達したかを確認する機能です。期間や端末などの条件を選んで確認できます。ただし、料金の位置まで画面が進んだことは、料金を読み、理解し、納得したことと同じではありません。

料金欄より前で到達者が減っていても、その位置の文章が原因とは限りません。求める情報を別のリンクで得た、対象外だと判断した、急用で中断したなど、観測だけでは区別できない理由があります。まず「料金欄への到達が少ない」と事実を記し、「料金が見つけにくいのではないか」は検証する仮説として分けます。

ページを短くした場合、同じ深さの割合が同じ内容を指すとは限りません。比較する画面の版と、料金・事例・フォームなどの位置も保存します。色の濃淡だけを比較資料にせず、どの期間・端末・対象ページの集計かを添えると、別の担当者も同じ条件で読み直せます。

録画で見える操作と、その理由を分けてメモする

同じ場所を繰り返し押す、前の画面へ戻る、フォーム入力をやめるといった動きは、追加調査の手がかりです。しかし、録画だけで「不安だった」「価格が高かった」と本人の気持ちを断定しないようにします。観察メモは「料金と事例を二往復した」のような行動で書き、解釈を別欄に置きます。

失敗したように見える訪問だけを集めると、普通に完了した人の操作が見えなくなります。条件を決めて複数の状態を確認し、同じ動きが成功した訪問にもあるかを見ます。録画の数を増やすこと自体を目的にせず、何を確かめるためにどの条件を見たかを残してください。

操作の理由を確かめたいときは、対象に近い利用者に課題を試してもらい、期待した情報や迷った点を聞く方法があります。誘導する質問を避け、先に本人の操作を見ることが大切です。進め方はLPのユーザーテストにまとめています。少人数の観察は問題発見の材料であり、そのまま全来訪者の割合を表す調査にはなりません。

必要な範囲を決めてから、行動を収集する

Clarityのマスキングの説明では、入力欄などの保護と、要素単位の設定を扱っています。また、設定変更は過去の録画へ遡って適用できないとされています。導入してから見直すだけでなく、入力後の確認画面や個別の内容が表示される場所も含め、先に収集範囲を確認します。

解析のために氏名や相談本文を集める必要があるかを見直し、閲覧権限、保管、共有方法を担当者と決めます。設定したつもりで終えず、テスト用の画面が録画でどう表示されるか確認してください。新しいツールがなくても、既存の受付区分、公開画面の点検、利用者への確認から始められる場合があります。

4. 改善案を、事実・仮説・確認方法で整理する

一つの観察から、修正案を一つに決めつけない

ここでは架空の法人向け相談LPを考えます。営業担当には「対応地域を確認するだけの連絡が多い」という報告があり、画面を見ると対応地域が下部にしかありませんでした。事実は受付区分と掲載位置です。「来訪者が地域を見つけにくい」という仮説は立てられますが、全員の離脱原因が分かったわけではありません。

対応案には、冒頭へ対象地域を簡潔に載せる、詳しい条件へのリンクを置く、広告の対象条件を合わせるなどがあります。いきなりLP全体を作り直すより、どの情報をどこへ足し、どんな誤解を減らしたいかを決めます。対象外の相談が減った場合は、総件数が下がっても改善の目的に合う可能性があります。

仮説は反対の結果も考えて書きます。「地域説明を目立たせれば有効な相談が増える」と考えたなら、対象地域の人まで相談を控える、説明を読まずに進む、別の条件への質問が増える可能性も挙げます。結果を見てから都合のよい理由を付けるのを避けるため、何を確認するか先に決めておきます。

影響と根拠と工数を、別々に評価する

優先順位は「ボタンは必ず先」「フォームは必ず短く」と固定しません。受付不能など利用を妨げる問題、事実と違う料金や対象条件は、実験の勝敗を待たずに修正すべき対象です。その上で、観察の裏付けがある案、影響する利用者、作業と確認の負担を並べます。

各案について、対象画面、確認した事実、予想する変化、修正内容、評価指標、悪化を見張る項目、担当、必要な材料を書きます。根拠が弱い案に細かい点数を付けても、確実な効果予測にはなりません。優先度の数値を会話の補助として使う場合も、元の観察や未確認事項を消さないようにします。

小さな文言変更でも、料金条件や個人情報の説明に触れるなら事業側の確認が必要です。逆に、大きく見える余白の調整が短時間で直せる場合もあります。見た目の変更量と工数を混同せず、実装担当に必要な作業と試験を確認してから順番を決めます。

改善依頼を、変更前後が確認できる形にする

「もっと分かりやすく」だけでは、原稿を直すのか、位置を変えるのか、リンクを増やすのかが揃いません。対象URL、画面の場所、現在の表示、差し替える原稿、期待する動作を示します。変更後に同じ操作で確かめられるよう、確認条件も添えてください。

具体的なボタンや補足文の作り方はLPのマイクロコピー改善、スマホの表示と操作はスマホLPの点検手順で詳しく扱います。この段階では施策を全部盛り込まず、今回確かめたいことに対応する修正と試験を依頼します。

5. A/Bテストと変更前後の比較を使い分ける

比較方法と終了条件を、開始前に決める

英国政府のA/Bテストの解説は、デジタルヘルス製品の評価資料ですが、仮説を立て、元の案と変更案を用意し、対象を無作為に分け、人数と期間を考えて比較する手順を示しています。LPへ応用する場合も、同じ時期に条件を揃えて比較する考え方と、月ごとの単純比較を区別します。

開始前に、対象の来訪者、振り分けの単位、主に見る指標、許容できない不具合、必要なデータ量、終了と判断の手順を決めます。必要人数は現在の率や検出したい差、採用する分析方法に依存するため、「何日」「何アクセス」だけを全LPに共通する基準にはできません。設計が難しい場合は分析担当と確認します。

複数の変更をまとめて比較すること自体は可能ですが、その場合に分かるのは変更一式の差です。見出しと画像とフォームを変えて良い結果が出ても、ボタンの色だけが効いたとは言えません。何を判断したい実験なのかに合わせて、変更範囲と結果の説明を揃えます。

全体の率が上がっても、内訳を確認する

次の表は、流入構成の影響を示す架空例です。各期間は1,000セッションで、流入群Xの受付成功セッションの割合は1%、流入群Yは5%と仮定します。ページに変更がなくても、Yの割合が増えると全体の率は上がります。実際の広告やお客様のデータではありません。

各期間の欄は「セッション数／受付成功セッション数」です。括弧内には、その群または全体の成功率を示します。

各群の率は変わっていませんが、合計では1.4%から4.6%へ動いています。この差をLP修正の成果と呼ぶことはできません。現実の比較でも、広告の配分、指名検索、新規と再訪、端末などの構成が変わっていないかを調べます。ただし、細かく分けすぎて各群が数件になると、別の不確かさが増える点にも注意します。

判断できない結果を、無理に勝敗へ変えない

毎日結果を見て、良い数字になった瞬間だけを選んで終了すると、当初と違う判断になります。進行中は計測や配信の異常を監視し、効果の判断は採用した分析方法と事前の終了条件に従います。不具合で中止した場合は、その理由と期間を残し、正常に完了した実験と同じ扱いにしません。

来訪が少ないLPでは、期間を延ばしても明確な差を判断できない場合があります。録画や聞き取りは次の仮説を考える助けになりますが、統計的な不確かさを埋めて勝者を証明するものではありません。改善率は保留しつつ、再現できた不具合の修正や、利用者が誤解した説明の見直しを進める判断もあります。

「差が確認できなかった」と「効果が絶対にない」も異なります。報告では、試した条件、得られた件数、残った不確かさ、次の判断を記します。期待に合わない結果を隠さず残す方が、同じ案を根拠なく繰り返すことを防ぎ、次の予算や担当の判断につながります。

6. 公開事例から、成果の数字より検証条件を読む

楽天24の事例は、対象と比較方法まで確認する

web.devで公開された楽天24の事例は、2022年のWebパフォーマンス改善報告です。アクセスとコンバージョンの多いLPを選び、改善版と元の版へトラフィックを50%ずつ配分して1か月比較したと説明しています。両版の見た目や機能は同じで、性能面を変更した設計でした。

報告では改善版のコンバージョン率が33.13%、訪問者当たり売上が53.37%増加しています。これは同社が公表した比較結果で、Acquaの実績や、自社LPへ適用できる予測値ではありません。記事内の実利用データの相関分析と、このA/Bテストの結果も分けて読む必要があります。

自社へ持ち帰るのは、検証の問いと条件

この事例から自社の検討へ持ち帰れるのは、同じ倍率を目標にすることより、何を変え、何を揃え、どの成果を測ったかという問いです。売上が発生するECと、受注まで時間がかかる法人向け相談LPでは、最終成果の確認方法が異なります。技術的な改善対象が似ていても、事業側の評価をそのまま移せるとは限りません。

自社で使う検討メモには、対象ページ、確認した問題、変更範囲、比較の期間、流入条件、主要指標、受付後の確認担当を書きます。資料にない母数や詳細な配信条件を推測で埋めないことも大切です。公開情報だけでは分からない点を残したまま、参考にできる部分を切り出してください。

古い技術事例を読む際は、現在の実装手順や指標と、当時の報告を分けます。事例の年代を消して「現在もこの設定が推奨される」と言い換えたり、一部の技術だけを抜き出して成果の原因にしたりしないようにします。自社での修正は、現在の環境を調べた上で決めます。

実績として発信するときは、未確認の点も整理する

自社で改善記事を公開するなら、対象期間、対象LP、変更内容、計測定義、分母と件数、同時期の広告や商品条件の変更を確認します。お客様の案件なら、社名、画面、担当範囲、数値について掲載できる範囲を確認してください。数値を公開できない場合でも、許可された作業内容と判断の説明は事例になります。

複数の施策を同時に実施した場合は、結果を特定の一施策の成果へ書き換えません。変更前後の比較であればその方法を明記し、A/Bテストをしたように見せないようにします。改善案を提案したこと、実装したこと、公開したこと、事業の成果が出たことも、別々の事実として記述します。

7. 修正の公開と、改善の判断を一つの運用にする

公開前後の確認と、戻す条件を決める

公開前には、変更内容だけでなく、関連するリンク、入力、エラー、受付、スマホ表示を合意した範囲で確認します。計測タグや外部サービスに触れた場合は、その動作も含めます。確認用の環境で正常だったことと、公開URLで正常に動いていることを分けて記録してください。

修正前の原稿や設定、戻し方、対応担当を残し、受付不能など何が起きたら戻すかを決めます。少ない件数で率が一時的に下がったことと、再現できる動作不良では対応が異なります。緊急に戻した場合も、変更日時と問題の内容を残し、その期間を後の比較で区別します。

報告は、事実・判断・次の作業をつなぐ

定例の報告は、数字の一覧だけで終えず、実施した変更、確認した事実、解釈、未確認の点、次の対応を分けます。たとえば「フォーム成功20件、前期間18件」だけで改善とは断定せず、分母と流入条件、受付区分、計測の状態も示します。判断材料が足りないなら、何が揃えば判断できるかを書きます。

受注まで時間がかかる事業では、今月の相談が今月中に結論を出すとは限りません。受付月別にその後の状態を追うなど、営業側の進み方に合う集計にします。未対応、検討中、不成立を混ぜてLPの失敗と呼ばず、どの段階の改善が必要かを担当者と確認してください。

改善を依頼するときは、分析、提案、原稿、デザイン、実装、公開確認、報告のどこまで含むかを揃えます。解析ツールを見られる人と、実際に修正できる人が別の場合は、その受け渡しも仕事に含めます。データだけ受け取って変更が止まる、変更だけ進んで評価できない、といった状態を避けるためです。

次の一件を決めるための相談メモを作る

最初の相談では、対象URL、増やしたい行動、現在の流入、計測の定義、受付後の状態、困っている画面、使える資料をまとめます。分からない欄は未確認と書き、仮の成果率で埋めないようにします。改修期限や広告の予定が決まっている場合は、それも伝えてください。

その上で、計測の照合が先なのか、再現した不具合の修正が先なのか、比較情報の追加を試すのかを決めます。一度の依頼で全LPを完成形にしようとせず、次の判断ができる範囲を具体化します。AcquaへのLP改善の相談でも、現状と確認できた事実から、調査・修正・公開後の評価に必要な仕事を整理します。