Header bidding is a programmatic advertising technique where publishers offer their ad inventory to multiple ad exchanges simultaneously before calling their primary ad server. Also known as pre-bidding, advance bidding, or holistic yield management, this method helps publishers increase competition for their ad space. By letting multiple demand sources bid at once, publishers ensure they receive the highest possible price for every impression.
What is Header Bidding?
Header bidding is an advanced programmatic selling process that allows publishers to collect bids from various demand sources outside their primary ad server environment. Historically, publishers sold ads through a "waterfall" or "daisy chain" system, where inventory was offered to buyers one by one in a specific order.
Header bidding bypasses this sequential process. It executes a simultaneous auction where demand-side platforms (DSPs) and ad networks connected to supply-side platforms (SSPs) compete for the same impression at the same time. This ensures that the publisher sees the true market value of their inventory before a sale is finalized.
Why Header Bidding matters
Publishers use header bidding to solve inefficiencies in traditional digital advertising. The primary benefits include:
- Increased Revenue: By expanding the pool of bidders, publishers can often achieve [yield increases of approximately 10 percent] (Digiday).
- Greater Transparency: Publishers can see exactly what different demand sources are willing to pay on a per-impression basis.
- Fair Competition: It allows non-Google demand sources to compete with [Google’s ad server, which holds a 90 percent market share] (The Current).
- Control over Inventory: Publishers decide which bidding partners participate in the auction and can prioritize specific inventory segments.
- Reduced Waste: Eliminating the waterfall structure prevents impressions from being passed back and forth between buyers, which often leads to lost inventory.
How Header Bidding works
The process begins as soon as a user visits a publisher's website or app. While the technical details vary slightly for mobile apps or video, the standard display ad process follows these steps:
- The user opens their browser and loads the publisher's URL.
- A snippet of JavaScript code located in the website's
<head>element executes. - The code calls out to multiple demand partners (SSPs and exchanges) to request bids.
- Partners return their bids within a specific timeframe.
- The highest bids are passed to the publisher's ad server.
- The ad server compares these external bids against direct sales or guaranteed deals.
- The ad server selects the winning bid and displays the ad to the user.
Client-side vs. Server-side Header Bidding
Publishers choose between running the auction in the user's browser (client-side) or on an external server (server-side).
| Feature | Client-side (CSHB) | Server-side (SSHB) |
|---|---|---|
| Location | User's browser | Dedicated external server |
| Transparency | High visibility into auction details | Lower transparency for publishers |
| Latency | Higher: can slow page load times | Lower: reduces browser overhead |
| Targeting | High cookie match rates | Potential for lost cookie data |
| Complexity | Easier to set up with wrappers | Highly technical configuration |
Best practices
- Select partners thoughtfully: Do not add every available SSP to your header. While more bidders can increase competition, too many tags can cause "tag lard" and slow down your website.
- Set strict timeouts: Limit how long the browser waits for bids. For [desktop, keep timeouts between 400 and 800 milliseconds] (Avenga), while mobile users can tolerate slightly longer waits.
- Use a wrapper: Implement an open-source framework like Prebid to manage multiple bidders more efficiently. A wrapper helps organize the code and prevents the need for manual updates to every individual SSP tag.
- Monitor page performance: Regularly check if ad bidding is negatively impacting your user experience. Fast page loads are critical for reader retention and SEO.
- Coordinate with Ad Ops: Ensure your ad operations team has set up matching line items in the ad server. If these are misconfigured, the ad server may ignore the winning header bids.
Common mistakes
Mistake: Neglecting mobile-specific timeouts. Fix: Set [mobile timeouts between 800 and 1,200 milliseconds] (Avenga) to account for slower network connections.
Mistake: Hard-coding too many scripts in the header. Fix: Use a header bidding wrapper to consolidate bidding requests and reduce the amount of bulk in your site's code.
Mistake: Failing to update line items. Fix: Create a system for Ad Ops to sync the price increments in the ad server with the bids being sent by the header bidding script.
Mistake: Ignoring latency risks. Fix: Periodically audit the speed of your bidding partners and remove those that consistently fail to respond before the timeout.
Examples
Example scenario (Yield optimization): A publisher uses a traditional waterfall where they offer an impression to Exchange A for $1.00. Exchange A declines. They offer it to Exchange B for $0.80. Exchange B accepts. With header bidding, the publisher offers the impression to both exchanges at once. Exchange C, which was at the bottom of the old waterfall, bids $1.20. The publisher makes $0.40 more than they would have in the waterfall.
Example scenario (In-app implementation): A mobile game developer uses header bidding to sell video ad space. Instead of calling a single ad network, the app sends a request to a dedicated bidding server. Several networks respond within 1,000 milliseconds. The server sends the winner to the game's primary ad server, ensuring the highest-paying ad is shown without freezing the game's interface.
FAQ
What is the difference between header bidding and a waterfall? A waterfall is a sequential process where inventory is offered to one buyer at a time in a ranked list. Header bidding is a simultaneous auction where everyone bids at once. The waterfall often results in lower revenue because a high bidder might be at the bottom of the list and never see the impression.
Does header bidding slow down a website? It can. Because header bidding requires the browser to wait for bids from multiple sources before the ad server is called, it can add latency. This is why setting appropriate timeouts and using server-side implementations for mobile are common solutions to protect the user experience.
Do I still need an ad server if I use header bidding? Yes. The ad server acts as the final decision-maker. It takes the winning bids from the header auction and compares them against your direct-sold campaigns, sponsorships, and guaranteed deals to ensure you meet all your contractual obligations while maximizing revenue.
Why did Google call header bidding an "existential threat"? Prior to [2014 when header bidding gained traction] (The Current), Google's ad server allowed its own exchange (AdX) to bid first on every impression. Header bidding allowed other companies to see the inventory first, breaking Google's monopoly on "first look" advantages.
How do I choose between client-side and server-side? Client-side is generally better for publishers who want maximum transparency and higher ad prices, as it allows for better user tracking via cookies. Server-side is better for publishers concerned primarily with page speed and user experience, such as those with heavy mobile traffic.
What is a header bidding wrapper? A wrapper is a container or framework that organizes all your header bidding partners. It makes it easier to add or remove demand sources and ensures that the bidding process follows the rules you set for timeouts and auction logic.
