Guides

SSP, DSP, and ad exchange: the OpenRTB ecosystem, explained

SSP, DSP, and ad exchange are the three acronyms every programmatic explainer throws at you at once. The clearest way to keep them straight is to anchor each to a role in the OpenRTB auction, because that is the protocol they all speak. Here is who does what, and why the boundaries are fuzzier than the diagrams suggest.

The three roles

SSP (supply-side platform). Works for publishers. It takes a publisher's inventory and makes it available for sale programmatically, handling yield, floors, and demand connections. Its job is to get the highest price for an impression.
DSP (demand-side platform). Works for advertisers. It decides, per impression, whether to bid and how much, based on targeting, budget, and the signals in the request. Its job is to buy the right impressions at the right price.
Ad exchange. The marketplace that runs the auction. It receives an impression opportunity, asks buyers to bid, picks a winner, and returns the winning ad. Many SSPs operate their own exchange, which is where the confusion starts.

How they map to OpenRTB

OpenRTB does not use the marketing acronyms. Its reference model names the roles functionally, and the mapping is direct:

The Exchange in the spec is the party that sends the bid request and runs the auction. An ad exchange, or the exchange side of an SSP, plays this role.
The Bidder is the party that receives the request and returns a bid response. A DSP is a bidder.
The Seat is the advertiser or agency on whose behalf a bidder acts, identified in wseat and seatbid.seat.
The Publisher owns the inventory, described in site.publisher or app.publisher. An SSP represents it.

So a single OpenRTB auction is: an exchange (run by or connected to an SSP) sends a bid request to many bidders (DSPs), each bidding for its seats (advertisers), over one impression from a publisher.

The request flow

Publisher            has an impression to sell
  -> SSP             packages it, applies floors, connects demand
    -> Exchange      broadcasts an OpenRTB bid request to bidders
      -> DSP(s)      each returns a bid response (or a 204 no-bid)
    <- Exchange      picks the winner, fires win/billing notices
  <- SSP             returns the winning ad to the page

Every arrow between the exchange and the DSPs is an OpenRTB message: a bid request out, a bid response back.

Why the lines blur

The clean three-box diagram rarely survives contact with a real supply path. SSPs run exchanges, so "SSP" and "exchange" often name the same company. Large platforms operate on both sides. And an impression frequently passes through more than one SSP or reseller before it reaches a DSP, which is exactly why the supply chain trust stack (ads.txt, sellers.json, schain) exists: to make that path auditable. Upstream of all of this, publishers often run header bidding to call several SSPs at once. The roles are functions, not fixed companies.

Side by side

	SSP	Ad exchange	DSP
Works for	Publishers	The marketplace itself	Advertisers
Goal	Maximize yield	Clear the auction	Buy efficiently
OpenRTB role	Publisher side / exchange	Exchange	Bidder
Sends or receives	Builds the request	Sends the request	Returns the response

Where validation fits

Whichever role you sit in, the bytes crossing between exchange and bidder are OpenRTB. An SSP or exchange builds bid requests; a DSP builds bid responses. Both drift from the spec in the same ways, and neither side gets an error when they do, only fewer bids or rejected responses. Paste either into the tester, or gate a build with the CLI. The common mistakes guide covers what usually goes wrong.

Sources

OpenRTB 2.6 specification: Section 1.5 (Terminology) and Section 2 (Reference Model)