タグ: GA4

  • スマホLPの追従CTAは必要？ボタン位置・文言・邪魔にならない設計

    スマホLPの追従CTAは必要？ボタン位置・文言・邪魔にならない設計

    スマホでLPを見ていると、画面下に「無料相談」「お問い合わせ」と書かれたボタンが追従してくることがあります。

    いつでも押せるため便利に見えますが、設置しただけで問い合わせが増えるとは限りません。

    • ボタンが本文を隠している
    • 「お問い合わせ」だけでは、押した後が分からない
    • 押すと長いフォームの先頭へ移動する
    • 電話、LINE、フォームの3つが並び、選べない
    • Cookie通知やチャットボタンと重なっている
    • CTAクリックだけ増え、送信は増えていない

    このような状態では、追従CTAが相談の入口ではなく、画面を狭くする固定パーツになってしまいます。

    結論から言うと、スマホLPの追従CTAは「いつでも押せるボタン」ではなく、「読者が相談しようと思った瞬間に、次の行動を迷わず選べる入口」として設計します。

    この記事では、小規模サービスや個人事業のLPを想定し、追従CTAを置くかどうか、何を表示するか、押した後をどうつなぐか、どこまで計測するかを整理します。

    追従CTAが必要かは、ボタンの色より先に決める

    追従CTAの改善というと、赤、オレンジ、緑などの色や、ボタンの大きさから考えがちです。

    しかし、最初に決めるのはデザインではありません。

    次の3点です。

    1. 誰がスマホでLPを見るのか
    2. その人はどの時点で何を確認したいのか
    3. LPを読んだ後、最初に取ってほしい行動は何か

    たとえば、初回相談に予約が必要なサービスなら「相談日時を選ぶ」が主な行動になります。見積もり前に要件確認が必要なら「制作について相談する」の方が自然です。

    一方、営業時間中の緊急対応が中心なら、電話ボタンが優先される場合もあります。

    追従CTAを置くこと自体を目的にせず、スマホ利用者が次に進むための行動を先に決めます。

    追従CTAが向いているLP

    追従CTAは、次のようなLPで使いやすい傾向があります。

    • ページが長く、CTAまで戻る手間が大きい
    • サービス内容を読んでいる途中で相談したくなる
    • 主な行動が1つに絞られている
    • スマホからの閲覧が多い
    • 問い合わせ、予約、見積もり相談など、押した後の流れが明確
    • CTAの遷移先がスマホでも使いやすい

    反対に、次のような状態では、追従CTAを追加する前に導線を整理した方がよい場合があります。

    • 電話、LINE、フォーム、予約、資料請求が同じ強さで並んでいる
    • 問い合わせ前に必ず読んでほしい条件が整理されていない
    • 押した先のフォームが長く、スマホで入力しにくい
    • CTAごとに文言や遷移先がばらばら
    • 画面下にチャット、Cookie通知、共有ボタンがすでにある

    入口だけ強くしても、押した後で迷えば相談にはつながりません。

    最初に「主CTA」を1つ決める

    スマホ画面は狭いため、複数のボタンを並べるほど選びやすくなるとは限りません。

    まず、最も取ってほしい行動を主CTAとして1つ決めます。

    サービスの状態 主CTAの例 補助導線の例
    要件を聞いてから見積もる 制作について相談する 料金目安を見る
    相談日時を先に決める 相談日時を選ぶ 相談内容を確認する
    資料を見てから検討してほしい サービス資料を見る 個別に相談する
    緊急性が高い 電話で確認する フォームで問い合わせる
    相談内容の分類が必要 相談フォームへ進む よくある質問を見る

    補助導線が必要でも、追従領域には主CTAだけを置き、他の選択肢は本文やフォーム付近へ分ける方法があります。

    「選べる数を増やす」より、「今押すべき入口を分かりやすくする」ことを優先します。

    ボタン文言は押した後の行動まで伝える

    「お問い合わせ」「詳しくはこちら」「無料相談」だけでは、押した後に何が起きるか分かりにくい場合があります。

    特にスマホでは、ボタンの周囲に説明文を置ける余白が少ないため、短い文言の中で行動を具体化します。

    曖昧になりやすい文言

    • お問い合わせ
    • 詳しくはこちら
    • 今すぐ
    • 申し込む
    • 無料相談

    行動が分かりやすい文言

    • LP制作について相談する
    • 自動化できるか相談する
    • 相談日時を選ぶ
    • 見積もり条件を送る
    • 料金と進め方を確認する

    長すぎる文言は読みにくくなるため、すべてをボタン内へ詰め込む必要はありません。

    たとえば、ボタンの上に短い補足を置きます。

    相談内容が固まっていなくても大丈夫です

    ボタン:

    LP制作について相談する

    このように、「押す不安を減らす補足」と「押した後の行動」を分けると整理しやすくなります。

    CTAはページ内の検討段階に合わせて置く

    追従CTAがあっても、本文中のCTAが不要になるわけではありません。

    読者は、ページのどこにいるかによって確認したいことが変わります。

    ファーストビュー

    何のサービスか理解した直後の入口です。

    ここでは、対象者と提供価値がまだ伝わっていない状態で強い申込みを求めないようにします。相談型サービスなら、「相談する」「進め方を見る」など、検討段階に合う表現が使いやすくなります。

    サービス内容の後

    できることを理解した後です。

    「この内容について相談する」「対応範囲を確認する」など、直前の説明とつながるCTAを置きます。

    料金・納期の後

    条件を確認した後です。

    「条件を伝えて概算を相談する」「希望納期を送る」など、見積もりに必要な次の行動を示します。

    FAQの後

    不安を解消した後です。

    「まだ決まっていない点を相談する」のように、FAQで解決しなかった疑問を送れる入口にします。

    追従CTA

    ページのどこでも使える共通入口です。

    特定セクションの文脈に寄せすぎず、LP全体を通じた主行動を表示します。

    本文中のCTAはその場所の文脈に合わせ、追従CTAは共通の主行動にする。この役割分担があると、同じボタンを繰り返すだけのページになりにくくなります。

    追従CTAを邪魔にしない表示ルール

    追従CTAは画面上に固定されるため、通常のボタンよりも表示確認が重要です。

    最低限、次を確認します。

    • 本文の最終行や表の下部を隠さない
    • Cookie通知と重ならない
    • チャットボタンやページ上部へ戻るボタンと重ならない
    • スマホ下部の安全領域を考慮する
    • 横向き表示で画面を占領しすぎない
    • フォーム入力中にキーボードと重ならない
    • モーダルやメニューを開いたときに前面へ残らない
    • エラーメッセージや送信完了表示を隠さない

    固定領域には、ボタン以外の情報を詰め込みすぎないことも重要です。

    電話番号、営業時間、補足文、アイコン、2つのボタンをすべて入れると、本文を読む領域が狭くなります。

    追従CTAの役割は、説明することではなく、次の行動を選びやすくすることです。

    常時表示ではなく、表示開始と停止を決める

    ページを開いた瞬間から追従CTAを出す方法もありますが、すべてのLPに向いているわけではありません。

    ファーストビューのCTAと重複して画面が窮屈になる場合は、読者が少しスクロールした後に表示する方法があります。

    また、フォームまで到達した後も固定CTAが残ると、入力欄や送信ボタンの邪魔になる場合があります。

    表示ルールの例:

    • ファーストビューを通過したら表示する
    • 本文を一定量読んだら表示する
    • 問い合わせフォームに到達したら非表示にする
    • メニュー、モーダル、Cookie通知の表示中は隠す
    • 送信完了ページでは表示しない

    表示開始と停止を決めると、CTAを目立たせながら、必要な操作を邪魔しにくくなります。

    押した先を最短にする

    追従CTAを押した後の遷移先は、ボタン文言と一致させます。

    「相談日時を選ぶ」と書かれているのに、サービス一覧の先頭へ移動すると、利用者はもう一度入口を探すことになります。

    「LP制作について相談する」と書かれているなら、問い合わせフォームで相談種別が選ばれている、またはLP制作向けの入力項目がすぐ見える状態が理想です。

    遷移先で確認したいこと:

    • ボタン文言と遷移先の見出しが一致しているか
    • ページ内リンクの移動先がずれていないか
    • 固定ヘッダーで見出しが隠れていないか
    • フォームの必須項目が多すぎないか
    • スマホの入力方式が項目に合っているか
    • 送信後に受付完了が分かるか
    • 自動返信や次の連絡目安が示されているか

    CTAはクリックで終わりではありません。押した後に迷わず完了できるかまでを導線として扱います。

    電話・フォーム・予約を同じ強さで並べない

    スマホLPでは、電話、フォーム、予約、LINEなど複数の連絡方法を用意したくなることがあります。

    しかし、すべてを追従CTAへ並べると、どれを選ぶべきか利用者に判断させることになります。

    連絡方法ごとに役割を分けます。

    連絡方法 向いている状況 事前に伝えること
    フォーム 内容を整理して確認したい 返信目安、必要項目
    予約 初回相談の枠が決まっている 所要時間、相談方法
    電話 緊急性があり、受付時間が明確 受付時間、対応できる内容
    メール 添付資料や詳細説明が必要 返信先、必要情報

    主CTAは最も標準的な相談方法にし、例外的な連絡方法は本文で案内する方が、入口を整理しやすくなります。

    CTAクリックだけを成果にしない

    追従CTAを設置した後、クリック数だけを見て「改善した」と判断すると、実際の問い合わせ増加とずれることがあります。

    次の段階を分けて確認します。

    1. CTAが表示された
    2. CTAがクリックされた
    3. フォームへ到達した
    4. 入力を始めた
    5. 送信処理を実行した
    6. 送信が成功した
    7. 管理画面やメールに受付記録が残った

    追従CTAだけでなく、ファーストビュー、料金表の後、FAQの後など、設置場所も分けて記録すると、どの文脈で相談意欲が高まったかを見やすくなります。

    たとえば、計測項目として次を持ちます。

    • cta_location: sticky、first_view、pricing、faq
    • cta_label: ボタン文言
    • destination: form、booking、phone
    • page_path: CTAが押されたページ

    ただし、イベント名やパラメータを増やすだけでは改善できません。

    「クリックは増えたが入力開始が増えない」なら遷移先やフォームを確認します。「入力開始は増えたが送信成功が増えない」なら必須項目、エラー、送信処理を確認します。

    実機確認で見るポイント

    制作画面のスマホプレビューだけでは、実際のブラウザUIやキーボードとの重なりを見落とすことがあります。

    公開前には、少なくとも複数の画面幅と実機で確認します。

    確認項目:

    • 親指で押しやすい位置か
    • ボタン内の文字が改行していないか
    • 長いページ名やブラウザバー表示時でも崩れないか
    • 縦向き、横向きの両方で本文を隠さないか
    • フォーム入力時に固定CTAが邪魔にならないか
    • Cookie通知、チャット、共有ボタンと重ならないか
    • ページ内リンク後の見出しが固定ヘッダーで隠れないか
    • 読み上げやキーボード操作でも意味が分かるラベルか
    • ボタンを連打しても二重遷移や二重送信が起きないか
    • 通信が遅いときに押せたか分かるか

    特に、画面下に固定する要素が複数ある場合は、個別に正常でも同時表示で崩れることがあります。

    「CTA単体」ではなく、「実際のページ上で他の固定要素と同時に表示した状態」を確認します。

    小規模サービス向けのCTA例

    YOSHIO.devのサービス領域に近い例で考えると、次のように整理できます。

    LP制作

    補足:

    既存LPの一部改善から相談できます

    主CTA:

    LP制作について相談する

    業務自動化

    補足:

    自動化できるか未確定でも大丈夫です

    主CTA:

    減らしたい作業を相談する

    小型ツール開発

    補足:

    Excelやスプレッドシートの現状から確認します

    主CTA:

    作りたいツールを相談する

    ローカルLLM・RAG

    補足:

    対象文書や利用人数が未整理でも相談できます

    主CTA:

    RAGの導入条件を相談する

    同じ「お問い合わせ」でも、サービスごとに利用者が伝えたい内容は異なります。

    サービスページの主題に合わせて文言とフォーム項目をつなげると、問い合わせ時の説明負担も減らしやすくなります。

    追従CTAの導入前チェックリスト

    • 主な行動を1つに決めた
    • CTAの対象者を説明できる
    • ボタン文言から押した後の行動が分かる
    • 補助導線を追従領域へ詰め込みすぎていない
    • ファーストビューと追従CTAの役割を分けた
    • 本文中のCTAは直前の内容とつながっている
    • 表示開始と停止の条件を決めた
    • フォーム到達後は邪魔にならない
    • Cookie通知やチャットと重ならない
    • 遷移先の見出しとボタン文言が一致している
    • CTAクリックと送信成功を分けて計測できる
    • 設置場所ごとのクリックを区別できる
    • 実機で縦向き、横向き、フォーム入力を確認した
    • 低速通信や連打時の挙動を確認した
    • CTAを外した状態とも比較できる

    まずは1ページ、1行動から見直す

    スマホLPの追従CTAは、目立つ色のボタンを画面下へ固定するだけの機能ではありません。

    誰に、どの行動を取ってほしいかを決め、ボタン文言、表示位置、表示条件、遷移先、フォーム、計測までを一続きで設計する必要があります。

    最初から複数のCTAや複雑な出し分けを作る必要はありません。

    まずは1つのLPで、主CTAを1つに絞ります。そのうえで、追従CTAのクリック、フォーム到達、入力開始、送信成功を確認します。

    クリックされない場合は文言や表示位置を見直します。クリックされても送信されない場合は、遷移先やフォームを見直します。

    このように段階を分けると、LP全体を作り直さなくても、問い合わせ導線のどこを改善すべきか判断しやすくなります。

    スマホLPのCTAが「あるだけ」になっていませんか？

    追従CTAを置いていても、文言が曖昧、押した先が長い、フォーム入力中に邪魔になる状態では、問い合わせ導線として機能しません。YOSHIO.devでは、既存LPのスマホ表示、CTA、フォーム、GA4計測を確認し、ページ全体を作り直すべきか、導線の部分改善で足りるかを整理できます。

    LPのスマホCTAについて相談する

    関連リンク

    FAQ

    追従CTAを置けば問い合わせは増えますか？

    必ず増えるとは限りません。追従CTAは入口を見つけやすくする仕組みです。文言が曖昧、遷移先が分かりにくい、フォームが入力しにくい場合は、クリックだけ増えて送信につながらないことがあります。CTAクリック、フォーム到達、入力開始、送信成功を分けて確認してください。

    追従CTAはページを開いた直後から表示すべきですか？

    LPの構成によります。ファーストビューにもCTAがあり、固定ボタンで画面が狭くなる場合は、少しスクロールした後に表示する方法があります。フォームへ到達したら非表示にするなど、表示開始と停止の条件を決めることが重要です。

    電話と問い合わせフォームを2つ並べてもよいですか？

    利用者が選びやすければ可能ですが、同じ強さで並べると迷うことがあります。標準的な相談方法を主CTAにし、電話は受付時間や緊急時など利用条件を添えて補助導線にする方法があります。

    CTAの色は何色がよいですか？

    特定の色だけで成果が決まるわけではありません。背景や他の要素と区別でき、文字が読みやすく、ボタンだと認識できるコントラストが必要です。色だけを変える前に、文言、設置場所、遷移先、フォームの使いやすさも確認してください。

    既存LPの追従CTAだけ改善する相談はできますか？

    可能です。既存LPの構成、スマホ表示、現在のCTA、フォーム、計測状況を確認し、必要な範囲だけ見直す方法があります。ページ全体の作り直しが必要か、CTAと問い合わせ導線の修正で足りるかを切り分けて相談できます。

  • LPの問い合わせ件数がGA4と合わない理由｜計測漏れ・二重計測を防ぐ設計

    LPの問い合わせ件数がGA4と合わない理由｜計測漏れ・二重計測を防ぐ設計

    LPの問い合わせ成果をGA4で計測するなら、送信ボタンが押された瞬間ではなく、フォームの受付が成功した時点をキーイベントにすることが重要です。

    送信ボタンのクリック、フォームの送信処理、受付完了、担当者への通知は、それぞれ別の状態です。

    クリック後に入力エラーや通信エラーが起きることもあります。反対に、問い合わせは正常に届いているのに、ブラウザ側の計測が動かずGA4へ記録されないこともあります。

    そのため、GA4の数字だけを見て「問い合わせは3件だった」と判断するのではなく、実際の受信メール、フォーム管理画面、スプレッドシート、CRMなどの受付記録と照合できる設計が必要です。

    この記事では、小規模事業者や少人数チーム向けに、LPの問い合わせ件数とGA4の数字が合わない原因、form_submitとgenerate_leadの使い分け、計測漏れと二重計測を防ぐ確認方法を整理します。

    入力項目の多さや自動返信など、フォーム自体の離脱原因を調べたい場合は、LPの問い合わせフォームで離脱される理由も参考になります。

    結論：問い合わせ計測は4つの状態を分ける

    問い合わせフォームでは、少なくとも次の4つを分けて考えます。

    状態分かること成果として扱うか
    フォーム入力開始フォームを使い始めた成果ではない
    送信操作送信ボタンを押した、または送信処理を開始した原則として成果ではない
    受付成功サーバー側で問い合わせを受け付けたGA4のキーイベント候補
    実際の受信記録メール、管理画面、CRMなどに問い合わせが残った業務上の正本

    GA4の拡張計測では、設定によりフォームの操作を form_start や form_submit として取得できます。

    ただし、form_submitはフォームの送信操作を捉えるイベントです。自社の受付システムに問い合わせデータが保存されたことや、担当者へ通知が届いたことまで保証するものではありません。

    問い合わせ獲得を表すイベントには、GA4の推奨イベントである generate_leadを使えます。generate_leadは、サーバーから成功応答が返った後や、受付完了ページが正常に表示された時点など、実際の受付成功に合わせて送ります。

    重要なイベントはGA4でキーイベントとして設定し、LP改善や流入元の評価に使います。

    GA4より実際の問い合わせが多いときの原因

    実際には10件届いているのに、GA4では7件しか記録されていない。この場合は、問い合わせの受付よりGA4のイベント送信が少なくなっています。

    1. 受付成功後にイベントを送っていない

    フォームプラグインや外部フォームを設置しただけで、GA4へ問い合わせ成功イベントが自動送信されるとは限りません。

    送信ボタンのクリックは取れていても、受付成功時の generate_leadが設定されていない場合があります。

    まず、どのタイミングで何のイベントが発生しているかをGA4のDebugViewやリアルタイム表示で確認します。

    2. Ajaxフォームでページ遷移が起きない

    Ajaxフォームは、ページを移動せずに「送信しました」と表示できます。

    サンクスページの表示を問い合わせ成果にしている場合、ページ遷移がないフォームではイベントが発生しません。

    この場合は、フォーム側の送信成功コールバックや、成功時に出力されるデータレイヤーイベントを使い、成功後だけ generate_leadを送る設計にします。

    3. 外部フォームや埋め込みフォームの中を計測できていない

    予約、資料請求、問い合わせに外部サービスのフォームを使う場合、LPとフォームが別ドメインになっていたり、iframe内で動いていたりすることがあります。

    LP側のGoogleタグだけでは、外部フォーム内の送信成功を直接取得できない場合があります。

    外部サービスが提供する完了ページ、コールバック、Webhook、タグ連携機能を確認します。連携方法がない場合は、外部フォーム側の完了件数を正本とし、LP側では外部フォームへの遷移までを補助指標として計測します。

    4. ブラウザ側の計測が遮断されている

    問い合わせの受付はサーバー側で成功しても、広告ブロッカー、ブラウザ設定、同意状態、通信エラーなどにより、GA4イベントが送られないことがあります。

    そのため、ブラウザで動くGA4の件数が、実際の受信件数と常に完全一致するとは限りません。

    GA4は流入や行動を分析する計測として使い、問い合わせの実数はフォーム管理画面や受付ログでも確認します。

    5. 特定のフォームだけ設定から漏れている

    同じサイト内に、通常の問い合わせ、見積もり相談、資料請求、採用応募など複数のフォームがある場合、一部のフォームだけイベント設定がないことがあります。

    LPごと、フォームごとに form_idや用途を整理し、どのフォームが計測対象か一覧にします。

    GA4の方が問い合わせ件数より多いときの原因

    GA4では10件の問い合わせがあるのに、実際の受信は6件しかない。この場合は、失敗した送信や重複したイベントまで成果として数えている可能性があります。

    1. 送信ボタンのクリックを成果にしている

    クリック計測は実装しやすい一方、入力エラー、必須項目漏れ、確認画面からの戻り、通信失敗も含む可能性があります。

    「送信する」ボタンを押したことと、問い合わせが届いたことは分けます。

    ボタンクリックはフォーム操作の分析に使い、問い合わせ成果は受付成功後のイベントにします。

    2. form_submitをそのまま問い合わせ成功としている

    form_submitが発生しても、サーバー側の受付処理が失敗する場合があります。

    また、フォームの実装によっては、確認画面へ進む処理や途中の送信操作を捉えることもあります。

    form_submitは送信操作の確認に使い、キーイベントにするイベントは受付成功後の generate_leadなどへ分けると、役割が明確になります。

    3. サンクスページを再読み込みすると再計測される

    サンクスページの表示をそのまま成果にすると、再読み込み、戻る・進む、ブックマーク、URLの共有などで同じ人が複数回計測されることがあります。

    完了ページは、送信処理を通った場合だけ表示できるようにします。さらに、同じ受付IDでイベントを何度も送らない制御があると重複を減らせます。

    受付IDそのものをGA4へ送る必要はありません。重複防止は自社側で行い、GA4には個人を特定しないイベントと必要最小限の分類だけを送ります。

    4. 自動計測と手動計測が両方動いている

    GA4の拡張計測、Googleタグマネージャー、フォームプラグイン、サイトへ直接書いたJavaScriptが、同じ送信を別々に計測している場合があります。

    たとえば、拡張計測の form_submitと、Googleタグマネージャーで作った generate_leadは目的が違えば併存できます。

    一方、同じ受付成功に対して generate_leadが2回発生しているなら二重計測です。どのタグが、どの条件で、何回発火したかをDebugViewとタグのプレビューモードで確認します。

    5. テスト送信や迷惑問い合わせも含まれている

    公開前のテスト、制作会社の動作確認、自社スタッフの送信、スパム送信がGA4へ記録されると、実際の商談候補より件数が多く見えます。

    GA4の問い合わせ獲得数と、有効な相談件数は別の指標です。

    受付成功は generate_lead、担当者が内容を確認した後は「有効」「対象外」「スパム」などをフォーム管理側で分類すると、広告やLPの評価を誤りにくくなります。

    おすすめのイベント設計

    問い合わせフォームでは、1つのイベントだけで全体を判断するより、途中の行動と受付成功を分ける方が原因を調べやすくなります。

    イベント例発生タイミング用途キーイベント
    form_startフォームへ初めて入力した入力開始率を見るしない
    form_submitフォームを送信した送信操作の確認原則しない
    generate_lead問い合わせ受付が成功した問い合わせ成果を測る候補
    form_error送信失敗やシステムエラーが起きた不具合を見つけるしない

    form_errorは必要に応じて作るカスタムイベントです。

    入力項目ごとの内容やエラーメッセージ全文をGA4へ送るのではなく、validation_error、server_error、timeoutなど、個人情報を含まない分類だけを送ります。

    イベントパラメータは分析に必要なものだけにする

    フォームが複数ある場合、イベント名だけではどのLPから問い合わせが来たか分かりません。

    次のような個人を特定しない情報をパラメータとして整理すると、分析しやすくなります。

    • form_id: contact_main、estimate_lpなどの内部識別名
    • form_location: LP下部、固定CTA、サービスページなどの設置場所
    • lead_type: 問い合わせ、見積もり、資料請求などの用途
    • page_type: LP、サービスページ、記事などのページ種別
    • submission_result: success、validation_error、server_errorなどの結果分類

    メールアドレス、氏名、電話番号、会社名、問い合わせ本文などをGA4のイベントパラメータへ送ってはいけません。

    フォームの入力値をデータレイヤーへそのまま入れる設計も避けます。分析に必要なのは「誰が送ったか」ではなく、「どのフォームで、どの状態になったか」です。

    フォーム方式ごとの成功判定

    サンクスページへ移動するフォーム

    受付成功後だけサンクスページへ移動する構成なら、完了ページの表示をきっかけに generate_leadを送る方法があります。

    ただし、URLを直接開ける、再読み込みで再発火する、別用途のフォームが同じ完了ページを使う場合は重複や混在が起きます。

    送信処理を通ったときだけ完了ページへ進めるか、フォーム種別を区別できるかを確認します。

    Ajaxで完了メッセージを表示するフォーム

    ページ遷移がないため、完了メッセージが表示されたことだけを見た目から推測するより、フォーム側が返す成功応答や成功コールバックを使います。

    成功時に dataLayer.push()で専用イベントを送り、Googleタグマネージャーで generate_leadを発火する形にすると、表示変更の影響を受けにくくなります。

    外部サービスへ移動するフォーム

    LP側では外部フォームへのクリックを計測し、外部サービス側では受付完了を計測します。

    同じGA4プロパティへイベントを送れるか、ドメインをまたぐ設定が必要か、外部サービスにタグやコールバックを設定できるかを確認します。

    連携できない場合は、外部サービスの受付件数を正本とし、LP側のクリック数は途中指標として扱います。

    電話、LINE、予約サービスもCTAに含むLP

    電話タップ、LINE遷移、予約ページへの移動は、問い合わせフォームの送信成功とは別の行動です。

    すべてを同じ generate_leadへまとめると、何件がフォーム問い合わせで、何件が外部遷移か分からなくなります。

    電話タップ、LINE遷移、予約完了、フォーム受付を分け、最終成果の定義を決めます。

    公開前に行う計測テスト

    設定しただけで終わらせず、成功、入力エラー、通信失敗、再読み込みなどを実際に試します。

    1. GA4のDebugViewとGoogleタグマネージャーのプレビューを開く
    2. フォームを空のまま送信し、成果イベントが出ないことを確認する
    3. 必須項目を一部だけ入力し、入力エラーでは成果イベントが出ないことを確認する
    4. 正常に送信し、受付完了後に generate_leadが1回だけ出ることを確認する
    5. 問い合わせメールまたは管理画面に同じテスト送信が1件あることを確認する
    6. サンクスページを再読み込みし、不要な再計測が起きないか確認する
    7. スマートフォンでも送信し、同じ条件で計測されるか確認する
    8. 複数フォームがある場合は、各フォームのIDと用途が正しく記録されるか確認する
    9. メールアドレスや問い合わせ本文がイベントパラメータやURLへ入っていないことを確認する

    DebugViewで見えたイベントが、標準レポートへすぐ同じ形で表示されるとは限りません。公開前の発火確認はDebugViewやリアルタイム表示を使い、日次の集計は処理後のレポートで確認します。

    毎月行いたい「GA4と実数」の照合

    計測は公開時に正しくても、フォームプラグインの更新、タグの変更、サンクスページURLの変更、外部サービスの仕様変更などでずれることがあります。

    月に1回でも、次の数字を同じ期間で並べます。

    • GA4の generate_lead件数
    • フォーム管理画面の受付成功件数
    • 担当者が受信した通知件数
    • 有効な問い合わせ件数
    • スパム、テスト、対象外の件数

    完全一致しないこと自体が、すぐに失敗を意味するわけではありません。

    大切なのは、なぜ差が出るか説明できることです。差が急に大きくなった場合に、フォーム障害、タグ停止、二重発火、通知メール不達などを調べられる状態にします。

    問い合わせ内容の保存、担当者への通知、未対応の一覧化まで必要な場合は、問い合わせフォームを小型業務ツール化する方法も参考になります。

    小規模なLPなら最初にここまで整える

    複雑な計測基盤を最初から作る必要はありません。

    小さく始めるなら、次の構成が現実的です。

    • 受付成功後だけ generate_leadを1回送る
    • generate_leadをGA4のキーイベントにする
    • フォームごとに個人情報を含まない form_idを付ける
    • 問い合わせをメールだけでなく管理画面やスプレッドシートにも残す
    • 月1回、GA4と実際の受付件数を照合する
    • LPやフォームを変更したら、成功・失敗・再読み込みを再テストする

    これだけでも、送信ボタンのクリック数を問い合わせ件数として扱う状態より、改善判断の精度を上げられます。

    アクセスが少ないから問い合わせがないのか。フォームで離脱しているのか。問い合わせは届いているのに計測できていないのか。原因を分けて見られるようになります。

    計測を整えた後は、LP公開後の改善チェックリストを使い、流入、CTAクリック、フォーム到達、問い合わせ内容まで順番に確認します。

    YOSHIO.devで相談できること

    YOSHIO.devでは、LP制作、公開後の改善、フォーム計測、問い合わせ後の業務自動化について相談できます。

    たとえば、次のような相談です。

    • GA4と実際の問い合わせ件数が合わない原因を整理したい
    • フォーム送信成功時だけキーイベントを発生させたい
    • Googleタグマネージャーの発火条件を確認したい
    • Ajaxフォームや外部フォームの完了を計測したい
    • 複数のLPやフォームを用途別に見分けたい
    • 問い合わせをスプレッドシートや小型管理画面へ残したい
    • LP公開後に何を見て改善すべきか整理したい

    タグ設定だけでなく、何を問い合わせ成果とするか、実際の受信記録とどう照合するかまで含めて整理します。

    現在のLP URL、フォーム方式、GA4で見えている件数、実際の問い合わせ件数が分かると、確認範囲を絞りやすくなります。個人情報を含む問い合わせ本文を送る必要はありません。

    問い合わせ計測・LP改善を相談する

    まとめ

    LPの問い合わせ件数とGA4の数字が合わないときは、計測ツールだけを見るのではなく、問い合わせ処理を段階に分けます。

    フォーム入力開始、送信操作、受付成功、実際の受信は別の状態です。

    送信ボタンのクリックや form_submitをそのまま成果にすると、入力エラーや通信失敗まで含む可能性があります。反対に、ブラウザ側の計測が動かなくても、問い合わせ自体は届いている場合があります。

    受付成功時に generate_leadを送り、GA4のキーイベントとして使い、フォーム管理画面や受付ログの実数と定期的に照合する。この形なら、計測漏れと二重計測の両方を見つけやすくなります。

    よくある質問

    GA4のform_submitだけで問い合わせ件数を計測できますか？

    送信操作の確認には使えますが、受付成功と同じとは限りません。入力エラーや通信失敗を除くため、サーバー側で受付が成功した後にgenerate_leadなどの成果イベントを送る設計がおすすめです。

    サンクスページを表示した回数をキーイベントにしてもよいですか？

    受付成功後だけ表示され、再読み込みやURLの直接表示で重複しない構成なら使えます。Ajaxフォームや外部フォームではページ遷移がない場合があるため、フォーム方式に合わせて成功判定を選びます。

    GA4の問い合わせ数と実際の受信件数は完全一致しますか？

    必ずしも完全一致しません。広告ブロッカー、ブラウザ設定、同意状態、通信エラーなどでGA4イベントだけ欠ける場合があります。実数はフォーム管理画面や受付ログで確認し、GA4は流入と行動の分析に使います。

    generate_leadには何を送ればよいですか？

    フォームID、設置場所、問い合わせ種別など、分析に必要な個人を特定しない情報に絞ります。氏名、メールアドレス、電話番号、会社名、問い合わせ本文はGA4へ送らないでください。

    Googleタグマネージャーを使えばフォーム改修なしで計測できますか？

    ボタンクリックやサンクスページ表示は設定できる場合がありますが、Ajaxフォームの受付成功を正確に取るには、フォーム側の成功コールバックやデータレイヤー連携が必要になることがあります。

    問い合わせ計測だけの小規模な相談もできますか？

    はい。現在のLP、フォーム方式、GA4と実数の差を確認し、成功条件、イベント、キーイベント、テスト方法を小さな範囲から整理できます。