Safari ITP後のクリックアトリビューション：2026年時点でまだ機能するもの

AppleはIntelligent Tracking Prevention（ITP）の最初のバージョンを2017年9月にリリースしました。プライバシー機能として位置づけられており、それは正確です。また、サードパーティクッキーのエコシステムが2013年頃から崩れ始めて以来、広告テック業界が積み上げてきたすべての回避策を体系的に解体するものでもありました。ITPの新バージョンが出るたびに、マーケターが前のバージョンで見つけた抜け穴が塞がれていきました。ITP 2.3が2019年にリリースされるころには、一連の閉鎖が十分に徹底されており、Safariで確実に機能し続けている唯一のアトリビューションパスは、そもそもクロスサイトトラッキングに依存していなかったものでした。

この記事では、その経緯を時系列で解説します。各バージョンが何を壊したか、どの回避策を具体的に塞ごうとしたか、そして2026年時点でアトリビューションがどこに立っているか。姉妹記事のクッキーレスアトリビューション解説はブラウザ全体の広い状況を扱っています。この記事は特にSafariについて、そして特にすべてを乗り越えるリダイレクトチェーンのパターンについて扱います。

まとめ#

• ITP 2.0（2018年）はクロスサイトドメインのすべてのサードパーティストレージアクセスをブロックし、SafariでのURL広告ピクセルアトリビューションパスを破壊しました。
• ITP 2.1（2019年）はJavaScriptで設定されたファーストパーティクッキーを7日間に制限し、タグマネージャーで設定された年単位のアトリビューションウィンドウを終わらせました。
• ITP 2.2と2.3はリンク装飾パラメータを剥ぎ取り、リファラーヘッダーをダウングレードし、最後のクエリ文字列の回避策を塞ぎました。
• 自社ドメインのショートリンクは、リダイレクト時にサーバーサイドでファーストパーティクッキーを設定します - これがITPのすべてのバージョンを乗り越え、Safariで信頼できる7日間のアトリビューションウィンドウを提供する唯一のパターンです。

ITPのタイムライン：バージョンごとの詳細#

ITPは完成した形で登場したわけではありません。各バージョンが前のバージョンへの対応として業界が開発した特定のクラスの回避策を狙い、段階的にリリースされました。何が生き残っているかの技術的な形は、何が閉じられてどのように閉じられたかによって定義されているため、この経緯を理解することが重要です。

ITP 1.0 - 2017年9月。 最初のリリースはバウンス頻度とユーザーインタラクションシグナルに基づいてドメインを「クロスサイトトラッカー」として分類しました。トラッカーとして分類されたドメインのクッキーはパーティション化されました - 設定はできますが、ユーザーが過去24時間以内にトラッカーのドメインに直接アクセスした場合にのみクロスサイトコンテキストで読み取れます。ユーザーが直接アクセスすることのない標準的なアナリティクスピクセルのようなドメインにとって、24時間ウィンドウは事実上ブロックでした。

ITP 1.1 - 2018年3月。 広告主は1.0に対して、ファーストパーティランディングとしてトラッカードメインを通してから遷移先にバウンスするリダイレクトチェーン経由でアトリビューションをルーティングすることで対応しました。これにより、ユーザーがトラッカードメインへの「直接訪問」を行い、インタラクションクロックがリセットされます。ITP 1.1はこのパターン（バウンストラッカーとして知られる）を特定し、バウンスリダイレクトチェーンが生成したインタラクションクレジットを削除しました。バウンスアンドリダイレクトのパターンのためだけに存在しているように見えるドメインはインタラクションステータスを失いました。

ITP 2.0が壊したもの#

ITP 2.0は2018年9月にリリースされました。これは構造的な転換点でした。1.xがサードパーティクッキーをパーティション化していたのに対し、2.0はさらに進みました。分類されたドメインのサードパーティストレージアクセスを完全に削除しました。クッキー、localStorage、IndexedDB、キャッシュされたデータ - ITPがクロスサイトトラッカーとして分類したドメインに対してはすべてブロックされました。

広告テックへの実際の影響は大きなものでした。Facebook Pixel、Google Adsコンバージョンタグ、ほとんどのリターゲティングピクセルは、クリックをコンバージョンに紐付けるためにクロスサイトクッキーの読み取りに依存しています。ITP 2.0以降のSafariでは、その読み取りが失敗しました。Metaの当時の報告では、Safariトラフィックのイベントカバレッジに15〜25%のギャップがあることが示されていました - ChromeやFirefoxでピクセルが捉えていたクリックとコンバージョンが、Safariユーザーからはまったく表示されなかったのです。

ストレージのブロックはクッキーに限定されていませんでした。トラッカーとして分類されたドメインでlocalStorageに識別子を保持しようとするスクリプトや、永続化にService Workersを使用しようとするスクリプトも同様にブロックされました。2.0の意図は、サードパーティストレージ層をトラッキング目的に対して構造的に利用不可能にすることであり、特定の一技術を破壊することではありませんでした。

ITP 2.1が壊したもの#

2.0がサードパーティアトリビューションを終わらせたとすれば、ITP 2.1（2019年3月）はそれへの対応として育っていた回避策、タグマネージャー注入によるファーストパーティクッキーアトリビューションを狙いました。

ロジックは合理的でした。サードパーティピクセルがブロックされている場合でも、JavaScript経由で広告主自身のドメインにファーストパーティクッキーを書き込むことでアトリビューションを保持できました - 通常はGTMのようなタグマネージャーによって注入されます。クッキーはファーストパーティであり、ITPのサードパーティストレージ制限の対象外でした。多くのチームがこの方法で設定した年単位のアトリビューションウィンドウに移行していました。ファーストパーティのdocument.cookie書き込みは安全だと考えていました。

ITP 2.1は、ファーストパーティかサードパーティかにかかわらず、document.cookie経由で設定されたすべてのクッキーを最大7日間に制限しました。この制限はスクリプトで設定されたクッキーに特に適用されました。Set-Cookie HTTPレスポンスヘッダーで設定されたクッキーは2.1の影響を受けませんでした。この区別は正確で重要です：JavaScriptのdocument.cookie = "..."は7日間に制限されます。サーバーレスポンスのSet-Cookie: ...; Max-Age=31536000はそうではありません。

即座の被害はGTMベースのアトリビューション設定でした。GTMはページのJavaScriptを通じてクッキーを書き込みます。それらのクッキーは、記載された有効期限にかかわらず、Safariで7日間で期限切れになります。火曜日にキャンペーンリンクをクリックして翌木曜日にコンバートしたユーザーはアトリビューションウィンドウ外になりました。ITP 2.0の後にチームが移行してきた年単位のファーストパーティクッキーアトリビューションウィンドウは終わりました。

ITP 2.2が壊したもの#

ITP 2.2は2つの領域を強化しました。まず、遷移先ページがITPによってクロスサイトトラッカーとして分類されたドメインからリンクされていた特定のケースで、JavaScriptクッキーの制限を24時間に短縮しました。ユーザーが分類されたドメインのページからリンクをクリックした場合、JavaScript経由で設定された遷移先サイトのファーストパーティクッキーは7日間ではなく24時間に制限されました。トラッキングされていないリファラーパスには7日間の制限が残りましたが、クリックチェーンに分類されたドメインが含まれる場合は24時間の制限が適用されました。

次に、より広く注目されたのが、ITP 2.2がリンク装飾に制限を導入したことです。広告プラットフォームとアナリティクスツールは、遷移先URLにクエリパラメータとしてアトリビューション識別子を追加するパターンを開発していました - Google Adsのgclid、Metaのfbclid、Microsoft Advertisingのmsclkid。特定の条件下で、リンク元ドメインがトラッカーとして分類されている場合、ITPはページが読み込まれる前にそれらのパラメータを剥ぎ取り始めたり、それらの存在に応じて設定できるクッキーを制限したりするようになりました。

これは、2.0と2.1の後にチームが移行してきたgclidベースのアトリビューションパスへの直接攻撃でした。理由は明確でした：Appleはクエリパラメータベースのユーザートラッキングをクッキーベースのトラッキングと同等のプライバシーへの影響を持つと見なし、同じ制限を適用すべきだと考えていました。

ITP 2.3が壊したもの#

ITP 2.3（2019年9月）は残り2つのギャップを塞ぎました。

1つ目はクロスサイトナビゲーションでのリファラーダウングレードです。以前のバージョンがストレージとリンクパラメータに焦点を当てていたのに対し、2.3はリファラーヘッダー - ユーザーが別のサイトからナビゲートしてきたときにページが受け取るReferer値 - を対象にしました。分類されたドメインからのクロスサイトナビゲーションに対して、ITP 2.3はリファラーをオリジンのみにダウングレードしました：完全なhttps://classified-domain.com/path?campaign=spring&source=emailではなくhttps://classified-domain.com/になります。アトリビューションコンテキストが含まれることの多いパスとクエリ文字列が削除されました。

2番目の変更はストレージキャッピングロジックを拡張しました。JavaScriptクッキーの7日間制限に加えて、ITP 2.3は分類されたドメインからの単一のクロスサイトクリック後にストレージキャップを適用しました：遷移先サイトのすべてのクライアントサイドストレージ - クッキー、localStorage、IndexedDB - がキャッピングの対象になりました。意図は、分類されたドメインからリンクされるという行為だけで、遷移先がデータを保持する能力にカウントダウンが始まるようなステートフルなアトリビューションパターンのクラスを塞ぐことでした。

2.2と2.3を合わせると、2.0と2.1の後にチームが使用していた3つの主要なルート（リンク装飾パラメータ、リファラーベースのアトリビューション、クロスサイトクリックチェーンにわたるストレージ蓄積）がすべて塞がれました。

生き残るもの#

ITPの一連の対策は系統的でしたが、クロスサイトトラッキングを標的にしていました。生き残るパターンは、本当にファーストパーティのもの - アトリビューションデータが自分のドメインで取得され、自分のサーバーで設定され、サードパーティドメインのストレージを通過しないもの - です。

サーバー設定のファーストパーティクッキー。 ITP 2.1のクッキー制限はJavaScript経由のdocument.cookie書き込みに適用されます。Set-Cookie HTTPレスポンスヘッダーによってサーバーで設定されたクッキーは記載された有効期限を保持します。主な制限は、クッキーがサーバーが管理するドメインに設定される必要があることです。

サーバーサイドイベント転送。 クリック識別子がリダイレクト時に取得されてサーバーサイドに保存される場合、コンバージョン時のアトリビューション照合はサーバー間の操作です。ブラウザクッキーが7日間生き残る必要はありません。クリックIDはデータベースにあります。これがサーバーサイドコンバージョントラッキングの背後にあるアーキテクチャであり、Meta CAPI、GA4 Measurement Protocol、TikTok Events APIがすべてサポートするよう設計されているアプローチです。

ハッシュ化されたメールや電話による決定論的マッチング。 ユーザーが認証済みかメールアドレスを送信している場合、コンバージョンをクッキーIDではなくメールハッシュで元のクリックに一致させることができます。このパスはITPとは完全に無関係です - ブラウザストレージに依存したことがありません。制限はカバレッジです：アトリビューションウィンドウ内で自分を識別したユーザーにのみ機能します。

これらのパターンの完全な技術的コンテキストはクッキーレスアトリビューション解説にあります。

ショートリンクリダイレクトのパターン#

自分のドメインのショートリンク - 共有ショートナードメインではなく - は、キャンペーントラフィックと自然に機能する形でサーバー設定のクッキーパスを提供します。

メカニクスはシンプルです。ユーザーがgo.acme.example/spring26を指すキャンペーンリンクをクリックすると、リクエストはgo.acme.exampleのエッジハンドラーに到達します。エッジハンドラーはクリックイベントを取得し、クリックIDを生成し、リダイレクトレスポンスにSet-Cookieヘッダーを設定します - acme.example上のサーバー設定のファーストパーティクッキーです。その後、クリックIDをクエリパラメータとして追加した遷移先URLへの302を発行します。

クッキーはリダイレクト時にサーバーによってSet-Cookieで設定されるため、ITP 2.1の7日間JavaScriptキャップは適用されません。クッキーはサーバーが設定した有効期限を保持します。ITP 2.3が完全に有効なSafariでも、go.acme.example上のサーバー設定クッキーは設定された完全なウィンドウの間生き残ります。Elidoではデフォルトで7日間の有効期限を設定しています。これはJS設定クッキーに対するITPの最も制限的な制約と一致しており、サーバー設定クッキーは7日間すべて保持されます。

遷移先ページはクッキーまたはクエリパラメータ（利用可能なものを）からクリックIDを読み取り、カートまたは注文属性に書き込み、コンバージョンイベントは購入時にサーバーサイドでそれを運びます。クロスサイトドメインは関与しません。クッキーはあなたのドメインにあります。アトリビューション照合はサーバーサイドの操作です。ITPにはブロックするものが何もありません。

これが、ショートリンクのカスタムドメインサポートがアトリビューションにとって重要な理由です：ブランディングのためだけでなく、クッキーのファーストパーティ分類のためにも。bit.lyやshort.ioのような共有ショートナードメインは、あなたのウェブサイトとは異なるオリジンです。bit.lyに設定されたクッキーはacme.example上のサードパーティクッキーです。ITP 2.0がそれをブロックします。go.acme.exampleに設定されたクッキーはファーストパーティです。ITPの何もそれには触れません。solutions/marketersページではキャンペーンアトリビューションフローをエンドツーエンドで説明しています。

ショートナーがクリックデータを合法的に処理できる範囲と、クリックイベントスキーマのデータ最小化の設定方法については、GDPRの詳細なコンテキストとしてURLショートナーのためのGDPRをご覧ください。

まだ機能しないもの#

部分的な解決策を過大に売ることより、正直な方が安上がりです。

クロスドメインのビュースルーアトリビューション。 ユーザーがpublisher.exampleで広告をクリックせずに見て、後でadvertiser.exampleでコンバートする場合、そのアトリビューションにITP安全なパスはありません。ビュースルーは本質的に、インプレッションからコンバージョンへのクロスサイトシグナルを必要とします。Safariはそれをブロックし、上記のサーバーサイド転送アプローチはクリック開始型です - ファーストパーティクッキーを設定するか、クリックIDを書き込むためにクリックが必要です。

未認証ユーザーのリアルタイムステッチング。 ユーザーがログインまたはメールアドレスの送信なしにコンバートする場合、利用可能な唯一の識別子はクッキーまたはクエリパラメータのクリックIDです。クッキーが期限切れ（最初のクリックから7日後、または2.2のより厳しい制限が適用される場合は24時間後）になると、ステッチは失われます。サーバーサイドのクリックID保存はウィンドウ内のコンバージョンに対してこれを解決します。ウィンドウが閉じた後に到着するコンバージョンには解決できません。

Safariでのファーストタッチの7日間を超えるアトリビューションウィンドウ。 購買サイクルが数週間または数ヶ月単位のビジネス - B2B SaaS、高価値Eコマース、金融サービスに一般的 - では、Safariのファーストパーティクッキーの7日間ウィンドウは、コンバージョンの相当部分がその発信クリックにアトリビュートできないことを意味します。これらのビジネスモデルにとって、決定論的なメールハッシュパスが唯一の選択肢です。Safariでの確率論的アトリビューションは行動するのに十分な信頼性がありません。

代替としてのフィンガープリンティング。 キャンバスフィンガープリンティング、オーディオフィンガープリンティング、フォント列挙は、クッキーなしにセッション間でユーザーを再識別しようとする回避策です。AppleはSafariでのフィンガープリンティング表面を削減する方向に明確に動いています。ITP 2.3リリースノートでは「他の形式のクロスサイトトラッキングに対する追加保護」に言及しており、その方向はすべての後続Safariリリースで継続されています。フィンガープリンティングはまた、URLショートナーのためのGDPRで探求されているように、GDPR Article 6に基づく重大な法的リスクをもたらします。上記のパターンの実行可能な代替手段ではありません。

実践的な出発点#

リダイレクトパターンは機能します。ショートリンクワークスペースにカスタムドメイン（go.yourdomain.example）を設定し、それを通じてキャンペーントラフィックをルーティングし、ユーザーがコンバートする前に遷移先ページがelido_clickクエリパラメータまたはファーストパーティクッキーを読み取り、注文またはカート属性に書き込むよう設定します。その後、コンバージョンAPIを通じてサーバーサイドで広告プラットフォームにコンバージョンをルーティングします。7日間のウィンドウはほとんどのキャンペーンタイプのクリックからコンバージョンへのパスの大部分をカバーします。

コンバージョン転送のセットアップ - Meta CAPI、GA4 Measurement Protocol、リトライセマンティクス、重複排除の形式 - については、サーバーサイドコンバージョントラッキングがこの記事の技術的な補完です。製品サーフェスについては、コンバージョントラッキング機能が出発点です。

ITPはアトリビューションを殺しませんでした。アトリビューションの特定のアーキテクチャを殺しました - クロスサイトの永続ストレージと制御できないドメイン間の無差別なデータ蓄積に構築されたものを。それに取って代わったアーキテクチャは、より脆弱ではなく、より堅牢です。