Header bidding emerged in around 2009 as a response to moves made by Google which allowed Google’s own ad exchange AdX to compete with publishers’ direct sold campaigns, leaving other exchanges to compete for the crumbs left behind.
By sending bid requests to multiple SSPs at the same time, header bidding allowed all demand sources to compete side-by-side, meaning publishers were more likely to receive higher bids for their impressions.
But header bidding isn’t a flawless technology. It can slow down web pages, and can require considerable management on the publisher’s end.
Recently we’ve seen an alternative gaining traction, called server-to-server bidding, or sometimes server-to-server header bidding. Server-to-server bidding has been around in various forms for a while. But the impending death of third-party cookies is giving server-to-server a new lease of life. Here’s how it works:
The Basics
Server-to-server bidding may sometimes be called server-to-server header bidding, but this is something of a misnomer.
Like header bidding, server-to-server (or S2S) bidding allows multiple demand sources to simultaneously compete for the same impression.
But header bidding’s name comes from the fact that the piece of code responsible for running it sits in the ‘header’ of a website. The client (the user’s browser) communicates with demand partners
With server-to-server bidding, the work is instead done by the ad server, rather than the browser – although the browser still has to put out a call to the ad server to ask it to send out bid requests.
The Technical Details
With header bidding, the piece of code which sends out requests to different SSPs and exchanges is found in a web page’s header/
The header physically sits at the top of a web page’s source code, and it contains a set of instructions on how to render the web page (you can view the header by accessing the source code of any website – it’s all the code which sits between <head> and </head>).
The header is designed to give the browser all the important information it needs to know first when loading a website, and is executed first. So if all the code within a header takes a long time to load, the content of a web page will also take a long time to load, creating latency on the visitor’s side.
Putting lots of calls to SSPs and exchanges can create this latency, since it takes a while for the browser to send each request and receive a bid. The more SSPs a publisher connects with, the greater this latency will be.
And the header was never really designed to handle bidding for ad inventory. Header bidding was really invented as something of a hack to counter Google’s moves which preferenced its own exchange,
In S2S bidding, the publisher instead sends out one request to a server, which itself sends out requests to SSPs and exchanges. These well-connected servers are able to communicate with demand partners much more quickly, and the speed of these connections isn’t dependent on the end user’s own internet connection.
The publisher may choose to set up their own servers to handle this – which open source header bidding technology Prebid caters for. But doing so will require a lot of technical work on the publisher’s end, and they’ll be required to maintain their own databases, which may be prohibitively expensive.
Or they can work with a vendor which offers server-to-server bidding. Google’s ‘Exchange Bidding’ and Amazon’s ‘Transparent Ad Marketplace’ both offer unified auctions via server-to-server connections. Or Prebid lists a number of ad tech companies which offer managed server-to-server bidding services.
The Pros and Cons
The first and most obvious benefit of S2S bidding is its speed. As mentioned above, one of the big drawbacks of header bidding is latency. And header bidding introduced a new tension for publishers – adding more demand partners increased yield, but created a worse user experience – which in itself could hurt revenues over time.
S2S bidding gets rid of this tension. With S2S bidding, the overall process remains quick no matter how many demand partners a publisher works with.
Managed S2S bidding services can also reduce workload on the publisher’s part, since the provider will handle a lot of the technical work.
But this advantage can also be seen as a disadvantage. Managed S2S bidding companies tend to be demand partners themselves, and this means an element of trust is required between the publisher and their partner. A demand partner which offers S2S bidding could, in theory, give preference to its own demand sources. And indeed, Google preferencing its own exchange was what sparked the creation of header bidding in the first-place.
Vendors – including Google – of course pledge to be neutral in their decisioning, but this trust requirement can still be a sticking point for some.
Another historical factor which has held back S2S adoption has been that client-side integrations have had better cookie match rates (since the browser itself holds cookies).
But with the impending death of third-party cookies, this factor is becoming less and less relevant. Adoption of alternative identifiers is increasing, meaning that S2S bidding already has less of a disadvantage than it has previously. And when third-party cookies are killed off for good in Chrome in 2023, this advantage for client-side integrations will be completely lost anyway.
