GA4で問い合わせを計測する方法｜キーイベント設定とテスト手順

GA4で問い合わせ数を計測するときは、いきなり「キーイベント」の星を付けるのではなく、先に何が起きたら問い合わせ成立とみなすかを決めます。送信ボタンのクリック、フォーム送信の試行、送信完了ページの表示、サーバーが正常に受け付けた瞬間は、似ているようで同じではありません。

基本の流れは、問い合わせ完了条件を決める、既存イベントとタグを確認する、フォームの仕組みに合うイベントを用意する、そのイベントだけをキーイベントに指定する、実際に送信して重複と欠落を検証する、の順です。問い合わせフォームなら、実際の受付成功を表すイベントにGoogle推奨イベント名のgenerate_leadを使い、入力開始や送信操作を表すform_start、form_submitは補助指標として分ける設計が考えやすいでしょう。

ただし、サンクスページへ移動するフォーム、画面を切り替えずに送信するAjaxフォーム、外部サービスの埋め込みフォームでは、適切な設定方法が異なります。この記事では、GA4とGoogleタグマネージャー（GTM）の現在の考え方に沿って、問い合わせをキーイベントとして設定し、DebugView・リアルタイム・実際の受信結果を照合するところまで順に説明します。

※GA4やGTMの画面名は2026年8月確認時点です。権限、プロパティの状態、段階的な画面更新によって表示が異なる場合があります。設定前に対象プロパティとウェブデータストリームを必ず確認してください。

最初に決めるのは、GA4の画面ではなく「フォーム送信が成立した条件」

問い合わせ計測の精度は、イベント名よりも成果地点の決め方で大きく変わります。送信ボタンを押しただけでは、必須項目の不足、通信エラー、迷惑送信対策による拒否などで受付が完了していない可能性があります。反対に、フォームは正常に受け付けられていても、計測タグの発火が間に合わずGA4だけが0になることもあります。

まず、サイト側で確認できる「成功の合図」を一つ選びます。候補は次のとおりです。

成果地点	向いているフォーム	強み	主な注意点
送信完了専用URLの表示	正常送信後に固有のサンクスページへ移動する	page_viewを条件にイベントを作りやすい	直接アクセス、再読み込み、戻る操作で重複しないか確認が必要
サーバー受付成功後のデータレイヤー通知	Ajax、SPA、画面遷移なしのフォーム	実際の受付成功に近い時点で発火できる	開発側で成功コールバックとdataLayer.push()の実装が必要
GTMのフォーム送信トリガー	ブラウザ標準の送信動作を使うフォーム	GTM内で設定しやすい	Ajaxや独自JavaScriptで送信動作が置き換わると反応しないことがある
電話・メールリンクのクリック	電話相談やメール起動も成果候補にするサイト	フォーム以外の接点を把握できる	クリックは通話成立やメール送信そのものではなく、近似行動である

固有のサンクスページがあり、送信成功時だけ到達できるなら、ページ表示を基にした計測は比較的分かりやすい方法です。一方、URLが変わらないフォームでは、ボタンクリックよりも、サーバーから成功応答を受け取った後の通知を使うほうが実態に近づきます。外部フォームや予約サービスを埋め込んでいる場合は、提供元が用意する完了コールバック、メッセージイベント、連携機能の有無を先に確認します。

GA4の拡張計測機能では、フォームへの最初の操作をform_start、送信操作をform_submitとして収集できます。ただし、サイトの実装によってはform_submitと実際の受付成功が完全には一致しません。問い合わせ件数として見たいのが「受信できた件数」なら、form_submitをそのままキーイベントにする前に、実送信で一致を確かめます。

問い合わせ成立を表すイベント名には、GA4の推奨イベントであるgenerate_leadが使えます。複数の問い合わせフォームがある場合は、イベント名をフォームごとに増やすより、form_id、form_name、lead_typeなどのパラメータで種類を区別する方法があります。氏名、メールアドレス、電話番号、相談本文など、個人を特定できる情報はGA4へ送信しません。

設定前に既存イベントとタグの経路を棚卸しする

新しいイベントを追加する前に、すでに同じ行動が計測されていないか確認します。二重計測の多くは、一つのフォームに対して複数の仕組みが同時に動くことで起きます。たとえば、GA4の拡張計測でform_submitが収集されているところへ、GTMでも同名イベントを送る、サンクスページ到達をGTMとGA4のイベント作成機能の両方で設定する、同じGTMコンテナがテーマとプラグインから二重に設置される、といった状態です。

最初に次の項目を一枚のメモへまとめます。

• 対象のGA4プロパティ名、測定ID、ウェブデータストリームURL
• Googleタグの設置方法。GTM、直接設置、WordPressプラグイン、Site Kitなど
• GTMコンテナIDと、公開中のコンテナバージョン
• 拡張計測の「フォーム操作」が有効かどうか
• DebugViewまたはリアルタイムですでに届いているイベント名
• フォームの送信方式。専用URLへ遷移するか、同じ画面で完了するか、外部サービスか
• 問い合わせフォームが複数ある場合の識別方法

イベント名は大文字と小文字を区別します。generate_leadとGenerate_Leadは別のイベントです。新しく付ける名前は文字から始め、文字・数字・アンダースコアを使い、空白を入れません。GTM、GA4のキーイベント設定、テスト記録で同じ名称をコピーして使うと、入力違いを防ぎやすくなります。

設計メモは、少なくとも次の形にしておくと設定の重なりを見つけやすくなります。

イベント名	発火条件	主なパラメータ	キーイベント	用途
form_start	フォームへの最初の操作	form_id、form_name	しない	入力開始数と離脱を見る補助指標
form_submit	フォーム送信を検知	form_id、form_destination	原則は実送信後に判断	送信操作の検知状態を確認
generate_lead	問い合わせ受付成功	form_id、lead_type	する	問い合わせ成立件数を数える
click_to_call	電話リンクのクリック	page_locationなど	必要性を個別判断	電話をかけようとした行動を把握

この表で「同じ成功操作からform_submitとgenerate_leadが届く」こと自体は問題ではありません。役割が異なるからです。問題になるのは、両方を問い合わせ件数として合算したり、一回の成功で同じgenerate_leadが二回届いたりする状態です。最終的に問い合わせ数として使うイベントを一つ決め、ほかは途中行動や診断用として残します。

フォームの仕組みに合わせて問い合わせイベントを作る

設定方法は一つに統一するのではなく、成功の合図がどこにあるかで選びます。ここでは代表的な三つの方法を説明します。

固有のサンクスページがある場合は、GA4でpage_viewから作る

正常送信後にだけ表示される専用URLがある場合、GA4の管理画面でpage_viewを基に新しいイベントを作れます。大まかな手順は次のとおりです。

1. 対象のGA4プロパティを開き、管理画面の「データの表示」から「イベント」へ進みます。
2. 「イベントを作成」を選び、新しいイベント名をgenerate_leadなどにします。
3. 作成方法で既存イベントを利用し、元のイベントをpage_viewにします。
4. ページURLの条件へ、送信完了ページだけを識別できる値を設定します。
5. 作成後、実際にフォームを送信し、DebugViewで一回だけ届くか確認します。

条件は、別ページまで含む広すぎる指定にしません。たとえば「URLにthanksを含む」だけでは、複数フォームや案内ページまで一致する可能性があります。サイト内で専用URLが一つだけか、末尾のスラッシュやクエリ文字列で別扱いにならないかを確認します。

また、page_viewそのものをキーイベントにすると、サイト内の全ページ表示が成果として数えられてしまいます。既存のpage_viewを変更して上書きするのではなく、条件に合うときだけ発生する別イベントを作ります。

サンクスページ方式は簡単ですが、URLを知っている人の直接アクセス、再読み込み、ブラウザの戻る・進むによる再表示で増える場合があります。可能であれば、送信後だけ有効な状態をサーバー側で持たせる、完了ページを検索結果へ出さない、実際の受信件数と定期照合する、といった対策を組み合わせます。キーイベントの「セッションごとに一回」という集計方法だけで重複を隠すのではなく、まず発火条件を直します。

ブラウザ標準のフォームなら、GTMのフォーム送信トリガーを検証する

通常のform要素がブラウザ標準の送信動作を行う場合は、GTMの「フォームの送信」トリガーを利用できます。トリガーでは、タグの送信を待つ設定、入力検証を通った場合だけ発火させる設定、対象フォームだけに絞る条件を確認します。

GTMでは、GA4イベントタグを作成し、イベント名をgenerate_leadにします。トリガーは「すべてのフォーム」ではなく、対象ページ、Form ID、Form Classesなどで目的のフォームへ絞ります。公開前にプレビューモードを開き、入力エラー時に発火せず、正常送信時だけ一回発火することを確認します。

ただし、見た目が一般的なフォームでも、JavaScriptが標準の送信処理を置き換えている場合があります。GTMのフォーム送信トリガーが反応しない、送信前に発火する、同じ操作で複数回発火する場合は、無理に条件を増やすより、次のカスタムイベント方式へ切り替えたほうが安定します。

Ajax・SPA・外部フォームは、受付成功後のカスタムイベントを使う

画面遷移なしで送信するAjaxフォームやSPAでは、サーバーが「受付成功」を返した後にデータレイヤーへ通知し、その通知をGTMで受ける方法が分かりやすい設計です。実装例は次のようになります。

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'contact_success',
  form_id: 'contact',
  lead_type: 'inquiry'
});

このcontact_successは、ボタンクリック時ではなく、送信先サーバーから正常受付の応答を受け取った後に実行します。GTMでは「カスタムイベント」トリガーでcontact_successを受け、GA4イベントタグからgenerate_leadを送ります。form_idやlead_typeはパラメータとして引き継ぎます。

外部フォームをiframeで埋め込んでいる場合、親ページのGTMはiframe内部の操作をそのまま取得できないことがあります。提供元の完了イベント、コールバック、postMessage、連携用データレイヤーなど、正式に用意された方法を確認します。送信ボタンの座標や表示変化だけを無理に検知する実装は、フォーム更新で壊れやすいため避けます。

電話リンクやメールリンクは、フォーム問い合わせと別イベントにします。click_to_callは「電話をかけようとした」行動であり、通話成立ではありません。フォーム送信と電話クリックを一つのgenerate_leadへまとめるかは、社内で同じ成果として扱うかを決めてから判断します。比較したい場合は別イベントのままにしたほうが、後から実態を読みやすくなります。

問い合わせイベントをキーイベントに設定する

イベントがGA4へ届く状態を作った後で、そのイベントをキーイベントに指定します。管理画面の「データの表示」から「イベント」を開き、既存イベントなら対象行の星を選びます。新しいイベントを作る画面で「キーイベントとしてマーク」を有効にし、作成時点から指定する方法もあります。ボタンが表示されない場合は、プロパティの権限を確認します。

ここで大切なのは、キーイベントを「重要そうな行動すべて」に付けないことです。たとえば、次の三つを同時にキーイベントにすると、一件の問い合わせが複数の成果として見える可能性があります。

• 送信ボタンのクリック
• form_submit
• 受付成功後のgenerate_lead

問い合わせ件数として採用するのは、事前に決めた完了条件に最も近い一つです。入力開始やボタンクリックは、フォーム改善の途中指標として通常イベントのまま確認できます。電話クリックも、フォーム問い合わせと意味が異なるなら別のキーイベントとして表示し、合計値だけで判断しません。

キーイベントの指定は過去データへさかのぼって適用されません。設定後に発生したイベントからキーイベントとして扱われます。また、リアルタイムは数分で確認できる一方、標準レポートへの反映には最大24時間程度かかる場合があります。設定直後の成否は、標準レポートを待つのではなくDebugViewとリアルタイムで確認します。

カウント方法には、発生ごとに数える方法と、セッション内で一回として数える方法があります。問い合わせフォームで同じ人が別件を連続して送る可能性があるなら、発生ごとの計測が実件数に近い場合があります。一方で、同じ操作が技術的に二回発火しているなら、カウント方法を変える前にトリガーを修正します。集計設定は、重複の修理手段ではありません。

公開前後のテストは「正常系・異常系・実受付」を同じ操作で照合する

計測テストは、GA4にイベント名が一度見えたら終わりではありません。ブラウザ上の結果、GTMの発火、GA4の受信、実際の問い合わせ受付を同じ送信操作で照合します。テスト前に、実施日時、使用端末、対象フォーム、入力したテスト識別語、期待するイベント名を記録しておくと、メールや管理画面の受付結果と結び付けやすくなります。

確認は次の順に進めます。

1. 実際の受付結果：完了画面が表示され、通知メール、管理画面、CRM、データベースなど、運用側でも一件受け付けられているか。
2. Tag AssistantまたはGTMプレビュー：正常送信時だけ対象タグが一回発火し、入力エラーや送信失敗では発火していないか。
3. DebugView：対象イベントが一回だけ表示され、form_id、lead_typeなどのパラメータが想定どおりか。
4. リアルタイム：イベント名とキーイベントが数分以内に確認できるか。
5. 標準レポート：翌日以降、実際の受付記録と大きくずれていないか。

DebugViewを使うときは、Tag AssistantまたはGTMのプレビューモードで自分の端末をデバッグ状態にします。DebugViewのイベントを選ぶと、同じ操作で送られたパラメータを確認できます。リアルタイムは直近の受信状況を広く見る画面、DebugViewは特定のテスト端末の詳細を見る画面として使い分けます。

正常送信だけでなく、発火してはいけない操作もテストします。

テスト操作	サイト側の期待結果	GA4側の期待結果	問題が出たときに疑う場所
必須項目を満たして正常送信	実受付が一件、完了表示	generate_leadが一回	イベント名、タグ、トリガー、測定先
必須項目を空欄にして送信	エラー表示、受付なし	generate_leadは0回	ボタンクリック計測、検証前の発火
通信失敗やサーバーエラー	受付なし、失敗表示	generate_leadは0回	成功応答前の発火
送信ボタンを連打	実受付の仕様どおり	実受付件数を超えない	二重クリック防止、複数トリガー
完了ページを再読み込み・戻る	新しい受付なし	原則として増えない設計が望ましい	page_view条件、直接到達、履歴操作
別の問い合わせフォームを送信	対象フォームだけ受付	パラメータで種類を識別	Form ID条件、広すぎるトリガー

テスト結果がDebugViewに出ない場合でも、すぐにイベント設定だけを作り直しません。対象プロパティや測定IDの違い、GTMプレビューの接続、同意状態、広告ブロック機能、クロスドメインやiframe、タグ公開前のワークスペースなど、受信前の条件を順番に確認します。Googleの同意管理を導入していて分析用Cookieへ同意していない場合、DebugViewに表示されないこともあります。

反対に、DebugViewでは届くのにキーイベントとして見えない場合は、星の指定、イベント名の大文字・小文字、設定時刻を確認します。標準レポートだけが0なら、反映待ちの可能性もあるため、リアルタイムと実受付の結果を先に残します。

二重計測・欠落・スパムを症状から切り分ける

計測トラブルは、「多すぎる」「少なすぎる」「GA4にはあるが実際にはない」の三つに分けると原因を追いやすくなります。

一回の送信で二回以上増える場合は、同じフォームに複数のタグが動いていないか確認します。拡張計測とGTM、GTMと直接設置、GA4で作ったイベントとGTMのイベント、テーマとプラグインによるGTMコンテナの二重設置が代表例です。Tag Assistantのイベント時系列で、どのトリガーが何回動いたかを見ます。サンクスページ方式なら、再読み込みや履歴操作でも同じイベントが作られていないか確認します。

実際には問い合わせが届いたのにGA4が0の場合は、イベントの発火点が早すぎるのではなく、遅すぎる、または到達していない可能性があります。ページ遷移前にタグ送信が完了しない、Ajaxの成功コールバックが変更された、外部フォームの完了通知を親ページで受け取れていない、同意状態で分析タグが送信されない、といった原因を切り分けます。まず実受付の時刻を基準に、Tag Assistant、DebugView、リアルタイムの順でどこまで届いたかを追います。

GA4では一件だが実受付がない場合は、ボタンクリックや送信試行を成功として数えていないか確認します。入力エラーでも発火するトリガー、直接開けるサンクスページ、迷惑送信対策に拒否された後の表示、テスト用の仮完了画面などが考えられます。フォームの受付ログまたは通知メールと突き合わせ、「計測上の成功」と「業務上の受付」が同じ条件になっているかを見直します。

スパムやボットが完了条件を通れば、GA4上も問い合わせとして数えられることがあります。GA4だけでは、その送信が有効な商談かどうかまでは判定できません。問い合わせ件数、迷惑送信として除外した件数、実際に対応対象となった件数を運用側で分け、必要に応じてフォームの迷惑送信対策を見直します。相談本文やメールアドレスをイベントパラメータへ送って品質判定する方法は、個人情報の送信につながるため使いません。

計測差が出たときに、GA4の数字だけを正解として実受付を合わせるのも、実受付だけを正解としてGA4を無視するのも適切ではありません。両者の定義と時刻をそろえ、どの段階で差が生まれたかを確認することが重要です。

変更日とテスト結果を残し、フォーム改修のたびに再確認する

問い合わせ計測は、一度設定すれば永続的に同じ状態が続くとは限りません。フォームプラグインの更新、送信完了ページのURL変更、Ajax化、GTMコンテナの更新、同意管理の導入、複数フォームへの分岐などで発火条件が変わります。誰が見ても同じ条件で再テストできる記録を残します。

記録項目	記入内容
変更日時・担当	いつ、誰が変更したか
対象	GA4プロパティ、測定ID、GTMコンテナ、対象フォームURL
成果条件	何を問い合わせ成立と定義したか
イベント	イベント名、発火条件、パラメータ、キーイベント指定
実装	GA4で作成、GTMフォーム送信、カスタムイベントなど
公開情報	GTMコンテナバージョン、サイト側の更新内容
テスト	正常送信、入力エラー、再読み込み、別フォームの結果
照合	実受付、Tag Assistant、DebugView、リアルタイム、翌日レポート
未確認事項	外部フォーム、同意状態、特定端末など残っている条件

イベント名だけでなく、「どのフォームのどの成功状態で発火するか」を文章で残すことが重要です。generate_leadという名前が同じでも、サンクスページ表示、ボタンクリック、サーバー受付成功では意味が違います。フォームやサイトを改修するときは、この記録を変更前に確認し、公開後に同じテストを繰り返します。

月次で問い合わせ数を見る場合も、GA4のキーイベント数だけを単独で報告せず、実際の受付件数との差、迷惑送信の有無、設定変更日を並べます。差が小さい期間でも、フォーム改修やタグ更新の直後は重点的に確認します。数字の増減を施策の成果と判断する前に、計測条件が同じかを確かめることで、誤った改善判断を減らせます。

問い合わせ計測は、設定よりも「実態と一致するか」で完成させる

GA4の問い合わせ計測は、完了条件を決め、既存イベントを棚卸しし、フォームの仕組みに合うイベントを作り、その一つをキーイベントに指定する流れで進めます。最後は、正常送信だけでなく入力エラー、再読み込み、連打、別フォームも試し、DebugView・リアルタイム・実際の受付結果を照合します。

大切なのは、星が付いたことやレポートに数字が出たことを完成条件にしないことです。「問い合わせが成立したときに一回増え、成立しなかったときは増えない」と確認できて、初めて運用判断に使える数字になります。設定後にアクセス数や問い合わせ数の見方を整理する場合は、ホームページのアクセス数が少なく見えた時に確認する4つの順番も、期間・指標・計測状態を切り分ける参考になります。