Header Bidding: Difference between Client-Side and Server to Server

If you are thinking about the implementation of Header Bidding on your websites, there are two types of implementation that you should think about it or a hybrid solution.

Client-Side Header Bidding
Client-Side Header Bidding

If you are thinking about the implementation of Header Bidding on your websites, there are two types of implementation that you should think about it or a hybrid solution. There is the Client-Side Header Bidding where the auction happens on the user's browser and the S2S Header Bidding where the auction happens on the server. Appnexus just did an infograph explaining the two types of Header Bidding.

On the Client-Side Header Bidding, the auction happens on the user's browser. The Ad call goes from the browser to participating exchanges (SSP's), and then to the DSP's. The best value of the Client-Side Header Bidding is that the cookie is dropped on the browser, so the cookie match rates are close to 100%. However, there is a disadvantage: more demand partners will slow load times of the ads.

Server to Server Header Bidding

Server to Server Header Bidding
Server to Server Header Bidding

On the S2S Header Bidding, the auction happens on the server, being the load times slower, but the cookie match rate also lower. As the load times are slower or stable, more partners can be included on the header bidding.

What are the main differences between Client Side / Server to Server Header Bidding?

Quantity of Demand Partners

With Server to Server Header Bidding, you will be able to add more partners to the auction without having a lower latency.

Stability & Latency

On the Server to Server, the auction happens on the server and not on the user's browser. This means less latency and better bid density.

Cookies

As the cookies are not loaded in the browser, the cookie match ratio could fall. Also on the S2S integration publishers can have less transparency.