Skip to main content
TMP — the Trusted Match Protocol — is the open AdCP standard for real-time targeting signals. When a buyer evaluates your inventory at auction time, the TMP Router sends a small request to one or more match providers, merges their responses, and hands the buyer back a set of targeting signals. The router does not make the buying decision — it enriches the request so a buyer can target the right user, in the right context, on your inventory. Connecting your storefront to TMP lets you serve demand that needs signals you can’t answer from your catalog alone. It generalizes the old single-vendor RTD module — one provider, header-bidding only — into a multi-provider, multi-surface standard (web, app, CTV, retail media, and agent-to-agent).
TMP is request-time targeting, not a new ad server. It sits alongside the ad stack you already run — your header-bidding setup or your own agent — and adds signals to buyer requests. Your inventory, pricing, and delivery stay where they are. TMP always means the Trusted Match Protocol — an open standard, not any vendor’s or SSP’s platform.

​
What you get

Three buyer capabilities your storefront can answer once TMP is connected:
These map onto the two TMP request types: Context Match (what is this request about — geo, URL, content) and Identity Match (who is this user eligible for). The two paths are kept structurally separate, so the context path never sees identity data and the identity path never sees the URL. This separation is what makes TMP privacy-preserving by design: no single request ever pairs who the user is with what they’re reading, so no provider can assemble a browsing profile — the protocol’s structure enforces it, not a policy promise.

​
Why it matters for your storefront

Buyers increasingly send briefs that require request-time signals — a campaign with a cross-publisher frequency cap, an audience the buyer wants to activate, a contextual targeting rule. If your storefront isn’t connected to TMP, those briefs can’t be filled against your inventory and the demand routes to sellers who can serve it. Enabling TMP widens the demand your storefront can cover rather than changing what you sell or for how much.

​
Do I need this if demand already flows?

Yes — if you want the demand that needs it. The demand you see today doesn’t depend on TMP: installing the module doesn’t gate, change, or re-route what already flows. What the install adds is the demand you can’t see today — briefs that require request-time signals currently skip your inventory because it can’t answer them. The code you install is one Prebid module that enriches the ad requests you already serve; there’s no new ad server and no change to how you sell.

​
How you connect — one router, two ways

The same open-source TMP Router is delivered two ways. Pick the one that matches how you run ads today.

1 · Prebid publishers

Run header bidding (Google Ad Manager / Prebid)? Add the Scope3 TMP module to Prebid.js or Prebid Server. It calls the hosted TMP Router and returns the merged signals as targeting keys — no infrastructure for you to run.

2 · Run your own agent

Operate your own ad stack or sales agent? Self-host the TMP Router — a single open-source container you deploy next to your product. For confidential operation, run it in a Trusted Execution Environment (TEE): attestation proves you’re running the audited build, so credentials are released to it and your data stays protected.
Both deployments speak the same protocol and serve the same three capabilities. For prebid publishers, step-by-step setup — install, credentials, and how to confirm it’s serving — is in Set up TMP with Prebid. The self-hosted runbook arrives with that path’s rollout.

​
What the connection does (and what the credentials are for)

TMP is designed to be private and minimal:
  • Small footprint. The router exchanges a few hundred bytes of JSON per request, not your full ad request.
  • Structural privacy. Context and identity code paths are separated; identity forwards carry only the minimum data each provider declared, re-signed per provider.
  • Credentials. The prebid module authenticates with an organization ID and an auth key. A self-hosted router uses a signing keypair so providers can verify that requests genuinely came from your router.
  • Attestation (self-host). Running the router in a TEE lets us release your credentials only to a verified, unmodified build — you don’t have to take the operator’s word that the right code is running.

​
Availability

The prebid integration is the established path today. The self-hosted container and TEE attestation are rolling out as part of TMP onboarding — talk to Scope3 to get set up and to receive your credentials. Contextual and URL-based targeting is rolling out now — check with Scope3 on current availability for your storefront.

Frequency caps

How buyer-side, cross-publisher caps work — enforced across the publishers running a buyer, including TMP-connected storefronts.

Inventory sources

How your storefront draws on the inventory TMP targets.

AdCP Trusted Match Protocol

The open protocol and router architecture behind real-time targeting.