OpenRTB and real-time bidding explained: the auction behind every impression

Every time a web page with ads loads, a live auction happens in the background — one impression, many potential buyers, a winner chosen in about the time it takes to blink. That process is real-time bidding (RTB), and the shared language that lets all the players talk to each other is OpenRTB. Together they’re the engine under most of programmatic.

Here’s how it works, step by step.

What real-time bidding is

Real-time bidding is the auctioning of a single ad impression, in real time, at the moment a page loads. Not a bulk buy of a thousand impressions negotiated in advance — one specific impression, for one specific user, auctioned individually in roughly 100 milliseconds.

That per-impression granularity is the whole point. Instead of buying “space on a sports site,” a buyer can evaluate this impression — this user, this page, this moment — and decide exactly what it’s worth to them, right now.

The step-by-step flow

Here’s what happens in that ~100ms window:

1. A user loads a page with an ad slot to fill.
2. The publisher’s SSP builds a bid request — a structured description of the impression: the site, the placement, the format, the device, the geo, and whatever user signals are available.
3. The request goes to an ad exchange, which broadcasts it to connected DSPs.
4. Each DSP evaluates the impression against its advertisers’ campaigns and returns a bid — or declines.
5. The exchange runs the auction and picks the winner. Because auctions are now first-price, buyers shade their bids toward the floor.
6. The winning ad is returned and rendered before the page finishes loading.

The user sees none of it. To them, the page just loaded.

Where OpenRTB comes in

Here’s the problem RTB creates: there are thousands of SSPs and DSPs. If every one needed a custom integration with every other, the ecosystem would collapse under its own wiring.

OpenRTB is the answer — a shared, standardized specification (stewarded by IAB Tech Lab) that defines exactly what a bid request and bid response look like. It’s the common language that lets any SSP talk to any DSP without a bespoke integration.

OpenRTB did for programmatic what a shared shipping-container standard did for global trade: it turned a mess of incompatible connections into an interoperable market. Any SSP can speak to any DSP because they agree on the format.

The bid request carries structured fields — objects describing the impression, the site or app, the device, the user, and the supply chain (the SupplyChain object that names every hop). Standardizing those fields is what makes the whole auction machine work at internet scale.

Why it matters

Understanding OpenRTB and RTB unlocks most of the rest of ad tech:

• It’s per-impression. This is why floor pricing, targeting, and fraud filtering all happen at the level of individual impressions, not bulk buys.
• It’s a standard, so it evolves. Changes to the spec — like schain 1.1 making non-payment hops visible — ripple across the entire market at once.
• The intelligence is moving pre-bid. The most valuable decisions — what to bid, what floor to set, whether to transact at all — happen before and during the request, not in a report afterward.

The takeaway

Real-time bidding is the live, per-impression auction that runs in the ~100 milliseconds a page takes to load. OpenRTB is the shared language that makes those auctions possible across thousands of independent buyers and sellers. Almost everything else in programmatic — floors, bid shading, supply-chain transparency, fraud filtering — is a layer built on top of that one fast, standardized exchange of a bid request and a bid.

---

Lumorrow is an AI-native exchange that adds real-time intelligence to the OpenRTB request — evaluating quality and setting floors pre-auction, before the impression is billed. See how the platform works → or explore it for demand partners →.