GA4にform_submitが記録されていても、そのまま問い合わせ完了として数えるのはまだ早いです。
イベント名がそれらしくても、実際に何をきっかけに発生したのかは別の話です。サイト内検索や採用応募の送信が同じ名前で混ざっていることもあります。入力エラー、正常送信、完了表示、実際の受信。この4つを1件ずつ照合してから、キーイベントにします。名前ではなく、操作と結果をつないで確かめます。
この記事でわかること
この記事では、form_submitを問い合わせ完了として扱えるか、設定を変える前に判断する手順を整理します。
form_submitと問い合わせ完了の違い- 入力エラーと正常送信を使ったテスト方法
- 完了表示、通知メール、GA4を照合する順番
- 重複発火と計測漏れの見分け方
- 自分で確認できる範囲と、設定変更を止める条件
form_submitは「フォーム送信の操作」であり、問い合わせの成立とは限らない
GA4の拡張計測では、フォームへの最初の操作をform_start、送信をform_submitとして記録できます。ただ、名前がform_submitだからといって、フォーム側の処理が成功したのか、完了画面が出たのか、通知メールが届いたのか。そこまでは分かりません。
問い合わせが届くまでを分けると、少なくとも次の4段階があります。
- 送信操作をする
- フォームが入力内容を受け付ける
- 画面に送信完了が表示される
- 管理側で送信記録や通知メールを確認できる
form_submitがどの段階で発生するかは、フォームの実装と計測方法を見ないと判断できません。入力エラーでも発生するのか、正常に受け付けた時だけなのか。ここを実際の操作で確認します。
あと、問い合わせ以外のフォームがあるサイトは要注意です。サイト内検索、資料請求、採用応募、メールマガジン登録。これが全部同じイベント名に入っていると、form_submitの合計は問い合わせ件数になりません。数字を見て「けっこう来てるな」と思っていたら、中身はサイト内検索だった。そういうこともあります。
先に「問い合わせ完了」と数える条件を決める
テスト前に決めたいのは、何が起きたら有効な1件とするかです。私なら「フォームが正常に受け付け、利用者に完了が伝わり、管理側でも送信を確認できる」を基準にします。
確認項目を表にすると、途中で数字の意味がぶれません。
| 確認場所 | 成功と考える状態 | 失敗・要確認の状態 |
|---|---|---|
| フォーム画面 | 完了メッセージまたは完了ページが一度表示される | 入力エラー、通信エラー、読み込み中のまま |
| フォーム側 | 送信記録が一件残る | 記録がない、同じ内容が複数残る |
| 管理側 | 通知メールなどで内容を確認できる | 未着、重複、別フォームの内容 |
| GA4 | 対象イベントが一度だけ増える | 増えない、複数増える、別フォームも混ざる |
フォーム側に送信記録を残す機能がない場合、そのためだけに新しいプラグインを入れる必要はありません。画面の完了表示、通知メール、GA4を同じ時刻で照合します。
営業メールやテスト送信を実際の問い合わせへ含めるかは、計測設定とは別の集計ルールです。GA4には正常送信として残っても、事業上の有効な問い合わせからは除外することがあります。ここまで一つの数字へ押し込むと、あとで説明しにくくなります。
エラー送信・正常送信・再操作の3パターンを試す
form_submitの発火条件は、3つの操作を分けると見えてきます。設定を変更せず現在の状態を記録しておくと、どの操作でイベントが増えたかを比べられます。
1. 入力エラーになる内容で一度送信する
必須項目を一つ空けるなど、フォームに用意されている入力確認を使います。実在する個人情報は入れず、エラー表示を一度出した時刻を控えます。
この操作でform_submitが増えた場合、少なくともそのイベントを「正常に届いた問い合わせ」と同じ意味では扱えません。エラーでも数える実装なのか、別のタグが送信ボタンのクリックを数えているのかを切り分けます。
2. 正常なテスト内容を一度だけ送信する
次は、テストと分かる内容を一件だけ送ります。送信時刻、ページURL、端末、ブラウザを記録し、次の順番で確認します。
- 完了メッセージまたは完了ページが表示されたか
- フォーム側の送信記録があれば一件増えたか
- 通知メールが一通届いたか
- GA4で対象イベントが一度発生したか
GA4だけを見るのではなく、一件の送信を入口から受信まで追いかけます。これで計測漏れがある区間を絞れます。
3. 完了後の再読み込みや戻る操作を確認する
完了ページを計測している場合は、再読み込みでイベントが増えないかも見ます。ただし、何度も操作すると結果が混ざるので、一回だけで十分です。
正常送信で一件、再読み込みでもう一件。これだと、問い合わせ一件を二回数えていることになります。完了ページの表示を条件にする時は、同じ完了状態を何度も出せてしまわないか。ここまで見ておくと安心です。
CTAのクリックまでは確認できるものの、フォームのどこで止まるか分からない場合は、フォーム到達から実受信までを5段階で追う方法で、クリック後の流れを先に切り分けられます。
GTMを使っているなら、公開前に発火理由を見る
Googleタグマネージャー（GTM）を使っている場合は、プレビューモードでどのタグが、何をきっかけに発火したかを確認できます。公開中の設定をいきなり変えず、テスト操作とタグの動きを対応させるための機能です。
見るのは、次の3点に絞ります。
- 入力エラー時に問い合わせ完了用のタグが発火していないか
- 正常送信時に一度だけ発火しているか
- GoogleタグとGTMなど、同じ役割の計測が重複していないか
GTMを使っていないサイトでは、無理に導入する必要はありません。GA4のリアルタイム表示とフォームの完了表示、通知メールを同じ時刻で比べます。デバッグ設定を使える環境なら、DebugViewも確認材料になります。
ここ、勘違いしやすいところです。設定画面でイベント名をgenerate_leadへ変えても、発火の条件まで直るわけではありません。generate_leadは見込み客の獲得を測るための推奨イベントですが、名前より先に「正常送信時に一度だけ発生する」状態を作るのが順番です。
form_submitをキーイベントにする判断基準
form_submitをキーイベントにしてよいのは、対象フォームの正常送信と一対一で対応していると確認できた場合です。キーイベントに指定すると、そのイベントは事業にとって大事な行動としてレポートへ出ます。指定する前のテストが数字の土台になります。
判断は次のように分けられます。
| テスト結果 | 判断 |
|---|---|
| 入力エラーでは増えず、正常送信で一度だけ増える | 問い合わせ完了の候補にできる |
| 入力エラーでも増える | そのまま問い合わせ完了にはしない |
| 正常送信しても増えない | 計測漏れを直すまで使わない |
| 一度の送信で複数回増える | 重複するタグや条件を整理する |
| 複数フォームが同じイベントへ混ざる | フォームを識別できる形に分ける |
| GA4は増えるが通知メールが届かない | 計測とメール配送を別々に確認する |
すでにform_submitをキーイベントにしている場合も、慌てて削除する必要はありません。変更前の期間、設定、テスト結果を残し、今後どの数字を正式な問い合わせとして見るかを決めます。過去の数字と新しい数字の定義が変わるなら、変更日も記録しておくと比較しやすくなります。
GA4と実際の受信件数がずれている場合は、GA4の問い合わせ数と受信メール件数が合わない原因で、イベント・フォーム送信・メール受信の3段階を詳しく整理しています。
自分で確認できる範囲と、設定変更を止める条件
入力エラー、正常送信、完了後の再操作を一回ずつ試し、時刻と結果を表へ残すところまでは自分でも進めやすい範囲です。GA4のイベント名、回数、対象ページを閲覧できるなら、それも一緒に記録します。
次の状態では、イベントを追加・削除する前に変更を止めます。
- 対象フォームがどの仕組みで送信されているか分からない
- Googleタグ、GTM、プラグインの計測が重なっている
- 入力エラーと正常送信で同じイベントが発生する
- 完了表示は出るが、送信記録や通知メールと結果が合わない
- 複数フォームを同じイベント名で数えている
- 変更前の設定へ戻す方法が分からない
問い合わせ計測は、イベントを増やす前に「何が起きたら1件とするか」を説明できる状態にします。対象フォームの動きと設定を照合できない場合は、確認できた事実だけを残して相談へ切り替えます。
おわりに
form_submitを問い合わせ完了として使う前に、入力エラー、正常送信、完了後の再操作を一回ずつ試します。完了表示、送信記録、通知メール、GA4が一件ずつ対応して初めて、キーイベントの候補にできます。
テストは自分でも進められます。GTMや複数の計測設定が重なり、どの条件でイベントが発生しているか追えない場合は、現在の設定と変更履歴から「正式な1件」の定義を整理できます。
