Around 90% of large publishers run header bidding in some form and, for many of them, it’s something that was set up once years ago and has barely been touched since.
This guide is the one we wish existed when we started building publisher ad stacks. It covers the mechanics (briefly, because the mechanics are well understood) and then spends the rest of its time on the parts that have a genuine impact on revenue. Like optimisation levers that most publishers never touch and analytics that most publishers have never seen. Finally, we touch on the shift toward real-time automated auction management.
WHAT IS HEADER BIDDING (AND WHY IT REPLACED THE WATERFALL)
Header bidding lets publishers offer their ad inventory to multiple demand sources simultaneously, before the ad server gets involved. Every exchange gets a fair shot at every impression, in a single auction.
It replaced the waterfall, where demand sources were called one at a time in a fixed priority order (usually price). The ad server would offer inventory to the top-ranked exchange first and only move to the next if the first passed. Exchanges lower in the stack never saw the good inventory. By the same token, exchanges higher in the stack had no reason to bid their true value because nothing was competing with them. Obviously, this meant revenue was not optimised and large sums were being left behind by publishers.
Header bidding fixed that by moving all demand sources into the same auction, competing on a level playing field. The highest bid always wins (more on this later) and publishers saw immediate revenue lifts. Adoption became near-universal within a few years and Prebid.js became the de facto open source standard.
The waterfall comparison is useful for understanding why header bidding exists, but it is 2016 thinking. Nearly every publisher of any scale has moved past it. The more useful point for anyone reading this in 2026 is that the same dynamic plays out within header bidding itself. A setup that was configured once and left alone is, at best, not too wrong for any given slice of your inventory, but also not very right for any of it. The market shifts on hourly, daily, weekly and yearly timescales. A static setup does not shift with it.
HOW DOES HEADER BIDDING WORK: A STEP-BY-STEP BREAKDOWN
The auction runs in six steps:
- A user loads a page. The Prebid.js library (or equivalent wrapper) fires before the ad server is called.
- Prebid sends bid requests to all configured demand partners simultaneously. Each partner evaluates the impression and returns a bid, declines to bid, or times out.
- The auction runs on a timeout. A typical client-side timeout is 1,300ms for display. Bids arriving after the timeout are discarded (though bid caching can carry late bids forward to subsequent refreshed impressions).
- Prebid collects all bids received within the timeout window and identifies the highest from each partner.
- The winning bid and its price are passed to the ad server (typically Google Ad Manager) as a key-value pair. GAM runs its own auction, comparing the header bidding winner against Ad Exchange, Open Bidding and direct-sold campaigns.
- The highest overall bid wins the impression. The ad renders.
This is a first-price auction in which the winning bidder pays exactly what they bid. DSPs apply their own bid shading (bidding below their true valuation to protect margins), which is one reason floor price strategy matters so much. More on that in the optimisation section.
A BASIC PREBID.JS CONFIGURATION
Most publishers run header bidding through Prebid.js, an open-source library maintained by Prebid.org. Here is a simplified example of how ad units are configured:
var adUnits = [{
code: 'div-leaderboard',
mediaTypes: {
banner: {
sizes: [[728, 90], [970, 250]]
}
},
bids: [{
bidder: 'appnexus',
params: {
placementId: 12345678
}
}, {
bidder: 'pubmatic',
params: {
publisherId: '987654',
adSlot: 'leaderboard@728x90'
}
}, {
bidder: 'indexExchange',
params: {
siteId: '112233'
}
}]
}];
pbjs.addAdUnits(adUnits);
Each bidder entry is an adapter. Basically a module that handles communication with a specific exchange. The config for each of these adapters defines which sizes are accepted, which partners compete and what credentials to pass.
In production though, this gets significantly more complex. Consent modules, user ID integrations, currency handling, timeout configuration and floor price logic all layer on top. Essential Prebid modules for a production setup in 2026 include consent management and user ID. Getting this right at scale is hard, which is why most large publishers use a managed wrapper rather than maintaining raw Prebid configs themselves.
HEADER BIDDING ADAPTERS
Each demand partner needs its own Prebid adapter. The adapter translates between Prebid’s standardised auction format and the partner’s API. Publishers typically run 10 to 15 adapters in a healthy setup. Beyond 12 or so, additional partners rarely increase yield meaningfully and can in fact start degrading performance, particularly on mobile where too many simultaneous bid requests can cause ads to fail loading entirely.
The top 3 to 4 partners typically account for 30 to 50% of auction wins. The remaining partners contribute incrementally, but their seemingly low value is not to be dismissed. In fact, they create important bid pressure that keeps the top partners honest.
CLIENT-SIDE VS SERVER-SIDE HEADER BIDDING
Client-side header bidding runs the auction in the user’s browser. Each configured bidder sends and receives bid requests directly from the page. This means full cookie and first-party data access for every partne, leading ultimately to higher match rates and typically higher bid values.
Server-side header bidding (via Prebid Server) moves the auction off the page to a server. The browser makes a single request, and the server fans out requests to all partners. This reduces page-level latency because the browser is only making one call instead of many.
The trade-off is match rates. When a bidder moves server-side, it loses direct access to the user’s browser environment. Cookie sync rates drop. Match rates drop. Bid values drop. The performance decrease is always considerable, particularly when server-side bidders compete against partners that still have client-side access.
Our view: if there is a way to run a bidder client-side, that’s usually your best option. The advice to run a hybrid client-side/server-side split was reasonable a few years ago when client-side stacks struggled with too many simultaneous requests. However, that advice is dated now. Modern browsers and well-optimised wrappers handle large client-side bidder counts without meaningful impact. Ads load asynchronously and do not block page rendering. Instead, the metrics to watch are cumulative layout shift and The Document Object Model (DOM) load times, not total page weight.
The exception to this is for mobile apps and live streaming/SSAI, where server-side is the only option.
PAGE SPEED
Adding bidders client-side does add ad tech weight to the page, but the impact is narrower than most publishers fear. Because ad loading is asynchronous, content renders independently of the auction. Where it can and often does become an issue is when the publisher relies on the DOM load event to fire other things (newsletter popups, tracking scripts, third-party widgets). A heavier ad tech payload delays the DOM fully loaded state, which delays those downstream triggers.
The bigger page speed problem is not header bidding itself but the accumulation of multiple ad tech stacks on the same page. A single optimised wrapper has minimal impact. Add a second or third vendor’s stack on top of that (outstream player, content recommendation widget, separate analytics) and CPU and memory consumption in the first few seconds of page load starts genuinely degrading user experience quickly.
HEADER BIDDING OPTIMISATION: WHAT ACTUALLY MAKES A DIFFERENCE TO REVENUE
Most publishers’ header bidding setups were configured once and never touched again. There is a significant and quantifiable gap between a static setup and one that is actively optimised.
TIMEOUT STRATEGY
A standard client-side timeout for display is 1,200 to 1,400ms. For midroll SSAI (server-side ad insertion for live and VOD video), timeouts run much longer, around 4,000ms, because the environment is different.
Roughly 10 to 15% of bids arrive after the timeout. Whilst this sounds like lost revenue, there is a trade-off to consider. That is, whether extending the timeout to catch those late bids means the ad loads later. One option would be to push the render below the fold or into a low-viewability position, but you lose more revenue than you gain. You lose money on the bids you never see, but you also lose money by being slow and failing to serve ads in view.
Bid caching can be used to soften the blow. Bids that arrive late can be carried forward and used to win refreshed impressions, so the revenue is not entirely gone.
The optimal timeout varies by context. Slower environments (certain geographies, certain devices) benefit from slightly longer timeouts. Fast environments benefit from shorter ones. A single static value cannot solve this, which is why timeout orchestration is moving toward real-time automation (more on this in the AI section).
FLOOR PRICE STRATEGY
Floor prices set a minimum bid below which an SSP’s bid gets thrown out. Think if it like a reserve price on eBay. Anything under your agreed floor is ignored. They exist to stop demand partners from bidding below the true value of an impression simply because nothing is making them bid higher.
Without floors, and unless roughly 70 to 80% of your inventory is sold in competitive auctions, bidders begin to sense the lack of competition and bid low. One test undertaken by our researches illustrates this well. They found that bidders that had been sending $0.01 bids were confronted with floor prices raised in $0.01 increments. Their bids instantly matched each new floor, proving they were willing to pay more all along. The bids only started to diminish above $0.10. That is where the real money is: pushing remnant buying strategies to their actual limit rather than accepting whatever they choose to pay.
But floors are fragile. Set them too high and you trigger traffic shaping, where SSPs stop bidding entirely on inventory they deem unprofitable. Set them wrong and it can take days to recover, even after rolling back. SSP responses to floor changes are unpredictable. A change that lifts revenue in one segment can suppress it in another.
The right level of granularity comes down to which segments show meaningful and consistent differences in bid distribution. In our view, context defined by site, geography, format, environment, device type and browser captures the most important variation. Placement and geography tend to drive the largest gains.
The bid distribution itself is right-skewed and log-normal, with peaks at each two-decimal-place increment ($0.01, $0.02, $0.03 and so on). Setting floors intelligently means understanding this shape for each segment. It’s impossible to monitor thousands of segments across constantly shifting distributions and react fast enough without automated AI systems in place. Without the data infrastructure to price segments accurately, you inevitably choke auctions in one place while propping them up in another.
BIDDER COUNT AND DIMINISHING RETURNS
The healthy range is 10 to 15 bidders. Beyond 12, additional partners rarely add meaningful yield and can actively hurt performance through increased latency, higher timeout rates and (on mobile) outright ad loading failures.
The decision to add or remove a bidder is harder than it sounds, though, because bidder latency fluctuates constantly. A partner that responds well today may time out consistently tomorrow. Managing this manually is, at scale, impossible, which is why bidder composition is another area moving toward automation.
AD REFRESH ECONOMICS
The initial ad impression on a page load typically accounts for about 30% of total ad revenue. The rest comes from refreshes. Refreshes 1 and 2 are the most significant, at roughly 15 to 20% of revenue each. After the first three impressions the curve tapers, but it does not collapse. CPMs stay relatively stable across refreshes. What drops is viewability, and that gradually pulls eCPMs down with it.
There is no hard rule on when to stop. You can refresh for a long time and still make money, even with low viewability. What makes refreshing counterproductive is doing it when the page is backgrounded and no user is actually there.
Display and video have fundamentally different refresh strategies. Display can and should refresh. Video should not. The right approach for video is ad pods: 1 to 3 ads per break within a content stream. More than 3 risks users leaving. If someone is refreshing video ads the way they refresh display, something has gone wrong.
HEADER BIDDING ANALYTICS: WHAT TO MEASURE AND WHY
If your header bidding analytics rely on SSP-reported data, you do not truly have analytics. You have a record of what each SSP decided to tell you.
Most publisher analytics (whether internal or outsourced) ingest data reported by SSPs as their source of truth. If an SSP says it served 500 impressions, that is what the dashboard shows and there is no independent count to compare against. The data is fragmented across systems that were never designed to work together. It is hard to spot when an SSP’s numbers are off, because they look reasonable enough in isolation. And SSPs have a natural incentive to present data favourably. The publisher’s continued business depends on the numbers looking good.
On top of that, combining data from different SSP systems inevitably leads to misinterpretation. Statistics are notoriously hard to calculate correctly across fragmented sources and (not to put too fine a point on it) notoriously easy to manipulate.
WHAT A HEALTHY AUCTION LOOKS LIKE
A healthy header bidding auction has a bid rate of 60 to 80%. That is the percentage of auctions where at least one partner returns a bid. In terms of bid count per auction, 1 to 2 bids is normal. 3 or more is strong.
Warning signs that something is going wrong, often before revenue visibly drops. For example:
- a declining bid rate
- increasing timeout rate
- rising no-bid responses
- the bid distribution shifting lower
- fewer bid requests reaching partners and
- a reduction in unique bidders.
Bid density varies by device, geography and time of day (bids tend to be higher during working hours and lower in the evenings, just as eCPMs and fill rates do).
INDEPENDENT VERIFICATION
We think publishers need independent verification of SSP behaviour. Not because SSPs are dishonest as a rule, but because the data architecture of most ad tech stacks makes honest mistakes invisible and deliberate manipulation undetectable.
We run independent impression-level counting, tracking every Prebid win and reconciling it against what each SSP reports back. Most SSPs reconcile within 1 to 3%, which is healthy. One SSP, for example, was overcounting their reported revenue by 225%. They were winning header bidding auctions but only recording a billable impression when the ad rendered in the viewport, not on the Prebid win event. The publisher was losing significant revenue from a single partner, month after month. The SSP’s own dashboard showed nothing wrong.
That detection was only possible because our system counts independently rather than ingesting SSP data as the source of truth. If the only thing telling you how an SSP is performing is the SSP itself, you do not have a source of truth.
VIDEO HEADER BIDDING
Video header bidding follows the same principle as display (simultaneous auctions across multiple demand sources) but the implementation is considerably harder.
The core challenge is that video ads have to integrate with a video player. Video players are built by web developers with their own frameworks, their own priorities and their own technical debt. Most publisher video players are held together with duct tape. Introducing a new ad decisioning layer into that environment takes close collaboration between ad ops and web development teams, and it is rarely straightforward.
SSAI AND DAI
Server-side ad insertion (SSAI) environments, used for live streaming and VOD, add another layer. Ads are stitched into the content stream on the server before reaching the user’s device. Header bidding integrates by passing bids to the SSAI provider, which fetches and inserts the winning ad into the stream.
The quality of this integration varies dramatically by provider. Well-built SSAI platforms (Yospace, for example) make it straightforward. Others, including Google DAI and Amazon MediaTailor, are more limiting and prone to breakage when ad macros are configured incorrectly. The timeout budget is also different: midroll SSAI auctions run at around 4,000ms, versus 1,300ms for standard display.
VAST VS VPAID
VAST (Video Ad Serving Template) is the standard format for video ad delivery. VPAID (Video Player Ad-Serving Interface Definition) is an older interactive format that lets ads execute code within the player.
VPAID has been officially deprecated for years, but in our view its actual phase-out is a long way off. The replacement (SIMID, Secure Interactive Media Interface Definition) has negligible adoption. At the time of writing, only one or two ad servers support serving SIMID creatives. Until that changes, VPAID is a practical reality that publishers and their tech partners need to support regardless of what the official deprecation timeline says.
For publishers choosing between the two: VAST is the default. VPAID is needed only for interactive or rich-media experiences, and its use is declining.
IN-APP HEADER BIDDING
In-app header bidding works under different constraints to web. The auction runs through an SDK embedded in the app, not a JavaScript library in a browser. That introduces problems with no real equivalent on the open web.
The biggest is development cycles. Changes to the ad SDK require a new app release, which means going through the publisher’s development team, QA and app store review. On the web, a wrapper update deploys instantly. In-app, a configuration change can take weeks to reach users, depending on how often the publisher ships and how much priority they give ad-related work.
App-ads.txt is another friction point. The principle is the same as ads.txt on the web (an authorised seller list to prevent domain spoofing), but the failure modes are less visible. Misconfigured entries can block demand partners from bidding without any obvious error. Managing this at scale requires tooling most publishers do not have.
On the demand side, in-app is one of the few environments where Open Bidding performs comparably to Prebid. The data constraints that make server-side less competitive on the web (cookie sync, match rates) matter less in app environments where device-level identifiers serve a similar function.
IDENTITY AND PRIVACY
The decline of third-party cookies has had less impact on header bidding than the industry predicted. In practice, cookies were largely replaced by localStorage, and the auction mechanics continued without dramatic disruption. The exception is Safari, where Apple’s restrictions on client-side storage result in measurably lower match rates and bid values.
Universal IDs have filled part of the gap. The frameworks making the biggest difference right now are SharedID, Criteo, Hadron, UID 1.0 and 33Across. Match rates vary by framework, geography and device. Publishers should be monitoring which IDs are driving actual bid rate lift rather than assuming all ID solutions are equal.
Consent has a significant and measurable impact on auction performance. For publishers with substantial EU traffic, bid rates are 5 to 6 times higher with consent versus without. CPMs are roughly 25 to 30% lower without consent. TCF integration within the Prebid auction is not optional for publishers serving European audiences. It is a direct revenue lever.
AI AND THE FUTURE OF HEADER BIDDING
The optimisation section above describes what needs to happen: floors, timeouts, bidder composition and refresh all need to adjust continuously based on real-time data. The problem is that no human team can do this at the required scale and speed.
A skilled ad ops analyst knows to adjust floor prices when bid patterns shift, or remove a bidder that keeps timing out, or shorten a timeout when mobile viewability drops. But they can only do this for a handful of segments, a few times a week, based on data that is already hours or days old. The market moves faster than that.
These systems do what a skilled analyst would do, but at a frequency and granularity that is not humanly possible.
OPEN BIDDING VS HEADER BIDDING
Open Bidding (formerly Exchange Bidding, or EBDA) is Google’s server-side alternative to header bidding. Instead of running auctions independently through Prebid, Open Bidding runs through Google’s infrastructure within GAM.
There is an inherent conflict of interest in this arrangement. Google, as the operator of the ad server, sees all competing bids before deciding what Ad Exchange wants to bid. No other participant in the auction has this information advantage. This was a central element of the US antitrust case against Google, which concluded in April 2025 with Judge Brinkema ruling that Google had violated Sections 1 and 2 of the Sherman Act by monopolising publisher ad server and ad exchange markets. The EU followed with a €2.95 billion fine in September 2025 for similar conduct.
In our experience, whenever a well-optimised Prebid setup is in place, Open Bidding is reduced to a marginal auction environment. It can often be paused with little to no revenue impact. The revenue it generates (typically a small single-digit percentage of total programmatic) would largely be captured elsewhere, perhaps for a fraction less per impression. But that last few percent comes at the cost of additional latency in the ad server auction, and the time spent worrying about it is usually better spent making the rest of your setup work harder.
The exception is in-app environments, where Open Bidding performs better relative to header bidding due to the constraints of SDK-based auction execution.
WHAT HAPPENS IF GOOGLE IS FORCED TO DIVEST ADX
The DOJ sought full divestiture of Google’s Ad Exchange and the open-sourcing of the DFP final auction logic. The remedy ruling is still pending (overdue as of early 2026). If a divestiture happens, header bidding becomes the primary mechanism for bringing programmatic demand to the ad server. Publishers with well-configured Prebid infrastructure will be in a good position. Publishers relying entirely on Google’s integrated stack will need an alternative, and fast.
HOW TO CHOOSE A HEADER BIDDING SOLUTION
The usual advice here is about features: how many adapters, what integrations, which analytics. Those are table stakes. The questions that are worth asking are about architecture and independence.
DOES IT COUNT INDEPENDENTLY?
If your analytics rely on SSP-reported data, you have no way to verify whether your partners are paying for what they win. An independent impression-level count, reconciled against SSP reporting, is the only way to detect discrepancies. Most platforms do not do this.
IS THE CONFIGURATION STATIC OR ADAPTIVE?
A wrapper that offers 20 bidder adapters but configures them once and never adjusts is a starting point, not a solution. The question is whether the system actively optimises floors, timeouts, bidder composition and refresh based on real-time performance data, or whether that falls to your ad ops team.
WHO OWNS THE DATA?
If your analytics are powered by a third-party tool, your data lives in someone else’s system, subject to their roadmap, their API stability and their commercial priorities. A platform that counts, stores and analyses independently gives you a source of truth that does not depend on any single vendor’s reporting.
CAN YOU SEE WHAT IS HAPPENING?
Some header bidding solutions require publishers to hand over their ad operations with limited visibility into what is configured and why. Others give you full transparency. They offer auction-level data, per-bidder performance, floor price logic, timeout settings. You should be able to see everything and change anything.
FREQUENTLY ASKED QUESTIONS
Is header bidding still relevant in 2026?
More relevant than ever. Around 90% of large publishers run it. The Google antitrust ruling confirmed header bidding was so effective at creating fair competition that Google actively worked to undermine it. With the potential divestiture of AdX from GAM still pending, independent auction infrastructure is becoming more important, not less.
What is the difference between header bidding and real-time bidding (RTB)?
RTB is the mechanism: an auction happening in real time. Header bidding is a strategy that uses RTB by running auctions across multiple exchanges simultaneously before the ad server is called. Header bidding does not replace RTB. It runs multiple RTB auctions in parallel.
What is the difference between header bidding and Open Bidding?
Header bidding runs the auction independently (typically through Prebid.js), giving the publisher full control. Open Bidding runs through Google’s infrastructure. The structural concern, confirmed in the antitrust trial, is that Google sees all competing bids before deciding its own. No other participant has that advantage.
What is the difference between Prebid and header bidding?
Header bidding is the concept (simultaneous auctions across multiple demand sources). Prebid.js is the most widely used open-source software that implements it. Most publishers running header bidding are running it through Prebid or a wrapper built on Prebid.
How many header bidding partners should I use?
10 to 15 is the healthy range. Beyond 12, additional partners rarely add meaningful yield. The top 3 to 4 account for 30 to 50% of revenue, but the rest provide incremental value through bid pressure and occasional high-CPM wins. Too many partners can cause ads to fail loading on mobile, dragging down fill and revenue.
Does header bidding slow down my site?
Ads load asynchronously and do not block content rendering, so the direct impact is limited. The metrics to watch are cumulative layout shift and DOM load times. Server-side header bidding reduces latency but at the cost of lower match rates and bid values. The bigger performance problem is usually the accumulation of multiple third-party ad tech stacks on the same page, not header bidding itself.
How do I know if my header bidding setup is working?
A healthy setup has a bid rate of 60 to 80%, low timeout rates and competitive bid values from multiple partners. Warning signs: declining bid rates, increasing timeouts, bid distributions shifting lower, fewer unique bidders.
Can I run header bidding alongside Google Open Bidding?
Yes, and most publishers do. The header bidding auction runs first, and the winning bid competes in GAM against Open Bidding, direct deals and Ad Exchange. The question is not whether to run both but whether the small incremental revenue from Open Bidding justifies the latency it adds.
What happens to header bidding if Google is forced to divest AdX?
Header bidding becomes the primary mechanism for bringing programmatic demand to the ad server. Publishers with their own Prebid infrastructure will be in a good position. Publishers relying entirely on Google’s integrated stack will need an alternative.
Is there a floor price in header bidding?
Yes. Floor prices set a minimum bid below which an SSP’s bid is thrown out. Without them, bidders in low-competition auctions will pay well below the true value of an impression because nothing makes them bid higher. A well-configured floor strategy pushes remnant buying to its limit. But floors are sensitive: too high and SSPs stop bidding entirely. Getting this right requires data-driven optimisation across thousands of segments, which is why floor management is increasingly automated.