What is Header Bidding and How Does It Work?
May 7, 2025 7 min read
Back in the early days of the Internet, when an advertiser wanted to buy ad space on a publisher’s website, they would call up the publisher’s sales team to make the purchase.
While the direct advertiser-publisher relationship is still around, the introduction and growth of technology has added speed, efficiency, and scale to the online media buying and selling process.
As the number of technology platforms has increased, so too has the number of processes; and one process gaining traction in the AdTech world is header bidding.
What is Header Bidding?
Header bidding (aka pre-bidding, advance bidding, and holistic yield management) is a process that enables publishers to simultaneously collect multiple bids from a number of demand sources (not only from their ad server) on all of their ad inventory prior to a sale.
This process allows publishers to “see” which demand sources (e.g. demand-side platforms [DSPs] and ad networks connected to ad exchanges and supply-side platforms [SSPs]) are placing the bids and the monetary value of their bids (e.g. $1.05), allowing them to get the highest cost per mille (CPM) possible. As bids are received before a publisher’s ad server is called, they are able to compete with a publisher’s premium deals, meaning advertisers have a better chance of winning the impression and publishers earn more money for their inventory.
How Did Header Bidding Come About?
AdTech vendors developed header bidding to enable publishers to collect bids on their inventory from demand sources before the ad call was sent to their DoubleClick for Publishers (DFP) ad server. The reason for this was to avoid the common situation where the DFP, which is used by a large majority of publishers, favored bids from the Google ad exchange, meaning non-Google demand sources would often miss out on bidding on or purchasing the publisher’s inventory, even though they were willing to pay more for it.
Header bidding has also, somewhat accidentally, replaced waterfall auctions.
A waterfall auction is a structured process for selling inventory handled by the publisher’s ad server, which would sell the available inventory to potential buyers in a sequential fashion.
Typically, the ad server would offer the inventory to premium buyers (e.g. guaranteed buys, direct sales made between the publisher’s sales team and the advertiser, and sponsorships). If the premium buyers failed to purchase all of the available inventory, the ad server would approach the next potential buyer (e.g. an ad network) with the aim of selling the remaining available inventory, known as remnant inventory.
The ad server would continue contacting various demand sources until all of the available inventory was sold. In the event the available inventory wasn’t sold, the publisher could display in-house ads (ads promoting their own products or services).
How Does Header Bidding Work?
The starting point of the header-bidding process involves adding a piece of JavaScript code, supplied by the header-bidding vendor, to the <head> element of a publisher’s website.
The snippet of JavaScript code is responsible for connecting to various sources interested in purchasing ad inventory.
From that moment on, each time a page loads, the demand sources (e.g. ad networks and buyers connected to supply-side platforms [SSPs] and ad exchanges) will be able to bid on each impression on that page. This allows advertisers to compete with a publisher’s direct deals, which often results in the advertiser showing an ad to a member of their target audience and the publisher earning more money for that ad impression.
A Step-by-step Explanation of How Header Bidding Works
Below is a step-by-step breakdown of what happens from the moment a user lands on a publisher’s website to the sale of available ad inventory:
- A user opens their web browser and types in the publisher’s URL (e.g. publisher-abc.com).
- The browser starts loading the page.
- The header-bidding JavaScript code located in the element executes and sends a request to the third-party header platform.
- Bids from various sources start coming in.
- The highest bid wins and then competes with the publisher’s other deals.
As you can see in the diagram, the speed at which bids are placed varies. This latency not only means some demand sources may not be able to place a bid due to being timed out, but also results in the page taking longer to load. The timeout rates vary and are different on desktop and mobile. With desktop, the timeout range is 400–800 milliseconds; with mobile, it’s 800–1,200 milliseconds.
The process described in the image above is an example of client-side header bidding (CSHB), but there is also a server-side implementation.
What is Server-side Header Bidding?
Server-side header bidding (SSHB) follows a similar process like the client-side implementation, but instead of sending the ad requests from the browser directly to the various AdTech platforms, server-side heading bidding sends the ad requests from the browser to a dedicated server. Then, the server sends the ad requests to different exchanges, SSPs, and DSPs. Once the server has received the bids, it then sends them back to the browser and on to the publisher’s ad server.
The Main Advantage of Server-side Header Bidding
The main advantage of server-side header bidding is a reduction in page latency.
As all of the bidding happens outside of the browser in a dedicated server, the browser is able to render all the other parts of the page without being bogged down with multiples ad requests — resulting in a better user experience.
The Main Disadvantages of Server-side Header Bidding
Despite the improvements in the user experience, server-side header bidding does come with a few disadvantages. The main ones being:
- A lack of transparency — as the bidding happens in a server, it can be hard for publishers and advertisers to see the details of the auctions, meaning they don’t know the true cost of the impressions, what auction type was used (e.g. first- or second-price auction), and how many fees were added on top.
- Bid latency — even though SSHB reduces page latency, the same cannot always be said for bid latency. Some bids may not be able to respond to the ad requests in time because of the extra step involved in SSHB (i.e. sending ad requests to the server first and then on the supply and demand sources, rather than sending them directly from the browser).
- Cookie match rates — because SSHB moves the bidding process off the page, cookies can be lost. This not only makes it hard for advertisers to identify users, but also means they may need to sync cookies, which can be a rather error-prone process.
- Technical complexity — setting up, configuring, and managing a server-side header bidding connection is much more complex for the header-bidding vendor and the platforms that use it.
It’s important to note that while the header-bidding process is nothing new — it’s been around for about 10 years — it really started to take off in 2014 and 2015 with the help of programmatic media buying.
In-app Header Bidding
Header bidding is currently making its way to various new platforms as more and more companies make their foray into the modern, faster bidding method. Platforms that already offer in-app header bidding include Google AdMob, Amazon, Oath, and AppLovin.
Technically speaking, header bidding has grown to become a slight misnomer today as mobile apps don’t have a header per se – but the core idea remains unchanged. Bids are simultaneously solicited from multiple demand partners before a call to the ad server is made.
Final Thoughts
The introduction of header bidding has changed the game of online advertising and brought with it a number of advantages for publishers and advertisers alike. Innovation is a constant force in the online advertising technology ecosystem, and AdTech companies adapt to changes.
Ready to boost your ad revenue with efficient header bidding? Let’s discuss a custom solution that fits your publishing needs and maximizes your inventory’s value.