GA4のフォーム送信が二重に数えられるとき｜タグ・操作・受付の切り分け

GA4のフォーム送信イベントが実際の受付より多いときは、まず「何が二重か」を分けて調べます。一回の操作で同じイベントが二回送られる場合、異なるイベントを合算している場合、完了ページの再表示を新しい送信として数える場合では、直す場所が違います。数字を合わせるためにタグを一括停止する前に、操作・送信経路・計測先・実受信を照合しましょう。

この記事は、企業の計測担当者と、フォーム・GTMの実装を検収する制作会社向けです。フォームの入力設計全体は問い合わせフォームの改善ガイドへ分け、本稿は二重計測の原因を絞る確認票を作ります。例は説明用で、Acquaの実際のGA4設定や顧客の数値ではありません。

1. イベント、操作、受付のどれが重複しているか分ける

同じイベント名か、別の名前かを確認する

GA4のイベント数は、イベントが発生した回数です。一人や一件の相談をそのまま数えるとは限りません。送信ボタンのクリック、フォーム送信、完了表示、独自の受付成功イベントを合算すると、一つの相談を複数回として扱うことがあります。まず報告に使っているイベント名と、その意味を一覧にします。

受付が二件なら、計測だけの問題ではありません。フォーム処理と業務側の重複を調べます。受付が一件でも計測の重複があるなら、送信経路を確認します。逆にGA4が少なくても、同意・通信・取得制限等により全受付が記録されない場合があります。受付件数とGA4を常に一致させることを合格条件にしないでください。

2. タグの送信経路と計測先を棚卸しする

サイトのタグは、テーマへの直接記述、GTM、解析用の追加機能、フォームの独自スクリプトなどから送られることがあります。サーバー側の送信を併用する構成もあります。一つの管理画面だけ見て、経路が一つだと判断しないでください。

棚卸しには、どの場所のどの処理が、どの操作を条件に、どのイベント名を、どの計測先へ送るかを書きます。全ページで送るタグと、一部のページだけにある古いコードも分けます。タグ名が似ていても、別の計測先なら同じプロパティでの二重とは限りません。

確認する場所の候補は、テーマと共通テンプレート、GTMコンテナ、解析/フォームの追加機能、独自コード、外部フォーム、サーバー連携です。責任者と現在の公開版を記録し、IDや設定を知らないまま削除しないでください。管理権限がない経路は未確認として、担当者へ依頼します。

拡張計測のform_submitと独自イベントを両方使う場合も、それぞれの役割が必要なら存在自体を誤りとしません。Googleの拡張計測資料で意味を確認し、フォームの実装上どの場面で発生するかを試します。別名のイベントを足して相談件数と呼ぶ問題と、同名を二重送信する問題は分けます。

3. 試験環境、入力、受付担当、復元点を用意する

試験を本物の相談として数えない

可能なら検証環境と承認された試験用データを使います。本番を試す場合は、受付担当と日時・送信先・自動返信・外部連携・除外の扱いを決めます。実顧客へ通知や予約・決済が進む条件を、調査のついでに操作しません。検証環境でも本番のタグや通知が残る場合があるため、接続先を確認します。

現在の公開タグ、コンテナの版、フォーム設定、対象ページと編集値を保存します。変更する前に元へ戻せる範囲と担当を決めてください。GTMの下書きが他担当の作業を含む場合は、その版を一括公開してよいと判断しません。調査対象の変更だけを合意します。

Googleの個人情報を送信しないための説明も確認します。氏名、メール、問い合わせ本文を解析パラメータへ加えて個別照合する方法は避けます。デバッグ画面や通信の記録も必要な担当だけで扱い、公開記事へ実顧客のデータを貼り付けません。受付の詳細と解析の集計は、権限を管理した別の情報です。

4. 一回の操作を、成功・失敗・再表示で試す

まとめて操作すると、どの動作で二回発生したか分かりません。試験ごとに開始状態をそろえ、時刻、操作、タグ発火、イベント、受付の結果を残します。例えば最初は正常入力から一回だけ送信し、その後に失敗と再表示を別の試験として確認します。

すべての試験で「イベントゼロ」を目指すのではありません。入力エラーを記録することには別の目的があります。成功だけを数えるイベント、操作を数えるイベントを設計どおりに区別します。試験中の機器・ブラウザ・同意状態も記録し、一つの環境での結果を全端末の確認としないようにします。

5. GTMのプレビューでトリガーとタグを照合する

GTMの公式プレビュー説明は、公開前の構成でタグの配信と順序を確認する方法を案内しています。対象コンテナと版を選び、現在のページにどのコンテナが入っているかを確認してから接続します。未公開の下書きを試した結果を、そのまま本番の状態と報告しないでください。

試験の操作に対応するイベントを選び、発火したタグ、発火しなかったタグ、条件、計測先、イベント名を確認します。一つの送信でクリックとフォーム送信の両トリガーが同じタグを動かすなど、どの条件が重なるかを見るための記録です。タグが発火したことと、GA4が受け取ったことは別の確認になります。

プレビューだけで全経路の確認を終えない

GTMの画面で一つのタグだけが見えても、テーマへ直接書かれた処理や追加機能、サーバー送信が別に存在する場合があります。棚卸し表と合わせ、必要なら実装担当がブラウザの通信とコードを確認します。発火回数だけでなく宛先と送信内容を見ると、別プロパティへの送信を誤って止めることを避けられます。

6. DebugViewと受付記録で時刻・名前・状態を確認する

GoogleのDebugView資料は、デバッグ用に収集されるイベントを確認する方法を説明しています。対象プロパティとデバッグ端末を選び、合意した方法でデバッグを有効にして、試験した時刻のイベント名と必要なパラメータを見ます。検証用の信号をいつ解除するかも決めます。

同じ時刻帯に同名が二回あれば、GTMの発火と別経路の候補を対応付けます。別名が一回ずつなら、報告の合算対象を見ます。何も見えない場合は、プロパティ、端末、デバッグの有効状態、同意や通信の条件を調べます。見えないことだけで送信処理が失敗したとは断定しません。

受付側では、承認した試験が保存され、担当に届いたかを確認します。解析のイベントを受付成功の代わりに使わず、試験の時刻と状態を必要な範囲で照合します。DebugViewの合格だけで、通常利用者の全データと広告の帰属まで確認済みにしないでください。

7. 原因が分かってから、限定した変更と再試験を行う

数字を半分にするだけで修正しない

同名を二経路から送る場合は、どちらを正本にするかと、残す経路の対象・条件・同意を合意します。別名を合算しているだけなら、集計の定義を見直す仕事かもしれません。完了ページの再表示で増える場合は、何を成功と判断するか、受付の仕組みに合わせた実装を検討します。

どのケースでも、対象タグと変更前後、影響するページ、他の計測、戻す版を示します。重複して見えるコードを片方消すだけでは、特定ページの計測や同意の処理がなくなる場合があります。未知の経路を削除せず、所有者と用途を確認してから変更します。

変更後は先の試験表を同じ条件で通し、成功、エラー、二度押し、再読込み、直接アクセスを確認します。公開後の版でも検証し、プレビューだけで完了にしません。過去の重複データが自動で訂正されると考えず、変更日と比較できない期間を記録してください。解析データの削除やフィルタ変更は影響する期間と対象が異なるため、必要性と復元の可否を別途検討します。

8. 検収結果と未確認事項を渡し、実相談は別に評価する

依頼メモには、対象URL、イベント名と意味、計測先、公開版、再現操作、時刻、発火・GA4・受付の結果、確認していない経路、変更範囲、戻し方を書きます。設定画面を何枚も渡すだけより、どの操作で何が起きたかを一つの試験表へまとめると調査しやすくなります。

解決状態は、成功・失敗・再表示が定義どおりに数えられ、経路と欠測を説明でき、受付が正常に届き、変更日と次の担当が分かることです。計測値が減っても相談が減ったとは限りません。実相談、受注、顧客の解決と工数・利益を別に観察します。

企業が問い合わせとサイトの問題を切り分けたい場合は企業向けWeb支援で対象を整理できます。制作会社が仕様と実装の調査・検収を依頼する場合は制作会社向け支援から支給物と範囲を合わせます。相談窓口へURLと再現操作、現在の担当を伝えてください。対応可否、解析設定の変更、費用は環境を確認して合意します。

確認日：2026年10月5日。公式仕様と実際のタグ・フォーム構成を照合し、変更は合意した対象と版で実施してください。