Header bidding is a programmatic technique that allows publishers to simultaneously offer their ad inventory to multiple demand sources before the ad server makes a final decision, maximizing competition and yield.
Quick Answer
Header bidding is a programmatic technique that allows publishers to simultaneously offer their ad inventory to multiple demand sources before the ad server makes a final decision, maximizing competition and yield.
Header bidding increases publisher revenue by 20 to 40 percent on average by replacing sequential waterfalls with simultaneous parallel auctions.
Client-side header bidding adds page latency; work with publishers to configure reasonable timeout settings (typically 300 to 600 milliseconds) that balance revenue and user experience.
Prebid.js is the dominant open-source header bidding solution and supports over 300 demand adapter integrations.
Key Takeaways
Header bidding increases publisher revenue by 20 to 40 percent on average by replacing sequential waterfalls with simultaneous parallel auctions.
Client-side header bidding adds page latency; work with publishers to configure reasonable timeout settings (typically 300 to 600 milliseconds) that balance revenue and user experience.
Prebid.js is the dominant open-source header bidding solution and supports over 300 demand adapter integrations.
How Header Bidding Works
Header bidding gets its name from the JavaScript code that publishers originally placed in the HTML head of their pages. This wrapper code fires bid requests to multiple SSPs and exchanges simultaneously before the page fully loads, collecting bids from all demand sources in parallel. The highest bid collected by the wrapper is then passed to the publisher's primary ad server — typically Google Ad Manager — as a key-value pair, where it competes against direct deals and AdX demand in the final unified auction.
Why Header Bidding Matters for B2B Marketing
The technical evolution of header bidding moved from client-side wrappers, which add page load latency, to server-side header bidding solutions. In server-side implementations, the bid collection process happens on an external server rather than in the user's browser, dramatically reducing latency. Prebid.js is the dominant open-source client-side wrapper, while Amazon TAM and Google EBDA are major server-side alternatives. Many publishers use hybrid approaches to balance latency and demand access.
Header Bidding: Best Practices & Strategic Application
For publishers, header bidding fundamentally changed the economics of programmatic advertising. By eliminating the sequential waterfall priority — which systematically undervalued premium impressions offered to lower-priority demand partners — header bidding exposed every impression to full market competition. Publishers report revenue lifts of 20 to 40 percent on average after switching from waterfall to header bidding. The trade-off is increased page latency, cookie matching complexity, and technical maintenance overhead.
Agency Perspective: Header Bidding in Practice
From the demand side, header bidding gave DSPs and their advertiser clients more access to premium publisher inventory that was previously locked behind publisher ad server priority hierarchies. Advertisers running campaigns through well-integrated DSPs benefit from a more level playing field against Google's own demand. Understanding header bidding architecture is important for media buyers troubleshooting delivery issues, as deal configuration problems in the publisher's wrapper are a common cause of PMP underdelivery.
Frequently Asked Questions: Header Bidding
Header bidding is a programmatic technique that allows publishers to simultaneously offer their ad inventory to multiple demand sources before the ad server makes a final decision, maximizing competition and yield.
Client-side header bidding adds latency because the browser must execute JavaScript and wait for bid responses before rendering ads. Publishers mitigate this with timeout settings that cap how long the wrapper waits for bids. Server-side header bidding moves this process off the browser entirely, but it can reduce bid response rates since user-level data is harder to pass server-to-server.
No specific action is required. If your DSP has adapter integrations with major SSPs, you are automatically participating in header bidding auctions when those SSPs are included in publisher wrappers. What matters is ensuring your DSP seat is connected to the SSPs that have strong publisher relationships in your target content categories.
Prebid.js is an open-source, client-side header bidding wrapper that supports a large ecosystem of demand adapters and gives publishers full control over configuration. Amazon Transparent Ad Marketplace (TAM) is a server-side solution operated by Amazon that simplifies latency but routes all bids through Amazon's infrastructure. Many publishers use both simultaneously to maximize demand access and performance.
MV3 Marketing helps B2B companies apply these strategies to drive measurable pipeline growth. Our team executes our services for technology, SaaS, and professional services companies.
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
