You’ve been lied to about ‘Server to Server’ Header Bidding


e’ve all heard about it – server to server header bidding – in fact on almost every sales call somebody asks us about it. This leaves me completely dumbfounded. I knew we worked in marketing technology, but I didn’t know that we were an industry of the best spin doctors on the planet – one wherein all of the middle men, who provide undifferentiated value, could take a piece of infrastructure they’ve all had for 5-10 years (servers), slap a new name on them, and somehow pitch it as a differentiator. Impressive, possibly more impressive than the infrastructure itself. Allow me to explain:

Header Bidding, the revolutionary technology that has often doubled publisher yields, is what’s known as a “client side” technology. In order to properly understand what this means, we need a quick lesson on web technology fundamentals and ad tech history.

I didn’t know that we were an industry of the best spin doctors on the planet – one wherein all of the middle men, who provide undifferentiated value, could take a piece of infrastructure they’ve all had for 5-10 years (servers), slap a new name on them, and somehow pitch it as a differentiator.

The first step in any website interaction involves the browser (like Google Chrome or Mozilla Firefox), also known as the client, making a request to a computer that has the HTML of the website in it, also known as a server.

This process is fundamental to how the internet works – every single website out there is distributed by servers communicating with clients. It is also the fundamental way that all online advertising works – there is always a piece of infrastructure, or code, that renders client side in the HTML of the website that creates communication between the advertising infrastructure and the user’s browser, or Client. Traditionally this has been an ad tag, so after the request above happens it triggers a second (or many) ad requests.

For decades this simple method, inserting an ad tag that calls a server, has been the way that online ads get delivered to websites. It’s simple, straightforward, and relatively fast.

However, you’ll notice something important about the diagram above – a single ad tag is only capable of calling a single ad server or ad exchange. This means that each of these ad tags, or ad requests, is only capable of communicating with one exchange. As a result, we ended up with what are called “waterfalls,” where a publisher would chain these requests together to try to speak to multiple exchanges. A “waterfall” is really a chain of client side HTTP requests that happen in a predetermined order. Sticking with the diagrams above, waterfalls look like this :

As you can see, in a waterfall, we have sequential HTTP requests. Each exchange gets called one at a time, in a predetermined order dictated by the trafficked passbacks. This is inefficient for any number of reasons – from a yield perspective, from a timing perspective (these requests happen one a time in a predetermined order), and all of the other things that header bidding has fixed. So what is header bidding in this context?

Header Bidding, at its core, is a way for the client to communicate with all of the ad exchanges / adservers at the same time. Instead of one of these client-side waterfalls existing, where the browser calls ad exchanges one at a time, header bidding is a way for the browser to communicate with all of them at once! It fixes almost everything, and drastically reduces the number of requests that need to happen on the page.

This looks almost identical to the process we outlined earlier – so why didn’t we always do this? The truth is, it’s only very recently that ad exchanges have thought of what they do as “bidding,” when in reality this is the process that they’ve been engaged in within the publisher adserver for a very long time (just in a very inefficient way). The inefficiency helped some companies, there might’ve been one or two IPOs that you saw based on their dominance in the “first” slot in the waterfall, and hurt others, like tier 2 players who would always end up later in the process with less desirable impressions.

Header Bidding, however, makes this possible because it holds an auction within the browser (or client) using Javascript – Javascript being a specific coding language that’s allowed to execute within the browser (or client-side). This is a lovely explanation of header bidding – but how does server to server play into this?

Server to Server header bidding is the notion of moving this currently client side (or in the browser) auction into somebody’s servers. If you look on the right side of the diagram, the decisioning mechanism that every ad exchange or ad server uses is a “server.” What’s actually happening in online advertising monetization is the following :

The lifecycle of an ad impression involves a number of Server to Server requests to DSPs, who bid on the inventory and then purchase it. A little (or not so little) known secret in the industry is that every exchange works with the same DSPs. This means that all of the efficiency that header bidding has provided has come from inefficiencies in this server to server infrastructure – throttling, cookie syncing, communication inefficiencies, have all created additional yield for publisher at great cost to the DSPs.

So DSPs are pissed. And they’re going to remain pissed, because the server to server requests they’re getting are probably 80% duplicates. But some people are advocating making this inefficiency worse by transforming the landscape into this :

The above looks like a mess – Because it IS. The top is the original header bidding request, a client side request triggering an advertising auction to that ad exchanges server to server partners, however the bottom two are “server to server” header bidding requests. They look exactly like the top request because a server to server header bidding request is really a server to server arbitrage – we’ve moved the bidding process out of the client into another ad exchange’s servers.

So now, instead of having direct access to the client, we’re using the same protocol to have the “server to server header bidding” ad exchange quite literally duplicate impression requests to the same DSPs.

This is the beginning of the end for ad exchanges who get moved off the page – as they’re literally adding no value to the transaction, they exist solely for the purpose of increasing strain on DSPs and trying to take advantage of their algorithms. It also means that the ad exchange hosting the server to server header bidding has a huge advantage – if it’s exclusive – which they almost never are.

This is the beginning of the end for ad exchanges.

The net-net result here is going to be a bunch of exchanges holding server to server header bidding auctions, and I would predict a tenfold increase in the “number of impressions” traded in the programmatic ecosystem as a result of this, without any actual new ad inventory