Is server-to-server (S2S) the universal “header” bidding solution for publishers?

When header bidding was introduced to the web publishing industry, it did truly add so much value that ranges from ad latency to user and bid transparency. It opened up part of the black box in the digital advertising ecosystem that was much appreciated and greatly welcomed by publishers. But what about publishers that don’t just have a web presence but also an app in the Apple Store and/or the Google Play store? Is there an opportunity where publishers can monetize their content across multiple platforms without needing to onboard dozens of ad-tech solutions that are platform specific?

When Server-To-Server (S2S) bidding was introduced to publishers, I got excited for the opportunity that will finally bypass several layers of restrictions and limitations of web browsers when attempting to involve many bidders in the client side auction. Publishers will be able to communicate from a single API call through their web servers to multiple SSPs (supply side platforms) without impacting user experience, page load times and adding a hefty amount of JavaScript to their pages. And in return, the response from that API call includes the highest bids for each ad unit involved. How amazing is that? Unfortunately that setup comes with several caveats.

Low user match rate

By moving SSPs from client-side to server side, they won’t be able to gain access to their cookies and other data that further identifies the user or their interests in their systems. Without that user-matching cookie SSPs and advertisers will have less data to go by when bidding and thus lead to an inefficient bid due to insufficient data. Whether the ad call is being made from the web or a mobile app, the user match rates will always be lower than with client-side bidding until the internet comes around and potentially offers a universal user identification platform without actually identifying the user.

SSP JavaScript Libraries

To solve the low user match rate mentioned above, SSPs are asking for their JS library to be added to the page as a way to augment their S2S offering in an effort to improve user matching. This hybrid solution isn’t aiding the goals behind moving SSPs from client-side to server-side. Publishers will still bear the responsibility of loading JavaScript libraries for each SSP on top of the S2S connection needed to trigger the auction.

What about the ad server? Is it S2S too?

For publishers using DFP, the S2S solution isn’t including the DFP call in that environment. The DFP call is still made on the client-side after the S2S call responds back with the highest bids for each ad unit. This might not be the case for mobile apps, but it’s definitely the case for web publisher using ad server that doesn’t offer server-to-server ad serving capabilities.

Tech ownership and scalability

For publishers willing to migrate from client-side to server-side bidding, they have a few options today. One option is to use the free Prebid Server but the free offering goes through AppNexus’ servers which removes a lot of control and ownership from the publisher. Other SSPs offer S2S services similar to their header bid wrapper services, but you’re still losing a lot of control and ownership over the tech (which perhaps for many publishers isn’t a deal breaker). For publishers to truly own their S2S solution, they would essentially need to build and host their own ad server that is able to make and receive server-side API calls to all the desired SSPs. This is a challenging task since you’re essentially building your own global real-time bidding server which comes with scalability, availability, performance and other challenges which took SSPs years (if not decades) to perfect.

For many publishers today, knowing the restrictions and limitations mentioned above, they decided to run S2S in a hybrid environment: client-side header bidding that includes their highest performing bidders plus server-side bidding for the remaining participants. This is probably an interim solution until the issues above are widely resolved, especially regarding the user-cookie mismatch and tech owenrship.

Leave a Reply

Your email address will not be published. Required fields are marked *