RTB (real-time bidding) is the auction protocol underlying programmatic advertising. Each ad impression is auctioned in 50-150 milliseconds — the SSP fires a bid request, multiple DSPs evaluate and respond with bids, the auction resolves, and the winning creative renders. The OpenRTB specification (managed by the IAB Tech Lab) defines the protocol: what bid requests look like, what fields they include, what bids must return.
The 50-150ms auction timeline
- 0ms — user opens publisher app / page. App / page fires ad request to the SDK.
- 5-20ms — SSP receives request, enriches with audience data, broadcasts to ad exchanges.
- 20-100ms — ad exchange broadcasts bid request to connected DSPs. Each DSP evaluates the request against advertiser targeting rules, calculates a bid price, responds.
- 100-130ms — exchange collects bids, runs auction, picks winner.
- 130-150ms — winning creative URL returned, ad renders.
Latency above ~150ms causes ad-slot abandonment (the impression times out and renders a fallback). Bidders that respond slowly get penalized — exchanges drop slow DSPs from the auction.
Auction types
- First-price auction: the winner pays their bid price. Industry standard in 2026 — Google AdX, most major SSPs shifted from second-price to first-price between 2017-2019. Forces advertisers to bid more strategically (you pay what you bid, not what you'd have to pay to win).
- Second-price auction: the winner pays one cent above the runner-up's bid. Classic eBay-style mechanism, used widely in programmatic until the late-2010s shift. Theoretically encourages truthful bidding (you can bid your max without overpaying); in practice, opaque mechanics + header bidding made it unstable.
RTB in mobile apps
- SDK-based: an SDK in the app (typically the publisher's mediation SDK — AppLovin MAX, ironSource LevelPlay, Google Admob) handles the bid request locally. SDK fires the request, receives the bid, renders the winning creative.
- Server-to-server (s2s): the publisher's backend handles the bid request, calling out to exchanges from the server. Used for header-bidding-style auctions where the publisher wants more control over the bid logic.
The bid-request payload in mobile includes app ID, ad format, user signals (where available), device signals, geolocation (with permission), content context. Post-ATT on iOS, user-level signals are sharply curtailed — the bid request is much less rich than on Android or pre-ATT iOS.
Common RTB pitfalls
- Bid timeout: DSPs that respond slowly get dropped from auctions. Maintain response times under 100ms.
- Stale audience data: bidding against audience signals that were fresh 5 minutes ago and stale now. Real-time audience updates matter.
- Auction collusion: when multiple bidders share data sources, bids can correlate suspiciously. Anti-collusion analytics in mature DSPs.
- Bid shading: in first-price auctions, sophisticated DSPs "shade" bids downward based on historical clearing prices — they bid what they expect to win, not their max. Naive bidding overpays.