DSP ↔ SSP / Exchange: RTB auction segment
Purpose
This document explains the DSP ↔ SSP / Exchange auction flow, the segment where standardization is strongest in the ad platform stack. It serves as the baseline for understanding where OpenRTB is directly applied.
Key Takeaways
- This is the primary segment where OpenRTB operates most directly.
- SSPs or exchanges construct the bid request, and DSPs return the bid response.
imp,site/app,device,user,source,regs, andpmpare central on the request side.price,adm,nurl,burl,dealid, andcridmatter on the response side.
Main concerns in this segment
| Concern | Description |
|---|---|
| Bid evaluation | whether the DSP will bid and at what price |
| Auction control | auction type, timeout, blocked categories, seat constraints |
| Creative delivery | which markup or VAST payload is returned on a winning bid |
| Deal handling | how PMP and deal conditions are applied |
| Privacy and regulation | how regs, consent, ID signals, and supply transparency are interpreted |
Standard protocol status
| Item | Assessment |
|---|---|
| Primary standard protocol | OpenRTB |
| Main scope | auction requests and responses between SSP / Exchange and DSP |
| Practical extension areas | supply chain, identity, privacy, and CTV-related signals continue to evolve |
Core fields often seen in bid requests
idimpsiteorappdeviceusersourceregspmpat,tmax,cur,bcat,badv,wseat,bseat
Core fields often seen in bid responses
priceadmnurlburllurladomaincriddealid
Data flow in this segment
Practical interpretation
This segment decides who bids with what price and what creative. Even though the SDK or player eventually renders the ad, the core auction data that determines the outcome moves through this segment.