A parent in Lyon opens a forum to compare car seats. In the same second, a student in Lille opens a page about budget flights. Both pages fill in an ad before either reader has finished scrolling past the headline, and the two ads could not be more different: a stroller brand for one, a low-cost airline for the other. Neither site knew in advance who was visiting. Neither advertiser picked that particular reader by name. Yet somehow, in a fraction of a second, the right ad found the right page.
That handoff, repeated billions of times a day across the open internet, is real-time bidding (RTB): an auction that opens and closes before most of us notice it happened. It is the foundational transaction mechanism behind most of programmatic advertising, the plumbing that decides, impression by impression, who gets to show an ad and what they pay for it.
Why real-time bidding was invented
Before RTB, publishers sold their unsold inventory, the space left over once direct sales teams had placed their campaigns, through ad networks at flat rates. A network would buy a block of impressions cheaply and resell them, with little visibility for anyone into exactly where an ad would land or who would see it.
That system had an obvious flaw. An advertiser had no way to pay differently for two visitors on the very same page, even if one of them was, for that advertiser’s purposes, worth ten times more than the other. Price was set in advance, in bulk, disconnected from the actual value of any single moment.
RTB replaced that flat, bulk pricing with something much narrower: a price decided fresh, for one impression, in the instant it becomes available.
For the first time, a buyer could pay more for a visitor worth more to them, and nothing at all for one who was not, without ever learning who that visitor actually was.
How the pieces fit together
Strip away the acronyms and an RTB auction is a simple idea executed at enormous speed: one ad slot, several buyers invited to the same moment, the best valid offer wins.
A publisher’s page (or its header bidding wrapper) signals that a slot is open. That signal reaches an SSP (a supply-side platform), which packages what little it knows, the slot’s size, the page’s topic, a rough device and location, into a single structured message and broadcasts it to every connected buyer at once. Each DSP (demand-side platform) receives that same message, in parallel, and has to decide, alone and in milliseconds, whether to bid and how much.
One slot, one request, every connected buyer invited to the same auction at the same time.
This article stays at that level: the rules, the roles, the data, the risks. If you want to watch a single impression move through these steps in order, millisecond by millisecond, we followed one all the way through elsewhere. Here, the focus is on how the auction itself is built.
Two rules for deciding a price
Once bids arrive, something still has to decide what the winner actually pays. There are two common rules, and the difference between them matters more than it sounds.
In a first-price auction, the winner pays exactly what it bid. This is now the dominant format in programmatic. Its side effect is that buyers have to guess, not just what an impression is worth to them, but what everyone else is likely to bid, and shave their own number down a little to avoid overpaying. That practice has a name: bid shading.
In a second-price auction (also called a Vickrey auction), the winner still wins, but pays only one currency unit above the second-highest bid, not its own number. This was the common format in early programmatic, and it still exists in some corners of the market today. Because the price paid depends on someone else’s bid rather than your own, it removes much of the incentive to shade: bidding your true value is already the safest strategy.
Same three example bids, two different outcomes: under a first-price rule the winner pays its own number, under a second-price rule it pays just above the runner-up.
Picture every raised hand as a bid: in an RTB auction, dozens of buyers answer the same request at once, silently and in parallel.
What is actually inside a bid request
A bid request is not a profile of a person. It is a short, structured message built to the OpenRTB specification, the shared format most of the industry speaks, and it is designed to say as little as possible about who is actually looking at the page. Typical fields include:
- Impression data: the ad slot’s size, its format (banner, video, native), where it sits on the page.
- Publisher data: the site or app’s domain, its content category, its language.
- Device data: device type, operating system, a rough, city-level location rather than an address.
- Audience data: any anonymous segments a publisher’s data platform has attached, if any.
- Deal data: a deal ID, if this particular slot belongs to a private arrangement rather than the open market.
Notice what is missing: no name, no email, no exact address. The amount of user-level information in a bid request has been shrinking for years, as privacy regulation and browser policy both push in the same direction: less to work with, more guesswork based on context instead of identity.
The clock is the hardest constraint
None of the above would matter if it took longer than a page load to resolve. Publishers set a bid timeout: the maximum time they will wait for offers before the auction closes and a backup ad is served instead. A bid that arrives even a few milliseconds late is simply discarded, no matter how high it was. The deadline does not negotiate.
That constraint shapes everything on the buying side. A DSP has to receive a request, check it against potentially thousands of active campaigns, apply rules (is this site allowed, is there budget left, does the geography match), price it, and respond, typically in under 100 milliseconds, for every single impression it sees. Large DSPs process hundreds of thousands of these requests every second, around the clock.
Behind every bid is a server, somewhere, deciding in a fraction of a second whether this particular impression is worth paying for.
RTB is not the whole market
Open-auction RTB competes with other ways of selling the same inventory. Publishers typically give first pick to guaranteed deals, programmatic guaranteed or direct insertion orders agreed in advance, which means the open RTB auction often only sees what was not already spoken for through those direct channels.
That used to put RTB buyers at a structural disadvantage: any slot sold directly never reached the open auction at all. Header bidding changed that, by letting RTB buyers compete for the same slot at the same moment as direct deals, instead of only getting what direct sales left behind.
Keeping an open, automated market safe
An auction with no human in the loop, running millions of times a second, creates its own risks. The main ones advertisers have to guard against are:
- Invalid traffic (IVT): bot activity that manufactures fake impressions to collect payment for ads nobody ever saw.
- Domain spoofing: a low-quality site misrepresenting its own address to look like a premium publisher.
- Unsafe adjacency: an ad landing next to content that conflicts with a brand’s guidelines.
Industry standards (ads.txt and sellers.json from IAB Tech Lab, the OpenRTB specification itself) plus independent measurement vendors help reduce these risks, but none of them replace active campaign management: allow lists, block lists, and someone actually watching where the budget lands.
FAQ
Is real-time bidding the same thing as programmatic advertising?
Not quite. Programmatic advertising is the umbrella term for buying and selling ads through software rather than human negotiation. RTB is one transaction method inside that umbrella, specifically the open-auction kind. Programmatic guaranteed deals and private marketplaces are programmatic too, but they are not auctions in the RTB sense.
How fast does one RTB auction actually take?
The full round trip, from the moment a page asks for an ad to the moment that ad is rendered, typically finishes in under 200 milliseconds, and often closer to 100. Most of that time is spent waiting on dozens of buyers to answer the same request in parallel, not on any single step.
What is bid shading, in plain terms?
In a first-price auction, the winner pays exactly what it bid, so bidding your absolute maximum valuation risks paying more than you needed to. Bid shading is the practice of estimating how much lower you can go while still probably winning, and bidding that instead.
Does RTB rely on tracking individuals?
Less than it used to. A bid request is built to describe a moment (a slot, a page, a rough device and location), not a person. Industry and regulatory pressure has steadily reduced the amount of identity-level data that travels inside it, pushing buyers toward contextual signals instead.
Can a small, local business realistically use RTB?
Yes. RTB itself does not care about the size of the buyer, only about the price and the rules attached to a bid. The barrier for small advertisers has historically been tooling and minimum spend, not the auction mechanism itself.
How Arago helps
Arago’s DSP runs this entire sequence on the open internet, across websites and mobile apps, over OpenRTB. A slot is auctioned in about 10 ms, Arago checks your zone, allowed-site and budget rules in about 30 ms, then bids or passes around 60 ms, with the ad appearing near 100 ms after the page opened. Allow and block lists, frequency capping, and your own tracking pixels per line item give you control over exactly where and how often each bid is placed. Draw those zone rules yourself in Map, and explore the interactive formats that run once a bid wins in Creative.
