Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

Skip links

Server Side Header Bidding

What is server-side header bidding?


Server-side header bidding carries out key header bidding processes via servers rather than the traditional browser. Doing so bypasses some of traditional header bidding’s technical limitations, improves latency and the overall user experience, and promises higher yields for publishers.

Despite its promised advantages, however, server-side header bidding has seen slow adoption rates due to issues with transparency, cookie loss, and fragmentation of platforms, among others. With proven revenue boosts from header bidding and the promise of further increases with server-side solutions, however, the industry seems poised to take up the services of any of the numerous vendors currently racing to bring server-side header bidding systems to market.

How Does Server-Side Header Bidding Work?


In traditional header bidding, the user’s browser handles the process of initializing and sifting through simultaneous connections from the publisher’s different bidding partners. You can learn more about the details in our header bidding glossary entry.

With server-side header bidding, the bulk of the work moves away from the user’s browser and into the hands of a dedicated server. The diagrams below illustrate the difference between the two approaches.

In server-side header bidding, essentially, the designated server acts as a “mediating layer” between the user and the actual bidding process.

What Can Server-Side Header Bidding Do for You?


Server-side header bidding offers many improvements, especially for publishers. By shifting the work from the user’s browser to a designated server — basically, from client-side to server-side — server-side header bidding improves speed, latency, scalability, and efficiency for the header bidding process.

A large part of the difference stems from the technological capabilities of servers compared to browsers.

A user’s browser can handle a limited number of simultaneous connections — often no more than 6 – 10. Additionally, each connection that a browser handles puts strain on the browser’s resources, potentially slowing down the header bidding process as a whole. Add to that the possibility that a publisher’s website might not be equipped to manage ad auctions efficiently, and you risk sluggish, unpleasant user experiences, with the corresponding drops in impact and revenue.

With a third-party server to handle the load, browsers don’t have to strain under the weight of juggling multiple, simultaneous bids. Instead, the user’s system merely has to wait for the outcomes of processes that are being carried out elsewhere.

The use of a server means publishers can accept more bidding partners, all without worrying about aggravating latency issues. Auctions can be conducted on larger scales, making for greater yields.

However, as promising as server-side header bidding may look, advertisers should keep certain downsides in mind:

Poorer cookie match rates


Since server-side header bidding essentially interposes a third-party server between ad exchanges/SSPs and the user. Rather than assigning or reading a user’s cookie directly, these exchanges must now rely on continual syncing with the third-party platform/server, which maintains the sole client-side setup with the publisher.

Should this syncing process fail or fall out of step, bidders won’t glean any relevant data about the user — and therefore can’t judge the value of the associated impression that they’re bidding for. Key methods like audience targeting become impossible.

Additionally, the vendor who owns the platform/server that maintains the client-side connection and oversees the server-side auction gains a tremendous information advantage over other bidding partners. Should that vendor be a competitor rather than a neutral party, the integrity and fairness of auctions could be irreparably compromised.

Lack of transparency


On a similar note, moving the process to a server means a loss of oversight for both publishers and bidding partners. With operations invisible and impervious to audit by parties outside the company that owns the server, the risk of rigged auctions, hidden fees, information leaks, and other fraudulent practices skyrockets.

Understandably, many industry members are calling for neutral third parties to take over the management of the servers that conduct server-side auctions. With numerous ad tech companies — from Google and Amazon to AppNexus, Sonobi, and more — developing their own server-side header bidding platforms, however, it seems unlikely that an industry-standard solution for resolving these issues will emerge anytime soon.