For most of the 2010s, a publisher running display ads was selling into an auction where one bidder always knew the room better than everyone else. That bidder was Google's exchange, and the reason it knew the room was that Google also owned the auctioneer. Header bidding is the technology publishers used to take that advantage away. It is a small piece of code with an outsized history, and understanding it is the fastest way to understand how the sell side of programmatic actually works.
The waterfall, and the problem with going one at a time
Before header bidding, a publisher's ad server sold inventory through a process called the waterfall, also known as daisy-chaining. The logic was sequential. Direct-sold campaigns went first. Then the ad server called demand sources one at a time, in a fixed priority order set by the publisher, usually ranked by each source's historical average price. The first source that accepted the impression won it. Whatever was left fell through to the next source down, and the next, until something cleared or the impression went unsold.
The waterfall had two structural flaws. The first was that it ranked sources by their average price, not by what any source would actually pay for the specific user looking at the specific page right now. If an exchange near the bottom of the chain happened to have a buyer willing to pay a high price for that exact impression, it never got the chance, because a higher-average source above it had already taken the inventory at a lower price. AdExchanger, writing in 2015, put the effect plainly: the model ignored pockets of high-value inventory and artificially capped a publisher's revenue. The second flaw was speed. Calling sources one after another is slow, and a chain of failed calls is slower still.
Then there was the part that made header bidding feel less like an optimization and more like a revolt. Google owned the dominant publisher ad server, DoubleClick for Publishers, and the dominant exchange, AdX. DFP had a feature called dynamic allocation that let AdX do something no rival exchange could: bid in real time on every impression, after the publisher's other demand had already shown its hand. Digiday described the mechanic with a clean example. If a rival exchange's average rate was two dollars, AdX could win the impression at $2.01, even when that same impression might have been worth five dollars to that rival based on the actual user. Google held what the industry came to call last look. It saw competing bids in an otherwise sealed auction, then bid. As one publisher told AdExchanger, dynamic allocation let AdX cherry-pick inventory. The house was also a player, and the house bid last.
What header bidding actually is
Header bidding moves the auction out of the ad server and into the page itself. A publisher places a snippet of JavaScript, called a wrapper, in the header of the page, so it loads before the ad server is called. When a user opens the page, the wrapper sends bid requests to many demand sources at the same time. Every source gets the same impression, at the same moment, with the same information, and a fixed window to respond, usually one to two seconds. The wrapper collects the bids, picks the highest, and passes that price into the ad server as a line item to compete against everything else.
The change is simple to state and large in effect. The waterfall asked sources one at a time and accepted the first yes. Header bidding asks everyone at once and takes the real highest bid. No source gets to bid last, because they all bid together. The privileged position Google's exchange held inside the ad server stopped mattering, because the decisive auction now happened before the ad server ran at all. The revenue effect was real enough to drive adoption fast: in a Digiday Research survey, 88 percent of publishers reported a lift after switching, and a third of them put the yield gain at 25 percent or more. This is also the mechanism that makes the real-time bidding auction work the way buyers expect, with genuine simultaneous competition rather than a queue.
Client-side versus server-side, and the cost of the snippet
There are two ways to run header bidding, and the choice is a genuine tradeoff rather than a settled answer.
Client-side header bidding runs the auction in the browser. The wrapper itself fires every bid request from the user's device. This is the original form, and it has a real advantage: because the calls happen in the browser, each demand partner can sync its cookie directly with the user, which keeps match rates high. Higher match rates mean buyers can identify the user, which tends to mean higher bids. The cost is page speed. Every bidder you add is more code and more network calls competing for the browser's attention while the page is trying to load. Industry guidance puts useful bidder timeouts in the 1,000 to 2,000 millisecond range, and the practical pattern is well known: add bidders and CPMs rise while page load slows, cut bidders and the page speeds up while some demand is lost.
Server-side header bidding moves the auction to a remote server. The browser makes one call to that server, and the server fans the request out to all the demand partners. This is much lighter on the page, and it removes the browser's limit on how many bidders you can reasonably include. The cost is match rate. When cookie syncing happens server to server instead of in the browser, identity leaks at every hop. Criteo's explainer gives the arithmetic: a 70 percent publisher-to-SSP match combined with a 60 percent SSP-to-DSP match leaves only about 42 percent overall. Fewer identified users means weaker bids. Server-side also gives the publisher less visibility into who saw the impression. Most large publishers now run a hybrid, keeping their strongest demand client-side and moving the long tail server-side.
Prebid, the standard that made it work
Header bidding could have stayed a mess of proprietary, incompatible integrations. It did not, mostly because of Prebid. In 2015, engineers at AppNexus built Prebid.js, an open-source wrapper that gave header bidding a common, vendor-neutral framework. In 2017 the work was spun out into Prebid.org, an independent organization founded by AppNexus and Rubicon Project, with other ad-tech firms joining the effort. The point of an independent body was credibility: a wrapper owned by one exchange would always be suspected of favoring that exchange's demand.
Prebid grew into the default plumbing of the sell side. Prebid.js handles client-side auctions in the browser. Prebid Server handles server-side auctions and supports environments without a real page header, such as mobile apps and AMP. Prebid Mobile brings the same logic into native apps. The project's own documentation describes an ecosystem of more than 300 demand partners and about 50 analytics providers, and calls Prebid.js the most widely used wrapper available. Industry tracking backs that up: by one widely cited count, roughly seven in ten header bidding setups run on Prebid rather than a proprietary wrapper. For a piece of open-source infrastructure, that is rare reach, and it matters. A publisher and a buyer can integrate once against a shared standard rather than negotiating a private integration for every exchange. Prebid sits inside the broader ad-tech stack as the sell side's connective tissue.
How Google fought back
Google did not ignore header bidding. It responded on two tracks, one public and one not, and both became central to the antitrust case that followed.
The public track was Exchange Bidding, later renamed Open Bidding. Announced in beta in 2016 and rolled out from 2018, it was Google's server-side answer: invite rival exchanges to compete inside Google Ad Manager, in a unified auction. In March 2017 Google said it was dropping last look, with a product manager describing a single auction where the highest price wins. On its face this was the concession header bidding had forced. In practice Open Bidding kept Google in the middle. Google charged a fee on the transactions, controlled payment and reporting, and still saw bid data that header bidding kept in the publisher's hands.
The track that did not show up in a blog post emerged later through litigation. The US Department of Justice and several state cases described a series of internal Google projects aimed squarely at header bidding. Project Bernanke, dating to 2013, subsidized Google's own bids on competitive AdX impressions, bidding above what an advertiser was willing to pay so that Google's exchange won more of the inventory header bidding was contesting. Project Poirot, from 2016, steered Google's own DSP to shade down its bids into rival exchanges, by ranges the DOJ complaint put at 10 to 40 percent at first and as much as 90 percent for some exchanges later, to make header bidding exchanges less profitable and pull spend back toward AdX. The DOJ filings record the result plainly: after Poirot, the exchange OpenX saw a 30 percent year-over-year drop in spend from Google's DV360 and laid off roughly 100 people. Unified Pricing Rules, introduced in 2019, removed publishers' ability to set higher price floors on AdX than on other exchanges, taking away a lever publishers had used to make AdX compete harder against header demand.
In April 2025, Judge Leonie Brinkema of the Eastern District of Virginia ruled that Google had illegally monopolized the publisher ad server and ad exchange markets and had unlawfully tied the two together. The court's findings named First Look and Last Look directly, alongside Unified Pricing Rules, as anticompetitive conduct. Header bidding is woven through that story. It was the workaround publishers built when they could not get a fair auction, and the pressure it created is part of why these mechanics ended up in front of a judge at all. The remedies trial ran in the autumn of 2025, with closing arguments in November, and the DOJ pressing for a forced sale of AdX rather than the lighter behavioral fixes Google preferred. The final order was still pending as of mid-2026, with appeals certain whichever way it lands.
Where header bidding stands now
Header bidding is no longer a revolt. It is plumbing. It runs quietly under a large share of the open web's display inventory, and the argument over whether publishers should use it is long settled. The live questions are about what gets layered on top.
The first layer is curation. Rather than asking every demand source on every impression, supply-side platforms increasingly package and data-enrich inventory into curated marketplaces before it reaches buyers. Index Exchange, which calls curation the biggest shift in programmatic since header bidding itself, says budgets are moving to curation faster than to any other recent change in the channel. Header bidding still carries the impression. Curation decides what shape it arrives in.
The second layer is page-speed intelligence. The original tradeoff has not gone away, but wrappers are getting smarter about it. Modern setups predict which demand partners are actually likely to bid on a given impression and load only those, instead of firing every bidder every time and paying the latency cost for nothing.
The third layer is agentic buying. As autonomous software begins to plan and transact campaigns, and as new agent-to-agent protocols compete to standardize how buying and selling systems talk, the header bidding auction becomes one of the things an agent operates rather than something a human configures. The mechanism that publishers built to win a fair auction is becoming an interface for machines.
The throughline is the same idea that started it. A fair auction is one where every bidder competes on equal footing, with the same information, at the same moment, and nobody bids last. Header bidding did not invent programmatic. It corrected it. That is why a snippet of code in a page header still matters more than its size suggests.
Council summary
The post argues that header bidding was less a technical optimization than a structural correction: publishers built it to escape a waterfall that ranked demand by average price and an ad server that quietly let Google's own exchange bid last. It traces the mechanic cleanly, from sequential daisy-chaining to a simultaneous in-page auction, then through the real client-side versus server-side tradeoff, the role of Prebid as neutral infrastructure, and Google's two-track response that the 2025 antitrust ruling later named as anticompetitive. The reader's takeaway is a working model of how the sell side actually clears an impression, and why a fair auction means every bidder competing on equal footing at the same moment with nobody bidding last. The piece is accurate, well sourced, and earns its length; every statistic now traces to a named source.
Comments