Before we talk about server-to-server (or S2S, or server-side bidding, or whatever you want to call it), we have to talk about header bidding. Header bidding allows publishers to solicit bids on all their inventory from a select group of demand partners in a unified auction, just by putting the partner’s code in the pub’s page. It’s a way to circumvent the programmatic waterfall, and it’s led to overall higher CPMs for many publishers. But, at the same time, header bidding calls for a certain amount of development work, and it’s been blamed for adding latency to page load.
One common refrain (although always up for debate) is that header bidding is a hack, and that there ought to be some kind of “next step” that doesn’t require so much work and open the door to so many user experience problems. So certain players in the industry started asking, “Why do we have to use the page header? These server-to-server connections already exist—connections like the ad server to any demand source’s server. They’re incredibly fast, and unlike the page header, it seems they can accommodate all the demand partners could work with at once.”
That’s the principle behind S2S. It’s still a unified auction between select demand partners, but the bid takes place on a partner’s server rather than on the page.
But wait—S2S isn’t necessarily as utopian as it sounds. Basically, what all those server-to-server connections mean is, demand partners are integrating with each other. As it stands right now with S2S, someone still has to manage the server-side connection, and that someone is one of the demand partners. And the S2S products in market offered by header tech companies are more or less header-based–the publisher still has to take a bit of code from the partner that manages the S2S connection and put it in the page header to call out a bid request from all the other partners integrated on the server side. It might be more accurate to call this process H2S, from the publisher’s perspective.
People sometimes talk about S2S as being a bit of a “black box,” and they’re not necessarily wrong. Only the partner managing the S2S connection can see what’s happening with the auction—the publisher and all other partners have to trust it’s all on the level. Predictably, not all vendors are okay with this situation, because they’d have to entrust their bids to another company that’s probably a competitor. There are apprehensions over mishandling or losing data, as well as over the question of whether one partner could take “last look” privileges before calling the ad server (a question Google has answered that they won’t do in their S2S, Exchange Bidding in Dynamic Allocation, or EBDA). Partner hesitation leads to publisher hesitation—many pubs would really prefer all their existing header partners were in the S2S connection, if they were to adopt S2S.
While part of the promise of S2S for pubs is lighter lifting on the tech side, S2S requires pretty robust tech for a vendor to offer it. Many folks by this point have predicted that if S2S continues to gain traction, we’ll see more vendor companies gradually drop away.
AdMonsters Resources
Last Stand for Google’s “Last Look:” What’s Next? (2017)
What’s Ahead for the Header? (2017)
Gotta Stay on the Page: An Interview With Index Exchange’s Alex Gardner (2016)
The Server-to-Server Way: Going Beyond Header Bidding With Sonobi’s Tony Katsur (2016)