What Is Real-Time Bidding (RTB)? | CPMKit

Real-time bidding is the auction protocol that sells a single ad impression in under 200 milliseconds, from the moment a user loads a page to the moment the winning ad renders. This article breaks down the full auction sequence, the data inside a bid request, the latency budget that constrains every participant, and what most people misunderstand about how RTB actually operates within programmatic advertising.

What Happens During an RTB Auction Step by Step?

An RTB auction fires every time a user loads a page with a programmatic ad slot. The publisher's ad server sends an ad request to one or more SSPs, each SSP broadcasts bid requests to connected DSPs, DSPs evaluate and respond, and the highest bid wins. The entire cycle completes before the page finishes loading.

Here's the sequence in order:

1. Page load triggers the ad request. A user visits a publisher's page. The publisher's ad server (typically Google Ad Manager) detects an available ad slot and fires an ad request to the SSP layer.
2. The SSP generates bid requests. The SSP packages the impression data (page URL, slot dimensions, user IDs, device type, geo, floor price) and sends a bid request to every connected DSP, often 20 to 50 simultaneously.
3. DSPs evaluate and bid. Each DSP matches the bid request against active campaigns, runs targeting checks (audience segments, frequency caps, brand safety), and decides whether to bid. If the impression matches, the bidding algorithm calculates a price and returns a bid response with the price and a creative URL.
4. The SSP runs the auction. Bid responses arrive within the timeout window (typically 100 to 150 milliseconds). The SSP selects the highest bid that meets the publisher's floor price. Under first-price auction rules, the winner pays exactly what they bid. DSPs use bid shading to offset the overpayment risk this creates.
5. The ad renders. The SSP returns the winning creative URL to the publisher's ad server, which renders the ad in the user's browser. The winning DSP receives a win notification. Losing DSPs receive loss notifications (if the SSP supports them under OpenRTB 2.6).

That five-step cycle repeats for every ad slot on every page load. A page with four ad units runs four separate auctions. A publisher serving 10 million pageviews per month with three slots per page triggers 30 million RTB auctions monthly.

What Data Does an RTB Bid Request Contain?

The bid request is the packet of information DSPs use to decide whether an impression is worth buying and how much to pay. The format follows the OpenRTB specification maintained by IAB Tech Lab, currently at version 2.6.

A standard bid request carries five objects:

• Impression object. Ad slot dimensions (300x250, 728x90), page position (above or below fold), supported formats (banner, video, native), and the publisher's bid floor, the minimum CPM the publisher will accept. Bids below it get rejected automatically.
• Site/app object. Page URL or app bundle ID, content category (IAB taxonomy), domain, and publisher ID. This is how DSPs evaluate brand safety and contextual relevance.
• User object. Cookie IDs, device advertising IDs (IDFA, GAID), or privacy-compliant alternative signals. Post-iOS 14.5, this field is often empty on mobile. Consent strings (TCF for GDPR, GPP for US state laws) ride here too.
• Device object. Device type, OS, browser, screen resolution, truncated IP, connection type.
• Regulations object. Flags for GDPR, CCPA, and COPPA applicability.

The bid response contains the bid price (expressed as CPM), creative markup or URL, advertiser domain, and any deal ID for PMP or preferred deal associations.

How Fast Does an RTB Auction Actually Run?

The full auction, from page load to rendered ad, completes in 100 to 200 milliseconds. To put that in context, a human eye blink takes 150 to 400 milliseconds. The ad is bought, sold, and displayed before you finish blinking.

The latency budget breaks down roughly like this: ad server processing (5 to 15ms), network transit outbound (10 to 30ms), DSP evaluation (10 to 50ms), network transit return (10 to 30ms), auction resolution (5 to 10ms), creative rendering (20 to 50ms). Total: 60 to 185ms in typical conditions.

Geographic distance eats into that budget fast. A DSP data center in Virginia receiving a bid request from a European SSP burns 40 to 80ms on network transit alone. This is why The Trade Desk, DV360, and other major DSPs run regional data centers processing thousands of queries per second (QPS) each.

SSPs enforce hard timeout windows, usually 100 to 150ms for the DSP response. If your bid arrives at 160ms, it's discarded. The SSP doesn't wait. A DSP with slower servers or fewer regional data centers cannot compete for impressions in distant geos. The physics of network latency eliminates them before the auction closes.

What Do Most People Get Wrong About RTB?

The biggest misconception: that RTB and programmatic are the same thing. They're not. RTB is one transaction method within programmatic. Programmatic also includes private marketplace deals, programmatic guaranteed, and preferred deals, none of which involve a real-time auction. RTB is the open-auction subset. It accounts for roughly 60% of programmatic spend, but conflating the two leads to confusion about deal types and pricing structures.

Second: people assume each impression goes through one auction. In practice, header bidding means a single impression may be auctioned across 5 to 8 SSPs simultaneously, each running its own RTB auction with its own connected DSPs. The header bidding wrapper then runs a meta-auction across the SSP winners. For more context, see our DSP vs SSP overview.

Third: win rates are low. A typical DSP wins 1 to 3% of the impressions it bids on. The infrastructure cost of losing 97%+ of bids is a real line item. This is why DSP bid filtering, pre-auction logic that skips bid requests unlikely to match active campaigns, matters for operational efficiency, not just targeting accuracy.

How Should You Think About RTB as a Publisher?

If you're a publisher, your open-auction eCPM is a direct function of how many DSPs see your bid requests, how clean your signal data is, and whether your floor prices are set correctly. Two things you control:

• Floor prices. Too high and DSPs won't bid. Too low and you leave money on the table. Dynamic floor optimization, adjusting by hour, geo, and device based on historical clearing prices, outperforms static floors by 10 to 20% on eCPM. Google Ad Manager supports rules-based floors. Pubstack and Assertive Yield offer algorithmic alternatives. (Use our CPM formula or CPM calculator to model potential revenue).
• Timeout settings. A 120ms timeout captures 90 to 95% of available bids. Extending to 200ms captures an additional 3 to 5% but adds perceptible page latency. For most publishers, 120 to 150ms is the right window.

Check your open-auction CPM against current CPM benchmarks by format and geo to gauge whether your RTB setup is competitive.