Skip to main content

​
Context Match と Identity Match

TMP は 2 つの操作を定義します。それらは設計上独立です — 別々のインフラで処理され、異なるデータを運び、異なる問いに答えます。パブリッシャーはそれらの結果を結合して最終的なアクティベーション決定を下します。 このページは、具体例を使って両操作と結合を説明します。

​
シナリオ

リテールパブリッシャーは、バイヤーエージェントからの 3 つのアクティブな AdCP メディアバイを持ちます。各メディアバイはパッケージを含みます:
  • Package A: スポンサープロダクト — コーヒーブランド、カルーセルフォーマット、検索とカテゴリーページで利用可能
  • Package B: ホームページテイクオーバー — プレミアムディスプレイ、ホームページのみで利用可能
  • Package C: 季節プロモーション — アイス飲料、ネイティブフォーマット、夏の間サイト全体で利用可能
買い物客が「best cold brew」を検索します。パブリッシャーの検索結果ページがロードされます。

​
Context Match

パブリッシャーは Context Match リクエストを TMP ルーターに送り、それが各バイヤーのエージェントにファンアウトします。リクエストはページコンテキストを含みます。ユーザーアイデンティティもパッケージリストも含みません — バイヤーエージェントはこのプレースメントに同期されたパッケージセットを使います。

​
パブリッシャーが送るもの

バイヤーエージェントはページが何についてか — コーヒー、ポジティブな購入意図、カリフォルニア — を見て、そのコンテキストに対してパッケージを評価します。欠けているものに注意してください: ユーザー ID なし、デバイス情報なし、セッショントークンなし、IP アドレスなし。

​
バイヤーが応答するもの

バイヤーエージェントは各パッケージをコンテキストに対して評価します。Package B はホームページのみなので、検索結果ページに一致しません。Package A と C は一致します。バイヤーはそれぞれのオファーを返します。
バイヤーは一致したパッケージごとにオファーを返します。各オファーは package_id と、任意で brand、price、summary、creative_manifest、macros を運びます。summary はパブリッシャーに関連性を判断するのに十分なものを与えます。クリエイティブマニフェストがインラインで存在するとき、パブリッシャーはレンダリングに必要なすべてを持ちます。大きなクリエイティブ（例: VAST 動画）については、マニフェストは埋め込む代わりに URL 経由で外部アセットを参照します。レスポンスは、パブリッシャーがアドサーバーに渡せるエンリッチメントシグナル — オーディエンスセグメントとターゲティングキー値 — も含みます。

​
Context Match が決して運ばないもの

  • ユーザー ID（ハッシュ化されたものでも他でも）
  • デバイス識別子
  • セッショントークン
  • IP アドレス
  • 特定のユーザーを識別しうる任意のデータ
これはポリシー制限ではありません。アイデンティティデータへのアクセスを持たないルーターのコンテキストコードパスによって強制されます — 共有メモリなし、共有状態なし、アイデンティティコードパスへの通信チャネルなし。TEE アテステーション はこの分離を独立に検証可能にできます。

​
Identity Match

別途 — そしてランダムな遅延とランダムな順序で、2 つのリクエストがタイミングやどちらが最初に着くかでペア化されないよう — パブリッシャーは Identity Match リクエストを TMP ルーターに送り、それが各バイヤーのエージェントにファンアウトします。リクエストはパブリッシャーの seller_agent_url とアイデンティティトークンを含みます。バイヤーは seller_agent_url からアクティブなパッケージセットを解決するか、パブリッシャーが送るとき明示的な package_ids リストに対して評価します。リクエストはページコンテキストを含みません。

​
パブリッシャーが送るもの

identities の各エントリは {user_token, uid_type} ペアです。パブリッシャーは利用可能なすべてのトークンを含めるべきです（SHOULD） — バイヤーは一致するグラフで解決し、より多くのトークンを送ることで追加のページコンテキストを漏らさずにマッチ率を最大化します。各 user_token は既存のアイデンティティプロバイダー（ID5、LiveRamp、UID2）から来るか、パブリッシャー生成です。uid_type はバイヤーにどのアイデンティティグラフに対して解決するかを伝え、試行錯誤のマッチングを避けます。consent オブジェクトはユーザーの同意シグナルを運びます — 規制された管轄区域のバイヤーはそれなしにトークンを処理してはなりません（MUST NOT）。トークンはバイヤーにとって不透明です — バイヤーはそれらを自身のアイデンティティグラフにマップでき（一致があれば）ますが、PII に逆変換したり任意のページコンテキストと相関させたりできません。 欠けているものに注意してください: URL なし、検索クエリなし、コンテンツシグナルなし、トピック ID なし。バイヤーエージェントはこのリクエストを純粋にユーザーアイデンティティとパッケージ適格性に基づいて評価します。

​
バイヤーが応答するもの

バイヤーは、このユーザーがパッケージ A と B に適格であることをレポートします。Package C は欠けています — ユーザーは適格でありません。パブリッシャーはなぜかを知る必要はありません — フリークエンシーキャッピング、オーディエンス不一致、その他の失格理由はバイヤー内部です。 serve_window_sec: 60 はルーターに伝えます: 「これを 60 秒キャッシュせよ。」ルーターはこのキャッシュされた適格性を使って、存在するあらゆるプレースメント — 単一スロット、CTV 広告ポッド、複数の広告ユニットを持つページ — を、バイヤーに再クエリせずに埋めます。パブリッシャーはプレースメントをまたいでどう割り当てるかを決めます。

​
Identity Match が決して運ばないもの

  • ページ URL
  • コンテンツハッシュ
  • 検索クエリ
  • トピック ID
  • コンテンツレーティング
  • ユーザーが何を見ているかを識別しうる任意のデータ
これはコンテキストデータへのアクセスを持たないルーターのアイデンティティコードパスによって強制されます — 共有メモリなし、共有状態なし、コンテキストコードパスへの通信チャネルなし。TEE アテステーションはこの分離を独立に検証可能にできます。

​
パブリッシャー側の結合

パブリッシャーは今や 2 つの独立したレスポンスを持ちます。彼らはそれらを自身のインフラで結合します — バイヤーエージェントもルーターも結合された結果を見ません。
パブリッシャーは Package A をどうレンダリングするかを既に知っています — それはスポンサーカルーセルスロットにマップします。インラインクリエイティブマニフェストは必要なカタログアイテムとアセットを運びます。パブリッシャーは残りを扱いました。

​
オファーモデル

TMP のレスポンスモデルはオファーです。オファーは package_id（必須）と任意フィールド: brand、price、summary、creative_manifest、macros（動的な値のキー値マップ）を運びます。 シンプルなケース（GAM/Prebid）: オファーは package_id を運びます。パブリッシャーは、ラインアイテムマッチングのため targeting_kvs シグナル経由で package_id を GAM に流します。macros マップは、GAM がレンダリング時にクリエイティブに挿入できる動的な値（例: スポンサーラベル、プロモーションテキスト）を運びます。 リッチなケース（AI アシスタント、動的リテール）: オファーは summary（「cold brew 50% オフ — レシピ統合」）を含むため、パブリッシャーは関連性を判断でき、レンダリングに必要なすべてを持つインライン creative_manifest を含みます。大きなクリエイティブ（例: VAST 動画）については、マニフェストは完全なペイロードを埋め込む代わりに URL 経由で外部アセットを参照します。 動的ブランド: プロダクトが dynamic_brands をサポートするとき、バイヤーは、事前設定されたパッケージブランドにロックされる代わりに、マッチ時にポートフォリオから選択して、オファーに brand を含められます。 可変価格: プロダクトが可変価格をサポートするとき、バイヤーはオファーに price を含められます。 クリエイティブマニフェストは、カタログアイテム、テキスト、画像、レンダリングに必要な他すべてを運びます。これは既存の CreativeManifest スキーマを再利用します。 ユーザーごとの露出トラッキングは TMPX マクロ — パブリッシャーがクリエイティブトラッキング URL に代入する Identity Match からの暗号化トークン — を通じて流れます。バイヤーのインプレッションピクセルがトークンを復号し、ユーザーごとの露出をリアルタイムでログします。get_media_buy_delivery 経由の集約配信レポートが、再照合とペーシングデータを提供します。

​
エンリッチメントシグナル

Context Match レスポンスは、パッケージアクティベーションと並んでエンリッチメントシグナルを含められます:
  • セグメント: パブリッシャーのアドサーバーにターゲティングシグナルとして流れるオーディエンスまたはコンテキストセグメント（例: 「coffee_enthusiast」「high_purchase_intent」）。
  • ターゲティングキー値: パブリッシャーがラインアイテムターゲティング、レポート内訳、リアルタイム決定に使える任意のキー値ペア（例: category_affinity=beverages）。
エンリッチメントシグナルは加算的です — 特定のパッケージに結びついていません。バイヤーエージェントは、パッケージをアクティベートしないときでもエンリッチメントシグナルを返し、需要ソースではなくデータプロバイダーとして価値を提供するかもしれません。 これが既存の RTD（Real-Time Data）モジュールが今日機能する方法です。TMP はエンリッチメントとパッケージアクティベーションを単一のプロトコルに統一するため、バイヤーエージェントは 1 つのレスポンスで両方をできます。

​
パッケージリスト管理

Identity Match は、特定のバイヤーのアクティブなパッケージ ID すべてを送ります — Context Match で一致したものだけではありません。これは意図的です: バイヤーがどのパッケージがページコンテンツに一致したかを相関させるのを防ぎます。バイヤーがハイキング記事に一致したパッケージのみを受け取ったら、ユーザーがハイキングについて読んでいたと知ってしまいます。 パッケージリストは、create_media_buy 経由で新しいメディアバイが作成されたときに更新されます。ルーターは、パブリッシャーとのバイヤーのメディアバイ履歴から導出された、バイヤーごとのアクティブなパッケージリストを維持します。 Context Match では、任意の package_ids フィールドが、パブリッシャーが特定の理由を持つとき評価を絞れます — 例えば、動画パッケージのみが適用される CTV ポッド構成。これは Identity Match に影響しません: Identity Match が package_ids を送るとき、その構成は現在のプレースメントと独立でなければなりません（all-active または fuzzed）、プレースメント固有のサブセットではありません。 期限切れまたはキャンセルされたメディアバイからの古いパッケージは、1 時間以内にアクティブリストから削除されるべきです。ルーターがこのクリーンアップに責任を負います。