同意モード v2 は 2024年3月6日をもって必須となりました。この日以降、Google の広告プロダクトへの EU および EEA からのトラフィックには、従来の ad_storage と analytics_storage に加え、2 つの新しいシグナル（ad_user_data と ad_personalization）を渡す必要があります。この変更は GDPR ではなく、デジタル市場法（Regulation (EU) 2022/1925）、具体的には、明示的な同意なしに指定されたゲートキーパーがサービス間で個人データを組み合わせたりクロス利用したりすることを禁じる DMA 第 5 条(2)項によって推進されました。
URL 短縮サービスにとって、これはリダイレクトのデータプレーンが厄介な形で交差することを意味します。短縮リンクはユーザーがクリックしたものであり、ランディング ページでの同意状態によって、そのクリックをアトリビューション（属性特定）できるかどうかが決まります。これら 2 つのイベントは異なるドメイン、異なる Cookie、そして多くの場合異なるセッションで発生します。この両者のギャップが、現在のアトリビューション損失の主な要因となっています。
この記事では、実務に携わるコンプライアンス担当の視点から、何が変わったのか、4 つのシグナルがリダイレクト サービスにおいて何を意味するのか、EDPB（欧州データ保護会議）の現在のガイダンス下でサーバーサイド リカバリが適法となるケース、そして違法となるケースについて解説します。リダイレクトを介した GA4 サーバーサイド トラッキングのためのエンジニアリング作業のほとんどは GDPR 下では問題ありませんが、その一部は DMA 下では許容されません。
DMA（デジタル市場法）の要点#
デジタル市場法（DMA）は 2024年3月7日から適用されました。この法律は「ゲートキーパー」（Alphabet、Amazon、Apple、ByteDance、Meta、Microsoft、Booking）を指定し、彼らに事前の義務を課しています。トラッキングにおいて重要なのは DMA 第 5 条(2)項です。ゲートキーパーは、同意なしにオンライン広告のためにサードパーティ サービスのエンドユーザーの個人データを処理したり、自社サービス間で個人データを組み合わせたりしてはなりません。
同意モード v2 は、Google による第 5 条(2)項への準拠メカニズムです。2 つの新しいシグナル（ad_user_data と ad_personalization）により、ゲートキーパーは、クリック テレメトリが広告やパーソナライズに使用される前に、パブリッシャーが第 5 条(2)項レベルの同意を取得したかどうかを確認できます。これらのシグナルが granted（許可）に設定されていない場合、Google の広告プロダクトは、ユーザー単位のアトリビューションを行わない、集計またはモデリングされたコンバージョンにフォールバックします。
DMA は GDPR に代わるものではなく、その上に重なるものです。管理者は依然として GDPR に基づく第 6 条の適法な根拠を必要とします。同意モード v2 は、GDPR のゲートが開いていても、ゲートキーパーを経由する広告データに対して閉じる可能性のある第 2 のゲートを追加します。
4 つのシグナルの平易な解説#
同意モード v2 は 4 つの boolean シグナルを送信します。それぞれ granted（許可）または denied（拒否）を設定でき、地域ごとにデフォルト値を設定可能です。
ad_storage — オリジナルの v1 シグナルです。広告目的で Cookie やその他のストレージを書き込むかどうかを制御します。denied の場合、Google タグは識別子なしで実行され、コンバージョン測定は Cookie を使用しない、モデリングされた集計データへと劣化します。リダイレクトによって UTM パラメーターやクリック識別子がページに渡され、それらが同意が付随するキーとなります。タグ プラットフォームの同意に関するドキュメントは、各シグナルが下流で何を行うかの公式なリファレンスです。
**ad_user_data** — v2 で新設されました。ユーザー データを広告目的で Google に送信してよいかどうかを制御します。これが DMA 第 5 条(2)項のシグナルです。denied` の場合、タグはハッシュ化された識別子、IP、ユーザーエージェントを含むユーザー データを Google 広告に送信できません。サーバーサイド タギングでもこれをバイパスすることはできず、シグナルはイベントと共に送信されます。
ad_personalization — これも v2 で新設されました。送信されたデータをリマーケティングを含むパーソナライズ広告に使用してよいかどうかを制御します。一般的な設定は ad_user_data=granted かつ ad_personalization=denied で、これによりアトリビューションは許可しつつ、リマーケティングをブロックします。
analytics_storage — 分析目的でストレージを書き込むかどうかを制御します。GA4 タグはこの設定に従います。denied の場合、GA4 は Cookie なしで実行され、同意モードのモデリングを使用して集計レベルでアトリビューションを再構築します。モデリングには最低限のトラフィック量と 7 日間の学習期間が必要です。
これら 4 つのシグナルは、短縮サービス側で決定されるものではありません。短縮サービスはクリックを生成し、ランディング ページがシグナルを読み取り、ランディング ページ上のタグがそれらをどう扱うかを決定します。短縮サービスの役割は、クリーンな状態（維持された UTM、維持されたクリック識別子、高速なリダイレクト）を届け、タグが発火する前にバナーが解決できるようにすることです。
リダイレクト データプレーンで発生する問題#
リダイレクト パスを真剣に扱うすべての短縮サービスにおいて、3 つの失敗モードが見られます。
クリック識別子は残るが、同意シグナルが残らない。 Meta 広告のクリックが s.elido.me/abc123?fbclid=… にヒットし、https://customer.example/landing?fbclid=… にリダイレクトされます。fbclid は維持されます。ページが読み込まれ、バナーが表示され、ユーザーが拒否します。Meta CAPI は既にその fbclid に紐づいたクリックを受け取っていますが、ユーザーは広告利用を拒否しました。短縮サービスに非はありませんが、管理者はエンドポイント側で CAPI の重複排除問題を解決する必要があります。
短縮サービスがランディング ページで理解できない識別子を付加する。 一部の短縮サービス（Bitly の bitly_session や Rebrandly の _branch_match_id など）は、ベンダー固有のパラメーターを付加しますが、これらは同意が拒否された場合に削除または特別な処理が必要です。Elido は UTM と顧客自身のクリック識別子のみを転送します。
ランディング ページの同意状態がリダイレクトの視点からは不明である。 短縮サービスは、まだ読み込まれていないバナーを見ることはできません。サーバーサイドのフォールバックの決定を、まだ存在しない同意状態に基づいて行うことはできません。唯一の誠実なデフォルトは、リダイレクト時に広告目的のサーバーサイド イベントを発火させないことです。バナーを解決させ、ページまたはそのプロキシが同意状態を付随させて発火するようにします。
エッジから直接 Measurement Protocol や CAPI イベントを発火させるベンダーは、ユーザーが同意することを賭けています。DMA 第 5 条(2)項の下では、その賭けを行う権利は彼らにはありません。EDPB ガイドライン 02/2023（eプライバシー指令第 5 条(3)項の技術的範囲について）でも、同意前の識別子注入に関連して、それは処理であり根拠が必要であり、バナーの欠如は根拠にならないという指摘がなされています。
適法なサーバーサイドの緩和策#
以下の緩和策は、GDPR と DMA の両方の下で維持されるものです。これらに共通するのは、ゲートキーパーにデータが送信されたり広告に使用されたりする前に、同意状態を確認しなければならないという点です。
同意状態を付随させた Measurement Protocol。 GA4 の Measurement Protocol は、gtag クライアントと同じ consent パラメーターを受け取ります。パターンとしては、ランディング ページがバナーを解決し、同意状態を顧客のファーストパーティ サーバーにポストし、ファーストパーティ サーバーが consent.ad_user_data と consent.ad_personalization を設定して GA4 に mp/collect リクエストを転送します。サーバーサイドですが、同意解決の下流に位置します。Elido のフォワーダー（リダイレクトを介した GA4 サーバーサイド トラッキングで解説）は、送信ペイロードに同意状態を適用します。
同意文字列を含む Conversion API。 Meta CAPI は data_processing_options と opt_out を、LinkedIn の Conversions API は enlli を、TikTok の Events API は limited_data_use を受け取ります。これらすべてがプラットフォームに同意状態を通知します。パターンは同一で、ランディング ページが解決し、ファーストパーティ サーバーにポストし、ファーストパーティ サーバーが同意状態を付随させて発火させます。
集計されたサーバーサイド レポート。 同意状態によって広告や分析目的の利用が拒否された場合でも、真に集計されユーザー単位の識別子を欠いたサーバーサイド レポートは、通常 DMA 第 5 条(2)項および GDPR 第 6 条（正当な利益）の下で問題ありません。EDPB の匿名化に関するガイドライン 04/2023 は、仮名化されたデータは匿名ではなく、k-匿名性が低い場合は依然として再識別が可能であることを再認識させています。保守的な運用としては、ワークスペース レベルで 10 以上のしきい値を持つカウントのみを公開することです。
ランディング ページでのファーストパーティ識別子解決。 最も耐性のあるアプローチは、GDPR 第 6 条(1)(b)のシグナル（サインイン、フォーム入力、確認メールのクリックなど）を介してユーザーを特定し、遡ってアトリビューションを行うことです。これは ad_storage や ad_user_data に全く依存しません。Safari ITP 後のクリック アトリビューションの記事でこのパターンを扱っていますが、これはポスト DMA の世界においても正解です。
違法なサーバーサイドの緩和策#
ツール ベンダーのピッチに登場することがありますが、採用すべきではない 3 つのパターンです。
ランディング ページの同意が解決する前にエッジから CAPI イベントを発火させる。 これは前述の失敗モードです。付随させるべき同意状態が存在せず、イベントを発火させることは管理者が同意を得たことを示唆しますが、実際には得られていません。一部のベンダーはこれを「確定的アトリビューション」と呼びますが、DMA 第 5 条(2)項の下では、ユーザーが許可していないデータ結合操作となります。
IP をハッシュ化し、そのハッシュを匿名として扱う。 EDPB は、個人データの概念に関する意見 4/2007 以来、そしてガイドライン 04/2023 でも、母集団にアクセスできる者がハッシュを逆転できる場合、ハッシュ化された識別子は個人データのままであることを明示しています。IP のハッシュは大規模に逆転させるのが容易であり、ハッシュ化は処理の法的性質を変えるものではありません。
ゲートキーパーとのサーバーサイド識別子同期。 ハッシュ化されたメールアドレスや電話番号を付随させてクリック イベントを Google や Meta に転送し、ゲートキーパー側の識別子グラフと照合させる操作は、DMA 第 5 条(2)項が明確に制限しているものです。照合はゲートキーパーによるサービス間のデータ結合です。これに対する同意は明示的かつユーザー単位である必要があります。ハッシュが存在することは操作を適法にするものではなく、同意の欠如が操作を違法にします。
CJEU および EDPB の最近の動向#
規制当局の最近の動きが、この状況をより鮮明にしています。
CJEU（欧州連合司法裁判所）による Case C-621/22 (Royal Lichtervelde, 2024) の判決は、Wirtschaftsakademie（C-210/16）および Fashion ID（C-40/17）からの共同管理者の分析を再確認しました。パブリッシャーがサードパーティのタグを統合し、そのタグがユーザー データをサードパーティに送信する場合、パブリッシャーとサードパーティはその処理について共同管理者となります。GDPR 第 26 条は、両者間の透明な取り決めを求めています。同意モード v2 の利用者にとって、Google との第 26 条の取り決めが整っている必要があり、同意状態は誠実に流れる必要があります。アトリビューションを回復するために ad_user_data=granted と偽ることは、双方にとって共同管理者としての責任を負うことになります。
EDPB の 広告の文脈における同意シグナルに関するガイドライン 03/2024（コンサルテーション ドラフト、最終版は 2026年第 3 四半期予定）は、明確に同意モード v2 に言及しています。ドラフトでは、ad_user_data シグナルは GDPR 第 7 条(4)に基づき、自由になされた同意に依存するものであり、詳細な制御なしに ad_storage と ad_user_data をバンドルしたバナーは、第 7 条の自由になされた同意のテストに失敗するとされています。現在の多くのバナーはこれらをバンドルしています。再設計は顧客の責任であり、短縮サービスはクリーンな状態を表面化させますが、バナーの設計までは行いません。
より広範なデータ移転への影響（同意は得られたがデータが依然として EU 外へ出る場合）については、シュレムス II とトラッキング ピクセルの記事で TIA の観点をカバーしています。DMA はその問題を解決するものではなく、別の制約を追加するものです。
Elido がリダイレクト レイヤーで行うこと（および行わないこと）#
Elido は処理者（Processor）であり、管理者（Controller）が同意の姿勢を決定しバナーを運用します。リダイレクト データプレーンは最小限のことを行います。
- UTM パラメーターと顧客自身のクリック識別子を維持します。ベンダー固有の広告識別子（
fbclid、gclid、msclkid、ttclid）は、管理者のアトリビューション対象であるため、デフォルトで転送されますが、ワークスペースごとのオプトアウトも可能です。 - リダイレクト時に広告目的のサーバーサイド イベントを発火させません。ClickHouse に書き込まれる内部的なクリック イベントでは、URL 短縮サービスのための GDPR に基づき、IP は /24 または /48 に切り詰められ、解析されたデバイス フィールドのみが保持されます。これはサードパーティとは共有されません。
- GA4、Meta CAPI、LinkedIn、TikTok、Reddit への同意対応のサーバーサイド コンバージョン転送をサポートしており、ランディング ページが提供する同意状態によってゲートされます。このフォワーダーは
/features/conversion-trackingにあり、設定方法はコンバージョン トラッキングのドキュメント ガイドに記載されています。 - 同意対応の転送が有効な場合、ランディング ページからの
consentペイロードを必要とします。ペイロードがない場合、イベントは黙ってデフォルトで発火されるのではなく、ドロップされます。
/features/analytics の分析ダッシュボードでは、キャンペーンごとの同意状態の内訳（許可、拒否、未設定）が表示され、マーケティング チームは同意拒否によってどれだけのアトリビューションが失われているかを確認できます。
Elido が行わないこと：バナーの実装、同意の事前決定、または実際には同意していないユーザーに対する許可状態の捏造。これらの決定は管理者（Controller）に委ねられており、GDPR と DMA の双方がそれを求めています。
調達における検討事項#
DMA 第 5 条(2)項に基づいて短縮サービスを検討している管理者にとって、3 つの質問があります。
その短縮サービスは、ランディング ページの同意状態に関わらず、リダイレクト時にサードパーティの広告または分析サービスにクリック データを転送していますか？ もしそうなら、それは DMA 第 5 条(2)項の違反リスクであり、停止すべきです。
その短縮サービスは、サーバーサイド コンバージョン エンドポイントへの同意状態の転送をサポートしていますか？ もしサポートしていない場合、管理者はランディング ページとゲートキーパー API の間に別のサーバーサイド タギング プロキシ（GTM サーバー コンテナ、Stape、Snowplow など）を設置する必要があります。
その短縮サービスの分析レイヤーは、集計データをサードパーティと共有していますか？ 一部のマーケティング重視のサービスは「業界ベンチマーク」を公開していますが、それは顧客のクリック データであり、トラフィックの形状からサブグラフが特定可能な場合があります。Wirtschaftsakademie や Fashion ID の下での共同管理者の分析はどうなっていますか？
これらの点について曖昧な対応をする短縮サービスは、管理者が監査で防御しなければならない DMA リスクを増大させます。
結論#
同意モード v2 はマーケティング上の取り組みではありません。Google のタグ プラットフォームを通じて提供される、DMA 第 5 条(2)項への準拠メカニズムです。4 つのシグナルは取得された同意について誠実であり、サーバーサイドの緩和策は同意状態がイベントに付随する場合に機能します。同意が拒否された世界でのアトリビューション損失は現実のものですが、ファーストパーティ識別子の解決策を導入すれば、見かけほど大きくはありません。短縮サービスはリダイレクト全体でクリーンな状態を提供し、管理者が自社のバナーに接続するための同意対応の転送機能を提供します。
2026年第 3 四半期に予定されている EDPB のガイダンスは、基準をさらに引き上げるでしょう。現在の基準のみを考慮して設計するのは短期的です。第 5 条(2)項が意図するもの、つまりサービス間のデータ結合に対する明示的、詳細、かつ自由になされた同意を目指して設計することこそが、次の法執行の波を乗り越えられる立場となります。
関連トピック#
- URL 短縮サービスのための GDPR：DPO が本当に見たいもの — コンプライアンス クラスターの礎石となる記事。
- Safari ITP 後のクリック アトリビューション — ブラウザ側の並行するアトリビューション損失の物語。
- クッキーレス アトリビューションの解説 — 同意拒否後も生き残るファーストパーティ識別子のパターン。
- リダイレクトを介した GA4 サーバーサイド トラッキング — 同意転送が依存する Measurement Protocol の形式。
- シュレムス II とトラッキング ピクセル — 同意を得たデータが大西洋を渡った後に何が起こるか。
- 製品紹介：
/features/analytics— 同意状態の内訳ビュー。 - 運用ガイド：コンバージョン トラッキングのドキュメント ガイド — 同意対応フォワーダーの設定。