Client-side vs. Server-side: Which Type of Header Bidding Solution Is the Best for Your Business?

Header Bidding technology is pretty ubiquitous these days, and it is not such a hot topic as it was 3 to 4 years ago. Most publishers have had it implemented in their ad stacks; or considered doing so but then decided not to for lack of resources or knowledge, or simply because they didn’t want to risk slowing down the page load time.

Many Publishers also do not know that they are using a type of Header Bidding which is not optimally suited to their needs, and that if they made a different choice while choosing a solution, or decided to switch it , they would not only improve their revenue take, but also limit internal costs and resources.

To help our Publishers make an educated choice in this regard, we have decided to provide a brief appraisal of the most popular Header Bidding solutions available on the market.

1. Client-side vs server-side

The divergence between the many types of Header Bidding is based on where the auction between SSP’s implemented within the technology takes place. It can either be happening at the browser level or directly between the ad servers.

A) Client-side solution

The solution which makes the bidding happen at the browser level is called client-side Header Bidding, because it takes place on the user’s computer. It works in such a way that every time a page loads, an ad request is sent to the demand partners asking for their bids. After that, the demand partners perform their auctions and return the prices to the page header. Once this happens, the header passes the information to the ad server (with the help of key values) where the winning bid is determined. Following this, the user is served with the winning bidder’s ad. As with every other type of Header Bidding, the client-side has both pros and cons.


– Pros of the client-side.

On the positive side, due to the fact that the bidding process happens in the browser, Ad Tech vendors representing Publishers and Advertisers are able to sync their cookies, which allows advertisers to identify the user on the Publisher’s site (at least on the browsers that still allow the use of 3rd party cookies). Thanks to this. targeted and retargeted ad campaigns are more efficient via the client-side solution, which ultimately results in more revenue for Publishers.

Another benefit of using the client-side is that this solution is currently the most commonly used on the market, even after introduction of Open Bidding (EBDA) and the Unified Pricing Auction by Google, which undermined the additional value of the auction pressure created by the other SSPs in the auction


– Cons of the Client-Side.

Due to the fact that Header Bidding requires the implementation of additional scripts in the page header, in most cases the page loading time is increased, which can not only negatively affect the user experience but also limit the number of impressions loaded, along with their visibility. All of this combined can sometimes end up being more negative for the Publisher’s business and outweigh the benefits of additional revenue and demand diversification. That is why the so-called latency issue is one of the main reasons why Publishers opt to go with server-side Header Bidding, or indeed to not use this technology at all.

Other negative sides of using the client-side solution are:
– Compatibility with the older browser versions
– Multiplication of bids due to the use of various header partners
– Limited number of ad requests sent from the Header Bidding
– Risk of tampering with data validation on the browser level
– Worse performance on the older devices

B) Server-side solution

As a response for the latency issues and the other limitations of the client-side model, the Ad Tech industry has come up with an alternative solution – the Server-side Header Bidding, which essentially works the same way as regular header bidding from the Publisher’s perspective, but requires substantially less implementation work. The requests are also sent from a central server rather than directly from the user’s browser; and this makes a big difference.

In terms of the Ad Server setup, Publishers can still choose to make recourse to a set of line items across all partners, or a set of line items per partner. However, because there are often hundreds to thousands of line items required per partner, it’s more likely for Publishers to opt for the former option and consolidate the ad server setup into a single set.


– Pros of the server-side.

Thanks to the moving of the bidding process from a browser to server level, the latency issue is significantly reduced as the browser ends up sending a single request instead of multiple ones. Although the possible benefits are measured in milliseconds, the difference is big enough to make a difference in the overall user experience, and performance of the Programmatic ad stack increases by up to 20-30%.

Apart from the smaller latency, there are 2 major benefits of the S2S solution impacting revenue in a positive way:
– it works better with Video and Rich Media products as they can load faster
– it does not have such limitations in number of binding partners as the Client-side


– Cons of the server-side.

Since the ad request in the S2S header bidding is sent to the SSPs from an external ad server, and not the user’s browser, due to the lack of cookie access, the match rates most probably will be lower. Due to this fact, coupled with the lower scale of the retargeting campaigns available; and because of a lack of data, the bid levels and final eCPM’s can end up being lower than in the client-side Header Bidding, which constitutes the main issue for Publishers considering the most optimal Header Bidding solution.

Apart from the matchrate issue, Publishers have to take into account that the server-side solution offers them lower transparency and control over the auction process
due to the fact that the management of the buyers and the blocking of unwanted ads is more limited than in the client-side solution. It’s also worth noting that the server-side is still a fairly new approach to Header Bidding and due to that it raises many concerns for both publishers and advertisers. This is sure to be enhanced in the coming years, especially given that Google went in this direction while creating their own Open Bidding solution, which has been positively appraised by many premium Publishers, thus giving the server-side approach another boost, and a reason for the industry to focus on making it better.

Making the better choice

Both the client-side and server-side Header Bidding solution comes with a set of pros and cons, which makes them more suited for some Publishers based on their specifics, such as business model, inventory type or current market trends. Usually it’s best to test out both implementations and to see what they will do in terms of the revenue and user experience of your website.

The other solution is to meet in the middle, and to go with the hybrid solution, combining the benefits of each model within one implementation. In fact, we have seen very good results with our Publishers running their main partners via both C2S and S2S; although one might expect that adding an extra server-side request would split the existing revenue between the server-side connection and the client-side connection. Usually, this doesn’t happen though, and instead the revenue from C2S seems to be largely unaffected when adding an extra server-side request, which only adds more revenue from the same SSP. The question is will it change in the near future due to the growing popularity of Supply Path Optimization activities on the Programmatic buying side.

Although the choice between the client and server-side is an important one, it’s not the only decision which Publishers need to make while considering their Header Bidding future. In the next part of this article we will compare the option for having a customized in-house solution, using one of the third-party products available on the market.