クッキーレスアトリビューション解説：2026年時点でまだ機能するもの

2012年から2019年の間にほとんどのチームが構築したマーケティングアトリビューションスタックは、2つのことに依存していました。ランディングページに広告プラットフォームが設置するサードパーティクッキーと、コンバージョンページで発火してそのクッキーに照合するブラウザピクセルです。この対の両方が今や劣化しています。どちらも回復しません。

この記事はクッキーへの嘆きではありません。2026年に実際に機能するものの地図です - どのアトリビューションパスが生き残り、実際には解決策でないのに解決策として売られてきたもの、そしてEUトラフィックに有料獲得を実施しているチームにとって機能するスタックが実践的にどのようなものかを説明します。

まとめ#

• AppleのITP 2.3、FirefoxのEnhanced Tracking Protection、そして進行中のChromeのサードパーティクッキー廃止が合わさって、EU Webトラフィックの60〜70%がデフォルトでサードパーティクッキーをブロックまたは大幅に制限するようになっています。
• 2つのアトリビューションパスがまだ機能します：クリックIDを通じて渡されるサーバーサイド識別子と、あなたのドメインが管理するリダイレクトチェーン経由のファーストパーティクッキー設置です。
• クッキーレスは同意不要を意味しません。ePrivacy指令2002/58/ECとGDPRは、ストレージメカニズムに関わらず、非必須アナリティクスには引き続き同意を要求します。
• 確率的なフィンガープリントステッチングはEUにおける準拠したフォールバックではありません。サーバーサイドクリックIDと組み合わせた決定論的なメールハッシュマッチングが、精度と規制の精査の両方に耐える唯一のアプローチです。

何が変わったか：簡単なタイムライン#

SafariはITP 1.0で2017年にサードパーティクッキーの制限を始めました。制限は急速にエスカレートしました。2019年9月にリリースされたITP 2.3は、スクリプト設定のファーストパーティクッキーの有効期限を7日間に、参照チェーンに既知のクロスサイトトラッカーが含まれる場合は24時間に制限しました。この変更だけで、ほとんどのアトリビューションベンダーが依存していた標準的なクリックIDからクッキーへのハンドオフが壊れました。

FirefoxのEnhanced Tracking Protectionは2022年にすべてのユーザーにTotal Cookie Protectionをリリースし、すべてのサードパーティクッキーをトップレベルサイトでパーティション化しました。あなたのチェックアウトページと競合他社のチェックアウトページでpixel.example.comが設定したクッキーは、構造的に2つの完全に別のクッキーになりました - クロスサイトの相関は設計上なくなりました。

Chromeのタイムラインは、Googleが2019年に発表して以来何度もシフトしました。Privacy Sandboxサイト（2026-05-12参照）に文書化されている現在の状況は、一部のユーザーに対して廃止が進行中で、完全なロールアウトは進行中です。Chromeの最終的な日付に関係なく、EUの状況はすでに確定しています：SafariとFirefoxを合わせるとEU市場のモバイルとプライバシーを意識したデスクトップトラフィックの大部分を占めます。サードパーティクッキーを必要とするアトリビューション戦略は、すでにヨーロッパのオーディエンスの大部分に対して機能しなくなっています。

典型的なEUのパフォーマンスマーケティングアカウントで測定された合計効果：ブラウザサイドのピクセルアトリビューションは、トラフィックミックスに応じてコンバージョンを25〜45%少なくカウントしており、iOSが多い縦型（ファッション、ビューティ、アプリ、サブスクリプションサービス）はその範囲の上端にあります。

2つの生き残るアトリビューションパス#

パス1：サーバーサイド識別子#

コアメカニクスはシンプルです。ユーザーが広告をクリックすると、広告プラットフォームはランディングURLにクリック識別子を追加します - Metaのfbclid、Googleのgclidなどです。その識別子はURLに存在し、クッキーにはないため、ITPやクッキーパーティション化はそれに触れません。

ランディングページはURLからクリックIDを読み取り、自分のドメインのファーストパーティクッキーに書き込むか、カートを通じて最終的に注文レコードに渡します。ユーザーがコンバートすると、バックエンドが注文からクリックIDを読み取り、広告プラットフォームのコンバージョンAPIにサーバー間でコンバージョンを送信します - MetaのConversions API、GA4 Measurement Protocol、Mixpanelのサーバーサイドイベントエンドポイント。

このパスはサードパーティクッキーに触れないため機能します。クリックIDはランディング時のURLクエリ文字列にあります。自分のドメインのファーストパーティクッキーはサードパーティクッキーと同じようにITPに制限されません（ただし、参照チェーンが疑わしい場合、スクリプト設定のクッキーの7日間キャップの対象になります - これについては以下で詳しく説明します）。コンバージョンイベントはサーバー間でフローし、ブラウザの外側で完全に処理されます。

弱点は実際に存在します。ユーザーがランディングとコンバージョンの間にクッキーをクリアした場合、クリックIDは失われます。コンバージョンが異なるデバイスで発生した場合、既知のメールアドレスを持つログイン済みユーザーがいない限り、クロスデバイスリンクはありません。iOS 17はプライベートブラウジングとMailにLink Tracking Protectionを導入し、URLから既知のクリックIDパラメータを剥ぎ取ります - fbclid、gclid、msclkidはリストに含まれています。Link Tracking Protectionが有効なMailアプリ経由で到着したユーザーは、サイトにクリックIDをまったく持ち込みません。

パス2：ファーストパーティリダイレクトチェーン#

2番目の生き残るパスは、アトリビューションサーフェスとしてあなたが管理するリダイレクトを使用します。広告プラットフォームのクリックIDの代わりに、自分のドメインのリダイレクト時に自分の永続的識別子を生成します。

ユーザーがあなたのドメインのリンクをクリックすると - ショートリンク、キャンペーンランディングリダイレクト、ブランデッドディープリンクのいずれでも - あなたのエッジのリダイレクトハンドラーはブラウザのプライバシー制限が適用される前に動作します。これにより：

1. あなたのドメインにサーバー生成のクリックIDを持つファーストパーティクッキーを設定できます。
2. 遷移先URLにクリックIDをURLパラメータとして追加できます。
3. ページ読み込み時ではなくクリック時に、完全な技術的コンテキスト（IP、ユーザーエージェント、リファラー、タイムスタンプ）を含むクリックイベントをサーバーサイドでログに記録できます。

これはあなたのドメインとあなたのサーバーサイドクッキーであるため、ITPが標的にするサードパーティクッキー制限の外側にあります。クッキーはリダイレクトレスポンスのSet-Cookieレスポンスヘッダーを通じてサーバーによって設定されます - サーバー設定のクッキーはJavaScriptのdocument.cookie書き込みに適用される7日間のITPキャップの対象ではありません。

これが、ブラウザピクセルでは提供できないアトリビューションサーフェスをURLショートナーが提供するものです。リダイレクトはショートナーのドメインで解決します。そのドメインがあなた自身のブランドドメインであれば、あなたのクリックIDはファーストパーティで、サーバー設定で、ブラウザサイドのプライバシー制限が実行される前にアーキテクチャ的に位置づけられています。

ショートリンクがアトリビューションサーフェスになる仕組み#

リダイレクトフローは次のように機能します。広告の遷移先URLはブランデッドショートリンクです - 例えばgo.acme.example/summer-sale。ユーザーがクリックします。リダイレクトリクエストがElidoのエッジハンドラーに到達し、そこでは：

• 遷移先URLを検索します。
• elido_click識別子を生成し、クリックイベントをサーバーサイドでログに記録します。
• リダイレクトレスポンスにファーストパーティSet-Cookie: elido_click=<id>; Domain=go.acme.example; SameSite=Lax; Secure; Max-Age=604800を設定します。
• 転送前に遷移先URLに?elido_click=<id>を追加します。

遷移先ページはクリックIDをクエリ文字列で受け取ります。タグマネージャーまたはテーマコードがそれを読み取り、カートまたは注文レコードに保存します。コンバージョンが発生すると、クリックIDと注文詳細を含むPOST /v1/conversionsをポストします - Elidoが顧客識別子のSHA-256ハッシュ化とMeta CAPI、GA4 Measurement Protocol、Mixpanelへのサーバーサイドファンアウトを処理します。

クリックIDはサードパーティクッキーに存在したことがありません。サーバー設定、ファーストパーティ、ブラウザのプライバシー層が干渉する機会を得る前にログに記録されました。サーバーサイド転送ステップの完全なメカニクスについては、ショートリンク経由のサーバーサイドコンバージョントラッキングで重複排除、ハッシュ化要件、リトライセマンティクスを詳細に説明しています。

ITPが具体的にクリックアトリビューションをどのように劣化させるか、そしてショートリンクリダイレクトチェーンがそれに対して何をするかについての広い問いについては、Safari ITP後のクリックアトリビューションがこの記事の運用面の補完です。

アイデンティティステッチング：何が機能して何が機能しないか#

サーバーサイドクリックIDは、ユーザーが同じブラウザセッションで同じデバイスでリンクをクリックしてコンバートする場合のアトリビューション問題を解決します。クッキーをクリアせず、Link Tracking Protectionがパラメータを剥ぎ取らない場合に限り。それはまだeコマースコンバージョンの大部分をカバーしています。しかし、すべてをカバーするわけではなく、残りのギャップを埋めるためにチームが使用するアプローチは、精度と法的露出の両方において大きく異なります。

決定論的マッチングは機能します。 ユーザーがログインしているか、ファネルのどこかでメールアドレスを提供している場合（メールキャプチャ、ニュースレター登録、チェックアウト）、そのメールアドレスをSHA-256でハッシュ化し、コンバージョンイベントに含めることができます。Meta CAPI、GA4、Mixpanelはすべて、クリックIDの代わりまたはそれと並んでハッシュ化されたメールをマッチングシグナルとして受け入れます。既知のメールトラフィックのマッチ率は高く - Metaは正規化されたハッシュ化メールが存在する場合、90%以上のマッチ率を内部的に報告しています。これがクッキー廃止後も無傷で生き残る主要なステッチングメカニズムです。

ここでは重複排除のペアリングが重要です。各コンバージョンイベントには、ブラウザサイドのピクセルとサーバーサイドの送信の間で同一のevent_id（Metaの場合）またはtransaction_id（GA4の場合）が必要です。これがなければ、両方のイベントが取り込まれ、コンバージョンが二重にカウントされます。注文IDは購入イベントの標準的な重複排除キーです。

確率的なフィンガープリンティングは機能しません - そしてEUでは合法でもありません。 ブラウザフィンガープリンティングは、スクリーン解像度、インストールされたフォント、タイムゾーン、ユーザーエージェント、キャンバスレンダリングフィンガープリントなどのシグナルの組み合わせから一意の識別子を組み立てます。識別子は確率的です - 共有クッキーやログインなしに2つのイベント間の高信頼マッチを割り当てます。一部のアトリビューションベンダーはこれを「クッキーレス計測」ソリューションとして提供しています。

EUでは、このアプローチには特定の法的問題があります。ePrivacy指令2002/58/ECのArticle 5(3)は、ユーザーの端末機器の情報へのアクセスまたは保存に対して同意を要求します。2022年以降の複数の監督当局の決定で繰り返されているEDPBの立場は、フィンガープリンティングは識別子が技術的に「クッキー」かどうかに関わらずArticle 5(3)の範囲内に含まれるというものです。オーストリアのDSB、フランスのCNIL、イタリアのGaranteはそれぞれ、同意なしのフィンガープリンティングに対して執行措置を発動しています。「クッキーは使用せず、フィンガープリンティングを使用する」という主張はコンプライアンスの議論ではありません。それはより詳しい精査を招く議論です。

法的露出の外側でも、確率的なフィンガープリンティングはブラウザのエントロピーが低下するにつれて精度が落ちます。現代のプライバシーに特化したブラウザは、キャンバス出力を正規化し、タイミングAPIの解像度を制限することでエントロピーを積極的に下げています。シグナルの品質は、正確な計測が最も必要な人口 - プライバシーを意識した、iOSが多い人 - でまさに低下します。

CRMを通じたクロスデバイスステッチングが残りのギャップです。 クリックしたのとは異なるデバイスでコンバートするユーザーに対して、機能する唯一のアプローチは決定論的なメールマッチングです。ユーザーが両方のデバイスでログインしている場合、ユーザーIDがリンクです。ログインしていない場合、デバイスAのクリックIDとデバイスBのコンバージョンは、ユーザーがハッシュ化してマッチングできる識別子（メール、電話）を自発的に提供しない限り接続できません。このギャップはサーバーサイドで閉じることはできません。クッキーレスの世界での実際のアトリビューション制限です。

コンプライアンスのオーバーレイ#

「クッキーレスアトリビューション」という表現は、クッキーが設定されていないため同意は不要だと人々に思わせることがあります。法律はそのようには言っていません。

ePrivacy指令2002/58/ECのArticle 5(3)はユーザーの端末機器の情報の保存またはアクセスに適用されます - クッキーだけではありません。アナリティクス目的で設定されたファーストパーティクッキーは、そのクッキーが非必須であれば、トラッキング目的で設定されたサードパーティクッキーと同じ同意を必要とします。上記のサーバー設定のクリックIDクッキーはアナリティクスに隣接しています。コントローラーの目的の評価と指令の該当する国内実施に応じて、同意が必要かどうかは異なります。

サーバーサイドアプローチが実際に行うこと - これが真のコンプライアンスの優位性です - は、処理をユーザーのデバイスからサーバーに移すことです。クリックイベントログ、コンバージョンイベントの転送、アイデンティティステッチ：これらはブラウザスクリプトではなく、あなたのバックエンドとElidoのバックエンドで行われます。つまり、広告ブロッカーがそれらを傍受せず、ブラウザのプライバシー機能がそれらをパーティション化せず、データ最小化のスタンスはサードパーティタグが送信することに依存するのではなく、あなたが管理できます。

GDPRの適法な根拠の問いはePrivacyの問いとは別です。サーバーサイドアトリビューションでも、識別可能なEU域内のデータ主体のクリックデータの処理に対して、GDPR Article 6に基づく適法な根拠が必要です。キャンペーンレベルのアナリティクスに対して、ほとんどのコントローラーはLegitimate Interest AssessmentによりArticle 6(1)(f)の正当な利益にこれを根拠づけています。個人レベルのプロファイリングやリターゲティングに対しては、根拠はより難しくなります。URLショートナーのためのGDPRコーナーストーンでArticle 6、28、30の分析を詳細に説明しています。ここでの要約は、クッキーレス≠同意不要であり、コンプライアンスのオーバーレイはストレージメカニズムが変わっても消えないということです。

Elidoのクリックイベントのデフォルトはデータミニマイゼーションのスタンスを反映しています：IPは保存前に/24（IPv4）に切り詰められ、完全なユーザーエージェント文字列は解析されてドロップされます。ユースケースが必要であれば、ワークスペースごとに完全解像度データが利用可能ですが、デフォルトは保守的な設定です。これは購入者とのDPA追補の会話に重要です。その会話の詳細については、solutions/marketersでマーケティングチームの調達タッチポイントを説明しています。

何を諦めるか#

正直な計算が重要です。クッキーレスサーバーサイドアトリビューションはブラウザサイドの劣化で失われたシグナルのほとんどを回復しますが、すべてを回復するわけではありません。

リアルタイムのクロスデバイスアイデンティティ。 上記の通り：ユーザーがモバイルでクリックして2つをリンクするログインイベントなしにデスクトップでコンバートした場合、アトリビューションは失われます。これに対するサーバーサイドの準拠した修正はありません。ギャップは構造的です。

正確なビュースルーアトリビューション。 ビュースルーアトリビューション - クリックではなく広告インプレッションの後のコンバージョンにキャンペーンをクレジットする - は、広告プラットフォームが両方のイベントでユーザーを照合する必要があります。サーバーサイドコンバージョンAPIはクリックベースのアトリビューションをうまく処理します。ビュースルーはプラットフォーム独自のクロスデバイスグラフに依存し、それ自体がシグナル損失に比例して劣化します。ビュースルーレポートはクリックベースの数値よりもノイズが多く信頼性が低くなることを期待してください。

長いルックバックウィンドウ。 ほとんどのサーバーサイドコンバージョンAPIエンドポイントは、クリックがコンバージョンにアトリビュートされる時間に遡れる制限を課します。Meta CAPIの標準ルックバックはクリックスルーで7日間です。GA4のMeasurement Protocolのアトリビューションウィンドウはチャネルによって異なります。これらのキャップは、クッキーベースの世界で一部のチームが使用していた28日間または90日間のウィンドウより短いです。サブスクリプション製品や長い調査サイクルを持つ検討された購入は、アトリビュート可能なウィンドウ外でより多くのコンバージョンが発生することになります。

ラストクリックの支配。 マルチタッチアイデンティティグラフがなければ、サーバーサイドアトリビューションはラストクリックにデフォルトします - チェーンの最も最近のクリックIDがクレジットを得ます。長期間にわたって支援コンバージョンを促すブランド認知キャンペーンに対して、ラストクリックのサーバーサイドアトリビューションは体系的にアッパーファネルの支出を過小評価します。緩和策はハッシュ化されたメールによるCRMステッチングです：すべてのログイン済みユーザーのメールがすべてのコンバージョンイベントにある場合、ログイン済みオーディエンスの部分に対してマルチタッチシーケンスを再構築できます。匿名ユーザーに対して、ラストクリックが上限です。

実践的なスタック#

上記の制約を踏まえ、2026年のEUトラフィックでパフォーマンスマーケティングを実施しているチームに機能するアトリビューションスタックを示します。

エントリーポイントとしてのショートリンククリックID。 すべての広告の遷移先はあなたのドメインのブランデッドショートリンクです。リダイレクトはサーバーサイドのファーストパーティクッキーを設定し、遷移先URLにクリックIDを追加します。これにより、ITPとクッキーパーティション化をセッション間で生き残る永続的なサーバー設定識別子が得られます。

カートと注文の配管。 クリックIDはページ読み込み時にカート属性に書き込まれます（URLパラメータまたはファーストパーティクッキーから）。注文作成時に、クリックIDは注文のカスタム属性に含まれます。これが耐久性のあるハンドオフです - クリックIDが注文に含まれれば、期限切れになりません。

MetaへのサーバーサイドCAPI。 注文支払い時に、バックエンド（またはコンバージョン転送機能）がクリックID、SHA-256ハッシュ化されたメール、ファーストパーティクッキーのfbc/fbp識別子を含めてMeta CAPIにPOSTします。event_idは注文IDで、ブラウザサイドのピクセルと一致します。Metaは48時間マッチングウィンドウ内で重複排除します。

GA4へのサーバーサイドMeasurement Protocol。 同時に、transaction_idが注文IDと等しいGA4サーバーサイドイベントが送信されます。client_idは利用可能な場合はGA4の_gaクッキー値、フォールバックとしてクリックIDです。GA4はセッションウィンドウ内でtransaction_idに基づいて重複排除します。

CRMメールハッシュステッチ。 クリックIDが欠落しているコンバージョン（オーガニック、ダイレクト、ブランド検索）に対して、ハッシュ化されたメールアドレスがアトリビューションシグナルです。これにより、アトリビューションの「既知ユーザー」セグメントが埋まり、ログイン済み顧客の基本的なマルチタッチ再構築がサポートされます。

長いルックバックのためのオフラインコンバージョンインポート。 コンバージョンがクリックから数週間後に発生するサブスクリプション製品やB2Bパイプラインに対して、プラットフォームのバッチAPI経由のオフラインコンバージョンインポート（MetaのConversions APIオフラインイベント、Google Adsオフラインコンバージョン）により、リアルタイムのルックバックウィンドウを超えてアトリビューションイベントを送信できます。マッチキーは引き続きハッシュ化されたメールまたは電話です。時間ウィンドウは拡張されます。これは匿名の長期サイクルアトリビューションを解決しませんが、メールアドレスを提供したオーディエンスの部分のループを閉じます。

上記のスタックはCDPを必要としません。サーバーサイドのクリックIDを生成して保持するURLショートナー、クリックIDを注文まで通す配管を持つバックエンド、そしてハッシュ化とAPIファンアウトを処理するコンバージョン転送レイヤーが必要です。ファンアウトレイヤーの技術的実装については、ショートリンク経由のサーバーサイドコンバージョントラッキングにペイロードの形式、重複排除メカニクス、リトライセマンティクスがあります。完全なキャンペーンUTMワークフローにおける位置については、solutions/marketersを参照してください。

機能しないバージョンのスタック：アイデンティティ解決のために広告プラットフォーム独自のクロスデバイスグラフに依存するもの、iOSユーザーがあなたの計測に有利な方法でApp Tracking Transparencyを有効にしていることを望むもの、またはギャップを埋めるために確率的なフィンガープリンティングを使用するもの。最初は制御不能です。2番目は楽観的すぎます。3番目はEUでのコンプライアンス上の責任です。

機能するものと共に作業してください。