GA4でフォームのイベントが増えていても、その数がそのまま問い合わせ件数とは限りません。
送信ボタンを押したこと、サイトが内容を受け付けたこと、店の受信箱へ通知が届いたことを分けると、数字の意味を確かめられます。
- 「送信操作」「受付成功」「通知メールの着信」を別の証拠で確認する。
- 完了ページ・同じページでの完了表示・外部フォームで方法を選ぶ。
- 正常送信だけでなく、入力エラー・直接訪問・再読込も試験する。
この記事は、店舗・小規模会社のサイト担当者が、制作会社へ計測を依頼し、結果を確認するためのガイドです。
公式資料の確認日は2026年10月12日です。
何を「問い合わせ1件」と数えるかを先に決める
送信操作、受付成功、通知メールは見る場所が違う
GA4の拡張計測には、フォームの操作を記録するform_startとform_submitがあります。
Googleは前者を入力の開始、後者をフォームの送信時のイベントとして説明しています。
ただし、実装したフォームでそのイベントが正常な受付と一致するかは、実際の試験で確認します。
入力エラーの際や、問い合わせ以外のフォームで記録されるものまで「商談の問い合わせ」と扱わないことが大切です。
| 見たいこと | 確認する証拠 | それだけで分からないこと |
|---|---|---|
| ボタン・リンクの操作 | クリック等のイベント | 正常受付やメール到達 |
| 対象フォームの受付成功 | 成功時の応答・完了表示とイベント | 担当者の受信箱への到達 |
| 通知メールの到達 | 通知先の受信箱・配送記録 | GA4の流入経路 |
| 実際の商談 | 受付管理・対応記録 | GA4に計測されなかった訪問 |
例えば、電話番号のリンクを押した数は、電話がつながった数ではありません。
メールリンクを押した数も、メールを送った数ではありません。
補助指標として使う場合は、名前を「電話リンククリック」など実際に見ている行動に合わせます。
受付成功の定義を、担当者と同じ言葉にする
「問い合わせ完了」は、対象フォームが内容を正常に受け付けたことと決めます。
「送信ボタンが押された」「確認画面へ進んだ」という手前の行動を同じ数にしないようにします。
資料請求と相談フォームがあるサイトなら、合算するか、別の種類として見るかも決めます。
フォームIDや種類を使う場合は固定の識別子にし、入力された氏名や内容を識別子にしないでください。
成功イベントを確認しても、通知メールの着信確認は残ります。
受付ができているのに通知だけ届かない場合、計測設定の変更だけでは解決しません。
フォームの方式に合わせて計測方法を選ぶ
送信成功後に専用の完了ページへ移動する場合
成功後だけ移動する完了ページがある場合は、そのURLの表示をもとにイベントを作る方法があります。
Google公式も、連絡先を送信して確認ページへ移動したケースを、新規イベント作成の例にしています。
使う前に、入力エラーでは完了ページへ移動しないか、URLを直接開けないか、再読込で重複して数えないかを確認します。
誰でも直接開ける完了ページの表示数を、完全な受付件数と呼ぶのは避けてください。
次は架空の設計例です。
ページの場所とイベント名は、実サイトに合わせて担当者が決めます。
| 設計項目 | 例 | 確認すること |
|---|---|---|
| 元のイベント | page_view | すべての閲覧を成功扱いにしない |
| 対象URL | example.com/contact/thanks/ | 他フォームや似たURLと混ざらない |
| 作るイベント | generate_lead | 既存設定と同じ成功を二重送信しない |
| 数え方 | 受付成功の定義に合わせる | 直接訪問・再読込の扱いを記録する |
URL条件で「thanksを含む」だけにすると、別のページも一致する場合があります。
ドメイン・パス・末尾や付加情報の扱いを確認し、実際に発生するURLでテストしてください。
同じページ内で完了メッセージが出る場合
送信してもURLが変わらないフォームでは、ページの閲覧だけで正常送信を区別できません。
フォームが正常受付を知らせる仕組みを、使用しているプラグインやフォームサービスの公式仕様で確認します。
制作会社へは「同じ画面でありがとうございましたと表示される」と伝えます。
送信ボタンのクリックへ成功イベントを付ける前に、正常受付の応答と連動できるかを確認してください。
フォームごとの仕様が違うため、別プラグイン向けのコードをそのまま貼る方法は選びません。
外部フォームへ移動する場合
自社サイトから外部フォームを開いたというクリックと、外部での受付完了は別です。
外部サービスにタグを設置できるか、どの計測に対応しているかを、その提供元の公式仕様で確認します。
クロスドメイン測定では、対象ページに同じウェブデータストリームのタグを使うなどの条件があります。
自社側へ設定を追加するだけで、計測できない外部フォームの成功まで自動で見えるわけではありません。
成功イベントを作り、必要なものをキーイベントにする
generate_leadは名前を付けるだけで自動収集されない
Googleの推奨イベントでは、問い合わせのフォーム・リクエスト送信にgenerate_leadが用意されています。
推奨イベントは自動では送信されないと案内されています。
そのため「イベント名を登録したから計測できた」と判断せず、実際の正常受付に対してイベントが届くかを確かめます。
受付成功を大切な行動として見る場合は、対象イベントをキーイベントにします。
既存タグと、同じ成功を数える設定を照合する
GA4管理画面、タグマネージャー、WordPressプラグイン、フォーム側の設定を別々の人が追加すると、同じ成功が重複することがあります。
現在どこからタグを設置しているかを先に確認します。
| 依頼前に控える項目 | 確認の目的 |
|---|---|
| 対象サイト・GA4プロパティ | 別サイトのデータを見ない |
| タグの設置場所 | テーマ、プラグイン、GTMの重複を調べる |
| 対象フォームのURLと方式 | 成功条件を選ぶ |
| 既存イベントとキーイベント | 同じ成功の二重計測を防ぐ |
| 受付先と通知先 | GA4と業務の受付を照合する |
すべてのpage_viewを問い合わせのキーイベントにしないでください。
閲覧という元イベントは残し、必要な条件を満たす成功だけを別に扱います。
既存イベントを上書きする場合は、他のレポートへの影響も確認します。
正常送信と、失敗・再読込を受入試験で確かめる
試験ごとに期待する結果を先に書く
設定担当者と店側が同じ操作を見られるよう、以下の表を渡します。
試験用の識別情報を用意し、実顧客の問い合わせをGA4へ送らないようにします。
試験の受付や通知が業務記録へ残る場合は、テストと区別できる運用にしてください。
| 試験 | 受付成功イベントの期待 | 一緒に確認すること |
|---|---|---|
| 必須項目を埋めて正常送信 | 定義した成功を記録 | 完了表示、受付記録、通知メール |
| 必須項目を空欄で送信 | 成功として記録しない | エラー表示、受付されていないこと |
| 別のフォームを送信 | 目的に応じて分ける | 対象フォームの絞り込み |
| 完了URLを直接開く | 直接訪問の扱いを確認 | 閲覧と受付成功の食い違い |
| 完了画面を再読込する | 二重計測の有無を確認 | 成功の定義、重複対策 |
| 戻る・再送信する | 実際の受付と対応させる | 再受付か表示だけか |
直接訪問や再読込を成功と区別できない方式なら、計測の限界を報告に残します。
成功の応答に連動する方法へ変えるか、どの程度の参考値として扱うかを判断します。
DebugViewでイベント名と中身を確認する
Googleは、デバッグモードを有効にしてDebugViewでイベントを確認する方法を案内しています。
Tag Assistantのプレビューなど、設定担当者が使う方法を共有してください。
画面にイベントが出たことだけでなく、名前、対象フォーム、発生回数、送信しているパラメータを見ます。
正常送信で二回出ていないか、入力エラーでも同じ成功が出ていないかを同じ表で確かめます。
標準レポートの表示は、DebugViewでの確認と同時とは限りません。
個人情報と、GA4の数字が受付数とずれる理由
入力内容をGA4へ送らない
Googleは、個人を特定できる情報をアナリティクスへ送ることを禁止しています。
氏名、メールアドレス、電話番号、問い合わせ本文をイベントへそのまま付けません。
URLのパラメータやページタイトルに入る情報も確認します。
例えば、完了ページのURLにメールアドレスを付けたり、イベントのラベルへ問い合わせ本文を入れたりしない設計にします。
受付内容を業務で見るための仕組みと、GA4で行動を集計する仕組みを分けてください。
フォームを区別する値は、入力内容ではなく、担当者が決めた固定の識別子を使います。
拡張計測で記録される送信先URLやボタンのテキストにも、顧客の入力値が入っていないか点検します。
自分で追加したパラメータだけを確認して終わりにしないことが大切です。
GA4を受付台帳の代わりにしない
同意の状態やブラウザー側の制限などによって、業務では受け付けた問い合わせでもGA4へ記録されない場合があります。
GoogleのDebugView案内も、プライバシー管理や同意モードの条件でイベントが表示されない場合を説明しています。
数が違うときは、同じ期間、同じフォーム、同じ成功の定義で比べます。
テスト・営業メール・重複・電話受付が混ざっていないかを確認し、GA4と受付記録の役割を決めます。
少数の問い合わせで大きな割合を示す前に、何件を何と比べたかも書いてください。
GA4は行動や流入の傾向を知るために使い、日々の返信は受付管理で行います。
GA4に出ないことを理由に、受け付けた問い合わせを放置しないようにします。
よくある質問
- form_submitをそのままキーイベントにしてよいですか？
-
対象フォームの正常受付と一致するかをテストして判断します。
問い合わせ以外のフォームや入力エラーが混ざるなら、成功条件と対象を絞ります。
イベント名だけで内容は決まりません。
- サンクスページがなければ計測できませんか？
-
正常受付を知らせる仕組みが利用できれば、同じ画面で完了するフォームも計測を検討できます。
プラグイン・サービスの公式仕様を確認し、クリックだけを成功と扱わないようにします。
- 外部の予約フォームまでGA4で測れますか？
-
外部サービスがタグ設置や成功計測に対応するかによります。
自社サイトからのクリックだけ見える場合もあるため、どこまで測れるかを先に確認します。
クロスドメイン設定だけで対応範囲は広がりません。
- GA4と届いたメールの数は一致しなければおかしいですか？
-
同意やブラウザーの制限、重複、対象期間、フォームの種類、通知配送などを確認します。
完全一致を前提にせず、正常受付と通知着信を別に点検します。
制作会社へは、フォーム方式と成功の定義を渡す
相談時は、サイトURL、フォームの名前、送信後にURLが変わるか、現在のイベント、正常受付として数えたい行動を伝えます。
アカウントのパスワードを本文や相談文へ貼る必要はありません。
必要な権限の渡し方は担当者と確認してください。
デジリスタの制作案内はアクセス解析の設定支援を案内していますが、各フォームの成功イベント実装や外部サービス連携が、すべて同じ制作料金に含まれるとは限りません。
対象の仕組みと試験範囲を確認して見積もります。
無料相談フォームへ、「問い合わせの受付成功を測りたい。
フォームは同じページで完了する」など、分かる範囲の状況をお知らせください。
