By TGM Team · Sun Oct 18 2026 · 8 min read
...
Header bidding is the auction method that lets several demand partners bid on the same ad impression at the same time, before the publisher's ad server makes its final decision. For most programmatic publishers, it has replaced the older waterfall, where the impression was offered to one partner after another in a fixed order.
The idea is simple. The decisions behind it are not. Where the auction runs, which partners take part and how long the page waits for their bids all affect revenue, page speed and the reader's experience. This guide explains how header bidding works, how client-side and server-side setups differ, and how publishers decide which combination fits their inventory.
The name comes from the original implementation: a piece of JavaScript placed in the header of a web page that called demand partners before the ad server loaded. The header is no longer the only place the auction runs, but the principle has not changed. Demand partners compete first, and the ad server sees their best offers alongside its own demand.
That ordering matters because an ad server can only choose between the options it is shown. When header bids arrive with real prices attached, direct campaigns, deals and programmatic demand are compared on actual value rather than on historical assumptions.
The result is usually more competition for each impression, and more of the impression's true market value reaching the publisher.
In a waterfall, the ad server works down a ranked list of partners, usually ordered by historical average CPM, and stops at the first one willing to fill the impression at its assigned price. The ranking is set in advance and adjusted by hand.
Waterfall vs. Header Bidding: 5 Key Differences
1. How Demand Partners Are Called
2. How Prices Are Determined
3. Impact on Revenue Opportunities
4. Ongoing Management
5. Pricing Visibility
The waterfall's weakness is that averages hide individual impressions. A partner ranked fourth may value a particular reader far more than the partner ranked first, but it never gets the chance to bid.
Header bidding removes that blind spot by asking every connected partner at once. The trade-off is time: the auction has to wait for responses, and every partner added is another response to wait for.
Each step adds time. That is why every header bidding decision is ultimately a trade-off between how much competition a publisher wants and how long it can afford to wait for it.
In a client-side setup, the auction runs in the reader's browser. Each demand partner receives its own request directly from the page.
The main advantage is identity. Each partner can recognize the identifiers it already holds for that reader, where consent allows, which generally supports stronger bids on addressable inventory. Client-side setups are also transparent: the publisher can see each partner's requests, responses and timing directly, which makes troubleshooting faster.
The cost is weight. Every partner adds network requests, JavaScript and processing on the reader's device. On mobile web, and on pages already carrying heavy scripts, adding partners eventually slows the page enough to cost more in lost engagement than the extra competition earns. In practice, that puts a ceiling on how many partners a client-side auction can carry.
In a server-side setup, the wrapper sends a single request to a server, which calls the demand partners and runs the auction there.
Moving the work off the device means publishers can connect more partners without the same page-speed penalty. Server-side auctions are also the only practical model where there is no browser to run code in, such as connected TV and many app integrations.
The trade-off is identity and visibility. Partners no longer see the reader's browser directly, so matching depends on user ID syncing and the identifiers passed in the request.
Match rates, and therefore bid values, can fall for partners that rely heavily on their own identifiers. Publishers also need server capacity, and reporting good enough to see what each partner is doing inside the server auction.
1. Where the Auction Runs
Client-Side: The auction runs in the user's browser, with bid requests sent directly from the browser to participating demand partners.
Server-Side: The auction runs on a server operated by the publisher or a header-bidding technology partner, which sends bid requests to participating demand partners.
2. Load on the Device
Client-Side: Places more processing and network demands on the user's browser. The load can increase as more demand partners are added.
Server-Side: Shifts much of the auction processing away from the user's browser, generally reducing client-side processing and network overhead.
3. Practical Number of Demand Partners
Client-Side: The number of demand partners that can participate efficiently may be limited by page performance, browser resources, and auction timeouts.
Server-Side: Can accommodate more demand partners without proportionally increasing browser-side processing, although server capacity, latency, and auction timeouts still impose limits.
4. User Matching and Identity
Client-Side: Can support direct access to browser-based identifiers and client-side identity mechanisms, potentially enabling stronger user matching when identifiers and consent are available.
Server-Side: User matching depends on identifier availability, identity-provider integrations, and ID synchronisation. Browser restrictions and privacy requirements can also affect matching.
5. Suitability for CTV and In-App Environments
Client-Side: Can be less practical in connected TV (CTV) and certain in-app environments where browser-based header-bidding technologies are unavailable or unsuitable.
Server-Side: Is often better suited to CTV and in-app environments because auctions can be initiated through server-side integrations without relying on a conventional web browser.
6. Per-Partner Bid Visibility
Client-Side: Bid requests and responses can generally be inspected at the browser level, making partner-level bid activity easier to debug and monitor.
Server-Side: Partner-level bid visibility depends on the server's logging, reporting, and analytics capabilities.
Few publishers choose one model outright. The common pattern is a hybrid, where the same auction includes some partners called from the browser and others called from a server. Typical rules of thumb:
The right split is specific to each publisher's audience, devices and demand partners. It should be tested, one partner at a time, rather than copied from another site's configuration.
The same principle, simultaneous competition, now applies across formats. In apps, it appears as in-app bidding, where networks and exchanges bid in a unified auction instead of a mediation waterfall.
In connected TV, there is no page to load a wrapper into, so competition happens server-side, usually alongside server-side ad insertion. Ad breaks are sold as pods, and the bid request carries much more of the context buyers need to value the impression.
For publishers working across web, app and CTV, that means one strategic question, how much competition each impression sees, answered with different technology in each environment.
Judge any change on the full picture, not one number. Track:
Test changes on a controlled share of traffic, with a comparable control group, and run the test long enough to cover normal weekday and weekend patterns. Change one variable at a time. If partners, timeouts and floors all change together, the result cannot be attributed. Our analysis of when higher CPMs can hurt publisher revenue shows why a single metric can point in the wrong direction.
1. Adding partners without checking their contribution. A partner that rarely wins still adds latency to every auction.
2. One timeout for every environment. Desktop, mobile web and server-side auctions rarely share an ideal setting.
3. Leaving unused code in the wrapper. Old adapters add weight with no revenue.
4. Moving everything server-side at once. It becomes impossible to tell which move caused a revenue change.
5. Ignoring the ad server's role. Header bids still compete with direct campaigns and deals, so line-item and priority settings must reflect real prices.
TGM builds custom Prebid adapter solutions for both client-side and server-side setups, connecting publisher inventory to multiple DSPs, SSPs and private marketplaces.
The same approach extends to CTV and OTT through server-side ad insertion and client SDK integration, so publishers working across formats can apply one competition strategy across their inventory.
For publishers reviewing their current configuration, the useful starting point is the same whatever technology is in place: a clean baseline of bid, timeout, win and revenue data by partner. If you would like a second view on your header bidding setup, TGM's publisher team can walk through it with you.
Q1. What is header bidding in simple terms?
It is an auction where several ad buyers bid on the same impression at the same time, before the publisher's ad server decides which ad to show.
Q2. Is header bidding the same as Prebid?
No. Header bidding is the auction method. Prebid is the most widely used open-source framework for running it, with Prebid.js for browser-based auctions and Prebid Server for server-side auctions.
Q3. Does header bidding slow down websites?
It can, particularly client-side on mobile. The main controls are the number of partners, timeout settings, lazy loading and moving some partners server-side.
Q4. Do I still need an ad server with header bidding?
In most setups, yes. The ad server makes the final decision between header bids, direct-sold campaigns and deals.
Q5. How many header bidding partners should a publisher use?
There is no fixed number. Keep partners that add incremental revenue after fees, and remove those that rarely win but still add latency.
Q6. Does TGM support client-side and server-side header bidding?
Yes. TGM builds custom Prebid adapters for both client-side and server-side setups, across web, CTV and OTT inventory.
