はじめに

計測プラットフォーマーはユーザー計測をサーバーサイドに移行する動きを進めています。
計測ツール提供側（計測プラットフォーマー） / 利用側ともに負担の大きいサーバーサイド計測が求められている背景を整理します。

1. クライアントサイド主体の計測

ユーザー計測ではブラウザに Cookie を保存してユーザーを識別します。Cookie は仕様で別ドメインに自動送信されません。
そのため、従来のユーザー計測では、Cookie に保存したユーザー識別子を計測サーバーへ送る手段としておもに 2 つの方法が使われています。

<img> ピクセルによる送信

1 × 1 px の透明画像タグをページに埋め込みブラウザが計測サーバーに画像をリクエストします。計測サーバーはレスポンスの Set-Cookie で Cookie を発行します。代表的な計測サーバーに Google 広告のコンバージョン計測やインプレッション計測する doubleclick.net があります。

具体的なコードは以下のようになります（正確性より分かりやすさを優先したサンプルです）。

<img src="https://ad.doubleclick.net/activity;src=XXXX;type=YYYY" width="1" height="1">

JavaScript による送信

JavaScript が Cookie の値を読み取り、クエリパラメーターに付与して計測サーバーに送信します。 代表的な計測サーバーに GA4 （ google-analytics.com ）があります。

擬似的なコードは以下のようになります（正確性より分かりやすさを優先したサンプルです）。

// クライアントで発行した Cookie を document.cookie で取得
const cid = document.cookie['_ga'];

// 取得した Cookie をクエリパラメーターに付与して計測サーバーに送信
send(`https://www.google-analytics.com/g/collect?cid=${cid}&...`);

2. ブラウザのプライバシー制限

Safari は ITP（ Intelligent Tracking Prevention ）を導入し機械学習でクロスサイトトラッキング能力があると判定したドメイン（ classified domain1 ）のサードパーティ Cookie を段階的に制限しました。

当初 google-analytics.com / doubleclick.net / facebook.com 等が classified domain の対象となりました。その後、分類の有無に関わらず全サードパーティ Cookie をデフォルトでブロックしました。

Firefox も ETP（Enhanced Tracking Protection）で同様にサードパーティ Cookie を全面的にブロックしています。

これにより <img> ピクセルが依存するサードパーティ Cookie の発行・送信は Safari / Firefox で機能しなくなりました。

一方、Chrome の対応は異なります。2020 年（ Chrome 80 ）に SameSite 属性が設定されていない Cookie のデフォルトを Lax に変更しました。これはサードパーティ Cookie の禁止ではなく、明示的な指定がなければ送信しないという変更です。SameSite=None; Secure を指定すれば <img> ピクセルのレスポンスで発行されたサードパーティ Cookie が今も送受信されています（ google-analytics.com や doubleclick.net はこれを行っています）2。

ITP は JavaScript（ document.cookie ）で発行した Cookie の有効期限を最大 7 日に制限しました。前述した GA4 の _ga Cookie はこの制限を受けるため、7 日を超えると再訪ユーザーが新規ユーザーとして誤認されて計測の精度が低下します。

サーバー発行 Cookie は当初この制限を受けませんでしたが、自社サブドメインの DNS レコードで計測サーバーの IP アドレスを隠蔽する CNAME クローキング / IP アドレスクローキングという迂回策も ITP に検知され、サーバー発行 Cookie も 7 日制限の対象となりました。名前だけを自社ドメインに見せかける回避策も ITP に制限されるようになりました。

3. サーバーサイド計測の必要性＆具体例

上述したとおりクライアントサイド主体の計測は段階的に制限されてきました。これらの制限を根本的に回避するには実際に自社ドメインのサーバーがリクエストを受けて Cookie を発行・管理する必要があります。通常自社サブドメイン（例: analytics.example.com）は classified domain に分類されないため ITP の有効期限制限を受けません。

例 Google server-side Tag Manager （ SGTM ）

自社ドメインのサーバーに GTM のタグサーバーを設置しブラウザからのリクエストをいったん自社サーバーが受けてから Google の計測サーバーへ転送する構成です。自社サーバーが Set-Cookie で Cookie を発行するため ITP の有効期限制限を回避できます3。名前だけを自社ドメインにするのではなく実際に自社サーバーでリクエストを処理する点が ITP 対策として機能する核心です。

まとめ

ブラウザのプライバシー強化はクライアントサイド主体の計測（ <img> ピクセルと JavaScript による送信）を段階的に制限してきました。またその迂回策も都度制限されてきました。

Google server-side Tag Manager へのシフトはこの流れへのソリューションといえます。 本記事がその背景理解の一助になれば幸いです。

  1. ITP の文脈での classified Domain とは、Safari が機械学習を用いてユーザーを追跡（トラッキング）していると判断したドメインのことです。 ↩

  2. プライバシー重視の流れにある現在においては、サードパーティ Cookie はすべてのブラウザで制限されると考えがちです。実際は Safari / Firefox と異なり Chrome はオプトインを条件に今もサードパーティ Cookie を許容しています。 ↩

  3. サーバーサイド タグ設定の概要 ↩