LPOとは、Landing Page Optimizationの略で、訪問の入口になるページを改善し、問い合わせなどの行動につなげる取り組みのことです。デザインの変更だけでなく、答えの順番、入力の負担、表示や操作の不具合も扱います。
始めるときは、改善するURLと、そこで受けたい行動を一つ決めます。見積もり依頼、技術相談、資料請求では、完了の意味が違います。全部を合わせた数字で、問い合わせ率の良し悪しを決めないでください。
送信できない、ボタンが別の場所へ飛ぶといった不具合があれば、テストの準備より先に直します。受信までの確認は問い合わせ導線の点検方法で扱っています。
LPには、なぜ二つの意味がある？
制作の会話では、広告から案内する縦長の一枚ものをLPと呼ぶことがあります。アクセス解析では形状を問わず、その訪問で最初に開かれたページをランディングページと呼びます。
Googleのランディングページのレポート説明は、セッションの最初のページビューに関連するパスとクエリ文字列を扱っています。検索から技術記事へ入れば、その記事が入口です。トップから製品詳細へ進んだ同じ訪問では、入口はトップになります。
| 会話の場面 |
LPが指すもの |
対象の例 |
| ページ制作 |
広告などの案内先の一枚もの |
試作相談の広告用ページ |
| GA4での分析 |
セッションで最初のページ |
製品詳細・技術記事・トップ |
したがって「LPの率が低い」と言われたら、どのURLへ、どんな入口から来た訪問を集計したかを聞きます。広告専用ページと、原因を調べる技術記事を同じ目的で比べないようにします。
たとえば、ヒケの原因を調べに来た設計者と、試作の見積もりを探して来た担当者です。前者はその場で答えを得て帰るかもしれません。問い合わせ率だけを理由に、原因の解説を削って見積もりボタンだけを置けば、検索してきた目的に答えられなくなります。
問い合わせ率のCVRは、どう計算する？
CVRは、定めた成果に至った割合です。サイトではセッション数やユーザー数、広告ではクリック数など、使う分母が異なります。「CVR」とだけ書かず、計算の対象を添えます。
入口ページを評価するこの記事では、次のセッション単位の率を使います。途中で別ページへ移って完了した行動も、同じセッションなら含めます。
今回使う問い合わせ率
問い合わせ完了のあったセッション数 ÷ 対象の入口から始まったセッション数 × 100
分子と分母の期間、対象の入口、流入条件をそろえます。問い合わせが同じ訪問で複数回あっても、分子では一つのセッションです。問い合わせ件数そのものを数える集計とは意味が違います。
Googleのトラフィック獲得レポートの指標説明にも、セッション キーイベント レートは、キーイベントが発生したセッション数をセッション総数で割ると記載されています。問い合わせの率にしたいなら、問い合わせ完了のイベントを対象にします。
資料の閲覧や送信ボタンのクリックまでキーイベントにしているなら、全キーイベントの率は問い合わせ率ではありません。対象を絞れないまま総数を代用せず、集計するイベントを確認します。
率だけでなく、元の件数も残す
同じ率でも、完了が少ない集計と多い集計では判断できる範囲が違います。セッション数、完了のあったセッション数、率を一緒に保存します。分母がない期間は、率を無理に出しません。
社内テスト、不要な営業送信、受け付け対象外の相談は、受信記録で別に整理します。GA4に記録された完了を、そのまま有効な商談や受注と呼ばないでください。個人情報を解析のイベント名やパラメータへ入れる必要もありません。
GA4では、どの画面で確認する？
先に、送信成功を表すイベントが正しく届き、キーイベントになっているかを確認します。未設定なら、ページを直す前後で同じ基準の率を比べられません。設定と二重計測の確認はGA4のキーイベントの使い方へ進んでください。
その後で、入口のレポートを開きます。公式ヘルプに沿った基本の操作は次のとおりです。
- レポートのエンゲージメントからランディングページを開く
- 期間を指定し、改善したいページのパスで絞る
- セッション数と、問い合わせ完了のキーイベントを確認する
- 必要に応じて、セッションの参照元とメディアで流入条件を分ける
- 受信側の記録と照合し、試験送信や重複を調べる
レポートが左メニューに無いときは、編集者以上の担当に追加を依頼します。セッション キーイベント レートが表示されていなければ、レポートの編集で指標を追加します。対象イベントも選べる形にし、全イベントの率と分けて保存してください。
入口と経路を同時に確認する方法として、公式ヘルプはトラフィック獲得レポートも案内しています。セッションの参照元とメディアに、ランディングページとクエリ文字列を追加して確認できます。前後で画面を変えるときも、対象イベントと集計条件をそろえます。
LPOでは、何から直す？
以下は、私たちが作業を整理するための提案です。全サイトに共通する効果の順位ではありません。不具合を除いた後、冒頭の答え、フォーム、速度を順に点検し、見つかった問題で作業順を変えます。
最初の画面で、探してきた答えが分かるか
試作の広告から来たのに、冒頭が会社の沿革と量産設備の紹介だけなら、試作を頼めるか判断できません。受ける仕事と条件を最初に出します。対応していない依頼まで受けられるように書き換える作業ではありません。
Googleの広告と案内先の改善ガイドも、広告の内容と案内先を一致させ、必要な行動へ進みやすくするよう説明しています。検索から来る記事では、見出しの問いと本文の答えを照合します。
私たちは暦の自社メディアで、持っていた説明やFAQを別ページへ送らず、その場で答える形へ直しました。出典は2026年8月21日以降の自社作業記録です。これは問い合わせ率の改善実績ではありません。既存の答えを、必要な位置で読めるか確認する例として挙げています。
フォームは、最初の返事に必要な項目か
予算や導入日が決まっていない技術相談へ、確定した値の入力を必須にしていないかを見ます。受付に必要な情報は残し、後のやり取りで確認できる項目は分けます。項目を何個にすれば率が上がる、という一律の数は置きません。
図面がなくても受ける相談なら、添付が必須になっていないかも確かめます。スマホで入力し、エラーの場所が分かるか、内容を失わずに戻れるか、送信が届くかまで試します。
答えやボタンが出るまで、待たされないか
大きな動画、重い製品写真、使っていないスクリプトを調べます。web.devのLCP改善手順は、画像の容量だけでなく、取得開始や表示までの待ち時間を分けて扱っています。写真を圧縮するだけで終えず、何を待っているかを制作担当に調べてもらいます。
必要な仕様や写真まで削らないよう、修正後も読めるかを確認します。読まれている位置はヒートマップの見方で調べ、進むための言葉はCTAの文言と置き場所で整理できます。
A/Bテストは、どの段階で行う？
A/Bテストは、訪問者を案に分け、決めた成果の違いを比べる方法です。比較する内容、対象、主に見る指標、終了の条件を開始前に決めます。曜日や広告が違う前月と今月を比べるだけでは、同じ条件の比較になりません。
少ない問い合わせで、少し多かった案をすぐ勝ちとしないでください。必要な数は、元の率、検出したい差、判断に使う基準で変わります。全サイト共通の必要訪問数は出せません。
米国NISTの二つの割合を比較する統計資料も、大きい標本での近似と、小さい標本での正確な検定を区別しています。小さい数でも計算方法はありますが、十分な差を検出できるかとは別です。検定できることを、必ず判断がつくことと混同しません。
訪問が少ない段階では、送信エラーや案内の誤りを直し、変更日と対象を残します。テストの結論が出るまで、明らかな不具合を放置する必要はありません。
改善後に、何を引き継ぐ？
対象URL、入口の種類、完了イベント、集計条件、変更日、直した箇所をまとめます。広告の配信やフォームの計測設定も変えたなら、その日付を添えます。率が動いた理由を、ページの変更だけに結び付けないためです。
オウンドメディアの構築と運用では、入口で答える内容と、相談を受ける窓口を合わせて整えます。次の修正を決める資料には、率のグラフだけでなく、実際にどんな依頼が届いたかも残してください。
仕様・出典の確認日：2026年10月23日。