Header bidding, server-side auctions and smart routing

Header bidding gave publishers more competition for every impression, and with it more complexity: more scripts, more partners and more places for latency to creep in. Deciding where auctions run and which bidders get each request is now a core yield decision. This guide explains client-side and server-side setups, how to pick and manage bidders, and how routing logic helps you get competition without the cost.

How header bidding changed the auction

Before header bidding, publishers typically ran a waterfall: the ad server called demand sources one after another in a fixed priority order, and each source only saw the impression if the ones above it passed. High-paying buyers lower in the order often never got a chance to bid.

Header bidding flipped that. Multiple demand partners bid at the same time, before the ad server makes its decision, and the winning bids compete with the ad server’s own demand. More simultaneous competition generally means fairer prices for the publisher.

The question that followed was where that simultaneous auction should run: in the user’s browser or app, or on a server.

Client-side header bidding

In a client-side setup, a wrapper script (Prebid.js is the widely used open-source option) runs in the user’s browser. It sends bid requests to each partner directly from the page, collects the responses and passes the results to the ad server.

Strengths:

• Match rates. Each bidder can read its own cookies in the browser, which helps it recognize users and bid with confidence where cookies are still available.
• Transparency. You can see each request and response on the page, which makes debugging and auditing more direct.
• Control. Adapters, timeouts and price granularity are all configured by the publisher.

Weaknesses:

• Page weight and latency. Every extra bidder adds network requests and script work in the browser, which can slow ad rendering and affect page experience.
• Device limits. Mobile devices on slower connections feel the cost of many parallel requests most.
• Browser caps. Browsers limit simultaneous connections, so large bidder lists can queue up.

Server-side header bidding

In a server-side setup, the browser or app sends a single request to a server (Prebid Server is the common open-source option, and many supply-side platforms, or SSPs, run their own). That server fans out to the bidders, runs the auction and returns the winner.

Strengths:

• Lighter pages. One outbound request replaces many, which reduces work on the device.
• Scale. You can include more demand partners without adding browser load.
• Beyond the browser. Server-side auctions are the natural fit for in-app and CTV environments, where a page-based wrapper does not apply.

Weaknesses:

• Identity loss. Bidders cannot read their own browser cookies from a server, so they rely on cookie syncing or other identifiers. Weaker user recognition can mean lower bids.
• Less visibility. The auction happens off the page, so you depend on the server’s logs and reporting to understand what happened.
• Operational dependency. If you use a partner’s server, its configuration and fees shape your auction.

Hybrid is the common answer

Many publishers run a hybrid: a small number of strong bidders client-side, where identity matters most, and a broader set server-side. The split should be reviewed regularly, because bidder performance and identity signals change.

Choosing and managing bidders

Adding bidders is easy. Getting value from them is harder. More partners can raise competition, but each one also adds latency, duplicate demand and setup work.

Use a regular review to decide who stays:

1. Win contribution. How often does this bidder win, and at what prices? A partner that rarely wins may still lift prices by bidding competitively, so look at bid density as well.
2. Unique demand. Does the bidder bring buyers you cannot reach elsewhere, or does it resell the same demand available through other partners? Duplicate paths add cost without adding competition.
3. Response time. How often does the bidder respond before your timeout? Chronic late responders slow the auction and win nothing.
4. Quality. Watch for creative issues, policy violations or suspicious demand. A bidder that causes brand safety problems costs more than it earns.
5. Transparency. Check that the partner appears correctly in your ads.txt and in its own sellers.json.

Setting timeouts

Timeouts decide how long the auction waits for bids. Too short, and you cut off valid bids. Too long, and ads render late, users scroll past slots and viewability suffers. There is no universal right value: test different timeouts by device type, connection and page template, and measure revenue and page experience together.

What smart routing adds

Even a well-pruned bidder list wastes effort if every request goes to every bidder. Smart auction routing uses data to decide which demand partners should receive a given request.

Routing logic can consider signals such as:

• Format and placement: some bidders are strong on video, others on display or native.
• Geography and device: demand varies by market, device type and environment (web, in-app, CTV).
• Historical bid behavior: a bidder that never bids on a certain kind of request does not need to receive it.
• Latency patterns: partners that respond slowly in specific conditions can be skipped there.

The benefit is twofold. Fewer unnecessary requests means lower latency and less load. And partners receive the requests they are most likely to value, which can improve their bid rates and the prices they offer. Routing works best alongside adaptive price floors (floors that adjust to demand conditions rather than staying fixed), but floors are a separate lever with their own tradeoffs.

Routing needs guardrails. Occasionally send traffic to lower-priority bidders so the model keeps learning, and monitor for cases where routing starves a partner that would have competed.

Getting auction architecture right takes data and ongoing tuning, not a one-time setup. Vortex Media combines smart auction routing, adaptive floors and predictive modeling with experts who tune each publisher’s setup. See how it works on our publishers page.