Prebid Server

Prebid Server is open-source software that runs a header-bidding auction on a remote server instead of inside the visitor's browser. Header bidding is the technique publishers use to offer an ad impression to many demand partners — supply-side platforms and exchanges — at once, before calling their ad server, so the impression goes to the highest bidder rather than a fixed waterfall. In the client-side version, that whole auction runs in the browser using a JavaScript library, Prebid.js. Prebid Server moves the auction off the page. The browser makes one request to the server, the server calls all the connected demand partners, collects their bids, picks the winner, and returns it to the page. Prebid Server is part of the Prebid project stewarded by the industry body Prebid.org, and publishers or their tech partners run it, often alongside Prebid.js in a hybrid setup.

The reason to run the auction server-side is browser load. Every demand partner added to a client-side auction means another set of bid requests firing from the user's browser, which consumes bandwidth, CPU, and, crucially, time, slowing the page and risking timeouts. Because a browser can only manage so many simultaneous connections, client-side header bidding practically caps how many partners you can call before the page suffers. Prebid Server lifts that cap by doing the heavy work on infrastructure built for it, so a publisher can connect far more demand partners and larger auctions without loading down the page. That extra competition can raise the winning bid and yield. The technique especially suits mobile and AMP environments, where browser resources are scarce. In short, the server-side move trades some signal for scale and speed, letting a publisher grow demand without punishing page performance.

The core choice is where the auction runs, and each side has a real trade-off. Client-side Prebid.js runs the auction in the browser, which keeps the auction close to the user and preserves signal — cookies and user IDs are readily available, so match rates are high and bidders, better able to identify the user, often bid more per impression. The cost is performance. Each added partner slows the page, and the number of bidders is limited. Server-side Prebid Server runs the auction on a server, which barely burdens the page and lets you add many more partners, but it introduces a cookie-syncing problem. The server must reconcile user IDs with each demand partner, and match rates tend to drop, which can lower bids. So client-side favors revenue per impression and signal, while server-side favors scale, speed, and breadth of demand. Neither is strictly better.

Because the trade-off is genuine, most sophisticated publishers do not choose one exclusively. They run a hybrid. A common pattern keeps the highest-value, signal-sensitive demand partners client-side in Prebid.js, where match rates and bids are strongest, while pushing the long tail of additional partners into Prebid Server, where they add competition without slowing the page. This captures much of the yield benefit of both. The decision also shifts with the environment and with the industry's move away from third-party cookies. As browser signal erodes, some of the client-side match-rate advantage narrows, changing the calculus. The key point is that Prebid Server and Prebid.js are not rivals so much as two placements of the same auction, and the practical question is which demand belongs on the page and which belongs on the server. Testing yield with each configuration, per placement, is how publishers settle it rather than by rule of thumb.

Use Prebid Server to scale demand beyond what the browser can carry — to add more partners, run larger auctions, and serve resource-constrained environments like mobile and AMP without degrading the page. Run it as part of a hybrid, keeping signal-sensitive, high-value bidders client-side where match rates are strongest and moving the additional demand server-side. Invest in cookie-syncing and identity solutions to recover the match-rate loss that server-side auctions bring, since higher match rates lift bids. Set sensible auction timeouts, monitor latency and win rates, and test yield configuration by placement rather than assuming server-side always helps. Because Prebid is open source, you can self-host the server or use a managed provider. Either way, treat it as infrastructure that needs monitoring and tuning. Used deliberately, Prebid Server grows a publisher's demand and yield without paying for it in page speed.

The failures come from treating server-side as a free upgrade. Moving all demand to Prebid Server sacrifices the client-side match-rate and signal advantage, which can lower bids enough to erase the scale benefit. Neglecting cookie-syncing leaves match rates poor and bids soft. Ignoring the added server latency and setting careless timeouts can lose bids to the very slowness the move was supposed to avoid. Assuming server-side beats client-side everywhere skips the per-placement yield testing that actually settles the question. And running a server-side stack without monitoring lets latency, errors, and timeouts quietly erode revenue. The discipline is to use Prebid Server for scale and speed within a tested hybrid, invest in identity and cookie-syncing to protect match rates, tune timeouts, and measure yield by placement, so the server-side move adds demand without giving back the value it was meant to capture.

Prebid Server extends header bidding, a programmatic technique that emerged around 2015, by running the wrapper auction server-side under the open-source Prebid project.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where prebid server is a core concern: