Answers

What is curation in programmatic advertising?

Short answer

Curation is the packaging of inventory plus data into a ready-to-buy deal, assembled on the sell side by a curator: a data company, an agency, a retail media network, or the SSP itself. The buyer sees one deal ID; the audience segments and inventory filters behind it are applied upstream, before the request is sent. In OpenRTB a curated deal arrives as an ordinary entry in imp.pmp.deals with no marker saying it was curated, which is exactly why curation is hard to audit. IAB Tech Lab's Curation object addresses that in the separate Deal Sync API, not in the bid request.

What a curator assembles

A curator takes supply it does not own, applies a filter, and sells the result as a package. The filter can be audience data (segments from a data provider or a retail media network), inventory quality criteria (an allowlist of domains or apps, an MFA exclusion list), or contextual and attention signals. The output is a deal id that a buyer can target in its DSP like any other private marketplace deal.

Two things make this different from a publisher-direct PMP. The selection happens on the sell side, before the bid request leaves the SSP, so the buyer never sees the impressions that were filtered out. And the curator sits in the middle of the money: its fee is taken from the same transaction, on top of the exchange fee.

How it looks in the bid request

It looks like a deal, because it is one. The relevant fragment of the request is the same one every PMP uses:

"imp": [{
  "id": "1",
  "pmp": {
    "private_auction": 1,
    "deals": [{
      "id": "curator-deal-8842",
      "bidfloor": 12.5,
      "bidfloorcur": "USD",
      "at": 1
    }]
  }
}]

There is no curator field, no fee field, and no description of the filter that produced this impression. The Deal object carries id (required), bidfloor, bidfloorcur, at, wseat, wadomain, guar, mincpmpersec, and durfloors. That is the whole vocabulary. See OpenRTB deals and PMP for how the four deal types map onto those fields.

Audience data attached to the impression travels separately, in user.data or content.data, where each Data object has an id and name identifying the provider and an array of segment entries. A curator that passes its segments through the request is identifiable there. A curator that applies them purely as an upstream filter is not identifiable at all.

Where the Curation object actually lives

IAB Tech Lab's answer to curation opacity is a Curation object carrying terms, inventory scope, and fee disclosure. It is defined in the Deal Sync API, a one-directional SSP-to-DSP push of static deal metadata that runs alongside the bidstream. The specification states plainly that it is not included in the OpenRTB request or response, and that criteria sent through it are not guaranteed to match what arrives in the live bid request.

For anyone building against OpenRTB, the practical consequence is that curation transparency is a sidecar feed to reconcile against, not a field to parse. More context in what the IAB Tech Lab 2026 roadmap means for OpenRTB.

What a buyer can still check

  • Deal id integrity. A bid that names a dealid never offered in the request is invalid, and exchanges drop it (loss reason 4, Invalid Deal ID).
  • The right floor. A deal-backed bid clears the deal's bidfloor, not the impression's. Bidding against the wrong one produces loss reason 101.
  • Seat restrictions. wseat on the deal, and wseat or bseat on the request, decide whose bids are eligible.
  • Supply path. Curated supply still carries source.schain, so the chain can be reconciled the same way as any other. See supply path optimization.

RTBlint validates a bid response against the request that produced it, which is where those checks live: openrtb.bid.dealid_unknown and openrtb.seatbid.seat_not_allowed both fire on a paired request and response in the tester.

Sources