> ## Documentation Index
> Fetch the complete documentation index at: https://docs.interchange.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Real-time targeting (TMP)

> Serve buyer demand that needs request-time signals — cross-publisher frequency capping, audience activation, and contextual/URL targeting — by connecting your storefront to the Trusted Match Protocol.

**TMP** — the **Trusted Match Protocol** — is the open [AdCP](https://adcontextprotocol.org) 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).

<Note>
  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.
</Note>

## What you get

Three buyer capabilities your storefront can answer once TMP is connected:

| Capability                            | What it does for buyers                                                                                                                | How TMP delivers it                                                                                             |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| **Cross-publisher frequency capping** | Honor a buyer's per-user exposure budget across every publisher they run — including yours — so they don't over-serve the same person. | Request-time exposure check keyed to identity.                                                                  |
| **Audience syndication**              | Let buyers activate their own audiences against your inventory: "is this user eligible for my package?" answered in real time.         | **Identity Match** — returns eligible package IDs and TTLs without exposing identity tokens to the wrong party. |
| **Advanced & contextual targeting**   | Target by geography, page URL, and content signals evaluated on the live request rather than a stale catalog.                          | **Context Match** — evaluates geo, URL, and content-artifact signals; returns offers and enrichment.            |

<Tip>
  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.
</Tip>

## 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.

<CardGroup cols={2}>
  <Card title="1 · Prebid publishers" icon="rectangle-ad">
    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.
  </Card>

  <Card title="2 · Run your own agent" icon="box">
    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.
  </Card>
</CardGroup>

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](/v2/storefront/tmp/prebid-setup). 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

<Note>
  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.
</Note>

## Related

<CardGroup cols={2}>
  <Card title="Frequency caps" icon="gauge-high" href="/v2/guides/frequency-caps">
    How buyer-side, cross-publisher caps work — enforced across the publishers running a buyer, including TMP-connected storefronts.
  </Card>

  <Card title="Inventory sources" icon="plug" href="/v2/storefront/inventory-sources/overview">
    How your storefront draws on the inventory TMP targets.
  </Card>

  <Card title="AdCP Trusted Match Protocol" icon="book" href="https://docs.adcontextprotocol.org/docs/trusted-match/router-architecture">
    The open protocol and router architecture behind real-time targeting.
  </Card>
</CardGroup>