{"id":27132,"date":"2021-02-17T15:05:42","date_gmt":"2021-02-17T14:05:42","guid":{"rendered":"https:\/\/yieldbird.com\/?p=27132"},"modified":"2024-07-22T19:27:12","modified_gmt":"2024-07-22T17:27:12","slug":"why-server-to-server-header-bidding-will-be-the-future-once-third-party-cookies-are-gone","status":"publish","type":"post","link":"https:\/\/yieldbird.com\/research-hub\/why-server-to-server-header-bidding-will-be-the-future-once-third-party-cookies-are-gone\/","title":{"rendered":"Why Server-To-Server Will Be the Future of Header Bidding Once 3rd Party Cookies Are Blocked on Google Chrome?"},"content":{"rendered":"\n

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. <\/span><\/p>\n\n\n\n

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.<\/span><\/p>\n\n\n\n

<\/div>\n\n\n\n
\"\"<\/figure>\n\n\n\n
<\/div>\n\n\n\n

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.<\/span><\/p>\n\n\n\n

Thanks to the fact that it\u2019s 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.<\/span><\/p>\n\n\n\n

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.<\/span><\/p>\n\n\n\n

<\/div>\n\n\n\n

Server-to-Server versus Client-Side Header Bidding in terms of cookie matching<\/strong><\/h2>\n\n\n\n
<\/div>\n\n\n\n

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.<\/span><\/p>\n\n\n\n

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.<\/span><\/p>\n\n\n\n

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\u2019s just too complicated to be properly scaled up. At least that was the case until recently.<\/span><\/p>\n\n\n\n

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 \u201cdownside\u201d should become obsolete in a matter of months.<\/span><\/p>\n\n\n\n

<\/div>\n\n\n\n\n\n