How does real time bidding work, one auction at a time?
Part of Programmatic media planning
The short answer
Real time bidding is an auction for a single ad impression, held while the page or app loads. An exchange sends a bid request to bidders, each answers with a bid or no bid before a deadline, the exchange picks a winner, notifies it and returns the ad. OpenRTB's tmax field sets that deadline in milliseconds.
Key takeaways
- One RTB auction runs through named messages in order: ad request, bid request, bid response or no bid, win notice, ad markup and a later billing notice.
- The exchange's tmax field sets the deadline in milliseconds, and a late answer is treated as no answer.
- A bid is qualified before it competes: it must be well formed, from an eligible buyer and seat, and meet floors and the seller's rules.
- Winning is not delivery: OpenRTB separates the win notice from the billing notice, which fires when the impression becomes billable under the exchange's policy.
- A site list acts inside the bidder, before the bid response; it decides where the buyer bids, not what the exchange offers.
What happens in a real time bidding auction step by step?
The OpenRTB 2.6 specification (opens in a new tab) defines RTB as "bidding for individual impressions in real-time (i.e., while a consumer is waiting)" and an exchange as "a service that conducts an auction among bidders per impression." Its implementation notes sum up the flow: an ad is requested by a client, possibly through other server intermediaries, the exchange runs an auction, "selects a winner, issues a win notice to the winning bidder, and passes the markup back to the client." Each of those hops is a separate message with its own name.
| Message | From and to | What it carries |
|---|---|---|
| Ad request | Page, app or a software kit inside it, to the exchange | The slot that is available, sometimes passing through other intermediaries first |
| Bid request | Exchange to each bidder, by HTTP POST | The impressions offered, site or app, device, any deals, the floor and the tmax deadline |
| Bid response | Bidder to exchange | Bids grouped by seat, each with a price expressed as CPM, the impression it is for and, for a deal, the deal ID |
| No bid | Bidder to exchange | An empty HTTP 204 response, or a response with a no-bid reason code in nbr |
| Win notice (nurl) | Exchange to the winning bidder | Confirmation of the win, "not necessarily indicative of a delivered, viewed, or billable ad," with macros such as the clearing price |
| Ad markup (adm) | In the bid, or returned on the win notice | The creative to render; if both carry markup, the adm contents take precedence |
| Billing notice (burl) | Exchange to the winning bidder | Called "when a winning bid becomes billable based on exchange-specific business policy" |
| Loss notice (lurl) | Exchange to a losing bidder | Called "when a bid is known to have been lost," where the exchange supports it |
How long does an RTB auction take?
As long as the exchange allows, which is a fraction of a second. OpenRTB's tmax is the "maximum time in milliseconds the exchange allows for bids to be received including Internet latency to avoid timeout," and the specification's own sample bid request sets it to 120, a little over a tenth of a second. For how auctions disclose their rules, the MRC Digital Advertising Auction Transparency Standards (opens in a new tab), issued in January 2026, cover disclosure and reporting for digital ad auctions across display, text, video and audio formats.
Exchanges publish their own limits. Google's Authorized Buyers peer guide (opens in a new tab), for example, says its deadline "typically ranges from 80 to 1000 ms," that it includes both network time and the time the bidder takes to answer, and that 85 percent of responses must arrive within it or the bidder is throttled. A response that misses the deadline does not count, so to the exchange a timeout looks like a no bid.
The clock does not stop when the auction ends. Billing can come much later, especially in apps that fetch an ad early and show it after a delay. The OpenRTB implementation notes (opens in a new tab) offer rules of thumb for how long that gap may reasonably be, and the exp field lets the exchange and the bidder state how many seconds they will allow between auction and billing.
| Impression type | Example expiration in the notes |
|---|---|
| Desktop and mobile web browsers | 1 minute |
| Mobile app banner ads that may be cached | 5 minutes |
| Mobile app native ads that may be cached | 10 minutes |
| Mobile and video interstitials | 30 minutes, or even longer |
| Audio or video with server side stitching | Very long or unknown |
What information does a bidder see before it bids?
Only what the bid request says, and only what the seller chose to fill in. The request describes the offer in a few groups of objects: the impression, the place, the device, the user and the source. Field by field reading of a sample is covered in the bid request guide. For auction mechanics, what matters is the boundary between what the bidder knows and what it does not.
| Topic | In the bid request | Not in the bid request |
|---|---|---|
| The slot | Format, size, position hints and the floor in CPM | Whether the slot will actually render on screen |
| The place | The declared site domain and page URL, or the app bundle, and any declared categories | The text of the article, unless the bidder prepared its own reading earlier |
| Deals | The private marketplace object with any deal IDs, floors and allowed seats | The terms of deals offered to other buyers |
| The selling path | The supply chain object, when the seller passes it | Whether every node is honest, which needs ads.txt and sellers.json checks |
| Competitors | Nothing | Other bidders' bids; the MRC describes first and second price bids as sealed (secret) |
How does the winning bid get chosen?
First, the exchange decides which bids may compete at all. The MRC standards call these qualified bids and describe the tests in order. Then the qualified bids are ranked, and the auction rule sets the price.
From received bid to winner, following the MRC's qualified bid definition
- Reject malformed bids. The MRC notes that "malformed bids are not processed."
- Confirm the buyer is eligible. The auctioneer checks which demand partners may take part, "which may include determining DealID eligibility."
- Apply the seller's thresholds. A qualified bid "must meet publisher business thresholds, e.g., price floors and buyer brand safety requirements," plus rules such as competitive brand separation.
- Check seat and advertiser lists. Bids are validated against "optional allow and deny lists for the seller," and each OpenRTB bid carries the seat ID and the advertiser domain, the latter defined "for block list checking."
- Rank and price. The exchange's auction rules pick the winner among qualified bids, and the auction type sets the price; in a first price auction the winner pays its bid, as the first price auction guide explains.
- Notify. The winner receives its win notice with the clearing price, and losers may receive a loss notice with a reason code where the exchange supports it.
The exchange is not always the last word. OpenRTB notes that "the exchange in question may not be the final decision-maker. It may propagate two or more bids into a second auction," which is what happens when a publisher collects bids from several exchanges at once through header bidding. For buyers, that means a bid can win one exchange's auction and still lose the page.
Where in the auction does a site list take effect?
A site list does not change what the exchange sends. Every eligible request still arrives at the bidder. The list acts at step three, inside the buyer's demand side platform, as the rule that decides whether a request is worth a bid. If the declared domain is not on the list, the bidder stays silent and the auction goes on without it.
Points in one auction where a listed site can still be missed
- The domain in the bid request is written differently from the list entry, for example with a subdomain the list does not cover.
- The impression comes from the site's app, which carries a bundle ID rather than a domain.
- The site sends requests only through exchanges the buyer's seat does not buy on.
- The floor in the request is above the line item's maximum bid.
- The bidder's answer arrives after tmax and is discarded.
- The bid wins the exchange's auction but loses a later auction among several exchanges on the page.
Each of these leaves a trace in the bidder's logs: no matching request, a no bid, a timeout or a loss notice. Reading those traces, rather than the overall spend figure, is how a desk finds out whether a short inclusion list is underdelivering because of the sites or because of the path to them.
Where does PlacementGraph work in the auction timeline?
What does tracing one auction look like for a real plan?
Fictional example
An indoor climbing gym chain in Illinois and Indiana
A fictional Chicago chain of indoor climbing gyms runs display ads in Illinois and Indiana, in English, beside fitness, local lifestyle and city weekend guides, to sell first visit passes. A regional city lifestyle magazine on the approved list shows almost no delivery after two weeks, and the client asks whether the magazine is refusing the campaign.
The trading desk follows one day of requests from the magazine through the messages. Requests arrive from two exchanges. On the first, the bidder answers in time but the floor is above the line item's maximum bid, so it sends no bid. On the second, bids go out but loss notices come back, and the magazine's ad setup turns out to collect bids from several exchanges before choosing.
The planner reports the finding to the client in auction terms: the magazine was eligible, the bidder chose not to bid on one path and lost on the other. The client agrees to ask the magazine for a private auction deal, and the planner records the decision beside the list version.
Frequently asked questions
What happens if the winning ad fails to load?
The bidder won but nothing rendered. OpenRTB calls the case where a bidder wins but fails to serve the ad markup a forfeit. Because the win notice does not mean delivery, an exchange can bill on delivery or rendering instead, signaled by the billing notice. Check the exchange's billing policy, since OpenRTB leaves it to each exchange.
Can a buyer see the bids it lost to?
Partly, and only if the exchange shares it. OpenRTB defines a minimum to win macro that can carry the price needed to tie the winning bid, and loss notices can carry a reason code. Exchanges may withhold both, for example under privacy controls or when price was not the reason for the loss, in which case the value is left empty.
What is a no-bid reason code?
A number a bidder can put in the nbr field of an otherwise empty response to say why it did not bid. OpenRTB 2.6 points to the list of codes in OpenRTB 3.0. Sending one is optional, since an empty HTTP 204 response also means no bid, but reason codes make timeouts and filtered requests easier to tell apart in logs.
Do exchanges filter bot traffic before the auction?
They are expected to try. OpenRTB's implementation notes recommend that exchanges filter known spiders and suspected non-human traffic before offering an impression to bidders, and that bidders no-bid such impressions with a reason code. Both sides should mark those records so they do not count toward planning, forecasting or reporting.
Sources
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab
- OpenRTB 2.6 implementation notes (opens in a new tab)IAB Tech Lab
- Digital Advertising Auction Transparency Standards (January 2026) (opens in a new tab)Media Rating Council
- Authorized Buyers peer guide (opens in a new tab)Google for Developers
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.