Every time a page loads or an app opens, an ad slot goes up for auction, and the entire process, from the ad request leaving the publisher to a winning creative rendering on screen, finishes in well under half a second. Media buyers see the result as an impression and a price. What they rarely see is the auction itself: dozens of demand-side platforms evaluating the same opportunity, each deciding in milliseconds whether to bid and how much.
That speed is not a side detail. It is the mechanism that makes programmatic advertising possible at scale. A DSP that cannot receive, evaluate, and respond to a bid request inside the auction window simply does not get to compete, no matter how good its targeting or creative is. Understanding how the auction works, and where the time actually goes, explains why infrastructure choices like unlimited queries per second matter as much as strategy.
This guide walks through real-time bidding step by step: what happens between an ad request and a rendered impression, how first-price and second-price auctions differ, and why the milliseconds a DSP has to work with shape what it can and cannot do for advertisers.
What Is Real-Time Bidding (RTB)?
Real-time bidding is the auction mechanism that programmatic advertising runs on. When a user visits a page or opens an app, the publisher’s supply-side platform packages that ad slot into a bid request and sends it out to every demand-side platform connected to the auction. Each DSP evaluates the request against its active campaigns and, if it finds a match, submits a bid. The highest qualifying bid wins, and its creative is served, all before the page finishes rendering.
The protocol most of the industry uses to structure this exchange is OpenRTB, a standardized specification that defines exactly what fields a bid request and bid response must contain, so a bid request built by one SSP can be understood by any DSP regardless of who built it. Without a shared protocol, every SSP-DSP pair would need a custom integration, and the auction could never scale to the thousands of platforms that participate in it today.
What makes RTB different from a traditional ad auction is that it happens once, per impression, in real time. There is no standing inventory being sold in bulk ahead of time. Every single ad slot is its own auction, evaluated fresh against whichever campaigns happen to be live and whichever audience signals are attached to that specific user at that specific moment.
The RTB Auction, Step by Step
A full RTB auction cycle looks simple from the outside, a page loads and an ad appears, but it involves a defined sequence of handoffs between publisher, exchange, and DSP. Here is what happens, in order:
- Ad request fires. A user loads a page or app screen with an ad slot. The publisher’s ad server recognizes the slot as programmatic-eligible and hands it to an SSP or ad exchange.
- Bid request is built. The SSP packages the opportunity into an OpenRTB bid request: page or app context, ad slot size, device and geo data, and whatever user or audience signals are available and permitted.
- Bid request is broadcast. The exchange sends the bid request to every connected DSP simultaneously, not one at a time. Each DSP receives the identical opportunity at effectively the same moment.
- Each DSP evaluates independently. Inside the DSP, the request is checked against active campaigns for targeting match, budget and pacing, frequency caps, and brand safety rules. This is the step where a DSP’s own logic, not the exchange’s, decides whether and how much to bid.
- Bid response is returned. If the opportunity qualifies, the DSP returns a bid response with a price and a reference to the winning creative, inside the auction’s timeout window. A DSP that responds late is treated the same as a DSP that did not bid at all.
- The exchange picks a winner. The exchange compares every valid bid response received in time and determines the winner according to the auction’s pricing rule, first-price or second-price.
- Win notice and creative render. The winning DSP receives a win notice, and the ad server retrieves and renders the winning creative in the slot the user is looking at.
The entire sequence, from step one to step seven, typically completes in well under 200 milliseconds, and a growing share of exchanges hold DSPs to timeout windows closer to 100 milliseconds or less. A DSP’s infrastructure has to complete step four, the evaluation logic, inside whatever slice of that window the network round trip leaves it.
First-Price vs Second-Price Auctions
How the winning price is calculated depends on which auction model the exchange runs. Most of the industry moved to first-price auctions over the past several years, but understanding both matters because a DSP’s bidding logic has to adjust to which one it is competing in.
| Auction type | Winning price | What it means for bidding strategy |
| First-price | The winner pays exactly the price it bid | Bidding the full value of an impression means overpaying; DSPs need bid-shading logic to bid below true value |
| Second-price | The winner pays one increment above the second-highest bid | Bidding true value is the mathematically optimal strategy, no shading needed |
Almost all major exchanges now run first-price auctions, which shifted the burden of price discipline from the auction mechanism itself onto each DSP’s bidding algorithm. This is one of the reasons DSP-side reporting on win rate and effective CPM matters more than ever: a DSP that consistently wins at close to its maximum bid is leaving margin on the table, while one that shades too aggressively loses winnable inventory.
Where the Milliseconds Actually Go
The auction timeout is not evenly split between the participants. A meaningful share of the window is consumed before a DSP’s own logic ever runs, which is why infrastructure and network position matter as much as bidding strategy.
| Stage | What happens |
| Request transit | Network time for the bid request to travel from exchange to DSP server |
| Internal evaluation | Targeting match, pacing, budget check, and price calculation inside the DSP |
| Response transit | Network time for the bid response to travel back to the exchange |
| Buffer for late arrivals | Exchanges hold a small margin before finalizing, but late responses are still dropped |
Two DSPs with identical targeting logic can still perform very differently if one spends more of the timeout window on network transit. This is why exchange connectivity, server placement, and the ability to handle bid volume without throttling are infrastructure questions, not just software questions, and why they show up directly in win rate.
What Happens When a DSP Runs Out of Time
A bid response that arrives after the timeout is not penalized, it is simply ignored. The exchange has already moved on to selecting a winner from whichever responses arrived on time, so a late bid is functionally identical to no bid at all. There is no partial credit and no second chance within that auction cycle.
At small scale, an occasional timeout is invisible in the numbers. The problem compounds as bid volume grows. A DSP running near its processing ceiling starts timing out on a rising share of requests during traffic spikes, exactly the moments when the most valuable inventory tends to be in play, because everyone else’s traffic spikes at the same time too. That produces a specific pattern in DSP reporting worth watching for: win rate holding steady on average but dropping sharply during peak-traffic windows, which points to a capacity problem rather than a targeting or bidding-strategy problem.
The fix is rarely a smarter bidding algorithm. It is usually infrastructure: more processing headroom, a shorter internal evaluation path, or removing duplicate bid requests from an unoptimized supply path before they ever reach the bidding logic. Diagnosing which one applies starts with the same reporting metrics that track win rate and bid rate over time, segmented by hour or by traffic volume rather than as a single flat average.
Why RTB Speed Matters More When You Own the DSP
On a rented, self-serve DSP seat, the auction speed is whatever the provider built and whatever tier of service the rented account is entitled to. A DSP owner sees the auction from the other side: every bid request that arrives, and every millisecond of the timeout window, is capacity the platform either uses or wastes.
This is where queries per second becomes a practical constraint rather than an abstract spec. A DSP that throttles incoming bid requests once volume exceeds its QPS allowance is not just missing some auctions, it is missing them inconsistently, at whatever moments traffic happens to spike. A clean supply path reduces how many duplicate and low-value bid requests compete for that same evaluation capacity in the first place, which is one of the reasons supply path optimization and QPS headroom tend to be discussed together.
For agencies and media buyers evaluating whether to keep renting seats or move to an owned platform, RTB mechanics are a useful lens: ask what auction timeout the current provider targets, what the actual QPS ceiling is, and how win rate has trended as bid volume has grown. Those numbers say more about a platform’s real capacity than a feature list does.
Ready to See the Auction From the DSP’s Side?
AdTech Europe gives agencies, ad networks, and media-buying teams a fully owned DSP with unlimited QPS and no auction throttling built in, whether through a white-label rental, a license, or a full source-code acquisition. Every plan connects to 1,000+ SSP integrations out of the box, so bid volume scales with the campaigns running on the platform, not with a rented seat’s fixed allowance. Current pricing for all three ownership models is on the pricing page.
If you want to see how the RTB auction performs on a platform you actually own, schedule a programmatic strategy meeting and walk through your current bid volume, win rate, and QPS needs with the AdTech Europe team.
FAQs
What does RTB stand for in advertising?
RTB stands for real-time bidding, the auction process that decides which ad wins an impression, in real time, as a page or app loads.
How long does an RTB auction take?
A full RTB auction cycle, from bid request to rendered creative, typically completes in under 200 milliseconds, with many exchanges enforcing DSP timeout windows of 100 milliseconds or less.
What is the difference between RTB and programmatic advertising?
Programmatic advertising is the broader category of buying and selling ad inventory through automated systems. RTB is the specific auction mechanism, the real-time, per-impression bidding process, that most programmatic buying runs on.
What is OpenRTB?
OpenRTB is the industry-standard protocol that defines the structure of bid requests and bid responses, so any SSP and any DSP can communicate in a real-time auction without a custom integration between them.
Is first-price or second-price bidding more common now?
First-price auctions are now the industry default across most major exchanges. In a first-price auction the winner pays exactly what it bid, which is why DSPs use bid-shading logic instead of bidding full value.
Why does QPS matter for real-time bidding?
QPS, or queries per second, is the volume of bid requests a DSP can evaluate each second. A DSP that hits its QPS ceiling starts dropping or throttling incoming auctions, which shows up as missed impressions and a falling win rate as bid volume grows.
Can a DSP owner change how the RTB auction logic works?
Yes, within the limits of the ownership model. A full source-code DSP acquisition gives complete control over bidding logic and evaluation rules, while a white-label or licensed DSP typically offers configuration of targeting, pacing, and bid-shading settings without access to the underlying auction code.
