計測が機能しなくなった理由

10年にわたり、マーケティング計測は単純な仕組みに頼っていました。広告プラットフォームのドメインからサードパーティ Cookieを設定し、それを何百万ものサイトで読み取るという方法です。これにより、広告主はユーザーの行動をつなぎ合わせ、サイトをまたいだ単一のプロファイルを作成できました。

クライアントサイド JavaScriptは、ブラウザからGoogle、Metaなどにピクセルを直接送信していました。導入は簡単で強力でしたが、ユーザーによる管理がほとんどないまま、あらゆる情報が第三者に漏れていました。

2017年、AppleはSafariにIntelligent Tracking Prevention（ITP）を搭載しました。デバイス上の機械学習を使用してドメインをトラッカーとして分類し、そのCookieをブロックまたは分離しました。

その後のITPでは、クライアントサイド（document.cookie / JavaScript-set）Cookieの有効期間が7日間に制限され、既知のトラッカーのリンク経由でユーザーが訪問した場合は、わずか24時間に制限されました。長期間のアトリビューション期間は、気づかないうちに崩壊しました。

FirefoxはEnhanced Tracking Protection（ETP）をデフォルトで有効にし、Disconnectリストを使用して既知のサードパーティトラッキング Cookieをブロックしました。Braveは、初期状態から積極的なブロック機能を搭載しました。

これらのブラウザでは、Chromeが変更を発表する何年も前から、サードパーティ Cookieは事実上使えなくなっていました。計測チームは、広告プラットフォームが報告するコンバージョンとバックエンドの実態との間に、ますます大きな差異を確認するようになりました。

Chromeは世界全体で最大のブラウザシェアを占めているため、その計画が最も大きな意味を持ちます。Googleはサードパーティ Cookieの完全な廃止を繰り返し延期し、2024年には強制的な削除ではなく、ユーザーが選択するためのダイアログを表示する方針へ転換しました。

正確なスケジュールがどうなるとしても、戦略的なシグナルは明確です。サードパーティ Cookieを前提に計測を設計してはいけません。サードパーティ Cookieは廃止が進む資産です。

Cookieの有効期限が早く切れたりブロックされたりすると、再訪ユーザーが新規ユーザーとして扱われます。コンバージョンを元の広告クリックに結び付けられなくなるため、プラットフォームでは過少報告が発生します。

同時に、モデル化されたコンバージョンや推定コンバージョンが別の数値を膨らませます。その結果、2つの真実の情報源が一致しなくなり、あらゆるダッシュボードへの信頼が損なわれます。

Cookieだけでなく、現在のブラウザはトップレベルサイトごとにストレージも分離します。サイトAにあるトラッカーのlocalStorageは、サイトBにある同じトラッカーのlocalStorageから分離されます。

これにより、Cookieのブロックをかろうじて乗り越えていた共有識別子の手法も機能しなくなります。フィンガープリンティングも積極的に抑制されており、SafariとFirefoxはノイズを加え、ChromeのPrivacy Sandboxは代わりに集計APIを提案しています。

モバイルでは、AppleのApp Tracking Transparency（ATT）により、アプリはIDFA広告識別子にアクセスする前に許可を求めることが義務付けられました。大半のユーザーは拒否しました。

これにより、モバイルアプリのインストール計測やオーディエンスターゲティングは大きな打撃を受け、業界はSKAdNetworkのような集計型でプライバシーを保護するフレームワークや、サーバーサイドで同意を得たデータへと移行しました。

多くのユーザーは、既知の分析ドメインや広告ドメインへのリクエストをブロックする広告ブロッカーやプライバシー DNSを使用しています。google-analytics.comやfacebook.comに送信するクライアントサイドのピクセルは、簡単にフィルタリングされます。

つまり、同意を得た正当な計測であっても、リクエストがブラウザから外部に送信されないだけで失われます。自社ドメイン経由でルーティングすることは、プライバシー対策だけでなく、信頼性を高める対策にもなります。

GDPR、ePrivacy、その他の同様の法律では、法的根拠が必要であり、ほとんどのトラッキングについて事前の同意が求められます。EUの複数の国でGoogle Analyticsに対して取られた執行措置では、米国サーバーへのデータ移転が問題視されました。

つまり、問題は二重になっています。ブラウザによる技術的なブロックに加えて、同意、データの最小化、管理を求める法的要件もあるのです。一方だけを解決しても、もう一方は解決できません。

ブラウザが今も信頼するものが1つあります。ユーザーが実際に訪問しているサイト（ファーストパーティ）が設定するCookieとストレージです。HTTP-onlyのサーバー設定によるファーストパーティ Cookieは、ITPによる最も厳しい制限を回避できます。

これが現代的なスタックの基盤です。識別情報とイベント収集を自社ドメインとサーバーに移し、同意を得たデータをプラットフォームに転送します。これがサーバーサイド トラッキングです。

重要なのは、単一の回避策ではなく、アーキテクチャを変更することです。ブラウザを第三者へのデータパイプラインとして使用することに依存するのはやめます。

その代わりに、ファーストパーティデータを収集し、明示的な同意を取得し、サーバーからシグナルを送信し、一部の計測が確定的ではなくモデル化されることを受け入れます。次のレッスンでは、このスタックをまさに構築していきます。

トラッキングは2つの方向から機能しなくなりました。ブラウザ（ITP、ETP、ストレージの分離、ATT）はサードパーティ識別子をブロックまたは短縮し、広告ブロッカーはクライアントサイドのピクセル自体の送信を阻止しました。さらに規制によって同意が必要になりました。

持続的な対応は、ファーストパーティで同意を得たデータをサーバーサイドで収集することです。サードパーティ Cookieは廃止が進む資産であるため、このコースの残りでは、現代のプライバシー耐性スタックを構築します。