GA4でreferralが計測できない？Referrer-Policyの影響とUTMで補う方法

外部サイトに紹介リンクを掲載してもらったのに、GA4のreferralにそのサイトが出てこない。メインサイトからサブドメインへの移動も、参照元／メディアで確認できない。そんなときは、GA4の設定とあわせて、リンク元のReferrer-Policyを確認してみてください。

リンク元が参照元情報を送らない設定になっていると、自社サイトへ訪問者が来ていても、どのサイトから来たのかを識別する材料が欠ける場合があります。外部サイトの設定は、自社では変更できないことも多いでしょう。

この記事では、Referrer-Policyの8種類とGA4への影響を整理し、参照元が渡らないときにUTMパラメーターで補えること、補えないことまで解説します。サブドメイン間の自己参照など、Referrer-Policyとは別の原因も分けて確認していきます。

外部サイト・サブドメインからのreferralが出ないときの切り分け

これらの移動がレポートに出てこないとき、次の2つを分けて調べます。

1. 移動先のページに、直前の参照元情報が届いていない
2. 参照元情報は届いているが、GA4では新しいreferralとして扱われていない

Referrer-Policyが直接関係するのは、主に1つ目の状態です。2つ目なら、GA4の自己参照の扱い、参照元除外、セッション、タグの構成などを確認する必要があります。

確認する項目も違います。直前のページを調べるのはdocument.referrerやGA4のpage_referrer、訪問の流入元を調べるのはセッションの参照元／メディアです。Googleの仕様では、page_referrerの既定値はdocument.referrerで、流入元の算出にも使われます。しかし、page_referrerの値がそのままセッションの参照元になるわけではありません。Googleのpage_referrer仕様も参照してください。

外部サイトから来たのに、referralとして見えない場合

提携先の記事から自社サイトへリンクがあるのに、その提携先がreferralに出ない場合もあります。リンク元がno-referrerやsame-originなら、通常の別オリジンへの移動では参照元を送りません。リンクにnoreferrerが付いている場合や、途中のリダイレクト、ブラウザー・アプリの制限も確認対象です。

参照元もキャンペーン情報も得られないことは、(direct) / (none)になる原因の一つです。ただし、参照元がないからアクセス自体が未計測とは限りません。まず移動先のpage_viewが記録されているかを確認します。GoogleのDirectトラフィックの説明も参考になります。

また、外部サイトからのアクセスがすべてReferralチャネルになるわけではありません。検索・SNS・広告などは別チャネルに分類されることがあります。Referralの行だけを見るのではなく、セッションの参照元／メディアと、確認しているチャネル定義をあわせて見てください。Googleのデフォルトチャネルグループの定義で確認できます。

同じドメインの仲間でも、同一オリジンではない

Referrer-Policyを読むときに大切なのは、ドメインの名前が似ているかではなく、オリジンが一致しているかです。オリジンは、スキーム・ホスト・ポートの組み合わせで決まります。

つまり、メインドメインからサブドメインへの移動も、その逆も、Referrer-Policyでは別オリジンへの移動として判定されます。サブドメイン同士でも同じです。

same-originのsameは、同じ運営会社や同じ親ドメインという意味ではありません。ここを取り違えると、サイト内の移動のつもりで参照元を止めてしまうことがあります。MDNの同一オリジンポリシーの解説で、オリジンの判定も確認できます。

Referrer-Policyの主な3種類を理解する

Referrer-Policyは、そのページからのリクエストに参照元情報をどこまで含めるかを決めます。HTTPレスポンスヘッダーやHTMLのmeta要素などで設定でき、リンク単位の設定もあります。まずは今回の切り分けで重要な3種類を押さえましょう。

1) no-referrer：参照元を送らない

同一オリジンか別オリジンかにかかわらず、参照元を送信しない設定です。メインドメインとサブドメインの間だけでなく、同一オリジン内の通常のページ移動でも参照元が渡りません。

2) same-origin：同一オリジンにだけ送る

同一オリジンへの移動では、ページパスやクエリを含む参照元URLを送ります。一方、別オリジンへは送りません。したがって、メインドメインとサブドメイン間の移動は送信しない側に入ります。

Referrer-Policy: same-origin

逆方向を調べる場合は、service.example.com側の設定を確認します。判断の出発点は、常にリンクをクリックした側のページです。

3) strict-origin-when-cross-origin：別オリジンにはオリジンだけ送る

同一オリジンにはパスやクエリを含むURLを送り、別のHTTPSオリジンにはオリジンだけを送ります。HTTPSからHTTPへ移動するときは送りません。

この場合、元サイトの識別に使える情報は残りますが、どのページから来たかやクエリの内容は分かりません。設定を変えて参照元が渡るようになっても、GA4のreferral表示まで保証されるわけではない点には注意してください。

これらの動作はW3CのReferrer-Policyの定義に基づきます。なお、参照元URLにはフラグメントなどが除かれるため、ここでいうURLはアドレスバーの文字列を無条件にすべて送るという意味ではありません。

残りの設定も含め、8種類の違いを比較する

Referrer-Policyには、上記以外にも設定値があります。HTTPSの一般的な公開サイトから移動する場合を、次の表に整理しました。

表のURLは、パスとクエリを含み、フラグメントなどを除いた参照元URLです。ブラウザーのプライバシー機能やリンク側の設定によって、さらに送信が制限される場合があります。

設定名は、残す情報と送信先の条件で読む

• ● origin：同一オリジンへの移動でも、パスとクエリを落とす
• ● strict-origin：originに加え、HTTPSからHTTPへの送信を止める
• ● origin-when-cross-origin：同一オリジンにはURL、別オリジンにはオリジンを送る。HTTPへの移動でもオリジンを送る点がstrict付きと異なる
• ● no-referrer-when-downgrade：HTTPSからHTTPへの送信は止めるが、別のHTTPSサイトには詳細なURLを渡す
• ● unsafe-url：HTTPへの移動も含め、パスとクエリを含むURLを送る

主要な現行ブラウザーでは、未指定時の既定値はstrict-origin-when-cross-originです。参照元を取得するためだけにunsafe-urlへ変えると、不要なURL情報まで外部へ渡すことになります。設定ごとの送信範囲はMDNのReferrer-Policy一覧、仕様の最新の検討状況はW3Cの編集者草案で確認できます。

GA4でreferralにならない、もう一つの理由

1) 参照元が届いても、自己参照として扱われることがある

GA4には自己参照を自動検出する仕組みがあります。Googleは、現在のページと同じドメインやそのサブドメインからの参照などを、新しい参照元として扱わないと説明しています。

そのため、page_referrerに元のサイトが入っているのに、セッションの参照元／メディアにexample.com / referralが出ないことはあり得ます。参照元除外リストが空でも、自動判定がある点は押さえておきましょう。手動の参照元除外やignore_referrerの設定も別途確認します。Googleの自己参照・除外する参照の説明が判断の基準になります。

2) 一続きの訪問なら、移動のたびに新しい流入元にはならない

メインサイトとサブドメインを一つのサービスとして計測している場合、見たいのは新規流入ではなく、その訪問中にどこへ移動したかという行動かもしれません。

Googleタグは既定でCookieを設定できる上位のドメインを使用します。両側で同じGA4の計測先を使い、Cookieなども適切に共有されていれば、移動前後を継続して測定できる構成があります。GoogleタグのCookie設定を確認してください。

一方、プロパティ・測定ID・Cookieのドメイン・同意状態が異なれば、同じ前提では判断できません。Cookieの範囲が異なるサブドメイン間の問題については、Googleのクロスドメイン測定の説明も参照します。サブドメインだから必ず追加設定が必要、または必ず不要、と決めつけないことが大切です。

Referrer-Policyが原因かを切り分ける確認手順

手順1：どちらからどちらへの移動かを書く

リンク元とリンク先のURL、確認しているGA4プロパティをメモします。両側を管理している場合は、それぞれの測定IDも記録します。往路と復路は分けて調べてください。設定が片方にしか入っていなければ、方向によって結果が変わる可能性があります。外部サイトからの流入なら、その外部サイトのリンク元ページが確認対象です。

手順2：リンク元の設定を確認する

開発者ツールのNetworkでリンク元ページのHTML文書を選び、レスポンスヘッダーのReferrer-Policyを確認します。あわせてHTMLのmeta要素、リンクのreferrerpolicy属性、rel属性にnoreferrerがないかも調べます。

noreferrerはリンク単位で参照元の送信を抑止します。HTTPヘッダーがstrict-origin-when-cross-originでも、リンクにこの指定があれば同じ結果になるとは限りません。MDNのnoreferrerの説明も参考になります。

手順3：実際にクリックして、移動先のdocument.referrerを見る

リンク元ページから対象リンクをクリックし、移動先の開発者ツールのConsoleでdocument.referrerを確認します。URLの直接入力や移動先だけの再読み込みでは、確認したいリンク移動を再現できません。

document.referrer

document.referrerは直前の参照元を表す値です。空だから特定の設定が原因、と単独で断定はできません。MDNのdocument.referrerの説明も参照してください。

手順4：GA4のpage_referrerとレポートを分けて確認する

デバッグモードを有効にし、移動先のpage_viewが届いているか、page_referrerに何が入っているかをDebugViewで確認します。イベントが届いていなければ、先にタグの発火や同意状態を調べます。GoogleのDebugViewの確認手順に沿って進めてください。

通信のHTTPヘッダーであるRefererと、GA4のイベントパラメーターであるpage_referrerも別物です。GA4への通信にRefererがないことだけで、page_referrerも空だとは判断しないでください。

手順5：安全な検証環境で、変更前後を同じ条件で比べる

管理しているリンク元にsame-originが設定されていて、別オリジンへの参照元送信が必要なら、セキュリティ要件を確認したうえでstrict-origin-when-cross-originなどを検討します。変更の比較では、同じブラウザー・同じリンク・同じ同意状態で、両方向のdocument.referrerとpage_referrerを記録します。

実務で脆弱性診断に対応した際も、診断書の設定例はsame-originでしたが、通常のHTTPS間でオリジン情報を残すためにstrict-origin-when-cross-originを採用したことがあります。ただし、この対応を、サブドメイン間のreferral表示が必ず復旧する方法として紹介することはできません。

サブドメインへの移動を測りたいときの考え方

目的がメインサイトから申込サイトへ何人進んだかを知ることなら、referralとして出すことだけにこだわる必要はありません。

• ● 両側を同じプロパティで測っているなら、ホスト名やページURLを区別して経路・ファネルを確認する
• ● 申込サイトへ進むリンクをクリックした回数なら、クリックイベントで測る
• ● 実際に申込サイトへ到達した数なら、移動先のページ表示や到達イベントも確認する

クリックと到達は別の行動です。別タブで開いた後に読み込みを中止する場合もあるため、どちらを成果として報告するかを先に決めます。イベントの整理にはボタンクリックをコンバージョンとして扱う範囲の考え方も参考にしてください。

GA4の拡張計測による離脱クリックに任せる場合も、クロスドメイン測定に設定したリンク先などは対象外になるため、対象リンクが実際に計測されるか確認します。詳しくはGoogleの離脱クリック計測の説明を参照してください。

同じサービス内の移動を識別するためだけに、内部リンクへ安易にUTMを付けるのは避けましょう。訪問を獲得した流入元と、訪問後のサイト内行動は分けて設計します。UTMの用途はUTMパラメータの意味・使い方・注意点で整理しています。

リンク元を直せないとき、UTMがあれば計測できる？

1) リファラーがなくても、UTMで流入元を識別できる場合がある

外部サイトのセキュリティ設定を変更してもらえなくても、掲載するリンク先URLを調整できるなら、UTMパラメーターが有効な選択肢になります。

Referrer-Policyが制御する参照元情報と、リンク先URLに付けるUTMは別の仕組みです。no-referrerだからUTMも自動的に消える、という関係ではありません。UTMが付いたURLで自社サイトへ到達し、GA4がその値を取得できれば、page_referrerが空でもキャンペーン情報として流入元を識別できます。GoogleのキャンペーンURLの説明も確認してください。

https://example.com/service/?utm_source=partner_site&utm_medium=referral&utm_campaign=partner_article

これは自動取得した参照元を復元するものではなく、あらかじめ決めた名前でリンク経由の流入を識別する方法です。UTM付きURLが別の場所へ転載・転送されても同じ値が残るため、実際にクリックされた掲載ページを証明する情報でもありません。

2) UTM付きなら必ずreferralに出る、とは限らない

utm_mediumは流入の実態に合わせます。メルマガならemail、有料広告なら広告の種類に合う値を使い、Referralの件数を増やすためにすべてreferralへ揃えることは避けましょう。チャネルは参照元やメディアなどのルールに沿って分類されます。

また、GA4は新しいキャンペーン情報を受け取っただけでは新しいセッションを開始しません。既存セッションの途中でUTM付きリンクから戻っても、そのセッションの参照元／メディアが必ずUTMの値へ切り替わるわけではありません。テストでは新しいブラウザープロファイルなどを使い、新規セッションでの流入と既存セッションでの再訪を分けます。Googleのキャンペーン・トラフィックソースの処理仕様が参考になります。

3) UTMを付けても補えないことがある

• ● GA4タグの不備などでイベント自体が送られていない
• ● リダイレクトやURLの書き換えで、GA4が読む前にUTMが消えている
• ● 同意状態やブラウザー・拡張機能の制限により、期待した形で計測できない
• ● 元の参照ページの完全なURLを知りたい
• ● 過去に取得できなかった流入元を復元したい

UTMは計測タグの代わりでも、同意やプライバシー設定を回避する仕組みでもありません。参照元が欠けているだけなのか、計測そのものに問題があるのかを先に見分けてください。

4) 自社でできる対応と、掲載先への依頼を分ける

1. 自社で配布・編集できるリンクなら、UTM付きURLを作成する
2. 外部の掲載記事なら、掲載先へリンク先URLの差し替えを依頼する
3. 実際の掲載リンクをクリックし、リダイレクト後もUTMが残るか確認する
4. DebugViewなどでイベントとpage_locationを確認し、その後のレポートで参照元／メディア・キャンペーンを見る

リンク元のポリシーが参照元を送らない場合、リンク先である自社のReferrer-Policyだけを変えても、相手から参照元を送らせることはできません。さらに、掲載URLの変更も依頼できず、参照元情報もない場合は、自社側のGA4だけで特定の外部サイトからの流入と確実に判別するのは困難です。

掲載先が専用のリンクを使えるなら、自社の専用URLを発行してUTM付きURLへ転送する方法も考えられます。ただし、これも専用URLを掲載してもらう必要があります。すでに到達した識別情報のないアクセスへ、後から推測でUTMを付けても正しい流入元の復元にはなりません。

パラメーターの使い分けはutm_source・utm_medium・utm_campaignの違いで整理しています。掲載先ごとのURL作成にはUTMパラメーター作成ツールを活用してください。名前は事前に揃え、個人情報や秘密の情報を含めないようにします。

まとめ：参照元の確認とUTMの活用を分けて考える

外部サイトやサブドメインからのreferralが見えないとき、リンク元のsame-originやno-referrerが参照元を渡さない原因になっている可能性があります。まずは移動先のdocument.referrerとGA4のpage_referrerを確認し、参照元がないのか、届いているのにreferralとして扱われていないのかを切り分けます。

外部サイトの設定を変えられなくても、UTM付きURLを掲載してもらえるなら、流入元を識別する方法になります。ただし、UTMの保持とGA4の計測が前提であり、元の参照URLや過去の欠損を復元するものではありません。同じサービス内の移動は、UTMで無理に流入扱いにせず、経路やクリック・到達イベントで確認しましょう。

原因を切り分けた後は、流入元や成果を同じ条件で継続して確認していきましょう。毎月の集計に時間がかかる場合は、InsightBaseのGA4・広告レポート作成機能で取得済みのデータを整理できます。まずはInsightBaseの無料登録から試してみてください。取得できなかった参照元情報を後から復元するものではありませんが、数字の変化を確認する作業に役立ちます。