How Real-Time Bidding Works: The Ad Auction Step by Step, in Milliseconds

Picture an auction house where each lot is a single view of an ad slot. The auctioneer describes the lot, every bidder in the room gets one chance to shout a price, and the gavel falls on a timer. Nobody waits for latecomers. Then the next lot comes up, and the process repeats.

In RTB the auctioneer is an ad exchange, usually run by a supply-side platform (SSP) on behalf of a publisher. The bidders are demand-side platforms (DSPs) acting for advertisers. The description of the lot is a bid request, a small JSON document written to the OpenRTB standard from IAB Tech Lab. The shout is a bid response. The timer is a field called tmax.

Three things make RTB different from older ways of buying ads. The sale happens per impression, not per block of a million. The buyer sees who is likely to view the ad, not just which site it runs on. And the whole exchange takes place inside the time it takes a page to load. RTB is one part of programmatic buying; the wider picture is in what is programmatic advertising.

The table follows one web display impression. The clock values are illustrative, built around a tmax of 120 ms, the value in the sample request of the OpenRTB 2.6 specification. Real timings vary by exchange, region and format; Google's deadlines run from 80 to 1,000 ms (Google Authorized Buyers, 17 September 2026).

Each step has a job worth knowing:

1. The ad call. When a browser or app reaches an empty slot, it asks the publisher's systems for an ad. Many websites first run header bidding, which collects bids from several SSPs before the ad server decides. The header bidding guide covers that pre-auction.
2. The bid request. The SSP turns what it knows into a bid request: the slot size, the page or app, the device, a coarse location, consent signals and the floor. It sends only what the user's consent and the publisher's settings allow.
3. The fan-out. The exchange sends the request to many DSPs in parallel. Large DSPs cannot read every request they could receive, so exchanges and DSPs agree volume limits, measured in queries per second (QPS). The trade-offs are covered in QPS, latency and bid performance.
4. The decision. Inside the DSP, a bidder checks the request against every live campaign. It asks whether the user is in a target audience, whether the frequency cap is reached and whether budget remains. It then predicts what the impression is worth and sets a price.
5. The response. The DSP returns a price and the ad, or says no. The OpenRTB guidance lists an empty HTTP 204 reply as the cheapest way to decline (IAB Tech Lab, OpenRTB implementation notes).
6. The auction. The exchange discards late bids, bids under the floor and ads that break the publisher's blocks. It then ranks the rest by price, or by deal priority where deals apply.
7. The final choice. The publisher's ad server compares the exchange's winner with direct campaigns. A sponsorship sold by the sales team can still take the slot.
8. The notices. When the ad wins and renders, the exchange calls the winner's notice URLs. The billing notice in burl marks the moment the impression becomes billable (IAB Tech Lab, OpenRTB 2.6).

A bid request is a short JSON document. The example below is a trimmed, valid OpenRTB 2.6 request for one mobile web banner. Values such as the domain and IDs are placeholders, and the privacy string is left as a label rather than a fake code.

Every field, with the rest of the 2.6 objects, is annotated in OpenRTB 2.6 explained. To change values and test what is valid, use the planned OpenRTB bid request builder. The supply-chain checks are covered in SupplyChain object, ads.txt and sellers.json.

The answer is shorter. A bid response names the request it answers, the slot it bids on, a price and the ad. This one bids $5.80 per thousand on the slot above:

The ${AUCTION_PRICE} macro is a placeholder the exchange replaces with the clearing price when it calls the URL (IAB Tech Lab, OpenRTB 2.6). The adomain field lets the publisher check the advertiser against its block list before the ad shows.

The auction ends in milliseconds, but the record-keeping takes longer. OpenRTB gives the winning bidder three notice URLs it can include in its bid (IAB Tech Lab, OpenRTB 2.6):

• Win notice (nurl). The exchange calls it when the bid wins. The specification warns that a win is "not necessarily indicative of a delivered, viewed, or billable ad".
• Billing notice (burl). The exchange calls it when the impression becomes billable under its own policy, typically when the ad is delivered or viewed.
• Loss notice (lurl). The exchange calls it when it knows the bid lost. Some exchanges do not send loss notices or hide the clearing price.

The gap between a win and a billable impression matters. A bid can win at the exchange and then lose at the publisher's ad server to a direct campaign. It can also win and never render, because the reader left the page. A DSP that counts wins and a publisher that counts renders will report different totals. Agreeing which notice defines a billable impression before a campaign starts prevents most of those disputes. Reconciling the two sides at impression level is covered in log-level data 101.

The auction rule decides what the winner pays, so it shapes how everyone bids. Compare a first-price auction with a second-price auction using two bids on one slot: DSP A offers $5.00 per thousand and DSP B offers $3.50, against a $2.00 floor. These figures are illustrative.

For years the second-price rule dominated. It looked simple: bid what the impression is worth, and you never pay more than needed to beat the runner-up. Header bidding broke that logic. Publishers ran several auctions in a row, so the "second price" of one auction stopped meaning much.

Google described the problem when it announced its switch. Ad Manager could run a second-price auction for its own buyers, then a first-price comparison against other demand (Google, 10 May 2019). Google called the change a way to "create a fair and transparent auction for everyone". It also said publishers would see "all bids submitted for their ads" and buyers would see the price needed to win.

The first-price rule is easier to audit, because the winner pays what it bid. It also moves the job of finding a fair price from the exchange to the buyer. That job has a name.

Bid shading means bidding below what an impression is worth to you, by just enough to still win most of the time. AdExchanger defined it in 2019 as "a technique buyers use in first-price auctions to avoid paying too much" (AdExchanger, 15 March 2019).

Here is how it works in practice. A DSP values an impression at $6.20 per thousand. Its model has learned that on this site, at this hour, bids around $5.70 win most auctions. So it bids $5.80, keeps most of its win rate and saves 40 cents per thousand compared with a bid at full value. These numbers are illustrative.

Shading needs data about past auctions. Exchanges help by telling buyers what it would have taken to win. OpenRTB 2.6 added an AUCTION_MIN_TO_WIN macro for this purpose (OpenRTB 2.6 change log). Sellers built tools too: AdExchanger reported that Rubicon Project (now Magnite) launched one at the end of 2017 and PubMatic followed in February 2018 (AdExchanger, 15 March 2019).

Publishers watch shading closely, because it lowers clearing prices. Buyers ask a different question: whether their DSP shades in their interest or keeps part of the savings. Both sides are covered in bid shading explained.

A floor price is the lowest bid a seller will accept. In OpenRTB it travels in imp.bidfloor, with a separate deal.bidfloor for each private deal (IAB Tech Lab, OpenRTB 2.6). For video and audio, sellers can also set floors that depend on ad length, using fields OpenRTB 2.6 introduced in 2022 and extended to deals in 2023 (IAB Tech Lab, OpenRTB implementation notes).

The switch to first price changed how floors work. Under second price, publishers raised floors to lift the price the winner paid. Google warned in 2019 that this habit "can erode trust" and that such floor strategies "will no longer be relevant" after the switch (Google, 10 May 2019). It launched unified pricing rules at the same time, with an initial limit of 100 rules.

Today a floor is a plain minimum. Many publishers adjust floors by page, device and time of day, an approach called dynamic floors. A news site might set $1.50 on article pages and $4.00 on its homepage. Setting floors well is covered in floor price strategy.

Every party in the auction works against a clock. The exchange sets the deadline in tmax, and it counts network time as well as thinking time (IAB Tech Lab, OpenRTB 2.6). A bid that arrives a millisecond late is treated as no bid.

Google's guidance for its buyers is a useful benchmark. The deadline "typically ranges from 80 to 1000 ms", and Google requires 85 percent of responses to arrive within it (Google Authorized Buyers, updated 17 September 2026). Bidders that miss that rate can be sent fewer requests. Google also advises bidders to aim below the deadline to leave a buffer for network delays.

On a web page there is a second clock. Prebid.js, which runs header bidding in the browser, waits 3,000 ms by default before it gives up on bidders (Prebid.js source). Prebid.org suggests setting the server-side timeout to 50% to 75% of the browser timeout and sends that value as tmax (Prebid.org, timeouts).

Distance matters. A bidder in Virginia answering an exchange in Frankfurt spends part of its budget on the ocean crossing. That is why large DSPs run servers next to the exchanges they buy from. The timeout trade-off is simple to state: longer timeouts let more bidders answer, but they delay the ad and can cost views. The planned RTB latency calculator works through the budget hop by hop.

A bid request can carry personal data, so it also carries the rules for using it. In OpenRTB 2.6 those signals sit in the regs and user objects (IAB Tech Lab, OpenRTB 2.6).

A consent string is a compact code. It records which purposes and which vendors a person agreed to. The string tells each vendor whether it has the person's consent, so a DSP can check whether the framework lets it use the personal data in that request. New EU strings had to follow TCF v2.3 from 1 March 2026, according to Google, which can limit or drop non-compliant ad requests (Google AdSense Help, 2 March 2026).

You can read a string yourself with the planned TCF consent string decoder. The legal side for European traffic is covered in GDPR, ePrivacy and the bidstream. Cookies still matter too: Google said in April 2025 that Chrome would keep third-party cookies (Digiday, 2025).

People often treat RTB, header bidding and deals as rival systems. They are layers of the same pipe.

• Header bidding decides which exchanges get to bid before the ad server chooses. Each exchange inside it still runs an RTB auction.
• Private deals run on RTB too. The seller adds a pmp object with deal IDs, and the buyer bids against those terms (IAB Tech Lab, OpenRTB 2.6).
• Programmatic guaranteed uses the same request, with a deal flag that tells the buyer it must bid.

A bank buying a fixed-price package on a finance site and a shoe brand bidding in the open auction may receive the very same request. Only the deal terms inside it differ. The four deal types are compared in programmatic guaranteed vs PMP vs preferred deal vs open auction.

This page explains the auction in plain terms. Engineers who build bidders or exchanges need more: request routing, caching, budget pacing across data centres, logging and reconciliation. Those topics live in RTB architecture explained and bidder architecture patterns. The RTB architecture hub links the full engineering set.

1. IAB Tech Lab, OpenRTB 2.6 specification and change log, GitHub (release 2.6-202606, 11 June 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md
2. IAB Tech Lab, OpenRTB 2.x implementation notes, GitHub (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md
3. IAB Tech Lab, AdCOM 1.0, List: Device Types, GitHub (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/main/AdCOM%20v1.0%20FINAL.md
4. IAB Tech Lab, Global Privacy Platform, Section Information, GitHub (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/Section%20Information.md
5. Google Authorized Buyers, "Peer guide" (last updated 17 September 2026). https://developers.google.com/authorized-buyers/rtb/peer-guide
6. Google, "An update on first price auctions for Google Ad Manager" (10 May 2019). https://blog.google/products/admanager/update-first-price-auctions-google-ad-manager/
7. AdExchanger, "Everything You Need To Know About Bid Shading" (15 March 2019). https://www.adexchanger.com/online-advertising/everything-you-need-to-know-about-bid-shading/
8. Prebid.org, "Prebid Timeouts" (accessed 9 November 2026). https://docs.prebid.org/features/timeouts.html
9. Prebid.org, "Prebid Server module" (s2sConfig timeout default, accessed 9 November 2026). https://docs.prebid.org/dev-docs/modules/prebidServer.html
10. Prebid.js source, src/config.ts, DEFAULT_BIDDER_TIMEOUT (accessed 9 November 2026). https://github.com/prebid/Prebid.js/blob/master/src/config.ts