Why Server-To-Server Will Be the Future of Header Bidding Once 3rd Party Cookies Are Blocked on Google Chrome?

Since the concept of Header Bidding was created, Publishers have often been forced to choose between higher yield and better user experience.
Using more SSPs in the wrapper usually meant more money, but also in most of the cases a bigger latency; which was an issue, especially for those Publishers with very sensitive audiences, or with a second leg of business other than ads.

Luckily, a different path has opened, that of Server-to-Server Header Bidding (S2S), which has given Publishers new opportunities and freed them from the binary choice between money and UX.

In the S2S version of the Header Bidding, the browser connects with a HB server, which later connects with all the demand sources which the Publisher has placed in it the wrapper. The server then collects the bids and pushes them to the browser.

Thanks to the fact that it’s one server connecting to another, using extra SSPs does not slow the browser in any way, as in the case of the client-side approach. As a result, Publishers achieve more demand and higher auction pressure, while retaining fast page loads. The end result is higher ad viewability and increasing yield. Win-win.

Although it seems like a no-brainer and an obvious choice – and that is why Server-to-Server Header Bidding has generated a lot of enthusiasm in the ad tech industry – it does have its caveats.

Server-to-Server versus Client-Side Header Bidding in terms of cookie matching

A crucial limitation for Publishers related to the use of Server2Server Header Bidding on their websites is a much lower cookie match rate from the one that they are able to achieve with Client-Side. And considering that less matched cookies means less retargeting options, which as we all know is most profitable in terms of Programmatic campaigns (especially on the Open Market). This has created a fair share of doubts and fears about the possible drops in monetization effectiveness.

The client-side is winning this particular battle (or at least has been winning it to date), as thanks to the direct SSP-Browse connection, SSP user ID cookies are included in the ad requests.

In the S2S case, browsers don’t pass on the cookies as the HB server and the SSPs are located on different domains. There is a way of course for Header Bidding servers to access the SSP cookies, but it would require a sync between the HB server and each SSP, and it’s just too complicated to be properly scaled up. At least that was the case until recently.

As most Publishers prepare for a future without 3rd party cookies – they are already unavailable on Safari and Mozilla, and will bite the dust on Chrome in 2022, S2S Header Bidding is becoming more widely adopted around the world, which has resulted in an improved cookie match rate, which surely should be monetized while the cookies are still here; but this specific “downside” should become obsolete in a matter of months.

Infrastructure requirements of Server-to-Server Header Bidding versus Client-Side solutions

The second biggest difference between Client-Side and Server2Server is the need for server infrastructure. In the Client-Side solutions case, the Publisher only has to place a wrapper code in the heads of his sites. There is no need for a specific server infrastructure for the Header Bidding. With S2S, things are not that simple and a specific server is needed for the purpose of running Header Bidding. 

This has two consequences: 

1. More work, and know-how is needed for the implementation

and maintenance of the solution. 

2.  Higher costs of using the Header Bidding, as the additional server will never come free.

Server-to-Server – still more pros than cons

Even taking into consideration the two main downsides of Server-to-Server Header Bidding, one of which will soon cease to exist, there are already more benefits that will arise from the adoption of this solution for your business.

Apart from the clear UX/speed value mentioned at the beginning of this article, a big benefit is related to the AMP monetization, which is specifically related to the changes from November 2017 when the ability to use client-side wrapper along GAM was removed.

This in turn made S2S the only real opportunity for Publishers with AMP pages to use Header Bidding.

For mobile in-app, almost the same as for AMP, most of the leading Header Bidding solutions operate in the S2S model only. Any other option for using HB on in-app traffic would require running an SDK for every bidder which does not make much sense, and could create huge frictions in the app stability.

New Server-to-Server options on every corner

In Q2 2018, Google released its Open Bidding product for Publishers using Google Ad Manager, as an easy-to-implement Server-to-Server Header Bidding alternative. Although thanks to the seamless setup it looked promising at the beginning, limitations in terms of the available partners, and the maintenance flexibility along with its availability only for GAM360 users made it a little less popular than initially expected. 

Amazon also used the S2S approach while entering the ad tech stage, when they created 2 solutions for Publishers looking to use their demand along with other SSP’s via the UAM/TAM products. Although for now it generates real value only for US and UK based publishers, the rapid growth of the ad revenue share created by Jeff Bezos company in 2020, and the huge expectations for its growth over the next couple of years makes this solution a must have for most of the large and medium Publishers, at least in terms of their test roadmaps. 

The solutions mentioned above are some of the bigger ones on the market, and as it often happens with a big scale, what they lack a bit is flexibility to specific business needs of different Publishers. That is why in Yieldbird we have looked to create the future of Header Bidding with our Quick Wrap product. While looking at revenue as a key aspect of our product, we have created a wrapper which is flexible, transparent, demand-agnostic, smart and simple, all of which arose from our cooperation with some of the biggest Publishers in the world, who told us that they prefer to have in-house demand management, so as to have full control over Header Bidding maintenance in possibly the most automated way.

Go with the flow, keep up the good work

Looking at the industry events, it looks quite clear as to where the dice will roll. As 3rd party cookies which were the biggest value drivers for the Client-Side Header Bidding will be gone by the end of next year, keeping up with this solution while knowing it can only hurt your ux and page speed does not make much sense anymore. 

Of course leaving one’s comfort zone, and getting the approval for additional costs to create a S2S solution or implement the one available on the market will never be easy. Still, for best results, we strongly recommend that you go with the flow. 

The future is here, and in the ad tech industry we all need to adapt to the changes that are coming thick and fast.