So far, most publishers have utilized client-side header bidding – i.e the auction takes place in the header of the web page. Client-side header bidding has some clear advantages, as it lets the demand partner access the web page directly, facilitating user matching and minimizing cookie loss.<\/p>\n\n\n\n
However, there are some distinct drawbacks with client-side auctions.<\/strong><\/h2>\n\n\n\n
Mainly, the more partners you add to the client-side auction, the slower the page load will be. Usually, you can work with 8-10 demand partners without slowing down the page too much, but beyond that, the user experience will suffer. Mobile browsers are especially sensitive because they can handle fewer simultaneous connections, especially if there are several connections to the same URL (as it would be the case if several demand partners use Rubicon as an SSP, for example).<\/p>\n\n\n\n
Client-side\nauctions are also dependent on the internet connection of the device. A slow\ninternet connection could slow down the page and ads even further. Demand\npartners may not be able to respond in time, reducing both the user experience\nand monetization.<\/p>\n\n\n\n
Do you like what you’re reading? Subscribe our newsletter for more content like this!<\/strong><\/h3>\n\n\n[mc4wp_form id=”407″]<\/p>\n\n\n\n
![\"\"](\"https:\/\/yieldbird.com\/wp-content\/uploads\/2019\/07\/0147-server-side-header-bidding-04-1024x640.png\")
<\/figure>\n
Advantages of server-side header bidding \ufeff<\/strong><\/h2>\n<\/div><\/div>\n\n\n\n
With server-side header bidding, the auction takes place on an external server, so instead of running multiple calls from the web page, you just make one call – to the header bidding<\/strong><\/a> server. The server then makes the call to all connected demand partners.<\/p>\n\n\n\nThis approach\nhas a number of advantages compared to the client-side auction. It enables the\nsite to work with an almost infinite number of demand partners. It is also not\ndependent on the user\u2019s internet connection, and since you would normally call\nit before the ad server, the response time of the demand partners will not\naffect page load.<\/p>\n\n\n\n
Overall, the latency of both the web page and the ads will be much lower with server-side auctions compared to the client-side.<\/p>\n\n\n\n
Also, S2S\n(server to server) enables publishers to integrate directly with DSPs, thereby\nbypassing the SSP and its revenue share.<\/p>\n\n\n\n
The other side\nof the coin is, of course, that demand partners may place lower bids and on\nfewer impressions due to difficulties with user matching.<\/p>\n\n\n\n
![\"\"](\"https:\/\/yieldbird.com\/wp-content\/uploads\/2019\/07\/0147-server-side-header-bidding-05-1024x640.png\")
<\/figure>\n
Hybrid header bidding offers the best of both worlds<\/strong><\/h2>\n<\/div><\/div>\n\n\n\n
Fortunately, publishers don\u2019t have to choose between client-side and server-side. It is entirely possible (and recommended) to run both C2S (client to server) and S2S (server to server) at the same time in a so-called hybrid setup. You simply run your most important partners on the client-side and the \u201clong tail\u201d on the server-side, with everyone competing in the wrapper. <\/p>\n\n\n\n
In fact, we see very good results with our publisher running its main partners both C2S and S2S. One might expect that adding an extra server-side request should just split the existing revenue between the server-side connection and the client-side connection, but usually, it doesn\u2019t happen. Instead, the revenue from C2S seems to be largely unaffected when adding an extra server-side request, and the server-side auction just adds more revenue from the same SSP.<\/p>\n\n\n\n
\u201cWe see an increase in their programmatic revenue by around 25-50% from the same SSP by running both C2S and S2S. I\u00b4m actually not sure why this is the case. One theory is that the DSPs just listen to a fraction of the traffic from a particular publisher, and by adding an extra request, you force them to listen to a larger portion of the traffic.\u201d<\/em> Fredrik Johansson, LiveWrapped<\/strong><\/a>.<\/p>\n\n\n\nInterview with MittMedia, that implemented LiveWrapped header bidding one year ago.<\/strong><\/h2>\n\n\n\n
Mainly, the more partners you add to the client-side auction, the slower the page load will be. Usually, you can work with 8-10 demand partners without slowing down the page too much, but beyond that, the user experience will suffer. Mobile browsers are especially sensitive because they can handle fewer simultaneous connections, especially if there are several connections to the same URL (as it would be the case if several demand partners use Rubicon as an SSP, for example).<\/p>\n\n\n\n
Do you like what you’re reading? Subscribe our newsletter for more content like this!<\/strong><\/h3>\n\n\n
[mc4wp_form id=”407″]<\/p>\n\n\n\n
<\/figure>
Advantages of server-side header bidding \ufeff<\/strong><\/h2>\n<\/div><\/div>\n\n\n\n
With server-side header bidding, the auction takes place on an external server, so instead of running multiple calls from the web page, you just make one call – to the header bidding<\/strong><\/a> server. The server then makes the call to all connected demand partners.<\/p>\n\n\n\nThis approach\nhas a number of advantages compared to the client-side auction. It enables the\nsite to work with an almost infinite number of demand partners. It is also not\ndependent on the user\u2019s internet connection, and since you would normally call\nit before the ad server, the response time of the demand partners will not\naffect page load.<\/p>\n\n\n\n
Overall, the latency of both the web page and the ads will be much lower with server-side auctions compared to the client-side.<\/p>\n\n\n\n
Also, S2S\n(server to server) enables publishers to integrate directly with DSPs, thereby\nbypassing the SSP and its revenue share.<\/p>\n\n\n\n
The other side\nof the coin is, of course, that demand partners may place lower bids and on\nfewer impressions due to difficulties with user matching.<\/p>\n\n\n\n
<\/figure>\n
Hybrid header bidding offers the best of both worlds<\/strong><\/h2>\n<\/div><\/div>\n\n\n\n
Fortunately, publishers don\u2019t have to choose between client-side and server-side. It is entirely possible (and recommended) to run both C2S (client to server) and S2S (server to server) at the same time in a so-called hybrid setup. You simply run your most important partners on the client-side and the \u201clong tail\u201d on the server-side, with everyone competing in the wrapper. <\/p>\n\n\n\n
In fact, we see very good results with our publisher running its main partners both C2S and S2S. One might expect that adding an extra server-side request should just split the existing revenue between the server-side connection and the client-side connection, but usually, it doesn\u2019t happen. Instead, the revenue from C2S seems to be largely unaffected when adding an extra server-side request, and the server-side auction just adds more revenue from the same SSP.<\/p>\n\n\n\n
\u201cWe see an increase in their programmatic revenue by around 25-50% from the same SSP by running both C2S and S2S. I\u00b4m actually not sure why this is the case. One theory is that the DSPs just listen to a fraction of the traffic from a particular publisher, and by adding an extra request, you force them to listen to a larger portion of the traffic.\u201d<\/em> Fredrik Johansson, LiveWrapped<\/strong><\/a>.<\/p>\n\n\n\nInterview with MittMedia, that implemented LiveWrapped header bidding one year ago.<\/strong><\/h2>\n\n\n\n
With server-side header bidding, the auction takes place on an external server, so instead of running multiple calls from the web page, you just make one call – to the header bidding<\/strong><\/a> server. The server then makes the call to all connected demand partners.<\/p>\n\n\n\n
This approach\nhas a number of advantages compared to the client-side auction. It enables the\nsite to work with an almost infinite number of demand partners. It is also not\ndependent on the user\u2019s internet connection, and since you would normally call\nit before the ad server, the response time of the demand partners will not\naffect page load.<\/p>\n\n\n\n
Overall, the latency of both the web page and the ads will be much lower with server-side auctions compared to the client-side.<\/p>\n\n\n\n
Also, S2S\n(server to server) enables publishers to integrate directly with DSPs, thereby\nbypassing the SSP and its revenue share.<\/p>\n\n\n\n
The other side\nof the coin is, of course, that demand partners may place lower bids and on\nfewer impressions due to difficulties with user matching.<\/p>\n\n\n\n
<\/figure>
Hybrid header bidding offers the best of both worlds<\/strong><\/h2>\n<\/div><\/div>\n\n\n\n
Fortunately, publishers don\u2019t have to choose between client-side and server-side. It is entirely possible (and recommended) to run both C2S (client to server) and S2S (server to server) at the same time in a so-called hybrid setup. You simply run your most important partners on the client-side and the \u201clong tail\u201d on the server-side, with everyone competing in the wrapper. <\/p>\n\n\n\n
In fact, we see very good results with our publisher running its main partners both C2S and S2S. One might expect that adding an extra server-side request should just split the existing revenue between the server-side connection and the client-side connection, but usually, it doesn\u2019t happen. Instead, the revenue from C2S seems to be largely unaffected when adding an extra server-side request, and the server-side auction just adds more revenue from the same SSP.<\/p>\n\n\n\n
\u201cWe see an increase in their programmatic revenue by around 25-50% from the same SSP by running both C2S and S2S. I\u00b4m actually not sure why this is the case. One theory is that the DSPs just listen to a fraction of the traffic from a particular publisher, and by adding an extra request, you force them to listen to a larger portion of the traffic.\u201d<\/em> Fredrik Johansson, LiveWrapped<\/strong><\/a>.<\/p>\n\n\n\nInterview with MittMedia, that implemented LiveWrapped header bidding one year ago.<\/strong><\/h2>\n\n\n\n
Fortunately, publishers don\u2019t have to choose between client-side and server-side. It is entirely possible (and recommended) to run both C2S (client to server) and S2S (server to server) at the same time in a so-called hybrid setup. You simply run your most important partners on the client-side and the \u201clong tail\u201d on the server-side, with everyone competing in the wrapper. <\/p>\n\n\n\n
![\"\"](\"https:\/\/yieldbird.com\/wp-content\/uploads\/2019\/07\/0147-server-side-header-bidding-06-1024x640.png\")
<\/figure>