Header bidding and Prebid

Around 2014, publishers discovered a hack. Instead of letting their ad server offer each impression to one partner at a time, they added code to the top, or "header", of their web pages that asked many SSPs for bids at once, before the ad server even made a decision. Revenues jumped. Within a few years this trick, header bidding, became the default way the open web sells ads.

The old way was like selling your bicycle by phoning one friend, waiting for a yes or no, then phoning the next. Header bidding is like posting it in a group chat with ten friends and taking the best offer in the next minute. Same bike, more competition, better price.

The problem: the waterfall

Under the waterfall, the publisher ad server ranked demand sources by their average historical price and called them in order. The first partner could take the impression at its fixed price even if a partner further down would have paid more for that particular user. Google's own exchange had a special advantage: through dynamic allocation, Google Ad Manager let AdX compete against the publisher's floor in real time while other partners were stuck in fixed positions, and it could see their prices. The court in the US ad tech case later described related privileges such as last look as part of how Google neutralised competition.

1. The old way: a waterfall: In the Waterfall (daisy-chaining), the publisher offers the slot to one partner at a time, in a fixed order, each with a floor price.
2. Pass… pass…: Network 1 has nothing worth $3 for this visitor, so it passes. The slot trickles down to Network 2, then Network 3. Every hop adds delay.
3. Money left on the table: Network 3 takes it for $1.20. But Network 2 had a buyer willing to pay $2.80. It was never asked the right way. The order, not the price, decided who won.
4. The new way: ask everyone at once: Header bidding puts a wrapper like Prebid in the page. It sends the request to every partner simultaneously.
5. Real prices come back: Everyone answers with a real price within a timeout (typically 1–1.5 seconds on the web): $2.10, $2.80, $1.20.
6. The ad server decides on price: The best header bid ($2.80) is passed to the publisher ad server, which compares it with direct deals and other demand. The highest price wins. Publishers typically earned noticeably more after switching.

How client-side header bidding works

1. Page loads a wrapperA JavaScript library, usually Prebid.js, loads in the page header along with a list of configured demand partners ("adapters").
2. Parallel requestsThe wrapper sends bid requests to all partners at the same time, each via its SSP.
3. Wait for the timeoutBids arrive within a set window, often around one second on the web. Late bids are discarded.
4. Pass bids to the ad serverThe best bids are attached to the ad request as key-values, so line items in the ad server can compete against direct campaigns and Google's demand.
5. Ad server decidesThe ad server picks the winner. If a header bidder wins, its ad is rendered.

Prebid: the open-source standard

Prebid started in 2015 as an open-source project from AppNexus (later Xandr, now part of Microsoft). In 2017 it moved to an independent body, Prebid.org, whose members include SSPs, publishers and other ad tech firms. Prebid.js runs in the browser; Prebid Mobile covers apps; and Prebid Server moves the auction to the cloud. Because it is free and neutral, Prebid became the most widely used header bidding wrapper on the open web.

Client-side versus server-side

Running many auctions inside the user's browser is heavy. Every extra partner adds network calls and slows the page, hurting user experience. Server-side header bidding solves this by sending a single request from the page to a server, which then fans out to many bidders.

Many publishers use a hybrid: a few high-value bidders client-side, the long tail server-side. Amazon runs its own server-side offering, Transparent Ad Marketplace (TAM) for large publishers and Unified Ad Marketplace (UAM) for smaller ones. Google responded to header bidding with Exchange Bidding, later renamed Open Bidding, a server-side auction inside Google Ad Manager where other exchanges can compete, for a fee.

Side effects: duplication and complexity

Header bidding created new problems. The same impression is now offered through several SSPs at once, and the same DSP may receive five or ten copies of one opportunity. This bid duplication inflates bid volumes, makes it harder to judge real supply and encourages buyers to cut paths, the subject of the supply path optimization lesson. It also made latency and auction timeout settings a constant balancing act for ad-ops teams.

Today the unified auction in Google Ad Manager, header bidding via Prebid, and server-side marketplaces from Amazon and others coexist on most large sites. The practical lesson for anyone buying or selling: the path an impression takes to reach a buyer is rarely simple, and each path has its own fees, speeds and data quality.