Real-time bidding (RTB) is the auction system that decides, in the time it takes a web page to load, which ad you'll actually see. Every time you open a page with ad slots on it, those slots run a live auction among advertisers, and the winning ad is the one that gets rendered — all before the page finishes rendering. That's the short answer to what is real-time bidding: a per-impression, machine-run auction that happens too fast for a human to be involved in any single decision.
This guide covers what RTB actually is, the mechanics of a single auction, the protocols and players that make it work, where it breaks down in practice, and the mistakes that cost publishers and advertisers money once they're running it for real.
The fundamentals of real-time bidding
Before RTB, buying and selling display ads mostly meant negotiated deals: an advertiser and a publisher (or their agencies) agreed on a price and volume in advance, and an ad server delivered against that contract. That model doesn't disappear under RTB — direct deals and guaranteed placements still exist — but RTB adds a second, automated layer underneath it: unsold or open inventory gets auctioned to the highest bidder, impression by impression, in real time.
The unit of sale is the single ad impression — one ad slot, on one page, for one visitor, at one moment. Nothing is bundled or averaged. Because each impression is sold on its own, the buyer can decide, for that specific visitor, how much they're worth right now, based on signals like the page content, the visitor's rough profile, geography, device, and the advertiser's own targeting rules.
This is different from "programmatic advertising" as a whole, which is a broader term for any ad buying done through software rather than manual insertion orders. RTB is one method of programmatic buying — the auction-based one. Programmatic also includes non-real-time methods, like programmatic guaranteed deals where price and volume are fixed in advance but delivery is still automated.
The standard that makes RTB interoperable across companies is OpenRTB, maintained by the IAB Tech Lab. It defines the request and response format — what a supply-side platform sends when asking for bids, and what a demand-side platform sends back — so that exchanges, SSPs, and DSPs built by different companies can talk to each other without custom integrations for every pair.
How real-time bidding works in practice
A single RTB auction runs through a fixed sequence, even though it completes in a fraction of a second:
- A user loads a page. The page has one or more ad slots that need to be filled.
- The publisher's ad tech sends a bid request. This goes out to an ad exchange or directly to multiple demand-side platforms (DSPs). It includes the placement details, some anonymized user and context data, and the floor price — the minimum the publisher will accept.
- DSPs evaluate the request on behalf of advertisers. Each DSP checks its advertisers' active campaigns, targeting rules, and budgets, and decides whether this impression is worth bidding on and at what price.
- Bids come back. Every interested DSP returns a bid — a price and the creative it wants to serve if it wins.
- The exchange runs the auction. The highest bid above the floor price wins. Depending on the auction type, the winner pays either their own bid (first-price) or the second-highest bid plus a small increment (second-price) — more on that distinction below.
- The winning ad is served. The creative loads into the ad slot as the rest of the page finishes rendering.
All of this — steps two through six — typically happens in well under a second, fast enough that it doesn't add a perceptible delay to the page for the visitor. Auctions run with a strict timeout: if a DSP doesn't respond in time, its bid simply doesn't count for that impression. That timeout is a real design constraint, not a technicality — it's why targeting logic in RTB systems has to be fast and pre-computed rather than doing heavy lookups mid-auction.
First-price vs. second-price auctions. Second-price was the original RTB default: the winner pays the second-highest bid, plus a small increment, rather than their own full bid. It encourages bidders to bid what an impression is genuinely worth to them, since overbidding doesn't cost extra. Most of the industry has since shifted to first-price auctions, where the winner pays exactly what they bid — largely driven by the rise of header bidding, where a publisher runs several auctions in parallel and a single, simple rule ("winner pays their bid") is easier to reconcile across them. The shift is well documented in the IAB Tech Lab's ongoing OpenRTB guidance, which added explicit first-price signaling to the protocol.
Who's actually involved: the RTB supply chain
An RTB transaction usually passes through several distinct pieces of infrastructure, each doing a specific job:
| Player | Role | Works for |
|---|---|---|
| Publisher's ad server | Manages ad slots on the site, decides what fills them | Publisher |
| Supply-side platform (SSP) | Packages the impression and sends it to auction | Publisher |
| Ad exchange | Runs the auction, matches bids to inventory | Both sides |
| Demand-side platform (DSP) | Bids on behalf of advertisers, applies targeting | Advertiser |
| Data management platform (DMP) | Supplies audience and targeting data to DSPs | Advertiser (mostly) |
In a simple setup, a publisher might work with a single SSP connected to one exchange. In practice, most sites run several SSPs at once so that more DSPs get a chance to bid on the same impression — this is what header bidding automates, running those parallel auctions in the browser before the page's own ad server makes the final call.
Where real-time bidding runs into trouble
RTB's speed and automation are also where its problems live.
Latency. Every additional SSP or DSP in the chain adds a request-response round trip. Publishers running many partners to maximize bid competition can end up slowing the page down enough to hurt user experience and, ultimately, viewability — the two things RTB was supposed to help, not hurt.
Ad fraud. Because bidding decisions are automated and happen at massive scale, RTB is a natural target for invalid traffic — bots generating fake impressions, or fraudulent domains misrepresenting what inventory they're actually selling. Buyers rely on verification vendors and reputable exchanges to filter this out, but it remains a persistent cost baked into programmatic spend.
Auction opacity. In a first-price auction with many SSPs involved, it's genuinely hard for either side to know whether they got a fair price, since the "second-highest bid" comparison that second-price auctions offered as a rough fairness check no longer applies the same way.
Data restrictions. Third-party cookies, which historically supplied a lot of the targeting signal in a bid request, are being phased out across major browsers. RTB itself doesn't require cookies — it just needs some targeting signal — but the shift is pushing the industry toward contextual signals and first-party data as the inputs bid requests carry.
Common mistakes to avoid
- Setting a floor price without checking fill rate. A floor set too high silently discards bids below it; a floor set too low leaves revenue on the table. Both mistakes look the same in casual reporting — "revenue is flat" — unless you're watching floor price and fill rate together.
- Running too many SSPs without measuring the latency cost. More auction participants means more competition, but each one adds page load time. Test with real page-speed metrics, not just win-rate numbers.
- Confusing programmatic and RTB. Treating every automated deal as an "auction" leads to wrong assumptions about pricing — a programmatic guaranteed deal has a fixed price; an RTB-won impression doesn't.
- Ignoring auction type when reading bid data. Comparing bid prices across a first-price and a second-price auction without adjusting for the mechanism will make one channel look artificially cheaper or more expensive than it is.
- Underinvesting in fraud filtering. Treating invalid traffic as someone else's problem, rather than checking it directly, means paying for impressions that were never seen by a real person.
FAQ
Is real-time bidding the same as programmatic advertising?
No. Programmatic advertising is the broader category — any ad buying automated through software. RTB is specifically the auction-based method within programmatic; programmatic guaranteed deals, for example, are programmatic but not auctioned.
How fast does an RTB auction actually happen?
Fast enough not to add a noticeable delay to page load — the whole request-bid-auction-serve sequence runs under a strict timeout measured in milliseconds, with unanswered bids simply excluded from that round.
Who sets the floor price in an RTB auction?
The publisher, usually through their SSP or ad server. It's the minimum the publisher will accept for that impression; bids below it are discarded before the auction runs.
Does RTB still work without third-party cookies?
Yes. A bid request needs some targeting signal, but it doesn't have to be a cookie — contextual data (what the page is about) and first-party data (what the publisher or advertiser already knows) both work as inputs, and the industry is shifting toward them as cookies phase out.
What's the difference between an SSP and a DSP?
An SSP represents the publisher's side, packaging inventory and sending it to auction to get the best price. A DSP represents the advertiser's side, evaluating bid requests and deciding what to bid based on the advertiser's targeting and budget.
Conclusion
Real-time bidding is the auction mechanism underneath most of the display and video ads you see online: a bid request goes out the moment a page loads, demand-side platforms respond with bids on behalf of advertisers, an exchange picks the winner, and a creative renders — all inside a fraction of a second. It's one method within the wider category of programmatic advertising, distinguished by the fact that price is set per impression, live, rather than negotiated in advance.
Key takeaways
- RTB auctions a single ad impression at a time, deciding the winner in the milliseconds between a page request and its render.
- OpenRTB, maintained by the IAB Tech Lab, is the standard protocol that lets exchanges, SSPs, and DSPs interoperate.
- First-price auctions (winner pays their own bid) have largely replaced second-price auctions industry-wide, driven partly by header bidding.
- More SSPs and DSPs in the chain means more bid competition, but also more latency — the trade-off has to be measured, not assumed.
- RTB doesn't require third-party cookies; it needs targeting signal, which is shifting toward contextual and first-party data.
