GA4にpage_viewが記録されない原因はGTMのGoogleタグ不在。3年間ページ別レポートが空だった話

こんにちは、Webサービス開発者のyuku_tasです。

簡単なプロフィール: MoldSpoon Inc.代表。開業から15年、業界に携わって20年。Webサイト/iOS/Androidアプリ開発から、
データ分析業務・コンサル業務、ベンチャーから保険会社まで様々な案件を個人会社の形で請け負ってまいりました。
詳しくはこちら

はじめに

自社サイトのアクセス状況を見ようとして、GA4の**「ページとスクリーン」レポートを開いたら数字が全部ゼロ**でした。

Google Tag Managerは入っています。GA4のリアルタイムにもユーザーは出ています。地域も参照元も取れています。それなのに、どのページが何回見られたのかだけが分からない。

調べた結果、原因はGTMのコンテナに「Googleタグ（GA4設定タグ）」が1本も無かったことでした。しかもこの状態、3年近く気づかずに運用していました。

同じハマり方をしている方がいそうなので、症状の見分け方から修正までを残しておきます。

症状：一見「動いている」のがタチが悪い

まず、この不具合が厄介なのは完全に壊れているわけではない点です。実際に取れていたものと、取れていなかったものを並べるとこうなります。

GA4は何かしらイベントが飛んでくればセッションとユーザーをカウントします。だから「アクセス解析が動いているかどうか」だけを見ていると、正常に見えてしまいます。

ダッシュボードを開いて「今日は何人来たな」と眺めるだけの運用だと、まず気づけません。私は気づけませんでした。

原因の切り分け：GA4の「イベント」を見る

GA4の管理画面をいくら見ても設定は正常でした。切り分けに使えたのはイベント名の一覧です。

レポート → エンゲージメント → イベント を開いて、送られてきているイベント名を確認します。

ここに page_view が無ければ、GA4側ではなくタグ側の問題です。

私の場合、ここに並んでいたのは page_view ではなく、見慣れない名前でした。

gtm.dom

これが決定的な手がかりでした。gtm.dom はGTMが内部的に使うdataLayerのイベント名で、本来GA4に送るものではありません。

真犯人：{{Event}} を送り続けるGA4イベントタグ

GTMのコンテナを開いてタグ一覧を見ると、こうなっていました。

• Googleタグ（GA4設定タグ）が存在しない
• 代わりに「GA4イベント」タグが1本だけあり、イベント名が {{Event}}、トリガーが DOM Ready

{{Event}} はGTMの組み込み変数で、「いま発火の原因になったdataLayerイベントの名前」が入ります。

つまりDOM Readyトリガーで発火させると、{{Event}} は gtm.dom に解決されます。結果として、

GA4に「gtm.dom」という名前のイベントが延々と送られ続ける

という状態になっていました。3年間、ひたすら gtm.dom を送っていたわけです。

なぜページビューが0になるのか

GA4の「表示回数」は、page_view という名前のイベントの数をそのまま数えています。名前が違えば別のイベントとして扱われるだけで、エラーにはなりません。

そしてpage_viewを送る役目を持つのが、まさに欠けていた**Googleタグ（GA4設定タグ）**です。これが無いので、

• ページを開いても page_view は飛ばない
• でも gtm.dom は飛ぶのでセッションとユーザーは立つ
• ページ別の指標だけが永遠にゼロ

という、中途半端に動いている状態ができあがります。

GA4の設定画面を何度見直しても原因は分かりません。GTMのタグ一覧を見て初めて分かります。

修正手順

やることは2つだけです。

1. Googleタグを追加する

GTMで タグ → 新規 から、タグの種類に 「Googleタグ」 を選びます。

• タグID: GA4の測定ID（G- で始まるもの）を入れます
• トリガー: Initialization - All Pages（初期化 - All Pages）を選びます

トリガーは「All Pages」ではなくInitialization（初期化）のほうを選ぶのがポイントです。他のタグより先に動く必要があるためです。

測定IDはGA4の 管理 → データストリーム から確認できます。

2. 壊れたGA4イベントタグを削除する

イベント名が {{Event}} になっているGA4イベントタグは削除します。残しておいてもgtm.domというゴミイベントが送られ続けるだけです。

あとは公開すれば反映されます。

なお、GA4側の設定（拡張計測機能、「ブラウザの履歴イベントに基づくページの変更」など）は元から正しく入っていたため、一切触っていません。 原因がGTM側だけの場合、GA4を触る必要はありません。

直ったことをどう確認するか

「たぶん直った」で終わらせないために、2段階で確認しました。

方法1: リアルタイムレポート

GA4の レポート → リアルタイム を開いた状態で、自分のサイトを別タブで開きます。

イベント名に page_view が出て、ページタイトルごとの表示回数が入れば成功です。

方法2: ブラウザの開発者ツールで送信内容を直接見る

より確実なのはこちらです。開発者ツールのネットワークタブを開いて collect で絞り込み、サイトを再読み込みします。

/g/collect へのリクエストのクエリ文字列に、次の2つが入っていれば正しく飛んでいます。

en=page_view          ← イベント名
tid=G-XXXXXXXXXX      ← 測定ID

en は event name の略です。ここが gtm.dom になっていたら、まだ古いタグが生きています。

この確認方法はGA4の反映待ち（数分〜数十分）を待たずに済むので、修正直後の切り分けに便利です。

ついでに直したこと：自分の開発アクセスが本番データに混ざっていた

計測を直したら、今度は参照元に localhost:3000 が記録されていることに気づきました。ローカル開発中のアクセスが本番のGA4に流れ込んでいたわけです。

Next.jsなら、計測タグを本番サイトでのみ読み込むようにすれば防げます。

// pages/_app.js
const isProductionSite =
  process.env.NODE_ENV === 'production' &&
  process.env.NEXT_PUBLIC_VERCEL_ENV !== 'preview'

export default function App({ Component, pageProps }) {
  return (
    <>
      {isProductionSite && (
        <GoogleTagManager googleTagManagerId={googleTagManagerId} />
      )}
      <Component {...pageProps} />
    </>
  )
}

NODE_ENV だけで判定するとVercelのプレビューデプロイも本番扱いになってしまう点に注意してください。プレビューは NODE_ENV === 'production' でビルドされるためです。Vercelが自動で入れてくれる NEXT_PUBLIC_VERCEL_ENV を併用すると、プレビューも除外できます。

計測データを綺麗にしたいなら、直すのは早いほうがいいです。混ざったデータは後から取り除けません。

よくある質問（FAQ）

Q. 過去のデータは復旧できますか？

残念ながら無理です。送られていないデータはどこにも存在しないので、後から埋める手段はありません。私も3年分をきれいに諦めました。

とはいえ全滅でもありません。ユーザー数・セッション数・参照元は正しく記録され続けていたので、「去年の同じ時期と比べて人が減ったのか」くらいの話ならこれまで通り追えます。使えないのはページ単位の指標（表示回数、エンゲージメント時間）だけです。

どのページが読まれていたかを知りたいなら、Google Search Consoleが残っています。GSCはGA4とは別系統でGoogle検索経由の表示回数とクリック数をページごとに持っているので、今回の件とは無関係に無傷でした。私も結局そちらを見て過去を振り返っています。

Q. GTMを使わずgtag.jsを直接入れている場合も同じことが起きますか？

そちらならまず起きないはずです。GA4のデータストリーム画面からコピーできるスニペットには最初からconfig（Googleタグに相当するもの）が含まれていて、これがpage_viewを送ってくれます。貼った時点で完成しているわけです。

裏を返すと、今回の落とし穴はGTMでタグを1つずつ手で組み立てたときにだけ開くものだと言えます。イベントタグのほうから作り始めると、土台にあたる設定タグの存在を意識しないまま出来上がった気になってしまう。私はそれをやりました。

Q. SPAでページ遷移したときのページビューは別途設定が必要ですか？

たいていは要りません。GA4の拡張計測機能にある「ブラウザの履歴イベントに基づくページの変更」がオンなら、historyの書き換えを検知してpage_viewを送ってくれます。しかも既定でオンです。

ただ、そこを疑うのは後回しでいいと思います。SPA遷移が取れていないように見えて、実は初回ロードのpage_viewからして飛んでいなかった、というのが今回のパターンでした。まずGoogleタグを入れて1回目が記録されるか見るほうが、切り分けとしては圧倒的に速いです。

Q. gtm.dom や gtm.js というイベントがGA4に出ているのですが

まさにそれです。この記事は最初から最後までその状態の話をしています。

GTMが内部で使っているイベント名が、そのままGA4まで届いてしまっている状態です。イベント名に{{Event}}を指定したタグが紛れ込んでいないか、GTMのタグ一覧を見てみてください。

まとめ

GA4でページ別の数字だけがゼロになる場合、チェックする順番はこうです。

1. GA4の エンゲージメント → イベント で page_view があるか見る
2. 無ければGTMのタグ一覧を開き、Googleタグ（GA4設定タグ）があるか確認する
3. イベント名が {{Event}} のGA4イベントタグがあれば、それが犯人
4. Googleタグを Initialization - All Pages で追加し、壊れたタグを削除して公開
5. 開発者ツールのネットワークタブで en=page_view が飛ぶことを確認する

一番の教訓は、「グラフに線が出ている＝正しく計測できている」ではないということでした。ユーザー数だけを見ていると、3年でも気づけません。

導入したときに一度、イベント名の一覧を目視する。これだけで防げます。

同じサイトの計測まわりでは、GTMのタグ読み込みが表示速度を落としていた話も書いています。

この記事が何かのお役に立てれば幸いです。
最後までお読みいただきありがとうございました！