問い合わせフォームの計測は正しい？GA4と受付記録を照合する確認表

AI生成のイメージ画像。実際のGA4画面や検証現場ではありません。

問い合わせフォームの計測を確かめるときは、GA4の数字と、サイトが実際に受け付けた記録を一緒に見ます。送信ボタンのクリックや完了画面の表示だけでは、受付が成功したか分からない場合があるからです。まず対象のフォームを一つ選び、「どの状態を1件と数えるか」を決めてください。本記事では、すでにある計測を確認したい中小企業のWeb担当者向けに、正常送信・入力エラー・再読み込みを点検する手順と、制作会社へ渡せる確認表をまとめます。

1. 最初に「何を1件と数えるか」を決める

送信操作と受付完了は、別の確認項目にする

GA4は、ウェブサイト上で発生した操作をイベントとして受け取ります。拡張計測機能のフォーム操作には、入力開始を示すform_startと送信を示すform_submitがあります。ただし、その記録だけを見て、社内の担当者が相談内容を受け取ったと判断するのは早計です。利用中のフォームで、いつイベントが発生しているかを確かめます。

出典：https://support.google.com/analytics/answer/9216061?hl=ja

表が収まらない場合は横にスクロールできます →

Googleの推奨イベントには、問い合わせのフォームや情報提供のリクエストに使うgenerate_leadがあります。名前を設定するだけで問い合わせが正しく数えられるわけではありません。自社で使う成功条件を決め、その条件を満たしたときにイベントを送る設計が必要です。既存の計測名が別にある場合は、最初から置き換えず、現在の用途と定義を確認しましょう。

出典：https://support.google.com/analytics/answer/9267735?hl=ja

対象フォームと集計条件を1行で残す

たとえば「会社サイトの見積もり相談フォームで、受付システムへの保存が成功した申込を数える」と書きます。資料請求、採用応募、一般的な質問が同じサイトにあっても、見積もり相談へ全部を合算しないようにします。何を成果として扱うかは事業の目的で決め、後から確認できる場所に定義を残してください。

記録には対象URL、フォームを区別する名前、イベント名、確認日、担当者を添えます。公式サイトとコラムを同じGA4プロパティで管理している場合は、どちらのサイトを対象にした数字なのかも記載します。単に「問い合わせ5件」と残すより、比較する範囲をそろえやすくなります。ここで挙げた件数は書き方の例で、実際の成果を示すものではありません。

2. フォームの方式と既存の計測経路を確認する

完了ページがあるか、同じ画面で完了するか

送信後に専用のページへ移動するフォームと、その場で完了メッセージを出すフォームでは、確認する箇所が変わります。前者では、完了ページが表示される条件を調べます。後者では、受付成功を通知する仕組みや、制作会社が設定した成功イベントを確認します。画面の見た目だけで成功条件を推測しないでください。

表が収まらない場合は横にスクロールできます →

完了ページを直接開いたり再読み込みしたりするだけで成功イベントが発生するなら、「受付された申込を数える」という定義とずれます。一方、ページが変わらないから計測できないと決めつける必要もありません。フォームの提供元の仕様や、サイトを管理する担当者に、利用できる成功通知と現在の実装を確認します。

動いている経路を調べてから追加する

Googleタグマネージャー（GTM）は、サイトの計測タグなどを管理する仕組みです。GTM、WordPressのプラグイン、テーマの設定、独自のコードが、それぞれ同じ送信を計測している場合があります。新しいタグを追加する前に、現在どこからGA4へ送っているかを一覧にしましょう。

調べる対象は「どのフォームか」「どの成功条件か」「どのイベント名か」「どのGA4プロパティへ送るか」の四つです。既存の経路が一つで正しく動いていれば、その経路を使って確認を進めます。複数の経路が見つかった場合も、すぐに全部を停止せず、使われているレポートと担当者を確認してから整理してください。

3. 一つの操作を受付記録とDebugViewで追う

対象の端末・フォーム・時刻を固定する

DebugViewは、デバッグモードの端末から届くイベントやパラメータを確認するGA4の画面です。Googleは、個人の端末で確認する方法としてTag Assistantやプレビューモードを案内しています。対象の端末を選び、テストした操作と届いたイベントを照合します。タグのプレビュー操作に不慣れな場合は、管理担当者と一緒に進めてください。

出典：https://support.google.com/analytics/answer/7201382?hl=ja

テストの前に、フォームの送信先と担当者に影響がないかを確認します。検証環境や、通知を送らず受付だけを確認できる既存のテスト機能があれば、その範囲で進めます。本番へ送る必要がある場合は、宛先の担当者とテスト内容・回数を先に合わせ、通常の営業対応へ混ざらないようにしてください。実在のお客様の情報を試験データとして流用しないことも前提です。

実施時刻を控え、正常な送信を一度行ったら、受付管理画面や保存ログに対応する記録があるかを見ます。続いてDebugViewで、定義した成功イベントの名前と回数を確認します。関係のないpage_viewなども表示されるため、画面上の全イベントを合計して問い合わせ件数にしないようにします。個々の成功イベントと受付記録を対応させてください。

受付保存・通知処理・メール到着を分ける

受付データの保存、通知メールの送信処理、メールの到着は別の段階です。たとえば、保存は成功したものの、通知メールが迷惑メールフォルダへ入る場合を考えます。このとき「メールが見えないから受付0件」と決めると、受付システムに残っている申込を見落とします。どの段階を成功地点にしたかに戻って調べましょう。

反対に、画面に完了と出ても受付記録がないなら、計測タグより先にフォームの処理を確認する必要があります。まず申込を受け取る機能の問題を直し、その後にGA4との一致を確かめる順序です。テスト結果は「受付あり・通知未確認・GA4到達あり」のように分けて書くと、次の調査を担当者へ渡せます。

4. 正常・エラー・再読み込みを確認表に残す

正常送信だけが成功しても、計測の確認はまだ途中です。入力エラーや完了画面の再表示を、新しい受付として数えていないかも確認します。以下は「受付が新たに成功したときだけ、成功イベントを1回送る」設計を点検するための期待値です。実際の検証結果ではありません。自社の仕様に合わせ、試せない操作は未確認と記入します。

表が収まらない場合は横にスクロールできます →

本番環境を故意に停止させてエラーを作る必要はありません。通信失敗や保存失敗など、運用へ影響する試験は開発担当が管理する検証環境で行います。連続クリックについても、フォーム自体が受付を二重作成しているのか、一つの受付に対してGA4だけ二重送信しているのかを分けて確認します。

記録には個人情報を貼り付けず、検証用の識別子や確認時刻を使います。受付の詳細を閲覧できる人と、計測の設定を触れる人が別の場合もあるため、情報を共有する範囲を先に決めます。スクリーンショットを添える場合は、氏名、メール、電話、相談内容が写らない状態にしてから共有してください。

完了条件は「タグを追加した」ではなく、「対象フォームの正常受付と成功イベントが対応し、エラーや再表示では増えないことを確認した」と書きます。実施できていない試験を合格欄に入れないことが、後日の改修判断にも役立ちます。PCで確認しても、スマホのフォーム表示や送信経路が異なる場合は、その違いを残してください。

5. 数が合わないときは条件から切り分ける

「0件」「2回以上」「一覧だけにない」を分ける

件数が合わないときは、受付からGA4までのどこで差が生まれているかを絞ります。下の表は原因を確定する診断結果ではなく、次の確認先を選ぶための順序です。複数の設定を一度に変えると、何が効いたか分からなくなるため、現状を控えてから一つずつ確認してください。

表が収まらない場合は横にスクロールできます →

DebugViewを使うには、確認したい端末のデバッグモードが必要です。Google公式資料では、同意モードを設定していてアナリティクスのCookieに同意していない場合など、イベントがDebugViewへ表示されない条件も説明されています。表示がないことだけでフォームの受付失敗と判断せず、端末の条件と受付の記録を別々に確認します。

出典：https://support.google.com/analytics/answer/7201382?hl=ja

GA4のデータフィルタで除外されたデータは、処理後のレポートに利用できなくなります。また、設定を変えても過去のデータをさかのぼって直す機能ではありません。「一覧にないから」と本番のフィルタをすぐに変更せず、何をいつから除外する設定になっているかを管理者と確認してください。

出典：https://support.google.com/analytics/answer/13296761?hl=ja

受付件数とGA4が完全一致しない場合もある

日々の全件集計では、ブラウザの計測制限や同意の状態、対象の期間、除外条件などによって差が生じます。動作試験で設計どおりかを調べることと、日々の業務でGA4が全受付を網羅するかは、分けて考える必要があります。受付の事実は受付システムで確認し、GA4は計測できた行動や流入の分析に使います。

イベント回数と人数も同じではありません。同じ人が別の日にもう一度相談することも、再読み込みで同じイベントが発生することもあります。「受付件数」「利用者数」「成功イベント数」のどれを比べているかをそろえ、差が残るときは未確認の範囲を明記します。数を一致させるためだけに申込を削除したり、根拠なくイベントを補ったりしないでください。

6. テストを分け、改修後も同じ定義で確認する

個人情報をGA4へ入れずに検証する

Googleは、個人を特定できる情報をアナリティクスへ送信しないよう求めています。氏名、メール、電話番号、相談本文をイベント名やパラメータへ入れないでください。フォームの入力欄だけでなく、送信後のURLやページタイトルへ入力値が付いていないかも確認します。受付管理のための情報と、解析へ送る情報は分けて設計します。

出典：https://support.google.com/analytics/answer/6366371?hl=ja

照合のために新しい識別子をGA4へ追加する場合も、その値から個人を識別できないかを管理担当者と確認します。日々の営業管理に必要な連絡先は、権限を持つ担当者だけが扱う受付システムへ保存し、共有のSEO管理表には集計値と条件だけを残す方法が使えます。

動作確認を集客成果に数えない

テストで発生した受付やイベントは、通常の見込み客と分けて扱います。GA4にはデベロッパートラフィックなどを対象とするデータフィルタがありますが、除外の影響は恒久的です。運用中の設定を確認し、適用範囲を理解した管理者が扱ってください。テストをした日、対象イベント、除外状況を記録し、未確認なら分析結果にその制約を添えます。

出典：https://support.google.com/analytics/answer/13296761?hl=ja

改修後は、同じフォーム、成功条件、端末条件で再検証します。計測の定義を変えた場合は、その日を境に単純比較できないことがあります。たとえば、従来は完了ページの表示を数え、変更後は受付保存の成功を数える設計なら、数字が減ったことだけで問い合わせが悪化したとは言えません。定義の変更を先に確認しましょう。

担当者へ相談するときは、設定画面を大量に送るより、対象URLと期待する結果、実際の違いを短くまとめます。まだ原因が分からなくても、その三つがあれば調べる範囲を絞れます。VELGRITへの相談も、対象のサイトと困っている現象を整理してお送りください。他社制作サイトは、構成や権限などを事前に調査したうえで対応範囲を確認します。

よくあるご質問