本コラムでは、Google タグマネージャー（以下、GTM）のサーバーサイド版であるサーバーサイドGTM（以下、sGTM）を活用したCookie延命の仕組みについて解説していきます。
サーバーサイドGTMの概要については弊社の以下コラムをご参照ください。
sGTMを知らない方にも伝わるよう順を追って解説していきますので、ぜひ最後までお付き合いください。
ITPとは何か、なぜデータ計測に影響するのか
ITPとは何か
ITP（Intelligent Tracking Prevention）とは、AppleのSafariブラウザに搭載されたプライバシー保護機能です。 ユーザーの行動がウェブサイトをまたいで追跡されることを防ぐために設計されており、2017年の登場以来、継続的に強化されてきました。
日本国内ではiPhoneユーザーが多く、スマートフォンにおけるブラウザシェアは全体の40%を超えています。
参考）https://gs.statcounter.com/browser-market-share/desktop/japan/2024
また、意外と知られていない点として、AppleのWebKitエンジンで構築されたブラウザはすべてITPの影響を受けます。
iOS上ではChromeやFirefoxを含むほぼすべてのブラウザがWebKitエンジンを使用しているため、実質的にiPhoneユーザーのほぼ全員がITPの影響を受けることになります。
JavaScriptで発行したCookieは最短1日で消えてしまう
ITP 2.1（2019年リリース）以降、JavaScriptで発行したCookieの有効期限は最大7日に制限されるようになりました。
さらに、以下の条件を満たした場合、有効期限がさらに最短1日にまで短縮されてしまいます。
- ITPにトラッカーとして分類されたドメインからのウェブサイト訪問
- URLにクエリパラメータやフラグメントが含まれている
例えばGoogle 広告のクリックURLにはgclid、Meta広告にはfbclidというパラメータが付与されるため、広告経由のアクセスはまさにこのパターンに該当し、これらの広告からの流入はいずれも1日制限の対象となります。
しかも、この1日制限の対象は広告のCookieだけではありません。そのページ上でJavaScriptによって発行されるすべてのCookieが影響を受けます。
Cookieの寿命が短くなると計測にどう影響するか
主に以下の2つが、データ計測への大きな影響として挙げられます。
同じユーザーが「新規」として計上されてしまう
例えば、Google アナリティクス（以下、GA）では、Cookieによってユーザーを識別しています。
そのため、ITPの影響でこのCookieが削除されると、再訪問したユーザーであってもCookieが存在しないため、GAは「新規ユーザー」と判断してしまいます。その結果、GAのレポートでは新規ユーザー数が実態よりも多く計上されている可能性があります。
コンバージョンの成果が正しく計測できなくなる
Cookieの有効期限が短くなることで、コンバージョンの計測にも影響が出ます。たとえば次のようなケースです。
- 広告をクリックしてウェブサイトに訪問
- 広告タグがCookieを生成（しかし、ITPの影響で有効期限は1日に短縮される）
- その訪問ではコンバージョンせず、離脱
- 2日後に再訪問してコンバージョン
このケースでは、初回訪問で生成された広告用のCookieが1日以上経過しています。
そのため、再訪問時にはCookieが削除されており、広告クリックとコンバージョンが紐づかなくなります。その結果、計測されるコンバージョン数が実態より少なくなり、広告効果を正しく評価できなくなってしまいます。
sGTMがCookieを延命できる理由
CookieはJavaScriptとサーバーの2通りの方法で発行できる
前のセクションでは「JavaScriptで発行したCookieはITPの制限を受ける」と説明しました。ここでまず押さえておきたいのは、CookieはJavaScript以外の方法でも発行できるという点です。Cookieの発行方法には、大きく2つあります。
1つ目は、JavaScriptによる発行です。ブラウザ上で動作するJavaScriptがCookieを書き込みます。広告やアクセス解析などのサービスのCookieは、通常この方法で発行されます。
2つ目は、サーバーによる発行です。ウェブサイトのサーバーがHTTPレスポンスに Set-Cookie ヘッダーを付けて返すことで、ブラウザにCookieを保存させる方法です。
前のセクションで説明したとおり、ITPはJavaScriptで発行したCookieの有効期限を制限しています。一方で、サーバーが発行したCookieであれば、この制限を緩和することができます。
ここで登場するのがsGTMです。
sGTMを使ってサーバー側からCookieを発行することで、Cookieの有効期限を改善できます。
ただし、サーバーから発行すればすべて解決というわけではなく、発行方法によって有効期限がどこまで延びるかが変わってきます。
ITPのサーバーCookieへの影響
ITPはサーバーから発行したCookieに対しても、以下のいずれかの条件を満たした場合、有効期限を7日間に制限します。
- ウェブサイトのサーバーとsGTMのサーバーのIPアドレス範囲が異なる場合
- sGTMのサーバーのドメインを、CNAMEレコードを使って設定している場合
sGTMは通常、ウェブサイトとは別のサブドメイン上に設置します。
例えば、ウェブサイトがwww.example.comの場合、sGTMはsgtm.example.comのように、example.com配下の別のサブドメインとして設置します。
ウェブサイトのサーバーとsGTMのサーバーは別の環境で構築されることがほとんどで、IPアドレス範囲も異なります。そのため、多くのsGTM構成ではこの7日間制限が適用されます。
本コラムのメインテーマはここからです。
ITPの7日制限を受けない構成にできる2つのアプローチを、次のセクションで見ていきましょう。
ITPの7日制限を受けない構成にする2つのアプローチ
同一オリジン アプローチ
前のセクションで見たとおり、sGTMをサブドメインに設置した場合、ウェブサイトとsGTMのIPアドレス範囲が異なるため、ITPがCookieの有効期限を7日間に制限してしまいます。同一オリジン アプローチは、この制限を受けない構成にする方法です。
その仕組みを理解するために、まず「オリジン」について簡単に説明します。オリジンとは、URLのhttps://www.example.comの部分を指します。この部分が一致していれば「同一オリジン」、異なっていれば「別のオリジン」です。
※厳密にはもう少し細かい条件がありますが、ここでは割愛します。
たとえば、以下のふたつのURLはパス部分は異なりますが、ドメイン以下が同じため、同一オリジンです。
- https://www.example.com/page/
- https://www.example.com/sgtm/
一方、以下のふたつのURLは、ドメイン部分が異なるため、同一オリジンではありません。
- https://www.example.com/page/
- https://sgtm.example.com/sgtm/
同一オリジン アプローチでは、ウェブサイトと同じオリジン上にsGTM用の専用パスを用意し、そこへのデータ送信をsGTMに転送する仕組みを構築します。
具体的な設定内容はインフラ構成によって異なるため、ここでは仕組みの概要に絞って説明します。
たとえば、ウェブサイトがwww.example.com、sGTMがsgtm.example.comで構成されており、sGTM専用のパスを/sgtm/とした場合、次のような流れになります。
- sGTM専用のパス（
https://www.example.com/sgtm/）にデータ送信をする - CDN（CloudflareやAWS CloudFrontなど）またはロードバランサーが
sgtm.example.comに転送する - データの処理はsGTM（
sgtm.example.com）側で行われるが、ブラウザからはwww.example.comと通信しているように見える
ブラウザから見ると、すべてのやり取りがwww.example.comとの通信になります。これにより、ウェブサイトとIPアドレス範囲が異なるサーバーとはみなされず、ITPの7日間制限の対象になりません。
Stape Cookie Keeper
Stape Cookie Keeperは、sGTMのマネージドホスティングサービスであるStapeが提供する機能です。Stapeについては以下の弊社コラムご参照ください。
このアプローチの特徴は、「ITPによるCookieの削除を防ぐ」のではなく、「削除されたCookieを復元する」という点にあります。
Cookie Keeperの仕組みを理解するうえで鍵となるのが「マスターCookie」です。マスターCookieとは、サイト運営者が自身のウェブサーバーから発行するCookieです。ウェブサーバーから発行しているため、同一オリジンとなり、ITPの影響を受けません。
Stapeが自動的に用意してくれるものではなく、自分たちでCookieを発行する必要がありますが、実装の要件は比較的シンプルで難易度は低めです。
Cookie Keeperは、マスターCookieを使って計測用Cookieの値をStapeのサーバー側に記録しておき、ITPによって削除された後に復元するという方法をとります。
具体的には、以下の3ステップで動作します。
- マスターCookieの発行：
ユーザーがウェブサイトにアクセスすると、ウェブサーバーがマスターCookieを発行します。ウェブサイトと同一オリジンのサーバーから発行されるため、ITPによる有効期限の短縮を受けにくく、長期間保持されます。 - Cookie情報の記録と紐づけ：
ブラウザがsGTMサーバーにデータを送信する際、マスターCookieと一緒にGAなどの計測用Cookieの値も送られます。Stapeサーバーは、マスターCookieをキーとしてこれらの値を紐づけて保存します。 - Cookieの復元：
ITPによって計測用Cookieが削除された後にユーザーが再訪問すると、ブラウザにはマスターCookieだけが残っている状態です。Cookie KeeperはマスターCookieをもとに保存済みの値を照合し、削除されたCookieを復元します。
以上のステップを経て、Cookieが復元されます。ユーザーから見ると、まるでCookieが消えていなかったかのように動作します。
なお、Cookie Keeperを利用するには、同じくStapeのCustom Loaderという機能を使う必要があります。Custom Loaderについては別途コラムを作成予定ですので、少々お待ちください。
どちらのアプローチを選ぶか
ここまで、同一オリジン アプローチとStape Cookie Keeperの2つの方法を見てきました。それぞれの導入要件と注意点を整理してみましょう。
同一オリジン アプローチの場合
ウェブサイトにCDNやロードバランサーが導入されていることが前提になります。そのうえで、sGTM向けのパスルーティングをネットワーク・インフラ層で設定する必要があるため、技術的なハードルは高めです。
さらに、複数のサブドメインでsGTM計測を行いたい場合は注意が必要です。サブドメインごとにCDNの構成が異なるケースは珍しくありません。たとえば、aaa.example.comはCloudflareで構築しているため同一オリジンの設定が可能でも、同じく計測対象のbbb.example.comではCloudflareを使っていないため同じ方法が使えない、といった状況が起こりえます。
こうしたサブドメインやディレクトリごとの構成の違いを把握し、整理していく作業自体も導入のハードルになります。
Stape Cookie Keeperの場合
sGTMのホスティング先としてStapeを利用していることが前提になります。
Cookie Keeperではインフラ層の変更は不要です。その代わりに、ウェブサイトに設置しているGTMコンテナスニペットを、StapeのCustom Loader対応版に書き換える必要があります。Cookie Keeperの機能はこのCustom Loaderを通じて動作するためです。そのため、GTMコンテナスニペットの書き換えが難しい環境では導入できない点に注意が必要です。
Custom Loaderについて詳しくは、Stapeの公式ヘルプを参照してください。
まとめ
本コラムでは、SafariのITPがCookieの有効期限を制限する仕組みと、sGTMを活用してその制限を緩和する方法を見てきました。
JavaScriptで発行されたCookieは、ITPによって最大7日間、広告経由の流入では最短1日にまで有効期限が短縮されます。その結果、同じユーザーが新規として計上されたり、広告のコンバージョンが正しく計測できなくなるといった影響が出ます。
sGTMを導入してサーバーからCookieを発行するだけでも、有効期限の下限は1日から7日間へと改善されます。さらに、同一オリジン アプローチやStape Cookie Keeperを活用すれば、ITPの7日間制限を受けない構成にでき、Cookieに本来の有効期限を設定できるようになります。
同一オリジン アプローチにはインフラ構成の見直しが、Cookie KeeperにはGTMコンテナスニペットの書き換えが必要になるなど、それぞれ導入にあたっての技術的なハードルがあります。しかし、そのハードルを乗り越えることで、ユーザーデータの計測精度をさらに向上させることができます。
アユダンテではsGTMの導入支援を行っております。「自社の環境ではどのアプローチが合っているのか」「そもそもsGTMの導入から相談したい」といったご要望がありましたら、お気軽にお問い合わせください。
