Lesson 1 of 7 · 8 min read · intermediate
Real-time bidding in 100 milliseconds
What happens in the blink between a page loading and an ad appearing: the ad request, the OpenRTB bid request, the bids and the winner.
A human blink takes somewhere around a tenth to a third of a second. In less time than that, while a page is still loading on your phone, an auction can be announced to dozens of bidders around the world, each of them can decide whether you are worth showing an ad to, name a price, and one of them can win. This is real-time bidding, and it happens many billions of times a day.
Picture a fish market in Tsukiji or Kochi, but sped up a million times. A single fish (one impression) is held up, a card describing it is flashed to every buyer at once, each buyer shouts a price within a fraction of a second, and the fish goes to the highest bidder before the next one appears. Then it happens again, and again, for every ad slot on every page.
The 100-millisecond auction
Your browser starts loading an article. The page has a space for an ad, but nobody has decided which ad yet.
- You open a page: Your browser starts loading an article. The page has a space for an ad, but nobody has decided which ad yet.
- The slot goes up for sale: Code on the page (often Prebid) calls the publisher’s SSP: “I have a 300×250 slot, on this article, seen by this device, in Mumbai.” That message is a bid request.
- Is anyone real here?: Before the slot is offered, traffic checks look for signs of invalid traffic: known data-center IPs, bot user agents, spoofed domains. Suspicious requests are dropped here, pre-bid.
- Bid requests fan out: The SSP sends the bid request to many DSPs at once, each buying for different advertisers. Every DSP now has a few dozen milliseconds to decide.
- Bids come back: Each DSP checks its campaigns and data: is this someone our advertiser wants? What is this impression worth? It answers with a price, per thousand impressions (CPM).
- Highest bid wins: In today’s first-price auction the highest bid wins and pays what it bid. DSP A wins at $4.20 CPM, which is $0.0042 for this single impression.
- The ad is delivered: The winner’s ad server sends the creative (the image or video) to the page. Tracking pixels fire so the impression can be counted, billed and measured.
- You see an ad: All of that happened before the page finished loading. It repeats billions of times a day, which is why fraudsters target it: fake “visitors” can collect real bids.
The five beats of an auction
- 1. Ad requestThe page or app has an empty slot. Code in the slot sends an ad request (also called an ad call) to the publisher's ad server or SSP, saying "I have a space, fill it."
- 2. Bid requestThe SSP turns that into a bid request: a structured message describing the impression, the page, the device and whatever it may legally share about the user. It sends this to many DSPs at once.
- 3. EvaluationEach DSP checks the request against its advertisers' campaigns: targeting, budgets, frequency caps, brand safety rules, fraud filters. It decides whether to bid and how much.
- 4. Bid responseInterested DSPs reply with a bid response: a price, the ad to show (or a link to it) and some identifiers. Anyone who does not answer in time is ignored.
- 5. Win and renderThe SSP picks a winner, tells it so, and returns the ad to the page. The browser loads the creative, and tracking pixels fire to count the impression.
The whole round trip is squeezed by a auction timeout. OpenRTB lets the seller state the maximum time a buyer has to reply, often in the range of one to a few hundred milliseconds. Bidders that are slow lose not only this auction but future ones, because sellers throttle partners who keep adding latency.
Inside a bid request
Almost all of this traffic speaks one shared language: OpenRTB, a specification maintained by the IAB Tech Lab. Version 2.x, with 2.5 and 2.6 the most widely used today, is a JSON document with a small set of top-level objects. You do not need to memorise them, but knowing the big ones lets you understand almost any conversation about targeting, privacy or fraud.
| Object / field | What it tells the buyer | Why it matters |
|---|---|---|
| id | Unique ID for this auction | Lets both sides match logs later |
| imp[] | Each ad slot on offer: banner or video, sizes, position, bidfloor, any deal IDs | Defines what is for sale and the minimum price |
| site / app | Domain, page URL and category, or app bundle and store URL | Context and brand safety; also what fraudsters spoof |
| device | User agent, IP address, OS, device type, advertising ID | Targeting, frequency capping and bot detection |
| user | Buyer-readable user ID and extended IDs (eids) | Audience matching, where consent allows |
| regs | Flags for GDPR, COPPA, US state privacy and the GPP string | Tells buyers what they may legally do |
| source.schain | Every company the request passed through | Supply-chain transparency and reseller checks |
| tmax / at | Time limit in ms; auction type (1 = first price, 2 = second price) | Sets the rules of the auction |
The bid response is smaller. It contains one or more bids, each with a price, an adm (the ad markup) or a URL to fetch it, a creative ID, the advertiser's domain (so the publisher can block competitors or sensitive categories) and, if relevant, the deal ID the bid belongs to.
How buyers recognise you
A DSP can only use its advertisers' audience data if it can match the user in the request to someone it knows. On the web this has long relied on cookie syncing: the SSP and DSP quietly exchange their cookie IDs through redirect pixels, building a lookup table. In apps, the Mobile advertising ID (mobile advertising ID) plays that role, where the user allows it. In 2026, Chrome still supports third-party cookies after Google dropped its deprecation plan, but Safari and Firefox block them by default, so buyers increasingly use shared IDs, hashed emails and contextual signals as well.
The seller's side of the maths
The publisher sets a floor price on each impression: bids below it are rejected. If floors are too high, fill rate collapses; too low, and buyers get bargains. SSPs increasingly set dynamic floors using machine learning, which is one reason buyers now pay close attention to how auctions are run, a topic covered in the auctions lesson.
Key takeaways
- Real-time bidding auctions each impression in roughly a tenth of a second while the page loads.
- The SSP sends an OpenRTB bid request describing the slot, site or app, device, user, privacy flags and supply chain.
- DSPs reply with a bid response containing a price, the ad markup and a creative ID; late bidders are dropped.
- The bidstream carries data to many companies, which is why consent and privacy fields matter.
- Floors, deals and direct campaigns can beat the highest open-auction bid.
Questions people ask
How does real-time bidding work?
When a page or app loads, its ad slot sends an ad request to an SSP. The SSP builds a bid request describing the impression and sends it to many DSPs at once. Each DSP decides within milliseconds whether to bid and how much. The SSP picks the winning bid above the floor price and returns the ad, which then loads on the screen.
What is in an OpenRTB bid request?
An OpenRTB bid request is a JSON message with objects describing the ad slot (imp, including sizes, floor and deal IDs), the site or app, the device (user agent, IP, OS, advertising ID), the user and their IDs, privacy regulation flags such as GDPR and GPP, the supply chain object, and auction rules like the timeout and auction type.
How long does a programmatic ad auction take?
A typical real-time bidding auction is designed to finish in roughly 100 milliseconds or so, although sellers set their own timeouts, often ranging from under 100 to a few hundred milliseconds depending on format and setup. Bidders that miss the deadline are ignored, which is why buyers invest heavily in fast infrastructure close to major exchanges.