AXE から TMP への移行
AXE と TMP は同じ問題 — 事前交渉されたパッケージのインプレッション時実行 — を異なるアーキテクチャで解決します。AXE は完全なリクエスト（ユーザー + コンテキスト + デバイス）を送り、不透明なセグメント ID を返します。TMP はリクエストを 2 つの構造的に分離された操作に分割し、オファーと適格性を返します。 このページは AXE の概念を TMP の同等物にマップし、移行中に両方を並行して実行する方法を記述します。概念マッピング
各ロールで何が変わるか
バイヤーエージェント
Before（AXE）: オーディエンスセグメントをオーケストレーターにアップロード。メディアバイのaxe_include_segment / axe_exclude_segment でセグメント ID を参照。
After（TMP）: Context Match と Identity Match エンドポイントを公開。コンテンツシグナル（Context Match）とユーザー適格性（Identity Match）に対してパッケージをリアルタイムで評価。クリエイティブマニフェストと適格性決定を伴うオファーを返す。
鍵となる違い: あなたのエージェントは、セグメントメンバーシップを事前計算する代わりにリアルタイムの決定を下します。ターゲティングロジックの完全な制御を持ちます — 仲介オーケストレーターなし。
パブリッシャー
Before（AXE）: オーケストレーターの Prebid RTD モジュールを有効化。axei/axex/axem キー値を受け入れ。それらのキー値をターゲットにする GAM ラインアイテムを作成。
After（TMP）: TMP ルーターをデプロイ（または TMP Prebid モジュールを使用）。ルーターからオファーと適格性を受け入れ。オファーシグナルから GAM ターゲティングキー値を設定し、動的クリエイティブレンダリングのためオファー macros を通過。GAM ラインアイテムは axei/axex の代わりに adcp_pkg をターゲット。
鍵となる違い: ルーターがオーケストレーターの RTD モジュールを置き換えます。GAM ラインアイテムは不透明なセグメント ID の代わりにパッケージ ID を参照します。
オーケストレーター
Before（AXE）: AXE エンドポイントを運用、セグメント状態を管理、Prebid RTD モジュールを配布。 After（TMP）: オーケストレーターは、パブリッシャーに代わって TMP ルーターを運用するか、バイヤー側のロール（バイヤーエージェント TMP エンドポイントを運用）に移行できます。仲介者としてのオーケストレーターのロールは TMP では任意です — バイヤーとパブリッシャーはルーターを通じて直接接続できます。並行運用
移行中、パブリッシャーは AXE と TMP を同時に実行できます:- Prebid で新しい TMP モジュールと並んで 既存の AXE RTD モジュールを保持
- 新しいメディアバイ は TMP を使う（
axe_include_segment/axe_exclude_segmentなし） - 既存のメディアバイ は期限切れになるまで AXE セグメントを使い続ける
- 両方の GAM ラインアイテム: AXE ラインアイテムは
axei/axexをターゲット、TMP ラインアイテムはadcp_pkgをターゲット
{TMPX} マクロ 経由でリアルタイムのユーザーごとの露出トラッキングを提供します。並行運用中、AXE と TMP のインプレッションの両方がバイヤーの露出ストアに供給されます — AXE はオーケストレーターのレポート経由、TMP は暗号化 TMPX トークンを受け取るバイヤーのインプレッションピクセル経由。バイヤーの露出ストアがソースにかかわらずユーザートークンとパッケージ ID で重複排除するため、二重カウントのリスクはありません。
切り替え
すべてのアクティブなメディアバイが TMP を使うとき:- Prebid からオーケストレーターの RTD モジュールを削除
- AXE ターゲットの GAM ラインアイテムを削除
axe_integrationsを削除しtrusted_matchを保持するようget_adcp_capabilitiesを更新
ターゲティングオーバーレイの移行
create_media_buy の AXE ターゲティングフィールドは TMP の動作にマップします:
新しいメディアバイは AXE フィールドを完全に省略すべきです。バイヤーエージェントの Context Match と Identity Match ロジックが、オーケストレーターのセグメント評価を置き換えます。
変わらないもの
create_media_buy— 同じタスク、同じスキーマ（AXE フィールドを除く）get_media_buy_delivery— 同じ配信レポートsync_creatives— 同じクリエイティブ同期- アドサーバーとしての GAM — TMP は依然として GAM が評価するキー値を設定
- 地理的およびその他のターゲティングオーバーレイ — これらはメディアバイフィールドであり、実行層の関心事ではない
OpenRTB User.eids クロスウォーク
OpenRTB 形状のパイプラインから橋渡しするバイヤーのために、TMP Identity Matchidentities[] 形状は OpenRTB 2.6 User.eids[] に次のようにマップします:
TMP
user_token フィールドは User.eids[].uids[].id に対応します。OpenRTB の User.eids[].uids[].atype は AdCP のより高忠実度の uid_type から導出されます。別個の AdCP フィールドではありません。橋渡しコードは上の表から atype を計算すべきで、uid_type と食い違いうる独立したユーザー提供の atype 値を追加すべきではありません。
AdCP は Identity Match リクエストごとに最大 3 つのアイデンティティを運びます（HPKE サイズ予算 — TMPX サイズ予算 を参照）。OpenRTB にはそのような制限がないため、OpenRTB から TMP に橋渡しするバイヤーは、切り詰めのためにバイヤー設定の優先順位（通常: 決定論的グラフを先に — UID2、RampID — 次に確率的またはパブリッシャースコープの ID）を適用しなければなりません。