> ## Documentation Index > Fetch the complete documentation index at: https://adcp-docs-ja.pier1.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # Web パブリッシャー向け TMP > TMP が Prebid と GAM を使って web ページで事前交渉されたパッケージをどうアクティベートするか。 # Web パブリッシャー向け TMP Web パブリッシャーは通常、ラインアイテム、ターゲティングルール、広告選択を管理するアドサーバー（GAM、Kevel、FreeWheel）を実行します。TMP は Prebid モジュールを通じてこのインフラと統合します — どのディールをアクティベートするかをアドサーバーに伝え、アドサーバーを置き換えません。 ## 今日どう機能するか AdCP ディールで Prebid を実行するパブリッシャーは、`create_media_buy` を通じて定義されたパッケージを持ちます。それらをアクティベートするため、パブリッシャーはアドサーバーで対応するラインアイテムまたは PMP ディールを手動で作成します。ベンダー固有の RTD モジュールが、完全な OpenRTB BidRequest をベンダーの API に送ることでターゲティングシグナルを注入します。これは機能しますが、ベンダーごとの統合を要求し不要なデータを送ります。 TMP は、ベンダー固有の RTD モジュールを、標準プロトコルを話す単一の Prebid モジュールに置き換えます。バイヤーエージェントはコンテキストとアイデンティティを別々に評価し、パブリッシャーは GAM に指示を渡す前に結果をローカルで結合します。 ## Context Match ページがロードされると、TMP Prebid モジュールは Context Match リクエストをルーターに送ります。リクエストはページコンテキストを含みます。パッケージリストは送られません — プロバイダーはこのプレースメントの同期されたパッケージセットを使います。 ### Context Match Request ```json theme={null} { "type": "context_match_request", "request_id": "ctx-7f2a-oakwood-91b3", "property_rid": "01916f3a-9c4e-7000-8000-000000000010", "property_id": "oakwood-publishing-main", "property_type": "website", "placement_id": "article-sidebar-300x250", "seller_agent_url": "https://oakwood.example", "artifact_refs": [ { "type": "url", "value": "https://oakwood.example.com/sustainable-kitchen-2026-03" } ] } ``` 要点: * リクエストごとにパッケージリストは送られない。プロバイダーはメディアバイセットアップからの同期されたパッケージセットを使って、このプレースメントのすべての適格なパッケージを評価する。同じパッケージがすべてのユーザーについて評価され、アイデンティティのコンテキストパスへの漏洩を防ぎ、レスポンスキャッシュを可能にする。 * `artifact_refs` はコンテンツをタイプと値で参照する。バイヤーエージェントはアーティファクトメタデータをそのキャッシュから解決する — リクエストにインラインシグナルは不要。 ### Context Match Response ルーターは各バイヤーエージェントにファンアウトしレスポンスをマージします。各バイヤーは、ターゲティングがコンテンツコンテキストに一致したパッケージのオファーと、キー値として GAM に流れるレスポンスレベルのシグナルを返します。 ```json theme={null} { "type": "context_match_response", "request_id": "ctx-7f2a-oakwood-91b3", "offers": [ { "package_id": "pkg-display-0041" }, { "package_id": "pkg-native-0078" } ], "signals": { "segments": ["sustainability", "home_cooking"], "targeting_kvs": [ { "key": "adcp_seg", "value": "sustainability" }, { "key": "adcp_seg", "value": "home_cooking" }, { "key": "adcp_pkg", "value": "pkg-display-0041" }, { "key": "adcp_pkg", "value": "pkg-native-0078" } ] } } ``` 要点: * `offers` はアクティベートされたパッケージごとに 1 エントリを含む。このプレースメントのプロバイダーの同期されたセットは 3 つのパッケージを含んでいた — この 2 つがキッチン/サステナビリティのコンテキストに一致し、3 つ目（`pkg-display-0103`）は一致せず欠如している。 * web/GAM アクティベーションについては、オファーはシンプル — `package_id` のみ。よりリッチなフィールド（`brand`、`price`、`summary`、`creative_manifest`、`macros`）はそれらを必要とする統合に利用可能だが必須ではない。 * `signals.targeting_kvs` は、Prebid モジュールが GAM 広告リクエストに設定するキー値ペア。GAM ラインアイテムはこれらのキーで一致するよう設定される。 ## Identity Match 別途、TMP Prebid モジュールはユーザーのアイデンティティトークンとパブリッシャーの `seller_agent_url` を伴う Identity Match リクエストを送ります。このリクエストはページコンテキストを運びません。バイヤーは `seller_agent_url` からアクティブなパッケージセットを解決します。モジュールが（下記のように）`package_ids` を明示的に送るとき、構成は現在のページと独立でなければなりません（MUST） — all-active（この publisher でのそのバイヤーのすべてのアクティブパッケージ）または fuzzed（バイヤーが黙って落とす合成の存在しない ID でパディングされたランダムサンプル）のいずれか。ページ固有のサブセットは禁止されています。 ### Identity Match Request ```json theme={null} { "type": "identity_match_request", "request_id": "id-3k9p-oakwood-d4f1", "seller_agent_url": "https://oakwood.example", "identities": [ { "user_token": "tok_uid2_8f2a3b7c", "uid_type": "uid2" }, { "user_token": "XY1a2b3c4d5e6f7g8h9i0jKlMnOpQrSt", "uid_type": "rampid" }, { "user_token": "ID5*aB3xY9kL...", "uid_type": "id5" } ], "package_ids": [ "pkg-display-0041", "pkg-display-0042", "pkg-display-0043", "pkg-native-0078", "pkg-native-0079", "pkg-display-0103", "pkg-display-0104", "pkg-video-0201" ] } ``` 要点: * `request_id` は context match の `request_id` と無関係。2 つは互いから導出可能であってはならない。 * `package_ids` の例は all-active モードを示す: このプレースメントの context match にあった 3 つだけでなく、サイト全体にわたるバイヤーのすべてのアクティブパッケージ。ページ固有のサブセットは禁止 — それはバイヤーがパッケージセットを比較してアイデンティティをコンテキストと相関させることを許す。fuzzed モード（バイヤーが黙って落とす合成 ID でパディングされたランダムサンプル）も許容される。 * `identities` はパブリッシャーが利用可能なすべてのトークン（UID2、ID5、LiveRamp、hashed email、publisher first-party）を運ぶ。各トークンは不透明 — バイヤーはそれを PII に逆変換できない。完全なセットを送ることは、異なるバイヤーが異なるグラフで解決するためマッチ率を最大化する。 ### Identity Match Response バイヤーはユーザーを要求されたすべてのパッケージに対して評価し、適格なパッケージの ID と、ルーターがこのレスポンスをどのくらいキャッシュできるかを定義する TTL を返します。 ```json theme={null} { "type": "identity_match_response", "request_id": "id-3k9p-oakwood-d4f1", "eligible_package_ids": [ "pkg-display-0041", "pkg-display-0042", "pkg-native-0078", "pkg-native-0079", "pkg-display-0104" ], "serve_window_sec": 60 } ``` 要点: * 適格なパッケージのみがリストされる。リストに欠如するパッケージ（例: `pkg-display-0043`、`pkg-display-0103`、`pkg-video-0201`）は不適格。バイヤーはフリークエンシーキャップ、オーディエンスメンバーシップ、購入履歴、その他のアイデンティティベースのシグナルから適格性を計算する。理由はパブリッシャーにとって不透明。 * `serve_window_sec` はルーターにこのレスポンスをどのくらいキャッシュするかを伝える。そのウィンドウ中、ルーターはバイヤーに再クエリせずにキャッシュされた適格性を返す。パブリッシャーはキャッシュされた適格性を使ってページ上のすべてのプレースメントに割り当てる。 * `frequency_capped`、`audience_match`、`recency` フィールドはない。バイヤーの内部的な理由はバイヤーに留まる。 ## アクティベーション: コンテキストとアイデンティティの結合 パブリッシャーは context match と identity match をローカルで結合します。ここで 2 つの半分が一緒になります — ルーターは同じインプレッションについて両方を決して見ません。 ### Step 1: 交差 context match からのオファーを取り、identity match の適格性でフィルターします。 | Package | Context Match | Identity Match | Result | | ------------------ | ------------- | -------------- | -------- | | `pkg-display-0041` | Offered | Eligible | Activate | | `pkg-native-0078` | Offered | Eligible | Activate | | `pkg-display-0103` | Not offered | Not eligible | Skip | 2 つのパッケージのみが生き残る: `pkg-display-0041` と `pkg-native-0078`。 ### Step 2: GAM ターゲティングを設定 Prebid モジュールは context match の `signals.targeting_kvs` を取り、それらをキー値ペアとして GAM 広告リクエストに設定します: ``` adcp_seg = sustainability, home_cooking adcp_pkg = pkg-display-0041, pkg-native-0078 ``` GAM ラインアイテムは `adcp_pkg` 値でターゲットするよう事前設定されています。広告リクエストが `adcp_pkg=pkg-display-0041` で到着すると、GAM はそれを対応するラインアイテムに一致させクリエイティブを提供します。 ### Step 3: GAM が選択 GAM は、TMP アクティベートされたディールと他の需要ソースの両方を含む、すべての適格なラインアイテムにわたって、独自の優先度ルール、競合排除、ペーシングロジックを適用します。TMP は GAM の広告選択を上書きしません。入力を提供します。 ## GAM ラインアイテム設定 各アクティブパッケージについて、パブリッシャーは `adcp_pkg = ` をターゲットにする GAM ラインアイテムを作成します。これが TMP アクティベーションと GAM 広告選択の間のリンクです。 * **ラインアイテムタイプ。** `create_media_buy` からのディール条件に応じて Sponsorship または Standard。保証ディールは Sponsorship、非保証ディールは Standard を使う。 * **優先度。** ディールタイプに基づいて設定。保証ディールは優先度 4-8、非保証は優先度 12-16。これは TMP 需要が GAM の選択ロジックで他のラインアイテムとどう競うかを決める。 * **クリエイティブ割り当て。** `sync_creatives` からの事前同期されたクリエイティブを参照するか、バイヤーが提供する場合は Context Match レスポンスのクリエイティブマニフェストを使う。 * **ライフサイクル。** メディアバイが終了またはキャンセルされると、対応するラインアイテムを非アクティブ化する。ルーターは 1 時間以内にパッケージを Identity Match に含めるのを停止する。 * **自動化。** パブリッシャーは、新しい `create_media_buy` 完了をリッスンしパッケージ詳細を GAM API 呼び出しにマップすることで、ラインアイテム作成を自動化できる。パッケージ ID、ディールタイプ、優先度、クリエイティブ参照はすべてメディアバイレスポンスから利用可能。 ## Prebid 統合 TMP Prebid モジュールは、ベンダー固有の RTD モジュールを置き換える Real-Time Data（RTD）モジュールです。それは [TMP Prebid 提案](/specs/prebid-tmp-proposal) によって定義され、標準の Prebid RTD モジュールインターフェースに従います。完全なフローを扱います: 1. **オークション初期化時**: ページ上の各プレースメントについて TMP ルーターに Context Match リクエストを送る。 2. **context match レスポンス時**: オファーとターゲティングシグナルを保存する。 3. **時間的相関除去の後**: ユーザーのアイデンティティトークンと各バイヤーのすべてのアクティブパッケージ ID を伴う Identity Match リクエストを送る。相関除去は 2 つの部分を持つ — ランダムな 100-2000ms 遅延 **かつ** ランダム化された順序: 各オークションは Identity Match リクエストが先に送られるか Context Match リクエストが先に送られるかのほぼ等しい確率を持つ。 4. **identity match レスポンス時**: context match 結果と結合する。広告ユニットにターゲティングキー値を設定する。 5. **入札リクエスト時**: GAM は TMP ターゲティングキーで豊かにされた広告リクエストを受け取り、通常どおりラインアイテムを選択する。 コンテキストとアイデンティティのリクエスト間の時間的相関除去はプライバシー措置です。ランダムな遅延だけでは不十分 — 固定順序（Identity は常に Context の後）は順序を通じてペアリングを漏らす。モジュールは遅延とどちらのリクエストが先に送られるかの両方をランダム化します。 ### Impression ID の代入 web/Prebid サーフェスでは、**Prebid TMP モジュールが決定層** で、3 層の [`{IMPRESSION_ID}` 鋳造階層](/docs/creative/universal-macros#impression-identification) — パブリッシャー先、決定層 2 番目、TMPX デコード時のバイヤー最後 — の一部です。モジュールはパブリッシャーが既に impression\_id を供給したか（`adUnit.tmp.impressionId` または同等のファーストパーティフック経由）を確認します。そうなら、その値を通過させます。そうでなければ、モジュールが独自に鋳造します。どちらにせよ、GAM 広告リクエストにターゲティングキー `tmp_impression_id` として値を公開します。これは、バイヤーのインプレッションピクセルがクロスアイデンティティ重複排除キーとして使う値です — `{TMPX}` が欠如するコンテキストのみのインプレッションに不可欠で、`{TMPX}` が存在するときでもバイヤーの重複排除パスが一様に保たれるため有用です。 **形式は実装の選択。** Prebid モジュールは ULID、UUID（任意バージョン）、または任意の衝突耐性のある識別子スキームを使ってもよい（MAY） — プロトコルは形式をピン留めしません。 **任意の最適化。** Prebid の `enableTIDs` 設定が `true` のとき、モジュールは別途鋳造する代わりに `adUnit.transactionId` を impression\_id として再利用してもよい（MAY）。`enableTIDs` は Prebid.js 8+ でオプトアウト（プライバシー上の理由で）なので、ほとんどのデプロイは独自に鋳造する必要があります。 ```javascript theme={null} import { ulid } from 'ulid'; // In the TMP Prebid module, at auctionInit. // Resolve the impression_id in priority order: // 1. publisher pre-mint (e.g., server-side, attached as adUnit.tmp.impressionId) // 2. Prebid transactionId (decision-layer reuse) when enableTIDs is on // 3. fresh decision-layer mint (ULID, UUID, or any collision-resistant scheme) function resolveImpressionId(adUnit) { if (adUnit.tmp?.impressionId) { return adUnit.tmp.impressionId; // publisher-side mint — highest priority } if (pbjs.getConfig('enableTIDs') && adUnit.transactionId) { return adUnit.transactionId; // reuse Prebid's tid when available } return ulid(); // decision-layer fresh mint } const impId = resolveImpressionId(adUnit); pbjs.setTargeting(adUnit.code, { tmp_impression_id: impId }); ``` GAM を通じてトラフィックされるバイヤーのクリエイティブトラッキング URL は、標準の GAM マクロ経由でターゲティングキーを参照します: ``` https://buyer.example/imp ?imp_id=%%PATTERN:tmp_impression_id%% &tmpx=%%PATTERN:tmp_tmpx%% &cb=%%CACHEBUSTER%% ``` レンダリング時に、GAM は KV を代入しバイヤーのインプレッショントラッカーが impression\_id を不透明な文字列として受け取ります。KV 名 `tmp_impression_id` は意図的に `hb_*` プレフィックス（Prebid 自身の名前空間）を避け、TMP が発するターゲティングにこのページの他の場所で使われる `adcp_*` 慣例をミラーします。 ## シーケンス図 ``` Page Load | |-- Prebid TMP Module ---> TMP Router (Context) | |-- fan out --> Buyer Agent A | |-- fan out --> Buyer Agent B | |<- merge <--- offers + signals |<--- Context Match Response -- | | (100-2000ms random delay; Context/Identity order randomized | per auction — diagram shows Context-first; Identity-first | runs the two phases in reverse) | |-- Prebid TMP Module ---> TMP Router (Identity) | |-- fan out --> Buyer Agent A | |-- fan out --> Buyer Agent B | |<- merge <--- eligibility |<--- Identity Match Response -- | |-- Join locally: intersect offers with eligibility |-- Set targeting KVs on GAM ad request |-- GAM selects and serves ad ``` ## OpenRTB との共存 ほとんどのパブリッシャーは、OpenRTB 経由で需要を供給する Prebid ヘッダー入札と並んで TMP を実行します。2 つのシステムは補完的です。 * **追加需要としての TMP。** TMP パッケージは GAM でラインアイテムとして現れ、優先度と価格で Prebid ラインアイテムと競う。GAM がイールド決定を扱う — TMP は Prebid を置き換えず、事前交渉された需要を追加する。 * **競合排除。** TMP と Prebid の需要ソースをまたいで衝突するブランドが一緒に現れるのを防ぐため、GAM 競合排除ルールを設定する。 * **収益帰属。** TMP アクティベートされたインプレッションは `get_media_buy_delivery` 経由で追跡され、Prebid インプレッションは既存の SSP レポートを通じて流れる。パブリッシャーは BI 層で再照合する。 * **タイムアウトの独立性。** TMP と Prebid のリクエストは並列で実行される。TMP タイムアウト（50ms）は通常 Prebid タイムアウト（1000-1500ms）より速いので、TMP 結果は GAM が必要とする前に準備できる。 ## Web のプライバシー制約 これらの制約はすべてのサーフェスに適用されますが、web のケースについて再述する価値があります: * **context match はユーザーデータを運ばない。** cookie なし、ユーザートークンなし、IP アドレスなし。プロバイダーはプレースメント上のすべてのユーザーについて同じ同期されたパッケージセットを評価する。 * **identity match はページデータを運ばない。** URL なし、コンテンツシグナルなし、プレースメント ID なし。`package_ids` リストは、送られるとき、現在のページと独立した構成（all-active または fuzzed）を持つ — 決してページ固有のサブセットではない。 * **パブリッシャーがローカルで結合する。** ルーターは同じインプレッションについてコンテキストとアイデンティティの両方を決して見ない。ページコンテキストとユーザーアイデンティティの両方を既に持つパブリッシャーのみが交差を実行する。 * **時間的相関除去。** 2 つのリクエスト間のランダムな遅延 **かつ** ランダム化された順序（Context Match または Identity Match が等しく先に送られる可能性）が、ネットワークレベルでのタイミングと順序ベースの相関を防ぐ。固定順序は順序を通じてペアリングを漏らすため、ランダムな遅延だけでは不十分。