GA4のBigQuery Exportにおいて、page_viewイベントでutmパラメータがnullになってしまう可能性のある原因について調査
弊社が運営するGA4コミュニティで下記のようなご質問をいただきました。
明確な原因は特定できなかったのですが、調査した内容をここにまとめさせていただきました。
記事の前半は、utmパラメータに関する基本的な内容ですので、後半から読み進めていただいてもよろしいかと思います。
頂いたご質問の要約
GA4をBigQuery Exportで利用していて、page_viewイベントに記録されるutmパラメータの確認をしていたのですが、 URL(page_location)にはutmパラメータが適切に記述されているのに、event_params > source, medium, campaigの値がnullになる事象がありました
前後イベントも併せて確認したところ、該当のutmパラメータ画空のpage_viewイベントの直前にscrollイベントが発火しており、そのscrollイベントのevent_paramsにutmパラメータが記録されていました
page_viewとscrollは同一page_locationで発生しています。
page_viewよりもscrollは先に発生していますが、ページ内リンクなど、一気にscrollする手法は使っていません。
GA4 BigQuery ExportでUTMパラメータが記録されない一般的な原因
Google Analytics 4 (GA4)では、URLに含まれるUTMパラメータ（例: utm_source、utm_medium、utm_campaign）を自動的に検出してイベントに関連付ける仕組みがあります。しかし、いくつかの理由でこれらのUTM情報が記録されない、あるいはnull（未設定）となる場合があります。主な原因は以下のとおりです。
UTMタグの不備や誤り: URLにUTMパラメータが正しく付与されていない場合、GA4はキャンペーン情報を認識できません。たとえば、utm_sourceやutm_mediumなど必須のパラメータが欠落していたり、綴りが誤っていると（Googleが定義していないカスタムのパラメータ名を使用している等）、データが記録されずnullになります
。GA4が認識できるUTMパラメータは決まっており、
utm_source、utm_medium、utm_campaign、utm_id、utm_term、utm_contentの6種類です。これ以外のパラメータ名を使った場合や、値が空・不正な場合は記録されません。また、大文字・小文字の不統一によるトラッキングミスを防ぐため、UTMパラメータ名および値はすべて小文字で記述することが推奨されています
。
URL構造の問題（長さやフラグメントなど）: 非常に長いURLの末尾にUTMパラメータが付与されている場合、ブラウザやAnalytics側でURLが一部切り捨てられ、UTM情報が欠落するケースがあります
。特にGA4ではURL長の上限を超えるとパラメータが途中で切れて記録されない可能性があります。また、URLの「#」（ハッシュ・フラグメント）以降にUTMパラメータを記述していると、ブラウザからはそれが送信されずGA4で取得できません。従って、UTMパラメータは必ず「?」以降のクエリストリング部分に含める必要があります（ハッシュの後ではなく）
。
オートタグと手動UTMの競合: Google広告などで自動タグ付け（gclid）を利用している場合、GA4は自動タグから得られる情報を優先し、手動のUTMパラメータを無視することがあります
。特に
utm_source=google、utm_medium=cpcのようにGoogle広告トラフィックと判断される場合、gclid（自動タグ）が存在するとUTMによる上書きが行われず、UTM起因のキャンペーン情報が記録されないことがあります。このようなケースではGA4レポート上で(not set)や(direct/none)と表示されたり、BigQuery上でも該当イベントのutmパラメータがnullになる可能性があります。対策として、GA4のプロパティ設定で「手動タグ設定による上書きを許可する」オプションを確認したり、Google広告用のトラッキングとUTMの整合性をとる必要があります。
内部トラフィックでのUTM利用: UTMパラメータは本来外部からのキャンペーン計測用ですが、もしサイト内部のリンクにUTMパラメータ付きURLを使用すると、トラフィックソースの計測が混乱します。UA（Universal Analytics）では内部UTMリンクを踏むと新しいセッションが開始されてしまいましたが、GA4でもセッションこそ引き継がれるもののイベント単位のキャンペーン情報として扱われ、正しい流入経路がわからなくなる恐れがあります。
。したがって、サイト内遷移にはUTMパラメータを付与しないようにし、代わりにカスタムディメンション等で内部キャンペーンを計測するのが望ましいです。
以上のような理由で、GA4のBigQueryエクスポートデータにおいてUTMパラメータが記録されずnullになってしまうことがあります。次に、今回のケースで問題となっているpage_viewイベントに絞り、そのUTMパラメータがnullになる原因を考察します。
page_viewイベントでUTMパラメータがnullになる可能性のある理由
通常、ユーザーがUTMパラメータ付きのURLでサイトに訪れると、最初のページビュー（page_view）イベントにそのUTM情報がひも付き、BigQueryのイベントデータ上でもevent_params内のsource, medium, campaignといったパラメータに値が入ります。ところが、page_viewイベントでこれらがnullとなるのは、GA4がそのイベントにキャンペーン情報を付与できなかったことを意味します。考えられる理由として以下が挙げられます。
page_viewがセッション内の最初のイベントではなかった: GA4では、セッション開始時の最初のイベントに対して流入元情報（UTMや参照元）を割り当てる仕様があります
。一般的には最初のイベントはpage_viewですが、何らかの事情でpage_viewより先に別のイベントが発生してしまうと、キャンペーン情報がその最初のイベントに紐付けられ、後から送信されたpage_viewには付かない可能性があります。実際にGA4では「セッション内でpage_viewが最初でない場合、ランディングページの属性付けが行われず、“(not set)”になる」ことが確認されています
。これは裏を返せば、最初のイベントでないpage_viewにはUTMパラメータが反映されないケースがあるということです。
UTMパラメータ付きURLで再訪したが新セッションとみなされなかった: ユーザーが一度サイトに訪れた後、同じUTM付きURLで短時間に再訪問した場合、GA4では新しいセッションと判定されず前回のセッションが継続することがあります（GA4はUAと異なり、デフォルトでは新たなキャンペーン流入でセッションをリセットしません）。この場合、再訪時のpage_viewイベント自体にはUTMパラメータが付いていても既に直前のセッションでキャンペーン情報を保持しているため、新規のキャンペーンとしてカウントされず、イベントパラメータ上ではnull（前回から変化なし）となる可能性があります。例えば、最初の訪問でUTM情報を取得済みで、その後30分以内に同じキャンペーンのURLでページビューが起きても、GA4は同一セッション内の動きと見なすため、個々のイベントの
source/mediumを更新しない挙動がありえます（UI上は流入元レポートに重複して出ないようにするため）。page_viewイベントの計測タイミングの問題: サイト実装上の問題で、GA4のページビュー送信が遅れたり、正しくクエリパラメータを含めて送信されていないケースも考えられます。例えば、GA4タグをGoogleタグマネージャー(GTM)で手動送信している際に、
page_viewイベントの「ページURL(page_location)」がUTMパラメータ抜きの値になってしまう設定ミスがあると、UTMは検出されません。また、GA4タグを非同期読み込みしている場合に、ページロード直後にユーザーがすぐ操作（例えばスクロール）を行うと、page_viewイベントより先に他のイベントが送られて順序が前後する可能性もゼロではありません。このように実装や発火順序の問題でpage_viewへのUTM付与がスキップされ、結果としてnullになった可能性があります。
以上のような理由が複合的に絡むことで、page_viewイベントにUTMパラメータが記録されない事象が発生し得ます。今回のケースでは特に「scrollイベントが直前に発生している」点がヒントとなります。次項では、そのscrollイベントとの関係に着目して原因を分析します。
scrollイベントではUTMパラメータが記録されているのにpage_viewではnullになる理由
ご提示の事象では、page_viewイベントの直前に発生したscrollイベントにはUTMパラメータ（source, medium, campaign）が記録されていたのに、続くpage_viewではそれらがnullになっていました。同一ページ上で連続して起こった2つのイベントで、UTM情報の有無が異なる理由として、主にイベント発生順序とセッションの扱いが影響していると考えられます。
今回、scrollとpage_viewは同じpage_location（URL）で発生しています。このことから、以下の2つのシナリオが推測されます。
シナリオ1: scrollイベントがセッション最初のイベントとしてUTMを取得 – 本来はpage_viewが最初のはずですが、何らかの理由でGA4がscrollイベントを先に認識・処理した可能性があります。GA4では最初のイベントに対してキャンペーンパラメータを付与するため
、もしscrollが先行するとそのイベントにutm_source/medium/campaignが割り当てられます
。その後に遅れてきたpage_viewイベントは、既にセッション内でキャンペーンが設定済みと見なされ、改めてパラメータを付与しなかった結果、event_params上ではnullになったと考えられます。この順序の逆転は通常起こりにくいものの、例えばページ読み込みと同時にscrollイベントが発火する特殊な状況（ページコンテンツが極端に短く初期表示で90%スクロールと判定された、あるいは実装上scrollトリガーが即時発火してしまった等）があれば理論上可能です。または、GA4の計測タグより先に別のスクリプトがイベントを送信した場合なども該当します。結果として、scrollイベントにはUTMが記録され、page_viewでは空になるという逆転現象が生じます。
シナリオ2: scrollイベントが前回セッションの終了間際に発生し、page_viewが新セッションとして記録 – 別の可能性として、scrollイベントとpage_viewイベントが異なるセッションに属していたケースです。例えばユーザーがそのページに到達した当初はUTM付きURLだったためscrollイベント（閲覧の途中で発生）にはキャンペーン情報が残っていたが、次のpage_viewイベント発生時には時間経過等でセッションが切れており、新規セッションとして扱われてUTMが引き継がれなかった、という流れです。この場合、scrollイベントは前のセッションの最後のユーザー行動としてUTM付きで記録され、一方page_viewは新しいセッション開始ですがURL自体は同じなので「直接流入」と見なされUTMパラメータが空になる可能性があります。例えば30分以上ユーザーが操作せずページを開いたまま放置し、再度動きがあったタイミングでpage_view相当のイベント（例えばSPAでの仮想ページビューなど）が記録されたような場合です。ただし通常のウェブページで自動収集されるpage_viewの場合、同じページに再訪問するにはリロード等が必要で、その際URLにUTMがついていればまた取得されるはずなので、このシナリオの可能性はやや低めです。
上記2つのうち、シナリオ1（イベント順序の逆転）が今回の状況に合致している可能性が高いと考えられます。すなわち、scrollイベントがpage_viewより先にセッション内で発生したためにキャンペーン情報がscroll側に付与され、page_viewイベントには付かなかったという理由です
。この結果、BigQuery上ではscrollイベントのevent_paramsにのみutmパラメータが残り、page_view側はnullになったと説明できます。
GA4のデータ収集はリアルタイム性やイベントドリブンの特性上、イベント発火のタイミング次第でキャンペーン属性の付与漏れが発生し得ます。今回のように「自動計測のscrollイベント」が予期せず先行してしまった場合、まさにそのような事態が起こりえます。いずれにせよ、scrollとpage_viewの矛盾はキャンペーンパラメータ付与タイミングのズレから生じたものと推定できます。
問題の回避方法・解決策
上記の原因分析を踏まえ、GA4でUTMパラメータが確実に記録されるようにするための対策をまとめます。
計測実装の見直し（イベント発火順序の調整）: GA4タグの実行順序を確認し、可能な限りpage_viewイベントがセッション内で最初に発生するようにします。もしGTMを用いている場合は、GA4のコンフィグタグ（またはページビュー送信タグ）をできるだけ早いタイミング（推奨: All Pagesトリガーでページ開加载時）で発火させます。他のカスタムイベントやトリガー（例: スクロール深度トリガーなど）がある場合、それらがページ読み込み直後に発火しないよう調整してください。特にscrollの自動計測はGA4設定ストリーム内で有効化/無効化できますが、通常90%スクロール時にしか発火しないとはいえ、ページ構造によっては読み込み直後に発火する可能性もあります。必要に応じて一時的にスクロール計測を無効化して問題が改善するか検証し、その上で実装を最適化しましょう。
UTMパラメータの付与ルールの徹底: キャンペーン用のURLに必ずutm_source, utm_medium, utm_campaignを含め、フォーマットを統一します。不足や誤字がないか事前に確認してください。すべてのUTM値は一貫して小文字で記載することで、同じキャンペーンが別表記で別トラフィックと認識されるのを防げます
。特にutm_mediumが抜けているとGA4側でキャンペーンと認識されないので注意が必要です
。「utm_」で始まるパラメータ以外はGA4では認識されないため、例えば
source=やcampaign=といった独自パラメータは使用しないでください（GA4エクスポートのevent_paramsにsource等が出力されるのは、GA4内部でutmパラメータを検出した場合のみです）。URLの形式と長さのチェック: UTMパラメータ付きURLが長すぎたり、特殊な構造になっていないか確認します。必要以上に長いクエリ文字列を避け、UTM以外の不要なパラメータは削除することが望ましいです。もしどうしてもURLが長くなる場合は、UTMパラメータが途中で切れたりしないか検証してください（実際にアクセスしてGA4のDebugViewやリアルタイムレポートで反映状況を見るとよいでしょう）。また、UTMパラメータは**「#」ではなく「?」以降**に配置し、ハッシュフラグメントの後ろに記述しないようにします
。
内部リンクでUTMを使用しない: サイト内のバナーや誘導リンクにはUTMパラメータを付与しない運用にします。内部リンクにUTMを付けてしまうと、GA4ではセッションは継続してもイベント単位で新しい流入元として扱われてしまい、正確なキャンペーン効果測定ができなくなります（最悪の場合、今回のようなキャンペーン情報の不整合を招きます）
。内部施策の計測には別途イベントタグやカスタムディメンションを活用するようにしてください。
GA4 DebugViewやレポートでの検証: 実装変更後は、GA4のDebugViewやリアルタイムレポートでUTMパラメータが期待通り記録されているか確認します。特にpage_viewイベントにおけるcampaign/source/mediumが正しく値を持つことをチェックしてください
。DebugViewでは各イベントのパラメータを詳細に確認できるため、scrollやpage_viewの順序やそれぞれのUTM付与状況をリアルタイムで追跡できます。不具合が再現する場合は、再度原因（タグの発火順やUTMの扱い）を突き止める手がかりになります。
データ側での補正（分析時の対処）: 万一、改善策を講じても一部のpage_viewでUTMが記録されないケースが発生する場合、BigQuery上でセッション単位に補完する方法も検討します。GA4のエクスポートデータでは各イベントに
session_idやuser_pseudo_idがありますので、同一セッション内の他イベント（例えば同セッション内のscrollやsession_startイベント）のUTM情報を用いてpage_viewイベントを補完するクエリを作成できます
。これは根本解決ではなく分析段階での救済措置ですが、過去データの整合性を取るには有効です。
以上の対策により、今回のようなpage_viewイベントでのUTMパラメータ欠損問題は回避・解決できる見込みです。特に重要なのは実装面で最初のページビュー計測とUTM取得が確実に行われるようにすること
です。また、マーケティング運用上もUTMタグ付けのルールを徹底し、GA4が情報を認識できる形でトラッキングすることが基本となります
。これらを遵守することで、GA4のBigQueryエクスポートデータにおいてもキャンペーン情報の欠損を防ぎ、正確な流入分析が可能になるでしょう。
参考文献・情報源: 本報告書の内容はGA4の公式ドキュメントおよびコミュニティフォーラムでの指摘、ならびに有志によるGA4分析ブログ等を参照してまとめています。
GA4では仕様変更や改善が継続的に行われているため、最新のアップデート情報にも注意を払いながら運用してください。
