cross-originでのdocument.refererとga:previousPagePath

この記事はGoogle Analytics 4ではなく、Universal Analyticsを対象としています。

目的

ディメンションとしての流入元について、ブラウザとGoogleAnalyticsの仕様を整理します。

※この記事では便宜上「直前のページ」を「流入元」として表現します。

前提: クロスオリジンのリファラー問題

Google Chromeではバージョン85からReferrer Policyが変更されており、デフォルトではクロスオリジンのリファラーはホスト名のみがセットされます。

※参考：Chrome85でWebサイトの流入元がとれない問題と対応方法

例えばexample.comからshop.example.comへの遷移で表すと以下のような形です。

計測ページ	遷移元	document.referer
https://shop.example.com	https://example.com/category	https://example.com

通常 document.referer には https://example.com/category がセットされると期待しますが、新しいポリシーでは https://example.com となります。手元の環境で確認したところ PC Chrome, Android Chromeが上記仕様に沿っていて、iOS 14.4 Safariではフルパスが設定されていました。

つまり「同一Google Analyticsプロパティ内でクロスオリジンの場合」や「外部(別ドメイン)流入」においての流入元計測の仕様理解が必要となっています。

※管理外のサイトからの流入に対しては対処する手立てはありません。

流入元を計測する方法

ページ単位で流入元を計測する場合には以下3つの選択肢があります。

1) システムディメンション

システムディメンションとして、前のページ遷移(ga:previousPagePath)が用意されています。

2) カスタムディメンション

document.refererの値をカスタムディメンションにセットします。GTMでセットする場合には組み込み変数にHTTP参照(HTTPリファラー)を利用します。前のページ遷移ディメンションではビューのフィルタが適用されてしまいますが、document.refererであればフルパスで計測することができます。

3) BigQueryで抽出 (GoogleAnalytics 360)

BigQueryテーブルから抽出する場合はシンプルで、直前のPAGEVIEWレコードを拾うだけです。分析関数であるLAG()を使うことで直前のレコードを抽出できます。

SELECT
  hits.page.pagePath as page_path,
  LAG(hits.page.pagePath) OVER (PARTITION BY fullVisitorId, visitId, date ORDER BY hits.hitNumber ASC) as previous_page
FROM
  `project_name.dataset_name.ga_sessions_YYYYMMDD`,
  UNNEST(hits) AS hits
WHERE
  hits.type = "PAGE"

システムディメンションはクロスオリジンの影響を受けるのか

クロスオリジンを考えた場合に、BigQueryはレコード単位で抽出しているので正確でありカスタムディメンションはdocument.refererの仕様に左右されるため不正確です。ではシステムディメンションはどのような挙動になるのでしょうか。 もしdocument.refererベースであれば不正確な値になっているはずです。

そこで複数ブラウザにて https://example.com/category から https://shop.example.com?rtest=true に遷移させる形で、システムディメンションとdocument.refererの値を比較して検証してみます。

1) ログの差異の確認

ページビュー発生時のMeasurement Protocolのパラメータの値を確認します。ChromeとSafariの差異をみる限り、drパラメータはdocument.refererの値をセットしているようにみえます。

Mac Chrome

dl: https://shop.example.com?rtest=true
dr: https://example.com/

iOS Safari

dl: https://shop.example.com?rtest=true
dr: https://example.com/category

実際にanalytics.jsのリファレンスを確認したところやはりdocument.refererとのことです。

ウェブサイトにトラフィックを送り込んだ参照ソースを指定します。この値はトラフィック ソースの算出にも使用され、値の形式は URL となります。このフィールドは create コマンドで初期化され、alwaysSendReferrer フィールドが true に設定されている場合を除き、現在のホスト名が参照 URL のホスト名と異なる場合にのみ設定されます。

フィールド名	プロトコル パラメータ	値の型	デフォルト値	最大文字数	対応するヒットタイプ
referrer	dr	テキスト	document.referrer	2,048 バイト	すべて

参考：analytics.jsのフィールドリファレンス  |  ウェブ向けアナリティクス（analytics.js）

2) GTMでリファラーをセット

システムディメンションとリファラーの値を比較するため、GTM経由でHTTP参照変数をカスタムディメンションにセットします。

3) カスタムレポートで抽出

rtestパラメーターが含まれるページビューにおいて、カスタムディメンションとシステムディメンションの値を比較してみます。

ブラウザ	カスタムディメンション(リファラー)	システムディメンション(前のページ遷移)
Chrome	https://example.com/	https://example.com/category
Safari	https://example.com/category	https://example.com/category

意外なことに前のページ遷移はリファラー制約の影響を受けていませんでした。おそらく、ページビューレコードベースで処理しており、drパラメーター(=document.referer)の値は参照していないものと思います。

まとめ

流入元集計について整理すると以下のような区分になると思います。

手段	メリット	デメリット
BigQuery (LAG関数)	同一ビュー内のクロスオリジン計測ができる。	計測ドメイン以外の値は取得できない
システムディメンション(previousPagePath)	同一プロパティ内のクロスオリジン計測ができる	計測ドメイン以外の値は取得できない。 ビューのフィルターの影響を受ける。BigQueryにエクスポートされないため、外部から利用する場合は CoreReportingAPI経由でpreviousPagePathを参照する必要がある。リンク押下でなく「ブックマーク遷移」でも前のページがカウントされる。
カスタムディメンション(document.referer)	計測ドメイン以外の値が取得できる(ブラウザ制約はあり)	同一プロパティ内のクロスオリジン計測ができない

軸が多くて悩むところではありますがまず最初に

• CoreReportingAPIを利用すべきか (ディメンション・フィルターを掛け合わせた場合の信頼性やAPI利用上限等)
• GoogleAnalytics360を契約してるか(BigQueryが利用できるか)

といった条件を最初に考えた上で、メリットデメリットでそれぞれを判断することになると思います。

おわりに

なんでこんな細かいことを検証しているかというと、DAUやMAUの変動の要因を探す場合にまず最初に流入元を分析する事が多いのです。ただ、参照元やメディアといったディメンションは直感的にもわかりにくい挙動のため「任意のサブドメイン・任意のディクトリにおける直前のページ」における数値変動を分析することが多い状況です。

というわけで普段からdocument.refererを活用していましたので、Chrome85の仕様変更もありGoogleAnalyticsの挙動も含めて今回整理してみました。