トピックス

GA4の問い合わせ計測を確認する方法|テスト・二重計測・受付件数との照合

問い合わせフォームの画面とチェックリストを使って計測を確認する担当者のイラスト
3BROS. JOURNAL / PRACTICAL GUIDEGA4 / MEASUREMENT CHECK

WORKING NOTES

イベントの数字と、実際の受付を照らし合わせる。

GA4に問い合わせのキーイベントが出ていても、すべてが新しい相談とは限りません。担当者のテスト、同じ操作での重複発火、フォーム以外の行動が含まれていないかを確認しましょう。この記事はタグの実装コードではなく、計測担当者と一緒に行う検証手順と記録方法をまとめたガイドです。

01何を1件と数えているかを確認する

問い合わせボタンのクリック、フォームの送信操作、正常な受付完了は別の行動です。最初に、現在のイベントがどの段階で送られるかを確認します。名前が「問い合わせ」でも、発火条件まで見なければ意味は分かりません。

行動分かることそれだけでは分からないこと
問い合わせボタンを押すフォームへ進もうとした送信や受付が完了したか
フォームの送信を操作する送信処理が始まった可能性入力エラーや通信失敗がないか
正常受付を確認するフォーム側で完了した営業対象の相談か、重複・テストか

表は横にスクロールできます。

GA4では、必要なイベントをキーイベントとして扱えます。フォーム関連のイベントも、対象フォームや実装によって挙動を確認する必要があります。イベント名だけを見て、受付メールの件数と一致する前提を置かないでください。

計測定義

イベント名・発火条件・対象フォーム・測定先プロパティを確認する。

受付定義

何を正式な受付として扱うかを、フォームや管理台帳で確認する。

成果定義

テスト、営業連絡、重複などをどう分類するか決める。

02正常・エラー・再表示を分けてテストする

テスト前に、フォームの受付担当へ実施時間を共有します。ダミーの入力を使い、実際の顧客情報を分析画面へ送らないようにします。テストが営業対応や自動通知を動かす場合は、運用担当と影響を確認してから進めてください。

テストケースフォーム側で見ること計測側で見ること
正常に送信する受付が1件作られるか定義した完了イベントが想定どおり発火するか
必須項目を空欄にする入力エラーになり受付されないか完了を意味するイベントが誤発火しないか
完了画面を再読み込み新規受付が増えていないか同じ受付を重ねて数えていないか
完了URLを直接開く受付を伴わず表示されるか表示だけで完了扱いにならないか
別の対象端末で送信通常の利用環境で完了するか端末・同意条件などで挙動が変わるか

表は横にスクロールできます。

完了URLがないフォームでは、その行は対象外として構いません。サイトの仕様に合うケースを選び、テスト結果を「成功・失敗」だけでなく、どの操作で何が起きたかで残します。

DebugViewで何を見る?

デバッグモードを有効にした対象端末で、イベントの順序やパラメータを確認します。通常レポートの反映とは分けて考え、デバッグ情報が表示されない場合は対象端末や設定条件も確認します。画面に出ないことだけでタグ停止とは断定しません。

正常送信の前後でイベントが2回出た場合は、時刻とイベント名、発火経路を担当者へ共有します。同じ名前のイベントがあるだけで即削除せず、別の用途で必要な計測かも確認してください。

03二重計測と受付件数との差を切り分ける

件数が合わないときは、まず対象期間、タイムゾーン、フォームの範囲、集計する指標をそろえます。GA4のイベント数・キーイベント数・ユーザー数は同じ意味ではありません。受付側にも迷惑送信や重複、送信後の削除があるかを確認します。

症状原因の候補最初に確かめること
1回の操作で複数発火複数タグ・複数経路・再表示同じテストでのイベント順序と条件
GA4だけ多いテスト混入・対象フォームが広いテスト履歴とイベント対象
受付側だけ多い同意や計測制限・タグ未発火端末条件と正常送信時の挙動
急に0件になる実際に送信がない・条件変更受付記録と直近のサイト変更

表は横にスクロールできます。

これらは原因の候補です。実際の発火条件や受付記録を見ずに、特定の設定が原因と断定することはできません。修正は問題が再現した条件に絞り、元の設定と変更日を記録してから行います。

キーイベントのカウント設定も確認する

イベント数とキーイベントの数え方が異なる場合があります。重複を見えなくするためだけにカウント設定を変えず、まず意図しない発火があるかを確かめます。設定変更後は同じテストを再実施しましょう。

数字が完全一致しないこともある

アクセス解析の取得条件と受付システムの記録条件は異なります。差の理由を説明できる状態を目指し、GA4の件数をそのまま顧客や商談の実数として報告しないことが大切です。

04テスト履歴を残して運用へ戻す

担当者の確認操作が少数データに混ざると、前週比較の見え方が変わります。テストした日と内容を残し、実成果を報告するときに混同しないようにします。テスト件数を推測で差し引くのではなく、確認できた記録に基づいて扱います。

計測テスト記録の例 実施日時:年月日・時刻・タイムゾーン 対象:フォームURL・GA4プロパティ・イベント名 操作:正常送信/入力エラー/完了画面の再表示 端末条件:ブラウザー・同意状態・デバッグ有無 期待する結果:正常受付のみ1回の完了イベント 実際の結果:イベント順序と受付側の確認結果 対応:修正担当・再テスト日・比較レポートへの注記
  • テストの受付連絡を運用担当へ共有した
  • 正常送信と入力エラーを分けて確認した
  • 不要な重複発火の有無を調べた
  • レポートの指標・期間・対象フォームをそろえた
  • テスト分を実成果と分けて記録した
  • 設定変更後に同じ条件で再確認した

イベントが0件なら計測故障ですか?

受付自体がなかった可能性もあります。受付記録を確認し、テスト送信で動作を検証してから判断します。リアルタイムの利用者が0人という瞬間値だけでも故障とは言えません。

問い合わせ本文をGA4へ送れば照合できますか?

問い合わせ本文や氏名・メールアドレスなどを分析パラメータへ入れる方法は採らず、受付側の管理記録とテスト日時を使って確認します。詳細な個別照合が必要な場合は、情報の扱いも含めて計測設計を見直してください。

参考情報

Google アナリティクス:キーイベントを測定する方法

Google アナリティクス:DebugViewでイベントをモニタリングする

確認日:2026年9月26日。比較表・記入例は本記事の実務例です。各社の体制や制作条件に合わせて調整してください。