キーイベントが計測されないときの調べ方

フォームを送信したのに、GA4のキーイベントが増えない。よくある状況です。原因は複数ありますが、上流から順に切り分けることで特定しやすくなります。いきなり設定画面を見直すと、遠回りになります。

切り分けの順番

計測のデータは、ページからGA4のレポートまで、決まった順に流れます。どこか1か所で止まれば、それより下には何も届きません。だから、上から順にどこで止まっているかを確かめます。

1. ページでタグが読み込まれる
2. 目的の操作でイベントが送信され、GA4に届く
3. GA4がそのイベントをキーイベントとして数え、レポートに反映する

よくある誤りは、レポートに出ないのを見て、いきなり3の設定画面から直し始めることです。1で止まっていれば、設定をいくら直しても数字は出ません。この記事では、この3段階を番号どおりに1つずつ確認します。

どの段階から見るかは、症状からある程度しぼれます。最初に確かめたいのは、リアルタイムレポートにイベントが出るかどうか。次の表で、当たりを付けてから始めると早く済みます。

症状	止まっていそうな段階	最初に見ること
リアルタイムにもDebugViewにもイベントが出ない	1〜2	送信完了ページでタグが動くか
イベントは出るが、キーイベントの数が0	3	イベント名と登録が一致しているか
昨日まで数えていたのに、今日から0	1〜2（変更の影響）	直前にサイトやGTMを変えていないか
リアルタイムには出るが、標準レポートに出ない	3（反映待ち）	反映待ちではないか（日付を置いて再確認）

3行目のように、急に止まった場合は、直前の変更がいちばんの手がかりになります。サイトのリニューアル、フォームの差し替え、GTMの公開などの日付と、数字が止まった日付を並べてください。日付が重なっていれば、その変更の中身から調べます。日付が重ならないときも、下流の設定から見始めず、1のタグの読み込みから順に確かめてください。

誰に何を聞くか

計測の不具合は、担当者の知らないところで起きた変更が原因のことがよくあります。サイトの制作会社がフォームを差し替えた、広告の代理店がGTMにタグを足した、といった変更です。切り分けを始める前に、関わっている人に次のことを聞いておくと、原因にたどり着く時間が短くなります。

聞く相手	聞くこと
サイトの制作会社	最近、フォームや送信完了ページ、ページの構成を変えたか
広告の代理店	GTMや計測のタグを追加・変更したか
フォームのサービスの担当	サービス側の仕様変更や、ドメインの変更がなかったか
社内の担当者	同意のバナーや、プラグインを入れ替えていないか

仮に、数字が止まった日の前日に、制作会社がフォームを新しい仕組みに入れ替えていたと分かれば、切り分けは2の段階（イベントが送られているか）から集中して見れば済みます。聞いた内容と日付は、そのまま計測の記録に残しておきます。

1. タグが読み込まれているか

最初に、対象のページでタグ自体が動いているかを確かめます。GTMを使っているなら、プレビューモードでそのページを開くと、タグの発火状況が一覧で見えます（使い方はGTMのプレビューモードの使い方）。問い合わせの成果を測るなら、確かめるページは送信完了後のページです。ここで止まっている場合、原因の多くは次の3つです。

• 送信完了ページにタグが入っていない：別システムのページだと、タグの設置が漏れがち
• フォームが別ドメインにある：外部のフォームサービスを使っている場合、そのドメインには自社のタグが入らない
• 同意管理で読み込みが止まっている：同意前はタグを読み込まない設定になっていることがある

特に2つ目は見落としやすい原因です。送信完了の画面が自社サイトのデザインに見えても、アドレスバーのドメインが外部サービスのものになっていることがあります。

GTMを使っていない場合や、プレビューモードが開けない場合は、ブラウザの開発者ツールでも確かめられます。送信完了ページを開いた状態で開発者ツールの「ネットワーク」を表示し、「collect」で絞り込みます。GA4への送信があれば、google-analytics.com の「g/collect」宛ての通信が並びます。何も出なければ、そのページではGA4のタグが読み込まれていません。

確認するときは、広告ブロックの拡張機能を切り、社外からのアクセスに近い状態で開きます。拡張機能がGA4への送信を止めていると、正しく設定されていても何も送られないからです。確認の手順を固定しておくと、担当が変わっても同じ結果になります。

2. イベントが送られているか

タグは動いているのにイベントが出ない場合、発火の条件が合っていません。GA4の管理画面にあるDebugViewを開いた状態で、実際にフォームを送信してみてください。イベントが届いていれば、その場で表示されます。届いていない場合は、トリガーの条件を確かめます。

• URLの条件が厳しすぎる：末尾のスラッシュやパラメータの有無で一致しなくなっている
• ページ遷移が速すぎる：送信後すぐに移動すると、送信が間に合わないことがある
• 自分のアクセスが除外されている：内部トラフィックの除外を設定していると、社内からのテストは記録されない。テスト中は除外を一時的に外すか、DebugViewで確認する（自社のアクセスを数えない ― 内部トラフィックの除外）

たとえば、トリガーの条件を「URLが /thanks/ に等しい」にしていると、実際のURLが /thanks/?id=123 のようにパラメータ付きなら一致しません。この場合は「含む」に変えるなど、実際のURLを見て条件を合わせます。

ページ遷移が速すぎる問題は、発火のきっかけを変えると避けられます。送信ボタンのクリックで数えている場合、送信完了ページの表示で数える形に変えると、送信が間に合わない問題は起きにくくなります。送信完了ページがなく画面の表示だけが切り替わるフォームは、別の方法が要ります。

テストの送信は、記録に残る形で行います。仮に、件名に「テスト」と入れて10時05分に送信したなら、DebugViewでその時刻のイベントを探し、フォームの管理画面にも同じ件が届いているかを見ます。両方にそろって初めて、イベントと実際の送信が対応していると言えます。テストの送信は、営業側の件数に入らないよう事前に伝えておきます。

DebugViewに表示されるのは、デバッグの状態で送られたデータだけです。GTMのプレビューモードで開いたページや、GA4のデバッグ用の拡張機能を有効にしたブラウザからの送信が対象になります（2026年9月時点）。普段のブラウザでただページを開いただけでは表示されません。プレビューモードから開き直し、端末の一覧で自分の端末を選んでください。

3. GA4側の設定が合っているか

イベントは届いているのに「キーイベント」として数えられない場合は、GA4側の設定の問題です。多いのは、イベント名のわずかな違いです。次の表の順に確かめます（画面名やメニューの位置は2026年9月時点の名称です）。

確認すること	見る場所
イベント名が完全に一致しているか	管理 → イベント。大文字小文字も区別される
キーイベントとして登録されているか	管理 → キーイベント
データストリームが正しいか	測定IDが本番用のものか確認

設定が正しくても、すぐには表示されないことがあります。キーイベントの登録は登録後のデータにのみ適用され、過去には遡りません。また標準レポートへの反映には時間がかかり、当日の数字は確定値ではありません。確認には、すぐに表示されるリアルタイムレポートとDebugViewを使います。

イベント名の違いは、目で見ても気づきにくいものです。たとえば、タグ側は「contact_complete」、キーイベントの登録は「Contact_complete」になっていると、GA4は別のイベントとして扱います。イベントの一覧から名前をコピーして登録し直すと、打ち間違いを防げます。GTMで送るイベント名とGA4の登録名は、一覧表にして並べておくと点検が楽です。

反映待ちかどうかは、日付を置いて判断します。GA4のヘルプでは、データの処理に24〜48時間かかることがあると説明されています（2026年9月時点）。修正した翌日に標準レポートが0件でも、すぐに失敗と決めず、2日後にもう一度見ます。その間の確認はリアルタイムレポートとDebugViewで行います。

登録が過去に遡らないため、登録前の期間の件数が必要なときは、フォームの管理画面や通知メールの件数を別に集計します。報告では「この日まではGA4で数えていない」と書き添えます。数字が途中から増えたように見えるのは計測を始めたためで、成果が増えたわけではないと、読む人に伝わるようにするためです。

直した後の確認と、日々の点検

直したら、それで終わりにしないことが大切です。修正の後に実件数と照らし合わせて、計測が正しく戻ったかを確かめます。ここでいう実件数とは、フォームの通知メールや管理画面に届いた件数のことです。GA4の数字だけを見ていると、半分しか数えていない状態にも気づけません。

仮の数字で見てみます。1週間でフォームの通知メールは20件、GA4のキーイベントは14件でした。

• GA4で数えられている割合：14÷20＝70%
• テスト送信や営業の迷惑メールを除くと、実件数は18件 → 14÷18で約78%
• 残りの差は、同意の拒否や広告ブロックで送信されなかった分と考えられる

このように、GA4の数字が実件数と完全に一致することはあまりありません。大事なのは、差の大きさが毎週ほぼ一定かどうか。ある週だけ割合が大きく下がったら、その週に何か変わったと考えて、この記事の順番で切り分けます。反対に、GA4のほうが実件数より多い場合は、二重に数えている可能性があります。

点検は、月に1回でも構いません。実件数とGA4の件数、その割合を表に1行ずつ書き足すだけです。修正した日やサイトを変えた日も同じ表に書いておくと、割合が変わった理由を後から追えます（計測が壊れていないか ― 月1回の点検リスト）。

修正の確認で送ったテストも、本番の成果として数えられ、件数が実際より多くなります。テストは内部トラフィックとして除外される環境から行い、確認にはDebugViewを使うのが基本です。除外できない場合は、テストの日時と件数を記録し、月の集計から差し引きます。営業側の管理表にも「テスト」と分かる印を付けておくと、両方の件数がずれません。

まとめ

キーイベントが計測されないときは、タグ → イベント → GA4側の設定の順に切り分けます。設定画面から見始めると遠回りになります。確認にはDebugViewとリアルタイムレポートを使い、反映の遅い標準レポートでは判断しません。直した後は、実件数と照らして割合が戻ったかまで確かめてください。