「イベントを設定したのに、GA4レポートに出てこない…」
「DebugViewを開いたけど、どこを見ればいいのか分からない…」
GA4のイベント設定で最後に詰まるのが、この “確認” です。
DebugViewは、送信されたイベント名とパラメータをその場で確認できるチェック画面。
ここを見れるようになると、「設定ミス」「名前違い」「二重計測」みたいな事故が一気に減ります。
（※前提の設定手順は Day 8の記事)、カスタムイベント作成は [ Day 9の記事 ] で解説しています）
この記事では、初心者が迷いがちな DebugViewで見るべき10ポイントを整理します。
「イベント名が合っているか」「パラメータが入っているか」「発火タイミングがズレていないか」まで確認できれば、イベント設定のミスはほぼ潰せます。
まずは「DebugViewとは何か？」から見ていきましょう。
DebugViewとは?【リアルタイム確認の必須ツール】
結論から言うと、DebugView =（デバッグモードで）GA4に送信されたイベントを、その場で確認できるデバッグ専用画面です。
DebugViewでできること
DebugViewでは、以下が確認できます。
確認できる項目
- イベント名：page_view、click、form_submit_complete など
- パラメータ：page_location、link_url など
- パラメータの値：実際のURL、クリックしたリンク先など
- 発火タイミング：イベントが送信された順番と時刻
つまり、「どんなイベントが」「どんなパラメータで」「いつ」送信されたかが、その場で分かります。
リアルタイムレポートとの違い
よくある疑問：「リアルタイムレポートじゃダメなの？」
結論：“来てるか確認”はリアルタイムでもOK。ただし”設定の検証”はDebugViewが強いです。
| 項目 | リアルタイム | DebugView |
|---|---|---|
| イベント名 | 見える | 見える ✅ |
| パラメータ名 | 見えない ❌ | 見える ✅ |
| パラメータの値 | 見えない ❌ | 見える ✅ |
| 発火順序 | 追いにくい | 時系列で明確 ✅ |
| 用途 | アクセス状況確認 | 設定の検証 ✅ |
DebugViewを使う3つのシーン
1. イベント設定直後
- 新しくイベントを作った後、「本当に動いているか？」を確認
2. カスタムイベント作成後
- Day 9の記事で解説した「イベント作成」の動作確認
3. 「イベントが出ない」トラブル時
- 設定したのに通常レポートに出ない → DebugViewで原因特定
前提: デバッグモードの有効化が必要
DebugViewを使うには、デバッグモードを有効化する必要があります。
有効化の方法は次のセクション（H2-2）で解説します。
DebugViewの開き方【3つの方法】
前提: デバッグモードの有効化が必須
DebugViewを使うには、デバッグモードを有効化する必要があります。
主な方法は3つです。
方法1: Google公式「Tag Assistant」（推奨）✅
初心者はまずこれが最短です。
手順
- Chromeで自サイトを開く
- Chrome拡張機能 「Tag Assistant（Google）」 をインストール
- 拡張機能を開き、サイトに接続（Connect）
- サイトを操作（ページ移動、クリックなど）
- GA4 → DebugView を開く
💡 ポイント
- DebugViewに出ない場合は、接続後にページをリロードしてから再操作してください
方法2: GTMプレビュー（GTM利用者向け）
GTMを使っている人はこの方法も便利です。
手順
- GTM管理画面 → 右上の 「プレビュー」
- 自サイトURLを入力 → 接続（Connect）
- 別タブで自サイトが開いたら操作する
- GA4 → DebugView を開く
💡 ポイント
- 多くの場合、プレビュー中の操作はDebugViewにも反映されます
（出ないときは方法1を優先）
方法3: Chrome拡張「Google Analytics Debugger」（最終手段）
古い方法で、環境によっては使えます。
手順
- Chrome拡張 「Google Analytics Debugger」 をインストール
- 拡張機能をON → 自サイトをリロード
- GA4 → DebugView を開く
⚠️ 注意
- UA向けの色が強く、GA4では動作が安定しないことがあります
- まずは方法1（Tag Assistant） を試してください
確認ポイント10選【これだけ見ればOK】
DebugViewで最低限チェックすべき10項目をまとめました。
おすすめは、まず 「基本5項目」 で“動いているか”を確認 → ダメなら 「応用5項目」 で“なぜ動かないか”を切り分ける流れです。
✅ 基本5項目(必ずチェック)
1. イベント名が表示されているか
確認ポイント
- DebugView左側にイベント名が時系列で並ぶ（例：
page_view,click）
ここで詰む典型
- デバッグモードが入っていない／接続が切れている
次にやること
- Tag Assistantで再接続 → 反映されない場合はリロード → もう一度操作
2. いま見ているプロパティ（測定ID）が正しいか
確認ポイント
- 見ているGA4が「本番」か「テスト」か
- 測定ID（
G-XXXX）が想定のプロパティか
ここで詰む典型
- テスト用プロパティに送っているのに本番を見ている（逆も多い）
次にやること
- GA4「管理 → データストリーム」で測定IDを確認（ここが最短）
3. 作ったカスタムイベント名が出ているか
確認ポイント
- 例：
form_submit_complete,pricing_view,youtube_clickが出るか
ここで詰む典型
- 条件が合っていない（
equalsで厳しすぎる／パラメータ名を間違えた）
次にやること
- DebugViewで「元のイベント（例：page_view）」を開いて、条件に使う値を実測する
4. イベントパラメータが入っているか
確認ポイント
- イベントをクリック → 右側に
page_location,link_urlなどが出るか
ここで詰む典型
- 期待したパラメータがそもそも送られていない（＝条件で拾えない）
次にやること
- まず「元イベントに必要パラメータがあるか」を確認してから条件を組む
5. パラメータの値が想定通りか
確認ポイント
/thanksが含まれているか、リンク先が正しいか、末尾スラッシュやクエリが付いていないか
ここで詰む典型
equalsで完全一致にして、?id=123や/thanks/で外れる
次にやること
- 基本は
containsで広めに拾う → 誤爆があれば後から絞る
🔍 応用5項目(トラブル時に確認)
6. 重複計測していないか（数が倍に見える）
確認ポイント
- 同じイベントが不自然に連続／同じ操作で2回送られている
原因の当たり
- 直貼りタグ + GTMの二重、または同じタグが複数発火
（SPAは“慣れてから”でOK。まず二重設置を疑う）
次にやること
- 実装を「GTMに統一」or「直貼りに統一」して片方を外す
7. “想定外のイベント”が出たときの切り分け
確認ポイント
scrollやfile_downloadが出るのは、拡張計測ONなら普通
ここで詰む典型
- それを“バグ”だと思って設定を壊す
次にやること
- データストリームの「拡張計測（ON/OFF）」を確認
- WordPressプラグイン等でタグが追加されていないかもチェック
8. デバッグ端末（タブ）を取り違えていないか
確認ポイント
- DebugViewが、いま操作している端末/タブのデータを見ているか
ここで詰む典型
- さっき開いた別タブのデバッグが残っている／接続が別タブになっている
次にやること
- Tag Assistantを“いま操作するタブ”で再接続 → 同じタブで操作し続ける
9. デバッグモードが途中で切れていないか
確認ポイント
- Tag Assistantの接続が切れていないか
- 別タブに移った瞬間、デバッグが外れていないか
次にやること
- 再接続 → 反映されない場合はリロード → 再操作
10. “出るのが遅いだけ”を疑う（通常レポートは遅延）
確認ポイント
- DebugViewで見えているなら、設定はほぼOK
- 通常レポートは24〜48時間遅れることがある
次にやること
- すぐ確認したいなら「リアルタイム / DebugView」で判断する
よくある見間違い3つ
DebugViewを見ていて 「あれ？おかしい？」 と思ったら、まずこの3つを疑ってください。
見間違い1: page_location と page_path を混同する
症状
- 「
page_pathで/thanksを条件にしたのに、発火しない…」
正体
page_locationは URL全文（例：https://example.com/thanks?id=123）page_pathは パス部分（例：/thanks）
解決策
- クエリ（
?id=123）や末尾スラッシュの揺れがありそうならpage_location+containsが安全 - パスだけで十分なら
page_pathでもOK（ただし 実際の値はDebugViewで実測してから条件を組む）
💡 Day 9の記事の「よくある間違い」も参照
見間違い2: 同じイベントが複数出る = バグ？
症状
page_viewが2回連続で出る- 同じ操作で同じイベントが複数回表示される
正体（まず疑う順）
- 異常ケースが多い: 直貼りタグ + GTMの二重設置、または同じタグが複数発火
- 次の候補: SPA（React/Vue等）で画面遷移の取り扱いにより
page_viewが複数回出ることがある
解決策
- まず 実装を統一（GTMのみ or 直貼りのみ）して重複を潰す
- SPAの可能性が高い場合は「履歴の変更時のページビュー」などの設定を確認
- H2-3の応用項目6「重複計測」 も参照
見間違い3: パラメータが空欄 or (not set)
症状
link_urlが空欄page_titleが(not set)と表示される
正体
- そのイベントにそのパラメータが付いていない（= そもそも送信されていない）
- 例：外向きクリックがOFF / 外部リンクではない / ボタンでURLが無い など
- もちろん、拡張計測がOFFで
click関連が入らないケースもある
解決策
- データストリーム → 拡張計測 がONか確認
- DebugViewで「元イベント」を開いて、必要なパラメータが存在するかを先に確認
- 元イベントに無いパラメータは、イベント作成の条件にも使えない
💡 ポイント: 条件を作る前に、DebugViewで「元イベントの材料（パラメータ）」を確認するのが最短です。
まとめ
DebugViewは、GA4に送られたイベントとパラメータをリアルタイムで確認できるデバッグ専用画面です。
イベント設定で迷ったら、まずDebugViewで「材料（イベント/パラメータ）」を見れば、原因が一気に絞れます。
この記事で解説したこと
- DebugViewの開き方（Tag Assistant推奨）
- 確認ポイント10選（基本5 + 応用5）
- よくある見間違い3つ
今日の最初の一歩（最短5分）
- Tag Assistantでデバッグモードを有効化（接続後にリロード）
- DebugViewを開く
- 自サイトを1〜2ページ操作して
page_viewが出るか確認 - 次に「基本5項目」を順にチェック（イベント名→パラメータ→値→タイミング）
💡 ポイント
- DebugViewでイベントが見えれば「送信自体」は成功です。
- 通常レポートは24〜48時間遅れることがあるので、まずはDebugViewで判定してください。
- もし見えているのに数字が変なら「本番/テストの取り違え」「二重計測」を疑いましょう。
次に読むべき記事
- Day 9: カスタムイベント作成マニュアル → DebugViewで“狙ったイベント”を増やす
- Day 8: イベントとキーイベントの違い → 成果（キーイベント）として数える
- GA4を0から学ぶ30日ロードマップ → 学習全体の地図
質問・相談はXで受付中
「DebugViewで〇〇が出ない」「この条件で合ってる？」など、気軽にリプライください！
コメントを残す