Documentation Index
Fetch the complete documentation index at: https://docs.adcontextprotocol.org/llms.txt
Use this file to discover all available pages before exploring further.
Migrating from AXE to TMP
AXE and TMP solve the same problem — impression-time execution for pre-negotiated packages — with different architectures. AXE sends a full request (user + context + device) and returns opaque segment IDs. TMP splits the request into two structurally separated operations and returns offers and eligibility.
This page maps AXE concepts to TMP equivalents and describes how to run both in parallel during migration.
Concept Mapping
| AXE | TMP | Notes |
|---|
axei (include segment) | Context Match offer | Package matched the content |
axex (exclude segment) | Package absent from eligible_package_ids | User fails suppression list, audience rule, or buyer-side frequency check |
axem (macro data) | Creative manifest + Offer macros + {TMPX} | Structured assets move to the creative manifest; dynamic key-values pass through Offer macros; per-user exposure tracking uses the {TMPX} macro from Identity Match |
| Orchestrator AXE endpoint | TMP Router | Single binary with two isolated code paths |
| Prebid Real-Time Data (RTD) module | TMP Prebid module | Replaces vendor-specific RTD modules with a single module |
axe_integrations URL | trusted_match capability | In get_adcp_capabilities response |
| OpenRTB-style request | Context Match + Identity Match | Two requests instead of one bundled request |
| Segment key-values on ad server | Targeting key-values from offers | Same GAM integration, different source |
What Changes for Each Role
Buyer agents
Before (AXE): Upload audience segments to an orchestrator. Reference segment IDs in axe_include_segment / axe_exclude_segment on media buys.
After (TMP): Expose Context Match and Identity Match endpoints. Evaluate packages against content signals (Context Match) and user eligibility (Identity Match) in real time. Return offers with creative manifests and eligibility decisions.
Key difference: Your agent makes real-time decisions instead of pre-computing segment memberships. You have full control over targeting logic — no intermediary orchestrator.
Publishers
Before (AXE): Enable the orchestrator’s Prebid RTD module. Accept axei/axex/axem key-values. Create GAM line items targeting those key-values.
After (TMP): Deploy a TMP Router (or use the TMP Prebid module). Accept offers and eligibility from the router. Set GAM targeting key-values from offer signals and pass through Offer macros for dynamic creative rendering. GAM line items target adcp_pkg instead of axei/axex.
Key difference: The router replaces the orchestrator’s RTD module. GAM line items reference package IDs instead of opaque segment IDs.
Orchestrators
Before (AXE): Operate AXE endpoints, manage segment state, distribute Prebid RTD modules.
After (TMP): Orchestrators can operate TMP Routers on behalf of publishers, or transition to a buyer-side role (operating buyer agent TMP endpoints). The orchestrator-as-middleman role is optional in TMP — buyers and publishers can connect directly through the router.
Parallel Operation
During migration, publishers can run AXE and TMP simultaneously:
- Keep existing AXE RTD module in Prebid alongside the new TMP module
- New media buys use TMP (no
axe_include_segment / axe_exclude_segment)
- Existing media buys continue using AXE segments until they expire
- GAM line items for both: AXE line items target
axei/axex, TMP line items target adcp_pkg
TMP provides real-time per-user exposure tracking via the {TMPX} macro. During parallel operation, both AXE and TMP impressions feed into the buyer’s exposure store — AXE via the orchestrator’s reporting, TMP via the buyer’s impression pixel receiving encrypted TMPX tokens. There is no risk of double-counting because the buyer’s exposure store deduplicates by user token and package ID regardless of source.
Cutover
When all active media buys use TMP:
- Remove the orchestrator’s RTD module from Prebid
- Remove AXE-targeted GAM line items
- Update
get_adcp_capabilities to remove axe_integrations and keep trusted_match
Targeting Overlay Migration
AXE targeting fields in create_media_buy map to TMP behavior:
| AXE field | TMP equivalent |
|---|
axe_include_segment | Context Match — buyer evaluates targeting in real time |
axe_exclude_segment | Identity Match — buyer checks suppression and audience rules |
What Doesn’t Change
create_media_buy — Same task, same schema (minus AXE fields)get_media_buy_delivery — Same delivery reportingsync_creatives — Same creative sync- GAM as the ad server — TMP still sets key-values that GAM evaluates
- Geographic and other targeting overlays — These are media buy fields, not execution-layer concerns
OpenRTB User.eids cross-walk
For buyers bridging from OpenRTB-shaped pipelines, the TMP Identity Match identities[] shape maps to OpenRTB 2.6 User.eids[] as follows:
AdCP TMP identities[].uid_type | OpenRTB 2.6 User.eids[].source | Notes |
|---|
rampid / rampid_derived | liveramp.com | atype: 3 (person-based, per IAB AdCOM Agent Types) |
id5 | id5-sync.com | |
uid2 | uidapi.com | atype: 3 |
euid | euid.eu | |
pairid | iabtechlab.com/pair | |
maid | adid (Android) / idfa (iOS) | Atypically carried on Device.ifa rather than User.eids in OpenRTB |
hashed_email | liveintent.com or buyer-specific | atype: 3 |
publisher_first_party | publisher-defined source URL | |
other | buyer-defined source URL | |
user_token field corresponds to User.eids[].uids[].id. AdCP carries up to 3 identities per Identity Match request (HPKE size budget — see TMPX size budget); OpenRTB has no such limit, so a buyer bridging from OpenRTB into TMP must apply a buyer-configured priority order to truncate (typically: deterministic graphs first — UID2, RampID — then probabilistic or publisher-scoped IDs).