What is server side header bidding, and what should buyers ask?
Part of Supply path transparency
The short answer
Server side header bidding sends one request from the page or app to a server, which runs the auction with each demand partner server to server and returns the bids for the ad server's decision. It lightens the work on the reader's device, but it changes what publishers and buyers can see about bidders, IDs and the selling path.
Key takeaways
- The browser makes one call to a bidding server instead of one call per SSP, so the bidder calls leave the page.
- Speed gains depend on configuration: the server needs its own time limit, set inside the page's overall limit.
- User ID syncing still happens in the browser, so moving the auction does not remove cookie matching or its privacy controls.
- A bidding server is not a node in the supply chain unless it handles the money, and then it must declare itself.
What is server side header bidding?
Definition
- Server side header bidding
- Header bidding in which a server, rather than code in the browser or app, sends the bid requests to demand partners, collects their responses and passes the results to the publisher's ad server.
Prebid.org, the open source header bidding project, describes its Prebid Server adapter (opens in a new tab) as "a way to get a batch of bids from other bidders with one request." The page sends that one request, the server "performs all the auctions server-to-server (S2S)", and the results come back in time for the ad server call. Prebid's documentation says this lightens the performance load on the user's device.
The Prebid Server overview (opens in a new tab) lists the settings where it is used: mobile apps, AMP pages, server side web with Prebid.js, and server side ad insertion cases such as CTV, digital out of home and audio. It names two common operators: tech savvy publishers who run the server themselves, and managed service providers for everyone else. How client side bidding works on a page is covered in the header bidding glossary; this page covers what changes once the calls move to a server.
How does server side bidding differ from client side header bidding?
A 2019 measurement study, No More Chasing Waterfalls (opens in a new tab) by Pachilakis, Papadopoulos, Markatos and Kourtellis, accepted at ACM IMC 2019, described three ways header bidding was deployed: client side, server side and hybrid. It found the client side model the most transparent to the publisher and the hardest to set up, and the server side model the easiest to set up and the least transparent, since publishers may not know which partners bid or what they offered.
| Question | Client side | Server side | Hybrid |
|---|---|---|---|
| Where are bidders called? | From the browser or app, one call per partner | From a server, after one call from the page | Some partners from the browser, others from a server |
| Work on the reader's device | Highest, since each partner call runs on the device | Lowest, one outbound call | In between |
| What the publisher can see | Each partner's bid on each slot | Depends on what the server operator reports | Full view of the client side partners |
| Setup effort | Wrapper tuning and line item setup | Least for the publisher if a provider hosts it; running it in house is harder | Moderate |
| Trust required | Little, since the auction runs in view | The publisher trusts the server to run a fair auction | Shared between the two |
The same study counted how its detector saw the three models in the wild across 35,000 top websites it crawled: server side 48 percent, hybrid 34.7 percent and client side 17.3 percent of the header bidding it observed. Those shares describe that 2019 crawl, not today's market, and the authors read them as publishers preferring the lower overhead of server side or hybrid setups.
What does server side bidding change for page speed?
Fewer calls from the device is the main gain, but the page still waits. Prebid's adapter documentation sets a separate timeout for the server side auctions and says it should be approximately 200 to 300 milliseconds less than the Prebid.js timeout, so that all bids return in time. If none is set, the default is 75 percent of the page's bidder timeout or 750 milliseconds, whichever is lesser. A server that waits too long for slow bidders still delays the ad call; one that cuts them off early returns fewer bids.
Speed claims are worth testing, not assuming. The 2019 study found client side latency could rise with the number of messages exchanged or a poor configuration, which is a property of the setup rather than of the model. A publisher can measure ad call time on its own pages before and after a change.
How does server side bidding affect the SupplyChain object?
The SupplyChain object, schain, lists the entities in the flow of payment for an impression, so the question is who pays whom. Prebid's server FAQ says that in general Prebid Server does not add an entry to the schain, because it is basically a simple proxy that does not insert itself into the money flow by default, though a managed service could be configured to add one. Prebid's supply chain module page (opens in a new tab) says providers that manage wrappers for several publishers and handle payments to them need to declare their intermediary status, since the SupplyChain specification (opens in a new tab) prohibits SSPs from adding upstream intermediaries.
| Arrangement | Who pays the publisher | Expected schain | What the buyer checks |
|---|---|---|---|
| Publisher runs its own bidding server | Each SSP, under its own contract | No node for the server; the first node is the publisher's account on that SSP | That account is DIRECT in ads.txt and PUBLISHER in sellers.json |
| Hosted server, publisher contracts each bidder | Each SSP | Same as above; the host is a technology vendor, not a seller | Nothing beyond the usual SSP account checks |
| Managed service that collects and pays out revenue | The managed service | A node for the service on every request it sells | An ads.txt line for the service and an INTERMEDIARY or BOTH entry in its sellers.json |
| One bidder in the setup is a reseller | The reseller, for that bidder only | A bidder specific node for that path | The reseller's RESELLER line and its sellers.json entry |
Location can also vary. OpenRTB 2.6 places the object at source.schain, while the module page says that since Prebid 10 it copies its schain settings into ortb2.source.ext.schain, the 2.5 location, unless a publisher sets ortb2.source.schain directly. Buyers' parsers should read both. The supply chain object guide explains each node field.
What should buyers ask about server side paths?
A server side path is not worse inventory, but it adds a party whose behavior the buyer cannot watch from the page. Prebid's FAQ warns publishers to list all their bidding partners in ads.txt, because bidders without an entry may be perceived by DSPs as unauthorized sources of the inventory. The questions below turn that warning into a review a trading desk can send to a publisher or its monetization partner.
Questions for a publisher or partner selling through a bidding server
- Who operates the server: the publisher, a hosting vendor, or a managed service that also handles payments?
- Does the operator insert an schain node, and does its sellers.json list the publisher's account?
- Is every bidder the server calls listed in the site's ads.txt with the right account ID and relationship?
- Which bidders run server side and which run client side on the same page?
- What is the server timeout, and how is it set against the page's own time limit?
- Does the request carry source.tid and fd, so the buyer can match copies and knows the exchange's win is provisional?
- How are user ID syncs triggered, and how many bidders are synced per page view?
The answers sit beside the static file checks covered in the SSP guide. A path that passes both is as buyable as any other.
What does a server side review look like on a real plan?
Fictional example
An artisan chocolate maker in Columbus, Cleveland and Cincinnati
A fictional artisan chocolate maker plans holiday gifting ads beside food, recipe, entertaining and local lifestyle sites read in Ohio, in English. Its agency has an approved list of regional food and city magazine sites and buys through one DSP on two exchanges.
Bid logs show that several city magazines owned by one regional group arrive with an schain node for a monetization company before the exchange node. The desk checks that company's sellers.json: it lists the group's sites as INTERMEDIARY, and the group's ads.txt files carry a matching line, with a MANAGERDOMAIN entry naming the company.
One food blog arrives without any extra node, through its own account on each exchange; the blogger confirms a hosted server with direct contracts. The desk keeps both paths, notes the managed service as an expected hop on the deal sheet and asks the group for its server timeout before the holiday flight starts.
How does PlacementGraph help before bids arrive from a server?
Frequently asked questions
Does server side header bidding work for CTV and mobile apps?
Yes. The Prebid Server overview lists mobile apps, AMP and server side ad insertion cases such as CTV, digital out of home and audio among its use cases. In those settings the server can take requests from an app SDK or an ad insertion system rather than from page code. The app-ads.txt guide covers seller checks for apps.
Who picks the winning bid when the auction runs on a server?
The ad server makes the final choice. Prebid's FAQ says Prebid Server does not decide the overall winner; it returns one bid per bidder per impression, choosing the highest ranked programmatic guaranteed bid in the Java version, then the highest deal bid if the request prefers deals, then the highest CPM, with a random tiebreaker.
Can a publisher see the server side auction for troubleshooting?
Prebid's FAQ says debugging can be switched on by adding pbjs_debug=true to the page URL when the server is called through Prebid.js. It also notes that the OpenRTB test flag turns on debugging, but SSPs may not respond to or log test requests, so test traffic is a poor guide to live delivery.
Does a bidding server have to appear in ads.txt?
Only if it sells. A server that only relays requests is a technology vendor, and the bidders it calls need their own ads.txt lines. A managed service that is paid for the inventory and pays the publisher is a seller, so it should have an ads.txt line and a sellers.json entry like any intermediary.
Sources
- Module: Prebid Server Adapter (opens in a new tab)Prebid.org documentation
- Prebid Server Overview (opens in a new tab)Prebid.org documentation
- Prebid Server FAQ (opens in a new tab)Prebid.org documentation
- Prebid Server endpoint: /cookie_sync (opens in a new tab)Prebid.org documentation
- Module: Supply Chain Object (opens in a new tab)Prebid.org documentation
- SupplyChain object specification (opens in a new tab)IAB Tech Lab, OpenRTB repository
- OpenRTB 2.6 specification (opens in a new tab)IAB Tech Lab, OpenRTB 2.x repository
- No More Chasing Waterfalls: A Measurement Study of the Header Bidding Ad-Ecosystem (opens in a new tab)Pachilakis, Papadopoulos, Markatos and Kourtellis, ACM IMC 2019 (arXiv)
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.