タグ: 問い合わせフォーム

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

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

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

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

よくある質問