Client-side vs Server-side Header Bidding

Programmatic advertising has revolutionized the scale at which digital publishers can sell their inventory. With scale, comes efficiency and that’s where Header bidding has really come to the fore. In 2019, the share of Global publishers using a Header bidding wrapper reached over 75%, officially overtaking waterfall as the strategy of choice. 

Client side vs server side header bidding

What is Header Bidding?

Header bidding is a programmatic ad buying technique that allows digital publishers to offer their inventory to multiple ad exchanges at the same time, all before sending a request to their ad servers. Prior to this development, the Waterfall technique of prioritizing the queue of ad requests in order of CPM value was the strategy of choice. As the name suggests, Header Bidding requires access to the header of a publisher’s page. Once a user loads a page, a javascript tag will request several different ad networks to place their bid. The highest bid wins and the publisher’s ad server connects the user to the advertiser’s server, which then shows the winning ad creative.

All this happens within the Header Bidding Wrapper, which is a container that holds all the different header bidding partners a publisher may want to work with many different buyers. There are ultimately two types of wrapper; Client-side and Server-side. 

Client-Side Header Bidding, Pros and Cons

The go-to solution and industry-standard version of Header Bidding. 


  1. More Control, as publishers are able to set who the buyers are within the wrapper, increasing transparency.
  2. Higher fill rates happen as all types of inventory are included in the auction. 
  3. Higher CPMs, as you have a better chance of interested parties willing to bid higher. 
  4. Better Cookie matching, as this version of header bidding, occurs within the browser. Therefore, all parties are able to sync their cookies to improve matching, enabling retargeting and better-targeted ads.


  1. Page latency is the number one issue with client-side header bidding. The more partners contained in the header, the longer the page will take to load, especially with the number of ad server calls taking place within the header. This leads to bad user experience.
  2. Ad request limits occur as a browser can only make a certain number of requests at any one time. This is usually between 8 to 12, meaning many demand partners may miss out on making a bid.
  3. The complexity of integration can catch out to a publisher who may not have a dedicated and experienced technical team. Tagging multiple demand sources individually takes time.
  4. Bid duplication happens as the impression request is sent to multiple demand partners at the same time. This leads to duplicate bid processing.
  5. Performance issues are likely to happen with multiple demand partners with multiple tech capabilities and response times all bidding at the same time. Any new logic on the page will also slow down the performance of the browser as well as the web site.

Server-side Header Bidding, Pros and Cons

The main difference Server-side header bidding brings is that the request is no longer sent by the browser. Instead, a Server-side header bidding technology partner will send requests server-to-server to SSPs, DSPs and Ad Exchanges from their external ad server. Thus resolves the biggest issue of latency.


  1. Reduced Latency is the biggest advantage. One call to an external server instead of multiple calls to different partners makes a big difference. 
  2. More Bids, as the limitations of ad requests, are removed. Now the request can be sent to as many buyers as you want.
  3. Better for Video and Rich Media. As these formats naturally take longer to load, having the ability to send requests outside of the browser frees up the load times


  1. Lower Cookie Match Rates happen as user data is filtered when sent to a server. Fewer Cookies matched mean less opportunity for demand partners to buy an impression and therefore less fill and lower CPMs.
  2. Lack of Control is an issue as unlike client-side header bidding, the server-side does not offer the publisher the ability to choose or rank the buyers.

What is the best option?

The biggest conclusion to be made with Header Bidding depends on your focus as a publisher. Client-side header bidding offers greater control and monetization for standard formats, but lacks in user experience due to latency issues. Whereas, Server-side header bidding offers better user experience as latency issues are minimized, but potential risks arise from a lack of control, transparency, and reduced match rates. So is the focus of User Experience or CPM?

In a perfect world, this would be a balance publishers would need to find for themselves. Currently, however, there are too many limitations when it comes to server-side, which is why it’s still used quite rarely. Publishers feel it’s simply not worth pursuing in it’s current form, considering the performance it delivers.

With Google entering the flat auction world with their Open Bidding (EBDA) feature, it’s possible that we’ll never see a fully operational third-party S2S solution. It works pretty much in the same way and is way easier to set up, being part of the tech giant’s AdX ecosystem. That said, many are concerned with handing over all control to Google, so we might yet be up for a surprise with future developments.

A lot of publishers are also looking at implementing a hybrid of the two. For obvious reasons, video and rich media demand partners should be focused on a Server-side approach. Testing is of course key. Deciding which partners are best under different circumstances can only happen once a period of testing alternative setups has happened.