GA4の計測漏れや二重計測は、タグを入れた後ではなく、イベントを決める段階から始まります。「問い合わせ完了を測る」とだけ決めても、完了ページの再読込、同じタグの二重設置、外部フォームへの遷移、同意状態の違いによって、実際の問い合わせ件数とGA4の数値がずれることがあります。
この記事では、問い合わせ・資料請求・予約などの重要行動を、GA4のイベントとキーイベントへ落とし込む方法を12項目の定義表で整理します。実装後はDebugView、リアルタイム、通信、標準レポート、業務記録を順番に確認し、「数字が出た」ではなく「漏れと重複の理由を説明できる」状態を完成とします。
GA4計測は「成果→行動→イベント→照合」の順で設計する
先にタグや管理画面を触ると、取得できるデータに事業判断を合わせてしまいます。最初に「何を成果とするか」を営業・マーケティング・サイト運用で合意し、その成果を示す利用者の行動を決めます。次にイベント名と発火条件を定義し、最後にフォーム受信や問い合わせ台帳などの業務記録と照合します。
| 順序 | 決めること | 残す証拠 | 避けたい状態 |
|---|---|---|---|
| 1. 成果 | 相談、資料請求、予約、購入など | 社内で合意した成果定義 | ページ閲覧を一律に成果とする |
| 2. 行動 | 送信成功、電話発信、予約確定など | 利用者と業務側の完了条件 | クリックだけで完了とみなす |
| 3. イベント | 名前、条件、パラメータ、除外 | イベント定義表と実装仕様 | 担当者ごとに名前が違う |
| 4. 検証 | 1操作で何回、どの値を送るか | DebugView、通信、テスト記録 | リアルタイムに出ただけで公開 |
| 5. 照合 | GA4と受信・CRMの差 | 件数差と原因の記録 | 異なる定義の数字を一致させる |
サイト全体の問い合わせ不足を診断したい場合は、ホームページから問い合わせが来ない原因の5段階診断で、検索表示、流入、判断材料、導線、営業連携まで確認してください。この記事は、その中の「GA4で重要行動を正しく測る」範囲に絞ります。
イベント・キーイベント・広告コンバージョンを分ける
GA4では、ページ表示、クリック、フォーム送信などの操作をイベントとして記録します。そのうち事業上重要なイベントへ「キーイベント」のマークを付けます。Google広告の入札や評価に使う場合は、GA4のキーイベントを基にGoogle広告のコンバージョンを作成できます。三つは同じ意味ではありません。
- イベント: 利用者の行動やシステム上の出来事を記録する単位。
- キーイベント: GA4内で、事業に特に重要だと指定したイベント。
- Google広告コンバージョン: 広告の評価・入札に使う成果。GA4キーイベントから作成する方法もある。
Googleは、用途に合う推奨イベントがある場合、そのイベント名とパラメータを使うよう案内しています。たとえば見込み顧客の獲得はgenerate_leadが候補です。ただし名称を採用するだけでは、送信成功の判定、対象フォーム、重複防止まで決まりません。
フォームの入力項目やエラー、離脱改善はEFOの費用対効果と改善手順、改善案の比較方法はA/Bテストの進め方で扱います。計測記事にUI改善や実験判定まで詰め込まず、役割を分けると更新しやすくなります。
実装前に12項目のイベント定義表を作る
イベント一覧には名前だけでなく、発火・除外・検証・責任者まで必要です。少なくとも次の12項目を1行にまとめます。未決定の項目を空欄のまま実装へ渡さず、「対象外」「計測しない」と判断した場合も理由を記録します。

| 項目 | 決める内容 | 問い合わせ送信の例 |
|---|---|---|
| 1. 事業成果 | 何を達成した状態か | 対象顧客から相談を受信 |
| 2. 対象行動 | 観測可能な完了操作 | フォームの送信成功 |
| 3. イベント名 | 推奨名または命名規則 | generate_lead |
| 4. 発火条件 | いつ1回送るか | サーバーが成功を返した時 |
| 5. 除外条件 | 数えない操作・環境 | 入力エラー、社内テスト |
| 6. パラメータ | 個人情報を含まない分析軸 | フォーム種別、CTA位置 |
| 7. キーイベント設定 | 指定有無とカウント方法 | 指定あり、イベントごと |
| 8. 重複防止 | 再送・二重実装への対処 | 送信済み状態と一意ID |
| 9. ドメイン境界 | ドメイン・外部サービス | 外部フォーム遷移 |
| 10. 同意・プライバシー | 同意状態と送信禁止情報 | メール・電話・本文を送らない |
| 11. 検証証拠 | 期待するイベントと業務記録 | 1回送信で各記録1件 |
| 12. 運用責任 | 所有者、承認者、再確認日 | マーケ責任者、更新担当 |
イベント名とパラメータを増やしすぎない
サービスごとに別のイベント名を作ると、サイト全体の成果を集計しにくくなります。一方、すべてを同じgenerate_leadにすると、どのフォームやCTAで発生したか分かりません。共通の行動はイベント名をそろえ、form_typeやcta_locationなど、個人を識別しないパラメータで分けます。
GA4の画面で既存イベントから新しいイベントを生成する方法もあります。ただしGoogleのイベント作成・変更の案内では、変更は過去データに適用されず、反映に1時間以上かかる場合があるとされています。緊急修正の便利機能として乱用せず、どこで生成したイベントかを定義表へ残します。
計測漏れは「到達できない境界」から探す
計測漏れはタグの書き間違いだけではありません。フォームが別ドメインで開く、同意前はタグが動かない、JavaScriptエラーで送信処理が止まる、完了画面がない、SPAでURLだけ変わる、といった境界で起きます。標準レポートの件数を見る前に、利用者の経路を端から端まで通します。
- 入口ページからフォームまたは予約画面へ進めるか。
- 同意前・同意後でタグの動作が方針どおりか。
- 入力エラーでは成果イベントが発火しないか。
- 正常送信の成功応答または確定状態で発火するか。
- 外部ドメインへ移ってもセッションと参照元が意図どおりか。
- フォーム受信・予約管理・CRMに同じテスト記録が残るか。
外部フォームとクロスドメインを別案件として扱う
外部フォームや予約サービスは、自社サイトと同じタグを自由に設置できるとは限りません。設置できる場合でも、GA4のクロスドメイン測定では、対象ドメインで同じウェブデータストリームのタグIDを使い、遷移時の_glパラメータが失われないか確認します。リダイレクトやサービス側の制限がある場合は、遷移クリックと外部側の完了を別の証拠として管理します。
「外部フォームへ進んだ」を問い合わせ完了と置き換えると、途中離脱も成果に含まれます。完了を取得できない場合は、イベント名も「フォーム遷移」に相当するものへ分け、業務側の受信件数と混同しないでください。
二重計測は「同じ成功を何回送れるか」で確認する
同じ問い合わせを2回以上数える典型例は、GoogleタグとTag Managerの両方で送る、クリック時と完了時の両方で同じイベントを送る、完了ページの再読込で再発火する、複数コンテナが残っている、送信ボタンを連打できる、SPAの履歴変更を重ねて検知する、といった状態です。
| テスト | 期待値 | 2件以上なら確認する場所 |
|---|---|---|
| 正常送信を1回 | 成果イベント1件 | タグ、トリガー、コンテナ重複 |
| 送信ボタンを連打 | 業務上の成功回数と一致 | ボタン無効化、サーバー処理 |
| 完了ページを再読込 | 新しい成果にしない | 再表示条件、送信済み状態 |
| 戻る・進むを操作 | 新しい成功がなければ0件 | 履歴イベント、SPA設定 |
| クリック後に入力エラー | 成果イベント0件 | クリック発火を完了扱いしていないか |
購入イベントでは、Googleはウェブストリームのpurchaseへ一意のtransaction_idを付けて重複を抑える方法を案内しています。空文字や、別取引で同じIDを使うと正しく集計できません。問い合わせでも、一意キーを利用できる場合は個人情報を含まない識別子とし、GA4だけでなく送信処理側の再実行防止も設計します。
公開前は5つの証拠を順番に確認する
一つの画面だけでは、発火条件、送信内容、処理後の集計、業務上の成功を同時に確認できません。テストケースごとに期待値を先に書き、次の順番で証拠を残します。

| 証拠 | 分かること | 確認時期 | 合格の例 |
|---|---|---|---|
| DebugView | イベント名とパラメータ | 操作直後 | 成功1回で期待イベント1件 |
| リアルタイム | 対象プロパティへ到着したか | 数分以内 | テスト端末のイベントを確認 |
| Tag Assistant・ネットワーク | タグ、同意、送信先、二重送信 | 操作中 | 意図した測定IDへ所定回数送信 |
| 標準レポート | 処理後の集計 | 通常24〜48時間後 | 日付・イベント・パラメータを確認 |
| 業務記録 | 実際の受信・予約・商談 | 同じテスト時 | テスト1件が識別できる |
GoogleのGA4トラブルシューティングでは、DebugViewは秒単位、リアルタイムは数分、標準レポートは通常24〜48時間の処理を見込むよう案内しています。公開直後に標準レポートへ出ないことだけで失敗と決めず、即時確認と処理後確認を分けます。
成功だけでなく失敗条件もテストする
正常送信だけでは、除外条件を確認できません。必須項目の未入力、入力形式エラー、通信失敗、キャンセル、戻る操作、再読込、同意の拒否と許可、PCとスマホ、主要ブラウザを組み合わせます。すべてを毎回試すのではなく、変更したタグ・フォーム・同意設定に影響するケースを選びます。
A/Bテストやフォーム改修を公開した日は、変更名、対象URL、イベント定義の版、担当者、テスト結果を残します。比較結果を経営指標へまとめる場合は、WebサイトKPIとダッシュボード設計で、分母・期間・対象をそろえてください。
GA4と問い合わせ件数は完全一致より差の説明を目指す
GA4のキーイベント件数と問い合わせ台帳は、同意拒否、広告ブロッカー、通信失敗、テスト除外、タイムゾーン、集計処理、キャンセル、電話・直接メールなどにより差が出ます。二つの数字を無理に同じ定義へせず、何を含み、何を含まないかを明記します。
- GA4が多い: 再読込、クリックと完了の二重発火、複数タグ、ボット、失敗操作の誤計測を確認。
- GA4が少ない: 同意状態、広告ブロッカー、外部フォーム、タグ未設置、JavaScriptエラー、測定IDを確認。
- 両方同じでも不安定: テスト数を増やし、端末・ブラウザ・フォーム種別・流入経路を分ける。
キーイベントのカウント方法には「イベントごとに1回」と「セッションごとに1回」があり、Googleはイベントごとを推奨しています。ただし、同じ人の複数送信を事業上どう評価するかは別の判断です。設定を変える前に、問い合わせ件数、ユニークな相談数、有効商談数を分け、変更日を残します。
個人情報と同意状態を計測要件に含める
イベントパラメータへ、氏名、メールアドレス、電話番号、会社名、自由記入本文を送信しません。GoogleのPII送信防止ガイドは、URL、ページタイトル、検索欄、フォーム入力、UTM、カスタムディメンションにも個人を特定できる情報が混ざる可能性を挙げています。完了ページのURLへメールアドレス等を付ける実装も避けます。
同意モードは、同意を取得する代わりの仕組みではありません。Googleは、利用者の選択を取得し、その状態を伝え、タグが選択を尊重することを求めています。基本モードと詳細モードでは、同意前後のタグ動作と送信内容が異なります。法務・プライバシーポリシー・CMPの方針を確認し、Tag Assistantでデフォルト状態と更新状態を検証します。
運用では担当・変更・再検証を一つの台帳に残す
正しく実装したイベントも、フォーム交換、URL変更、CMS更新、タグ整理、同意バナー変更、外部サービスの仕様変更で壊れます。イベントごとに業務責任者、定義承認者、実装担当、公開担当、定期確認担当を決め、変更履歴と再検証結果を同じ台帳へ残します。
| タイミング | 確認範囲 | 完成条件 |
|---|---|---|
| 実装前 | 12項目の定義、個人情報、同意、境界 | 空欄と役割衝突がない |
| 公開前 | 成功・失敗・再読込・端末別テスト | 期待回数と値に一致 |
| 公開直後 | DebugView、リアルタイム、通信、受信 | 同じテストを追跡できる |
| 24〜48時間後 | 標準レポートと業務記録 | 差を説明できる |
| 変更後・定期 | 影響するイベントと主要経路 | 再検証日と証拠が残る |
点検のたびにサイト全体を保存する必要はありません。変更対象のフォーム、タグ、テンプレート、イベントと、その影響経路に範囲を限定します。復旧用の全体バックアップは公開作業の承認後に1件だけ確認し、記事ごとに同じ全体データを複製しない運用にすると、どれが復旧基準か迷いません。
GA4キーイベント設計の公開判定
- 事業成果と対象行動が、営業・マーケティング・運用で合意されている。
- 12項目のイベント定義に空欄がなく、推奨イベントとの関係を確認した。
- 正常送信、入力失敗、再読込、連打、同意状態、外部遷移を必要範囲で試した。
- DebugView、リアルタイム、Tag Assistantまたはネットワーク通信で、名前・値・回数を確認した。
- 標準レポートを24〜48時間後に確認する担当と日付が決まっている。
- GA4とフォーム受信・問い合わせ台帳の差を記録できる。
- 個人情報をURL、イベント、パラメータ、UTMへ送らないことを確認した。
- 変更履歴、所有者、承認者、再検証日が残る。
この8項目を満たしてから、チャネル別の投資判断や改善施策へ進みます。費用配分を検討する場合はマーケティング予算の決め方を参照し、計測できていない成果を0件として扱わないでください。
まとめ
GA4の計測品質は、タグの有無より、成果定義、発火・除外条件、重複防止、外部境界、同意、検証、業務記録との照合で決まります。イベント名だけの一覧ではなく、12項目を1行にした定義表を作り、成功と失敗の両方を試してください。
みやあじよでは、サイトの目的と営業フローを確認し、イベント定義、タグ実装、フォーム・外部サービスの検証、KPI整理まで支援します。支援範囲はWeb集客・改善サービスをご覧ください。どこから点検すべきか整理したい場合は、お問い合わせフォームからご相談いただけます。