問い合わせフォームへ送る1ページLPを運用し、GA4ではアクセス数と完了数しか見ていない担当者向けの記事です。
「GA4は入っています。アクセス数も見ています」
それでもLPを改善できないケースがあります。
理由は、アクセス数と最終CVだけでは、途中のどこで止まっているか分からないからです。
計測ツールを設置することと、意思決定できる計測を設計することは別です。
■ 最初に決めるのは、最終CV
まず、ページの目的を一つ決めます。
・購入完了
・問い合わせ送信
・予約完了
・資料請求
・説明会申込み
複数の行動がある場合も、事業にとって最も重要なCVを決めます。
電話や外部予約システムへ移動する場合は、サイト内で確認できる最終地点も定義します。
■ 途中の行動を分解する
問い合わせLPなら、
1.ページ閲覧
2.主要CTAクリック
3.フォーム到達
4.入力開始
5.送信ボタンクリック
6.完了ページ表示
という流れがあります。
CTAは押されているのに送信されないなら、ファーストビューよりフォームを疑います。CTA自体が押されないなら、訴求、証拠、料金、案内位置を見直します。
途中を計測することで、全体を作り直さずに済みます。
■ スクロール率だけでは読まれたか分からない
ページ下部まで到達しても、内容を理解したとは限りません。
スマートフォンで勢いよく流しただけかもしれません。逆に、上部で必要な情報を得て電話した人は、スクロールが浅くても価値があります。
スクロール率は、CTAクリック、滞在、動画再生、フォーム到達、ヒートマップと組み合わせて見ます。
■ 外部リンクは、行き先別に分ける
宿泊施設なら、
・通常予約
・団体見積り
・電話
・アクセス地図
で目的が違います。
すべてを「外部リンククリック」と一つにまとめると、どの需要が強いか分かりません。ボタンの役割と設置場所が分かる名前でイベントを設計します。
■ 流入元で読み手の温度が変わる
広告、検索、SNS、指名検索では、ページへ来た理由が違います。
広告で具体的な商品を見た人に、会社の歴史から長く説明すると離脱するかもしれません。指名検索の人は、価格より運営会社や実績を確認したい場合があります。
全体CV率だけでなく、流入元、デバイス、ページ、キャンペーンごとに分けます。
■ 数字を増やしすぎない
計測できるからといって、すべてのクリックをイベントにすると、重要な数字が埋もれます。
経営者や担当者が毎週見る指標は、
・流入数
・主要CTA率
・フォーム到達率
・最終CV率
・1件あたりの獲得費
など、判断に必要なものへ絞ります。
詳細データは原因調査のときに使います。
■ 公開前に計測表を作る
イベント名、発生条件、目的、確認画面を一覧にします。
たとえば、
・cta_primary_click:主要CTAを押した
・form_start:入力を始めた
・form_error:送信時にエラーが出た
・generate_lead:問い合わせが完了した
のように定義します。
実装後は、自分で一連の操作を行い、数字が正しく入るか確認します。
GA4を入れる目的はレポートを眺めることではありません。
どこを直すと成果に近づくか、チームで同じ事実を見て判断することです。
■ 「途中CV」は、改善のための診断装置
ここで大切なのは、途中CVを最終成果と取り違えないことです。
CTAクリックが増えても、問い合わせが増えなければ売上にはつながりません。フォーム開始が増えても、対象外の問い合わせばかりなら営業負担が増えるだけです。
途中CVは評価のゴールではなく、どこに詰まりがあるかを見つける診断装置です。
たとえば、次のように読みます。
・CTAクリック率が低い:訴求、オファー、証拠、ボタン位置を疑う
・CTAは押されるがフォームへ着かない:遷移速度やリンク不具合を疑う
・フォーム開始率が低い:入力項目の多さ、心理的負担、個人情報への不安を疑う
・入力開始後の完了率が低い:エラー表示、必須項目、スマホ操作を疑う
・完了は多いが商談化しない:集客キーワードや対象者の絞り込みを疑う
一つの数字だけで結論を出すのではなく、前後の行動をつないで読みます。
■ 最初に設定したい5つの途中CV
1ページの問い合わせLPなら、私は次の5つから始めます。
1.主要CTAのクリック
ファーストビュー、料金後、実績後、最下部など、どこに置いたCTAかを区別します。同じ文言でも、押された場所によって読み手が判断したタイミングが違います。
2.フォームの表示・到達
別ページのフォームならページ表示、同一ページならフォーム領域の表示を見ます。CTAを押した人が本当に入力画面まで進めたかを確認します。
3.入力開始
最初の入力欄へ触れた時点です。フォームまで来たものの入力しない人と、入力中に離脱した人を分けられます。
4.入力エラー
どの項目で、どの種類のエラーが起きたかを確認します。電話番号の形式や郵便番号、自動入力との相性など、作り手が気づきにくい障害が見つかります。ただし入力内容そのものを分析ツールへ送らないようにします。
5.送信・予約・購入の完了
完了ページの表示だけに頼ると、再読み込みで二重計測されることがあります。フォーム側の送信成功と連携し、一度の成果を一度だけ数えられるか確認します。
この5段階があれば、「読まれていない」「押されない」「入力されない」「送信できない」を切り分けやすくなります。
■ 電話と外部予約を“計測不能”で終わらせない
地域事業、医療、宿泊施設では、電話や外部予約サイトが重要な窓口になります。
電話の成約そのものをWebだけで完全に把握できない場合でも、電話番号タップは計測できます。営業時間内と時間外、ページ上部と下部、スマホとPCを分ければ、導線改善の材料になります。
外部予約についても、予約エンジンへ移動したクリックを、プラン、日付検索、団体相談など目的別に分けます。外部側から予約完了データを戻せない場合は、「予約完了」ではなく「予約画面への送客」と明記します。
計測できたこと以上の成果として報告しない。この線引きが、数字への信頼を守ります。
■ イベント名は、半年後の担当者が読める言葉にする
実装者だけが分かる `click_01` や `button_a` では、後から意味が分からなくなります。
イベント名には行動を、追加情報には場所や種類を持たせます。
例として、イベントは `cta_click`、追加情報は `location=hero`、`cta_type=consultation` のように分けます。
こうすると、イベントを無限に増やさず、同じ定義で比較できます。日本語の計測仕様書には「誰が・どこで・何をしたら発生するか」を書き、実装名との対応を残します。
■ 流入を比較するなら、UTMの命名を先に統一する
SNS投稿や広告ごとに担当者が好きな名前を付けると、同じ媒体が別々に集計されます。
大文字・小文字、略称、日本語と英語、日付の付け方を統一します。広告、メール、SNS、提携先など、継続して使う流入だけでも命名表を作ります。
ただし、社内リンクへUTMを付けると本来の流入元が上書きされることがあります。UTMは外部から入るリンクに使い、ページ内の位置はCTAの追加情報で区別します。
■ 公開直後に必ず行う計測テスト
計測は、設定画面を見ただけでは完成しません。
公開したスマートフォンとPCで、広告リンクを開くところから問い合わせ完了まで実際に操作します。
・一回の操作が二回記録されていないか
・戻る、再読み込みでCVが増えないか
・必須項目エラーが正しく記録されるか
・別ブラウザやスマートフォンでも動くか
・自社のテスト送信を本番レポートで除外できるか
・同意管理を導入している場合、その条件下で期待通り動くか
数字が入ったことだけでなく、数字の意味が仕様書と一致しているかを確認します。
■ 毎週の会議で見るのは、グラフより「次の判断」
レポートを豪華にしても、改善案が決まらなければ価値は生まれません。
毎週または隔週で、次の順に見ます。
1.最終CVと獲得単価は許容範囲か
2.前週・前月から大きく変わった区間はどこか
3.流入元やデバイスに偏りはあるか
4.ヒートマップや問い合わせ内容と矛盾しないか
5.次に一つだけ何を変えるか
アクセスが少ないLPでは、日々の上下に反応しすぎないことも重要です。十分な件数がないときは、数字だけで勝敗を決めず、録画やヒートマップ、営業現場の声を合わせて仮説を育てます。
■ 問い合わせ数の先に「良い問い合わせ」を置く
最終的には、問い合わせ件数だけでなく商談化や成約との接続が必要です。
問い合わせ日時、流入元、相談内容、商談化、成約を個人情報へ配慮しながら対応付けると、「CV率は高いが成約しない広告」と「件数は少ないが良い相談が来る記事」を区別できます。
LP改善の目的は、ダッシュボードの数字をきれいにすることではありません。事業にとって良い相談を、無理のない獲得費で増やすことです。
GA4の設定は技術作業に見えますが、本質は経営判断の共通言語を作る仕事です。何を成果と呼び、どこまで進めば見込みが高まり、どの数字なら施策を止めるのか。そこまで決めて初めて、計測が改善につながります。
石井DXスタジオでは、LP制作時にCTAとフォームの計測を考え、公開後のヒートマップやA/Bテストへつなげます。
A/Bテスト込みのLP制作はこちら