GTMのReferrerについて: GA4のpage_referrer・参照元 / メディアとの違い

GTMのReferrerとGA4のページの参照元 URLを整理する

GTMやGA4を触っていると、「Referrer」「page_referrer」「ページの参照元 URL」「参照元」「流入元」「参照元 / メディア」など、似た言葉が多く出てきます。

これらはどれも「どこから来たか」に関係しますが、同じものではありません。

GTMの Referrer は、ブラウザから見えている直前ページ情報をGTM内で参照するための変数です。一方、GA4の page_referrer は、GA4のディメンションである「ページの参照元 URL」に反映されるイベントパラメータです。さらに、GA4の セッションの参照元 / メディア や ユーザーの最初の参照元 / メディア は、ユーザーやセッションの流入元を表す別のディメンションです。

この記事では、まずこれらの用語の違いを整理したうえで、GTMの Referrer と document.referrer の関係、GA4の「ページの参照元 URL」との違い、Referrer-Policy、SPA、iframe、複数ドメインをまたぐ導線での注意点をまとめます。

特に、Referrer や「ページの参照元 URL」をGA4の流入元ディメンションの代わりに使わないこと、GTMの Referrer は主に条件判定やデバッグで使う値として捉えることを軸に整理します。

まず結論

GTMの Referrer は、現在のページに来る直前の参照元URLを返す変数です。Google公式ヘルプでも、Webコンテナの組み込み変数 Referrer は「現在のページの完全な参照元URL」を返すものとして説明されています。

この値の元になるのは、基本的にはブラウザが持っている document.referrer です。

document.referrer

一方、GA4の page_referrer や「ページの参照元 URL」は、GA4に送られるイベントパラメータ / ディメンションとして扱われます。こちらも多くの場合はブラウザのリファラー情報をもとにしますが、GA4のレポート上で見る セッションの参照元 / メディア や ユーザーの最初の参照元 / メディア とは別物です。

つまり、ざっくり分けるとこうです。

項目	何を表すか
GTMの Referrer	ブラウザが保持している直前ページのURL
GA4の page_referrer / ページの参照元 URL	GA4イベントに紐づく直前ページURL
GA4の セッションの参照元 / メディア	GA4のルールで決まるセッション単位の流入元

似ていますが、用途が違います。

用語の違いを先に整理する

この記事では似た言葉が何度も出てきます。先に、実務で混同しやすい用語を整理しておきます。

厳密な定義はツールや文脈によって少し変わりますが、GTMとGA4の計測設計では、次のように分けて考えると理解しやすくなります。

用語	主に指しているもの	代表例
リファラー	ブラウザが持っている直前ページ情報	document.referrer
Referrer	GTMなどの変数名としてのリファラー	GTM組み込み変数 Referrer
参照元	文脈によって意味が変わる日本語表現	前ページ、外部サイト、流入元など
ページの参照元 URL	GA4でページの直前URLを表すディメンション	page_referrer
流入元	ユーザーやセッションを獲得した元	google / organic、newsletter / email
参照元 / メディア	GA4が分類した流入元の内訳	参照元=google、メディア=organic

リファラー

リファラーは、ブラウザが扱う「直前ページ情報」です。

JavaScriptでは、次のように確認できます。

document.referrer

たとえば、ページAからページBへ通常のリンクで遷移した場合、ページBから見るとページAがリファラーになります。

ページA
↓
ページB

このときページBで document.referrer を見ると、ページAのURL、またはページAのオリジンが入ることがあります。

ここで大事なのは、リファラーは「そのページの直前にいた場所」であって、「ユーザーが最初にどこから来たか」ではないことです。

Google検索から流入したユーザーでも、サイト内を3ページ回遊した後であれば、現在ページのリファラーはGoogleではなく、自サイト内の直前ページになることがあります。

Referrer

Referrer は、GTMの組み込み変数名として出てくる表記です。

GTMの Referrer は、基本的にはブラウザのリファラー情報を参照します。つまり、通常のWebページで同じコンテキストを見ている場合、document.referrer と同じ値として確認できます。

ただし、GTM上では Referrer という英語の変数名で表示されるため、GA4の「ページの参照元 URL」や一般的な「参照元」と混同されやすいです。

この記事で Referrer と大文字始まりで書く場合は、原則としてGTMの組み込み変数を指します。一般概念としてのリファラーを指す場合は「リファラー」と書きます。

参照元

「参照元」は日本語として便利ですが、かなり曖昧な言葉です。

この記事でも、一般的な説明ではできるだけ「直前ページ」「流入元」「外部サイトのドメイン」のように具体的に書き分けます。一方、GA4のディメンション名として出てくる場合は「参照元」や「参照元 / メディア」と表記します。

会話の中では、次のような意味で使われることがあります。

• 直前に見ていたページ
• 外部から遷移してきたサイト
• 広告や検索などの流入チャネル
• GA4の「参照元」ディメンション
• レポート上の「参照元」

たとえば「参照元を見たい」と言われたとき、その人が知りたいものは次のどれかもしれません。

• 直前ページを知りたい
• 検索、広告、メールなどの流入チャネルを知りたい
• どの外部サイトから来たかを知りたい
• どのLPを経由したかを知りたい
• フォーム直前のページを知りたい

これらは似ていますが、使うデータが違います。

そのため、計測要件では「参照元を取る」とだけ書かずに、「セッションの流入元を見たいのか」「現在ページの直前ページを見たいのか」「外部サイトのドメインを見たいのか」まで分けて確認した方が安全です。

ページの参照元 URL

「ページの参照元 URL」は、GA4で page_referrer パラメータによって自動的に入力されるディメンションです。

GA4のイベントには、ページURLを表す page_location、ページタイトルを表す page_title、ページの参照元 URLを表す page_referrer などのパラメータがあります。

このうち page_referrer は、ページ単位の直前URLを送るためのイベントパラメータです。

page_location: 今見ているページ
page_referrer: そのページの参照元 URL

ページ単位で「このページの前にどこを見ていたか」を調べる用途に近いです。

一方で、GA4の集客レポートで見る セッションの参照元 / メディア とは別です。「ページの参照元 URL」が自サイト内の前ページになっていても、セッションの参照元 / メディア は google / organic のまま、ということは普通にあります。

流入元

「流入元」は、マーケティングやアクセス解析では、ユーザーやセッションを獲得した元を指すことが多いです。

たとえば、次のようなものです。

google / organic
google / cpc
newsletter / email
x.com / referral
(direct) / (none)

これは、現在ページの直前ページとは限りません。

たとえば、ユーザーがGoogle検索からサイトに来て、サイト内で複数ページを見た場合、現在ページのリファラーは自サイトの前ページになります。しかし、セッションの流入元はGoogle検索として維持されます。

Google検索
↓
/lp/
↓
/service/
↓
/contact/

/contact/ で見た場合、直前ページは /service/ です。しかし、このセッションの流入元はGoogle検索です。

この違いを混同すると、「フォーム到達の直前ページを知りたい」のか、「フォーム到達ユーザーの獲得チャネルを知りたい」のかが曖昧になります。

参照元 / メディア

GA4の 参照元 / メディア は、GA4が集客元を分類するためのディメンションです。

ここでの 参照元 は、一般的な「前に見ていたページ」という意味ではなく、GA4のディメンション名としての「参照元」です。

参照元 は「どこから」、メディア は「どの種類の経路で」と考えると分かりやすいです。

参照元	メディア	意味
google	organic	Googleの自然検索
google	cpc	Google広告などのクリック課金広告
newsletter	email	メールマガジン
example.com	referral	外部サイトからの参照
(direct)	(none)	直接流入として分類されることがあるアクセス

参照元 / メディア は、UTMパラメータ、広告連携、リファラー、GA4のセッション判定などをもとに決まります。

ただし、direct流入の場合は常に (direct) / (none) になるとは限りません。GA4では前回の非directの流入元がセッションの流入元として使われることがあります。この仕様は深掘りすると別テーマになるため、この記事では「directは例外がある」程度に留めます。

さらにGA4には、ユーザースコープの ユーザーの最初の参照元 / メディア、セッションスコープの セッションの参照元 / メディア とは別に、キーイベントのアトリビューションに紐づく接頭辞なしの 参照元 / メディア もあります。これはキーイベントへの貢献をどの流入元に割り当てるかを見るためのもので、通常のイベントでは (not set) になることがあります。

このあたりはGA4のスコープとアトリビューションの話になり、この記事の主題から外れます。ここでは「GA4の 参照元 / メディア には複数のスコープがあり、どの 参照元 / メディア を見ているかで意味が変わる」程度に押さえておきます。詳しくは別記事で扱います。

そのため、document.referrer やGTMの Referrer をそのまま 参照元 / メディア の代わりに使うことはできません。

この記事での使い分け

この記事では、以降の用語を次の意味で使います。

• Referrer: GTMの組み込み変数
• document.referrer: ブラウザのJavaScriptプロパティ
• リファラー: ブラウザが扱う直前ページ情報の一般名
• ページの参照元 URL / page_referrer: GA4でページ単位の直前URLを表す情報
• 流入元 / 参照元 / メディア: GA4がユーザー、セッション、キーイベントなどのスコープで分類した流入元情報

この前提で読むと、「GTMではReferrerに前ページが入っているのに、GA4の流入元はGoogleのまま」という状況も矛盾ではないと分かりやすくなります。

GTMのReferrerとは

GTMの組み込み変数 Referrer は、現在のページに対する参照元URLを返します。

たとえば、次のような遷移があったとします。

遷移	GTMの Referrer に入りうる値
Google検索からサイトへ流入	https://www.google.com/ など
サイトAからサイトBへ遷移	サイトAのURL、またはオリジン
同一サイト内でページAからページBへ遷移	ページAのURL
URL直打ち、ブックマーク、アプリ経由	空になることがある

GTM独自の流入元判定をしているわけではなく、ブラウザが渡せる参照元情報を見ているだけです。

そのため、GTMプレビューで Referrer を確認するときは、「GTMが何かを推測してくれている」のではなく、「そのページでブラウザから見えている参照元情報を表示している」と考える方が安全です。

document.referrerとの関係

document.referrer は、現在のページへ移動する直前にユーザーがいたページのURIを返すブラウザのプロパティです。

ブラウザの開発者ツールで次を実行すると、そのページで見えているリファラーを確認できます。

console.log(document.referrer);

通常のWebページで同じコンテキストを見ている場合、GTMの Referrer とブラウザコンソールの document.referrer は同じ値として確認できます。

ただし、ここで大事なのは「取れるはずの値が常に完全なURLで取れるわけではない」という点です。GTMの設定ミスではなく、ブラウザや遷移元サイトのポリシーによって制限されることがあります。

Referrer-Policyの影響

リファラー情報は、Referrer-Policy の影響を受けます。

ここで出てくる「オリジン」とは、URLのうち、基本的には次の3つを組み合わせた部分です。

スキーム + ホスト名 + ポート番号

たとえば、次のURLがあるとします。

https://www.example.com/article?id=123

この場合、オリジンは次の部分です。

https://www.example.com

パスである /article や、クエリである ?id=123 は含みません。

マーケティングの文脈では、「URL全体ではなく、ドメイン部分くらいまでしか分からない」と理解すると近いです。厳密にはドメインだけではなく、https か http かというスキームや、必要に応じてポート番号も含みます。

現在の主流ブラウザでは、明示的な Referrer-Policy が設定されていない場合のデフォルトが、概ね strict-origin-when-cross-origin になっています。Chrome、Firefox、Edgeではこのポリシーがデフォルトとして扱われ、Safariも細かな差はありますが、クロスサイトでリファラーを絞る方向の挙動になっています。

strict-origin-when-cross-origin は、リファラーとして送る情報量を、遷移先との関係に応じて変えるポリシーです。

Referrer-Policy: strict-origin-when-cross-origin

代表的には、次のように動きます。

遷移	送られうるリファラー
同一オリジンへの遷移	フルURL
HTTPSから別オリジンのHTTPSへ遷移	オリジンのみ
HTTPSからHTTPへの遷移	送られない

たとえば https://example.com/article?id=123 から外部サイトへ遷移した場合、外部サイト側では https://example.com/ までしか見えないことがあります。パスやクエリが必ず渡るとは限りません。

そのため、GTMの Referrer が空だったり、ドメインまでしか入っていなかったりしても、それだけで実装ミスとは判断できません。

ここで重要なのは、サーバー側で制御できる範囲には限界があることです。

自サイトから外部サイトへ送るリファラー量は、自サイトのレスポンスヘッダーや meta タグ、リンクごとの referrerpolicy 属性である程度制御できます。しかし、外部サイトから自サイトへ来るときに、相手サイトやブラウザが送ってこなかったリファラーを、自サイトのサーバー側で後から増やすことはできません。

つまり、分析上「外部サイトの参照元URLをパスやクエリまで取りたい」と思っても、受け取り側の開発だけで解決できる問題ではありません。

また、計測のために unsafe-url や no-referrer-when-downgrade のような緩いポリシーへ変更する依頼は慎重に扱うべきです。URLのパスやクエリには、検索語、会員ID、メールアドレス、キャンペーン識別子、申込内容など、ユーザーにとって漏れてほしくない情報が含まれることがあります。それを外部ドメインへ送る設定は、セキュリティやプライバシーの観点で好ましくありません。

参照元URLの細かいパスを無理に取ろうとするより、広告やメールではUTMパラメータを付ける、外部媒体ごとにLPを分ける、フォーム遷移前の内部導線は自サイト内でイベントとして記録する、といった計測設計で補う方が安全です。

GA4のページの参照元 URLとの違い

GA4では、page_referrer というイベントパラメータによって入力される「ページの参照元 URL」というディメンションで、直前ページのURLを扱います。

これは「ページの参照元 URL」を見るための情報です。内部導線の確認や、特定ページの直前にどのページを見ていたかを調べるときに役立ちます。

ただし、GA4の セッションの参照元 / メディア とは意味が違います。

状況	通常ページでの GTM Referrer / GA4 ページの参照元 URL	GA4 セッションの参照元 / メディア
Google検索で流入した直後	GoogleのURLやオリジン	google / organic
その後、サイト内でページ遷移	自サイトの前ページURL	セッションの流入元として google / organic が維持される
セッション中に外部認証ドメインから戻る	外部認証ドメインが入ることがある	セッション開始時の流入元が維持される
直接流入	空になることがある	(direct) / (none)、または前回の非direct流入元になることがある

つまり、Referrer や「ページの参照元 URL」は「直前ページ」、セッションの参照元 / メディア は「GA4がセッションに対して決めた流入元」です。

ここを混同して、GTMの Referrer をそのまま「GA4の流入元」として扱うと、分析結果がずれます。

「Referrer = 流入元」ではない

実務で一番多い誤解はこれです。

Referrer は、あくまで直前ページです。流入元チャネルやセッションの獲得元とは限りません。

たとえば、ユーザーがGoogle検索からサイトに来て、以下のように回遊したとします。

Google検索
↓
/lp/
↓
/form/
↓
/thanks/

このとき、分析画面で見るならGA4の「ページの参照元 URL」を確認します。/thanks/ の「ページの参照元 URL」には、多くの場合 /form/ が入ります。

しかし、GA4のセッション流入元は google / organic のままです。

このとき、「ページの参照元 URL」を見て「流入元はフォームページだ」と考えると、意味がずれます。フォームページは直前ページであって、セッションの獲得元ではありません。

GTMの Referrer は、GTMプレビューで「そのページ上ではどのリファラー値が見えているか」を確認するための値だと考えると整理しやすいです。

複数ドメインをまたぐ導線との関係

決済、予約、会員登録、ログイン認証などでは、ユーザーが複数のドメインをまたいで移動することがあります。

たとえば、次のような導線です。

www.example.com
↓
auth-service.example
↓
www.example.com/mypage/

この場合、www.example.com/mypage/ でGTMの Referrer を確認すると、直前ページとして https://auth-service.example/ が見えることがあります。GA4の「ページの参照元 URL」でも、同じように外部認証ドメインが入ることがあります。

一方で、GA4の セッションの参照元 / メディア は、セッション単位の流入元です。GA4では、セッションの途中で外部ドメインから戻ってきたとしても、その時点で セッションの参照元 / メディア が外部ドメインに上書きされるわけではありません。

つまり、次のような状態は普通に起こります。

GTMのReferrer: https://auth-service.example/
GA4のページの参照元 URL: https://auth-service.example/ になることがある
GA4のセッションの参照元 / メディア: セッション開始時の流入元が維持される

これは矛盾ではありません。Referrer や「ページの参照元 URL」は「直前ページ」を見ていて、セッションの参照元 / メディア は「セッションの流入元」を見ているためです。

複数ドメインをまたぐ導線では、ドメインの性質によって確認すべきGA4設定が変わります。

自社で管理している別ドメインで、同じGA4計測の対象にできる場合は、クロスドメイン計測を検討します。たとえば、www.example.com と shop.example.com のように、どちらにも自社でタグを設置できるケースです。

一方、外部認証サービスや外部決済サービスのように、自社のGA4タグを設置できない外部ドメインでは、クロスドメイン計測ではなく、不要な参照の除外を検討します。不要な参照の除外をしておかないと、認証ドメインや決済ドメインが流入元として残り、その後のdirect流入でも前回の非direct流入元として参照されてしまうことがあります。

ただし、クロスドメイン計測も不要な参照の除外も、GTMの Referrer の値そのものを消したり、別の値に書き換えたりするものではありません。GTMプレビューで Referrer に外部ドメインが表示されていても、それだけでGA4の流入元がその外部ドメインになる、という意味ではありません。

SPAでの注意点

SPAでは、Referrer が期待通りに更新されないことがあります。

通常のページ遷移では、ページAからページBへ移動するとブラウザのナビゲーションが発生します。

/page-a/
↓
/page-b/

しかしSPAでは、history.pushState() などでURLだけを変更し、ページ全体を再読み込みしないことがあります。

この場合、document.referrer は「前の仮想ページ」には更新されません。最初にそのSPAへ入ってきたときの参照元が残ったり、期待した内部遷移元が取れなかったりします。

SPAで「直前の画面」を計測したい場合は、Referrer だけに頼らず、次のような設計を検討します。

• 画面遷移時に dataLayer へ前画面のパスを送る
• History Changeトリガーを使う
• 仮想ページビューの送信時に前ページ情報をイベントパラメータとして付与する
• セッションストレージなどで前回の仮想ページを保持する

SPAの「前ページ」は、ブラウザの document.referrer ではなく、サイト側の実装で管理する値として設計した方が安定します。

ただし、これは「GA4に送る page_referrer を更新できない」という意味ではありません。

document.referrer 自体はブラウザの値なので、SPA内の仮想ページ遷移に合わせて書き換えることはできません。一方で、GA4へ送信する page_referrer は、GTMやgtag.js側で明示的に指定できます。

gtag.jsで仮想ページビューを送る場合は、たとえば次のように page_referrer を指定できます。

gtag('event', 'page_view', {
  page_location: 'https://www.example.com/page-b/',
  page_referrer: 'https://www.example.com/page-a/'
});

GTMで送る場合も考え方は同じです。サイト側の実装で前画面のURLやパスを dataLayer に渡し、GA4イベントタグのイベントパラメータとして page_referrer にセットします。

dataLayer.push({
  event: 'virtual_page_view',
  page_location: 'https://www.example.com/page-b/',
  page_referrer: 'https://www.example.com/page-a/'
});

GTM側では、page_location と page_referrer をデータレイヤー変数として作成し、GA4イベントタグのパラメータに設定します。

イベント名: page_view
イベントパラメータ:
  page_location = {{データレイヤー変数 - page_location}}
  page_referrer = {{データレイヤー変数 - page_referrer}}

つまりSPAでは、GTMの Referrer に前画面が自動で入ることを期待するのではなく、サイト側の実装で前画面を管理し、その値をGA4の page_referrer として送る設計にするのが現実的です。

iframe内でGTMが動いている場合の注意点

GTMが通常のページではなく、iframe内のページで動いている場合も注意が必要です。

たとえば、次のように親ページの中にフォームや予約画面がiframeで埋め込まれているケースです。

<iframe src="https://form.example.com/contact/"></iframe>

このとき、iframe内で実行されるGTMの Referrer は、親ページ側の document.referrer とは別の文脈で評価されます。

MDNの説明では、iframe内の document.referrer は、同一オリジンでは親ウィンドウのURL、クロスオリジンではデフォルトで親ウィンドウのオリジンになるとされています。

つまり、次のような違いが起こります。

確認している場所	document.referrer / GTM Referrer の見え方
親ページ	親ページ自体に来る前の参照元
iframe内ページ	iframeを埋め込んでいる親ページ、または親ページのオリジン

たとえば、ユーザーがGoogle検索から https://www.example.com/lp/ に来て、そのページ内に https://form.example.com/contact/ のiframeがある場合を考えます。

Google検索
↓
https://www.example.com/lp/
  └ iframe: https://form.example.com/contact/

この場合、親ページ側では document.referrer がGoogleになることがあります。一方、iframe内で動くGTMの Referrer は、https://www.example.com/lp/ または https://www.example.com/ のように、親ページを指す値になることがあります。

これはGTMの値がおかしいのではなく、GTMがiframe内のドキュメントで実行されているためです。

そのため、iframe内で計測する場合は、次の点を確認しておくと安全です。

• GTMコンテナが親ページ側で動いているのか、iframe内ページ側で動いているのか
• 親ページの参照元を見たいのか、iframeの埋め込み元を見たいのか
• クロスオリジンiframeでパスまで必要なのか、オリジンだけで足りるのか
• 必要であれば、親ページからiframe側へURL情報を渡す設計にできるか

iframe内の Referrer は、「ユーザーがサイトに来る前の流入元」ではなく、「iframe内ページから見た参照元」になりやすいです。埋め込みフォームや外部予約ツールを計測するときは、この違いを前提にデバッグする必要があります。

GTM変数 Referrerの実務での使いどころ

GTMの Referrer は、GA4の分析レポートで直接見るための変数ではありません。

GTM上でタグを発火するかどうかを判定したり、GA4へ値を送る前に現在ページで見えているリファラーを確認したりするための変数です。

つまり、主な使いどころは「分析」そのものではなく、タグ実装上の条件分岐やデバッグです。

タグの発火条件に使う

たとえば、特定の前ページから来た場合だけタグを発火したいときに使えます。

Referrer "次を含む" /campaign/

ただし、これは主に自サイト内の前ページを条件にする場合に向いています。外部サイトのパスやクエリを条件にするのは不安定です。Referrer-Policyによって、外部サイトからの遷移ではオリジンまでしか取れないことがあるためです。

例外的な導線を除外する

特定のページから来た場合はタグを発火しない、という除外条件にも使えます。

たとえば、確認画面から入力画面へ戻ったときに、フォーム開始イベントを再度送らないようにするケースです。

Page Path "等しい" /form/
Referrer "次を含まない" /confirm/

このような使い方では、Referrer は「ユーザーの流入元」を見るためではなく、「今の画面にどういう直前導線で到達したか」を判定するために使います。

タグの値を出し分ける

タグの発火有無だけでなく、送信する値の出し分けに使うこともあります。

たとえば、同じ完了ページでも、直前ページが資料請求フォームなのか、問い合わせフォームなのかでイベント名やパラメータを変えたい場合です。

Referrer "が次を含むとき" /download-form/ -> generate_lead
Referrer "が次を含むとき" /contact-form/  -> contact

ただし、この設計はURL構造に強く依存します。フォームの種類を判定したいだけなら、可能であればフォーム側で form_type などの明示的な値を dataLayer に出す方が安定します。

計測前のデバッグに使う

gtm_referrer

GTMプレビューで Referrer を見ると、そのページ上でGTMから見えているリファラーを確認できます。

GA4の「ページの参照元 URL」が想定と違う場合、まずGTMプレビューで Referrer を確認すると、次の切り分けがしやすくなります。

• ブラウザ上ですでにリファラーが空なのか
• GTMでは見えているが、GA4タグへ渡せていないのか
• SPAやiframeの影響で、期待している前ページとは違う文脈を見ているのか
• Referrer-Policyやリダイレクトで値が制限されているのか

この意味で、GTMの Referrer は分析用の最終データというより、タグ実装時の確認材料として役立ちます。

GA4のページの参照元 URLの実務での使いどころ

GA4で「直前ページを分析したい」場合は、多くの場合、GTMの Referrer をカスタムパラメータとして送るよりも、標準の「ページの参照元 URL」を見る方が自然です。

page_referrer は、GA4の「ページの参照元 URL」に反映されるイベントパラメータです。ページビューだけでなく、フォーム送信、クリック、完了イベントなどと組み合わせて見ることで、「そのイベントが発生したページの直前に何を見ていたか」を確認できます。

フォーム到達前のページを見る

複数のページから同じフォームへ遷移する場合、フォームページや完了ページのイベントに紐づく「ページの参照元 URL」を見ると、どのページから来たかを確認できます。

/service-a/ -> /contact/
/service-b/ -> /contact/

このようなケースでは、/contact/ のページビューやフォーム送信イベントの「ページの参照元 URL」に /service-a/ や /service-b/ が入ります。

ここで見ているのは「セッションの流入元」ではなく「フォーム到達直前のページ」です。セッションの参照元 / メディア とは別の軸として使います。

完了イベントの直前ページを見る

問い合わせ完了、購入完了、資料請求完了などのイベントでも、「ページの参照元 URL」は有効です。

/contact/
↓
/thanks/

この場合、完了ページのページビューや完了イベントに紐づく「ページの参照元 URL」には、多くの場合 /contact/ が入ります。

完了ページに直接アクセスされていないか、想定外のページから完了ページへ到達していないかを確認する補助情報になります。

内部導線のざっくりした確認に使う

「ページの参照元 URL」は、ページ単位の内部導線を確認する用途にも使えます。

たとえば、料金ページを見たユーザーが、その直後に問い合わせページへ進んでいるか、記事ページから資料請求ページへ進んでいるか、といった確認です。

ただし、「ページの参照元 URL」はあくまで直前ページです。複数ページをまたいだ経路全体を見たい場合は、探索レポートの経路データやBigQueryエクスポートなど、別の見方が必要になります。

デバッグ時の見方

GTMプレビューやGA4 DebugViewでリファラーを見るときは、次の順で切り分けると整理しやすいです。

1. ブラウザコンソールで document.referrer を確認する
2. GTMプレビューで Referrer を確認する
3. GA4に送っているイベントパラメータを確認する
4. GA4の「ページの参照元 URL」と セッションの参照元 / メディア を分けて見る
5. Referrer-Policy、リダイレクト、クロスドメイン設定、不要な参照の除外を確認する

GTMで見える値とGA4の流入元レポートが違う場合、まず「直前ページ」と「セッション流入元」を同じものとして見ていないかを疑うのが近道です。

よくある落とし穴

Referrer が空なのでGTMの設定ミスだと思う

直接アクセス、ブックマーク、アプリ内ブラウザ、メールアプリ、プライバシー系ブラウザ拡張、rel="noreferrer"、Referrer-Policyなどで空になることがあります。

外部サイトのフルURLが取れる前提で条件を作る

現在のブラウザ仕様では、外部サイトからの遷移でパスやクエリまで取れるとは限りません。外部サイトを条件にするなら、基本はホスト名やオリジンまでに留める方が安全です。

SPAで前画面が取れると思い込む

SPAの画面遷移はブラウザの通常ナビゲーションではないことがあります。前画面を取りたいなら、サイト側の実装で前画面情報を dataLayer に出す設計が必要です。

iframe内でも親ページと同じ値になると思い込む

iframe内でGTMが動いている場合、Referrer はiframe内ページから見た参照元になります。親ページの流入元をそのまま見ているわけではありません。

GA4の流入元と比較して「値が違う」と判断する

GTMの Referrer とGA4の セッションの参照元 / メディア は同じ定義ではありません。比較するなら、GA4の「ページの参照元 URL」や送信イベントのパラメータと見比べる必要があります。

まとめ

GTMの Referrer は、ブラウザが持つ直前ページ情報を参照する変数です。

GA4の「ページの参照元 URL」も近い文脈で使われますが、GA4の セッションの参照元 / メディア や ユーザーの最初の参照元 / メディア とは意味が違います。また、GA4にはキーイベントのアトリビューションに紐づく接頭辞なしの 参照元 / メディア もあります。

この記事では主に セッションの参照元 / メディア を例にしてきましたが、いずれにしても Referrer や「ページの参照元 URL」をGA4の流入元ディメンションの代わりとして扱うのは避けた方が安全です。

実務では、次のように整理しておくと迷いにくくなります。

• Referrer はGTMで直前ページを確認したり、条件判定に使ったりするもの
• page_referrer は「ページの参照元 URL」に反映されるイベントパラメータ
• セッションの参照元 / メディア はGA4が決めたセッションの流入元を見るもの
• GA4の 参照元 / メディア はスコープによって意味が変わる
• 外部サイトのフルURLが必ず取れるとは考えない
• SPAでは前画面情報をサイト側の実装で管理する
• iframe内では親ページではなく、iframe内ページから見た参照元になる
• クロスドメインや不要な参照の除外は、GTMの値そのものを書き換えるものではない

Referrer は便利ですが、流入元判定の代用品ではありません。

「ブラウザから見えている直前ページ情報」として扱うと、GTMとGA4の見え方の違いを説明しやすくなります。

参考

• Google タグマネージャー ヘルプ: Built-in variables for web containers
• Google タグマネージャー ヘルプ: User-defined variable types for web
• MDN: Document.referrer
• MDN: Referrer-Policy header
• Chrome for Developers: A new default Referrer-Policy for Chrome
• web.dev: Referer and Referrer-Policy best practices
• Google Analytics ヘルプ: トラフィック ソース ディメンションのスコープ
• Google Analytics ヘルプ: トラフィック ソースのディメンションについて
• Google Analytics ヘルプ: キャンペーンとトラフィック ソース
• Google Analytics ヘルプ: アナリティクスのディメンションと指標
• Google Analytics ヘルプ: 拡張計測機能イベント
• Google Analytics ヘルプ: 自動収集イベント
• Google Analytics ヘルプ: 除外する参照を設定する
• Google Analytics ヘルプ: レポートに表示される「(not set)」という値の意味