How to Implement Prebid Server: A Technical Deep Dive
This guide explains how Prebid Server works, how it differs from client-side header bidding with Prebid.js, and how agencies and publishers can deploy it to build demand networks and ad exchange-style setups.
An Overview of Prebid
What Is Prebid?
Prebid is an open-source solution that allows publishers to run header bidding auctions on their websites and mobile apps. Prebid.org is the organization that manages and maintains the standards, JavaScript libraries, and SDKs that companies use to add header-bidding capabilities to their digital properties.
Header bidding is a technical process whereby publishers sell ad impressions via multiple supply-side platforms (SSPs) before their ad server is called to find an ad for available ad space.
The benefit of using header bidding is that publishers are often able to find higher-paying advertisers through header bidding than through the deals they have set up directly in their ad server — for example, direct deals and OpenRTB deals.
What Is the Difference Between Prebid.js and Prebid Server?
When implementing header bidding using Prebid, publishers have two main options: Prebid.js and Prebid Server. In simple terms, Prebid.js is a JavaScript library for running client-side header bidding auctions in the web browser, while Prebid Server is a dedicated server that runs those same auctions server-side.
Both implementations come with trade-offs.
The main benefit of running header bidding auctions in the browser is that individual identification is more straightforward — for example, via cookies. The main downside is page-load latency. The more demand partners a publisher works with, the longer it takes to display ads, which can degrade the user experience.
Running header bidding auctions on a server moves all of those client-side requests away from the browser, which reduces latency to bidders. The main downside is that individual identification becomes harder, because passing cookies from the browser to Prebid Server is more difficult.
For app developers wanting to monetize mobile ad inventory, Prebid Server is not optional — the Prebid Mobile SDK requires it.
Prebid.js vs. Prebid Server: Which Delivers More Ad Revenue?
Identifying which implementation delivers more ad revenue is rarely straightforward; it depends on factors like the publisher's inventory type, audience, and the demand partners involved.
Generally speaking, if a publisher relies on cookie matching — identifying an individual via IDs stored in web cookies — they may see a decrease in ad revenue when switching from Prebid.js to Prebid Server. The reason is that advertisers will pay less for an impression when they cannot identify the individual and determine whether that person belongs to their target audience.
To get the best of both approaches, some publishers opt for a hybrid model: running their best-performing demand partners via Prebid.js while routing all other demand partners through Prebid Server.
How Prebid Server Works and How Agencies Can Use It to Build an Exchange
Typical Prebid Server Implementation vs. Agency-Operated Exchange
A typical publisher use case looks like this: a publisher has Prebid.js configured on their website to sell inventory through multiple SSPs. For performance reasons, they decide to move to server-side header bidding (SSHB), so they deploy Prebid Server, configure adapters on the server side, and adjust their Prebid.js configuration to connect to it.
The agency use case is different. An agency with an established demand network needs a scalable way to onboard new publishers into that network. To do this, the agency creates an adapter that connects to their own Prebid Server and distributes that adapter to publishers. From the publisher's perspective, the agency's adapter functions like any other Prebid.js adapter — it just happens to be routing requests to the agency's Prebid Server rather than directly to an SSP.
Can Publishers Call Multiple Different Prebid Servers?
Yes. The adapter that a publisher configures on their website can call any endpoint that returns bids — and that endpoint could be a Prebid Server operated by an agency, a separate Prebid Server operated by the publisher themselves, or both simultaneously. Publishers can implement and call multiple different Prebid Server setups via different adapters configured on their site.
This is beneficial for agencies because they don't need to build custom software integrations with each demand source; they can use Prebid Server as the integration layer instead.
Bid Duplication: A Real Risk
One issue that arises when publishers work with multiple Prebid Server setups — or when a publisher and an agency both have adapters pointed at some of the same demand sources — is bid duplication. If a publisher and the agency they work with have the same demand sources in their adapters, they may both receive bids from the same source for the same impression.
Bid duplication is fairly common across both client-side and server-side header bidding implementations.
Even when different user IDs are involved, bids ultimately originate from a single website — and that website can be identified because the domain can be passed in an OpenRTB request. Advertisers can detect bid duplication by correlating the timing of bid requests received, among other methods.
From the publisher's side, identifying overlapping demand sources depends on how transparent the agency is about their adapter. Some agencies will disclose exactly which demand partners they work with and which source returned a given bid. Others operate more like a proxy — presenting bids as coming from their own network without revealing that AppNexus, for instance, was the actual source under the hood. If publishers ask their agency for a list of demand partners, they should be able to spot overlapping bidders.
How the Header Bidding Process Works with Prebid Server
The diagram shows where Prebid Server fits within the broader ecosystem.
The end-to-end process for a web page visitor looks like this:
- A user visits a web page and the page begins loading.
- The page loads the Prebid.js script, which is located in the page header (between the
<head></head>tags), and sends a request to Prebid Server. - Prebid Server passes information about the website, available inventory, and the user (including user ID, if available) to the SSPs and ad exchanges configured in its adapters.
- The SSPs pass bid requests to demand sources — DSPs and ad exchanges — which evaluate the impression against potentially hundreds or thousands of active ad campaigns and submit bids on behalf of advertisers.
- The SSPs analyze responses from demand sources and return the winning bid to Prebid Server.
- Prebid Server returns the bids to Prebid.js on the publisher's website.
- Depending on Prebid.js configuration, either all bids or only the highest bid are passed to the publisher's ad server. The header bidding bid then competes against other monetization sources in the ad server, such as direct deals.
- If the ad server determines that the header bidding bid wins, a special creative is returned to the browser, which renders the advertisement.
Who Can Operate a Prebid Server?
Prebid Server can be operated by a publisher, by an SSP, or by an agency. The Prebid Server instance contains adapters from SSPs and ad exchanges, which are called whenever Prebid Server receives a request from a website or mobile app.
In the agency scenario, the agency manages the Prebid Server and distributes its adapter to publishers. The agency holds the identifiers, bid parameters, and configurations that apply across multiple publishers — and can generate publisher-specific parameters when needed. Publishers simply add the agency's adapter to their website to gain access to the agency's demand network.
Prebid Server Is Not an Ad Server — and Doesn't Run Auctions Itself
An important distinction: Prebid Server works similarly to an exchange in that it manages connections to multiple demand sources, but it does not run auctions itself. The actual decision about which bid to return is made inside the SSP or ad exchange, just as in a standard RTB auction.
When people refer to a "Prebid auction," they mean that bid requests are being sent out to multiple SSPs. The auction logic lives in those SSPs — not in Prebid Server.
Prebid Server is also not an ad server. There is no complex decisioning logic that can be programmed into it the way you would in an ad server. Prebid Server either returns all bids or the single highest bid it receives from demand sources — that's the extent of its decision-making.
The final decision about which ad to display belongs to the publisher's ad server (e.g. Google Ad Manager or another ad server). The ad server receives the winning bid from the header bidding auction, compares it against other line items such as direct deals, and selects the highest-paying option.
How Prebid Server Passes the Winning Bid to the Ad Server
Prebid Server does not interact with the ad server directly. It returns bids to the browser, and the browser then passes them to the ad server via Prebid.js — configured to send either all bids or only the highest-paying one.
To actually display the winning creative, publishers need to configure a Prebid Universal Creative in their ad server. This is an HTML snippet set up as a creative on a line item in the ad server. When the header bidding bid wins the ad server auction, the ad server returns that snippet to the browser. The snippet then calls Prebid to display the winning creative — effectively the ad server telling Prebid: "you won; now render the ad."
This is conceptually similar to piggybacking: the code that displays the Prebid ad is served as an HTML snippet from the ad server. The ad server only knows that a particular line item won; the snippet handles the actual ad rendering by calling back to Prebid.
All of this — the request from the browser to Prebid Server, the outbound calls to SSPs and demand sources, the return of bids, the ad server decision, and the creative render — happens while the web page is still loading. The number of moving parts means there are many places where misconfiguration can cause the entire header bidding process to break. A single error in adapter configuration or bid parameters can result in no ads serving at all, which is why careful implementation and thorough testing matter.
How Long Does It Take to Build an Exchange Using Prebid Server?
The timeline depends on factors like the number of demand sources being integrated and any custom requirements. The deployment itself — standing up the Prebid Server instance and writing the adapter — is relatively straightforward and typically takes around one month. After that, expect another four to six weeks for configuration, testing, issue resolution, and implementing any custom features.
A realistic full timeline from start to production-ready is roughly two to three months, with the later weeks dominated by the integration and quality-assurance work rather than the core build.