Header Bidding: A Practical Introduction

Table of Contents

What Is Header Bidding?

Header bidding is a programmatic advertising technique that allows publishers to request bids from multiple demand partners before the ad server makes its final selection. Eligible bids are collected within a defined timeout and can then compete with other demand in the publisher’s ad server.

This differs from a traditional waterfall, in which demand sources are called sequentially. The simplified example below illustrates how parallel competition can prevent a higher bid from being missed:

Floor Price: $4.50
Waterfall
CPM
$2.50		 Demand 1 Below the floor
CPM
$3.10		 Demand 2 Below the floor
CPM
$5.30		 Demand 3 Winner
CPM
$9.50		 Demand 4 Not called
Header Bidding
CPM
$2.50		 Demand 1 Below the floor
CPM
$3.10		 Demand 2 Below the floor
CPM
$5.30		 Demand 3 Losing bid
CPM
$9.50		 Demand 4 Winner
Simplified example: a waterfall calls demand sources sequentially, whereas header bidding lets eligible sources respond within the same auction window. The final ad-server decision may also include direct campaigns, Ad Exchange, and other eligible demand.

By increasing competition before the ad-server decision, header bidding can help publishers access more demand, improve bid density, and optimize overall yield. Results vary according to the quality of the demand partners, geographic coverage, formats, timeout settings, floors, fees, and the implementation itself.

Header bidding became widely adopted during the mid-2010s. Prebid.js, launched in 2015, played an important role in standardizing implementations by providing an open-source framework and a common adapter model. It remains one of the most widely used client-side header bidding solutions.

Google offers Open Bidding, a server-to-server feature within Google Ad Manager that allows approved third-party demand partners to participate in the Ad Manager auction.

Amazon Publisher Services offers server-side solutions such as Transparent Ad Marketplace (TAM) and Unified Ad Marketplace (UAM).

Prebid, Open Bidding, and Amazon Publisher Services can coexist within the same monetization stack, although the exact setup, reporting, fees, and auction dynamics depend on the publisher’s configuration and commercial agreements.

How Does Header Bidding Work?

  1. A user visits a page and an ad opportunity becomes available.
  2. The header bidding wrapper sends bid requests to the configured demand partners. In a client-side setup, the browser coordinates these requests; in a server-side setup, a server-side platform coordinates them.
  3. Demand partners return their bids within the timeout defined by the publisher. Late responses are normally excluded from that auction.
  4. Prebid processes the eligible responses and sets the relevant ad-server targeting values. Depending on the configuration, the ad server may receive targeting for the top bid or for multiple bids.
  5. Google Ad Manager or another ad server evaluates the eligible header bidding line items alongside other demand and campaigns according to its priorities, targeting, pricing, and auction rules.
  6. The winning creative is returned and rendered in the ad slot.

Benefits of Header Bidding

Greater competition and yield potential: Multiple demand partners can evaluate the same impression within a shared auction window. This can increase bid density and may improve CPMs, fill rate, and total revenue when the demand mix and implementation are well optimized.

Less waterfall inefficiency: Parallel bid requests reduce the need to call demand partners one after another and can prevent a high-value bid from being excluded simply because that partner appeared later in a waterfall.

More control and auction insight: Publishers can choose their demand partners, configure timeouts and floors, and obtain granular auction data. The exact level of transparency depends on the wrapper, analytics tools, server-side provider, and partner agreements.

Flexible architecture: Publishers can use client-side, server-side, or hybrid implementations and adapt the stack to different formats, devices, markets, and operational requirements.

Latency consideration: Header bidding does not automatically make a page faster. Client-side wrappers add JavaScript and network requests, while server-side solutions reduce browser-side work but still introduce processing and network time. Bidder count, wrapper size, timeouts, consent flows, and lazy loading should all be monitored.

Types of Header Bidding

Client-Side

In a client-side implementation, the browser coordinates the auction by sending bid requests to the configured demand partners and collecting their responses within a defined timeout. The bidders normally evaluate the opportunity and generate their bids on their own servers.

Prebid.js is the best-known open-source client-side wrapper. Client-side implementations can provide strong cookie matching and direct visibility into browser activity, but adding too many bidders or modules can increase page weight, network activity, and latency.

Server-Side

In a server-side implementation, the browser or app usually sends one request to a server-side platform, which then communicates with multiple demand partners. Common examples include Google Open Bidding, Amazon Publisher Services, and Prebid Server. Microsoft Advertising also offers a managed implementation called Prebid Server Premium (PSP).

The main advantage is lower browser-side overhead and the ability to connect more demand partners without creating a separate browser request for each one. Potential trade-offs include lower user-match rates in some environments, additional platform fees, differences in reporting, and less direct visibility into the server-side auction, depending on the provider.

Hybrid Implementations

Client-side and server-side header bidding can run together. A publisher may keep selected demand partners client-side while moving others server-side. A hybrid model can balance user matching, latency, demand access, and operational complexity, but it should be monitored carefully to avoid duplicated demand paths and unnecessary auction overhead.

Common Demand Partners and Platforms

The right partner mix depends on the publisher’s audience, inventory quality, formats, geography, scale, technical resources, and commercial terms. The following list is alphabetical and is not a ranking or endorsement. Amazon Publisher Services is a publisher demand platform rather than a conventional SSP.

Before adding a partner, publishers should evaluate demand uniqueness, ad quality, geographic coverage, formats, privacy support, and payment terms. Connecting more partners does not automatically produce better results.

Useful Prebid Features and Modules

Currency

The Currency module is useful when one or more bidders return bids in a currency different from the currency used by the publisher’s ad server. It converts bidder currencies into a common ad-server currency before price bucketing and targeting. It is optional when every bidder already uses the required currency.

Supply Chain Object

The Supply Chain Object communicates the sequence of entities involved in selling or reselling an impression, helping buyers understand the path through which the inventory is offered.

Starting with Prebid.js 10, publishers should provide this information as first-party data through ortb2.source.schain or ortb2.source.ext.schain. The standalone schain module is therefore no longer required for new configurations, although it may remain in use for compatibility during migration.

Price Floors

The Price Floors module provides a framework for defining, signaling, and enforcing static or dynamic minimum prices. A floor strategy should be tested carefully: floors that are too low may leave revenue on the table, while floors that are too high may reduce bid participation and fill.

GPT Pre-Auction

The GPT Pre-Auction module helps bidders identify and report inventory at the Google Ad Manager slot level. Before bid requests are sent, it can add the Global Placement ID (GPID), Prebid Ad Slot information, and the matching Google Ad Manager ad-unit name to the ad unit’s first-party data.

GPID provides a consistent identifier for an individual ad placement, which is particularly useful when a page reuses an ad-unit name or creates slots dynamically. Publishers should define a stable naming strategy and confirm how each demand partner consumes this signal.

Index Exchange reported higher bid rates and CPMs among publishers using GPID on its platform.

Identity Solutions

Third-party identifiers are restricted or unavailable in several browsers, privacy modes, devices, and consent states. Chrome currently maintains user choice for third-party cookies rather than applying a universal phase-out, while Chrome Incognito blocks them by default.

As a result, identity should be treated as one part of a broader strategy that also includes first-party data, authenticated audiences, contextual signals, seller-defined audiences where applicable, and privacy-preserving measurement.

Examples of identity submodules supported by Prebid include Criteo, Lotame, SharedID, ID5, and LiveRamp.

Useful Header Bidding Resources

Last reviewed: July 2026. Implementation details should always be checked against the latest official documentation.