Header Bidding: a Rapid Evolution with its Own Downsides

In the coming months, we will see a shift from browser-side to server-side header bidding. Why? What are the differences between them, and what are the disadvantages of the server-side method? Grzegorz Kubrakiewicz, Head of Technology at Yieldbird, answers these and other questions.

The past few months have seen some pretty intensive development and new innovations in the adtech industry. What was most important in your opinion?

Well, header bidding was definitely a buzzword for 2016. This kind of technology has just boomed, and we saw a number of publishers who changed their method of providing demand for their ad slots by replacing their waterfalls with header bidding. That was something very characteristic of 2016.

Could you briefly explain how header bidding works? Just to make sure we’re all on the same page.

Header bidding is a successor of waterfalling. Waterfalling fills ad units on a website using a sequence model, which helps to raise CPM and fill rate. As a result, the publisher earns more, but the technique also sees publishers losing a number of ad impressions thanks to increased latency when loading the webpage or advertisement.

Then came header bidding. The difference here is that header bidding sends requests to multiple SSP at the same time. That minimizes the negative impact on user experience (latency) but preserves the advantages of water falling, namely collaboration with multiple SSPs.

This comes along with a trend of making advertising more user-friendly.

In fact, I would rephrase it: this is a way to protect online publishers against driving their users away. The users are accustomed to getting free content, as digital publishing still largely operates on a no-cost basis. Advertising is the leading way to both earn revenue and maintain the quality of the publications. Naturally, users would prefer to have the same content without any ads, but in that case, the entire system would collapse.

Thus, there is an always-evolving balance to be struck between users’ and publishers’ needs. When this balance favors publishers, it will soon shift in the user’s direction. If publishers apply new solutions, it may affect UX, potentially leading the audience to either choose different media outlets or install an adblocker.

The adtech industry, of course, tries to minimize the negative elements of this business model, which explains the rising popularity of header bidding.

So does this mean that header bidding will be even more user-friendly in the coming months?

Definitely! Though keep in mind that header bidding is not a cure-all. A huge amount of work is being dedicated to improving latency and shortening page-loading times, and header bidding is a way to achieve this. The technology continues to improve, and will soon be applicable to other formats, such as video advertising.

So far there have been very limited opportunities to bid on video ads, but this is changing as we speak. I’m sure in the next couple of months we will see a big rise in header bidding’s popularity among publishers and advertisers, but we will continue to face issues with latency.

As with everything, there are pros and cons to header bidding. How long until it’s once again replaced by something new?

It’s a common belief in the adtech industry that within a year there will be no header bidding as we know it now, but rather there will be server-side header bidding.

This works in a similar way to browser-side header bidding (also known as client-side header bidding), but there is one significant difference: in server-side header bidding, calls to the various SSPs are sent from an ad server, not from a webpage.

This means that there is only one call sent from a webpage, and all other calls to SSPs and the bidding itself is held on an external server, from which an ad is sent back to the website. This is why server-side header bidding is also called server-to-server header bidding. Consider the following, very simplified model:

So where are the downsides?

Browser-side header bidding is a ‘democratic’ solution. It depends on a webpage set up in which the demand partner receives a call, and nobody gets more information than each other (unless a publisher who owns a website decides differently).

In server-to-server header bidding, the main partner (ad server) gets all the information, and the others (SSP) get only what the main partner will deliver. This means that major players can reinforce their superior position. Some companies cooperate with one another, like AppNexus with Index Exchange, by cross-sharing their log-level data. But right now it’s not clear how this may (or may not) bolster their market position.

Will this solution help to fight against malware in advertising?

It should. Generally speaking, server-to-server solutions help to keep the ecosystem hygienic. With browser-side header bidding, there are more contact points that are ‘unguarded’, and the bidding takes place in a client’s browser which is much harder to control. The advertising framework operates on a user’s computer we know little about, which opens the door to abuses. With a server-side solution, the risk is reduced.

Who provides the server-side technology?

It’s no secret that most main players are in-game: Google, AppNexus, Index Exchange, Rubicon Project – all of them are working on solutions. But so are retail companies such as Amazon or Target.com., and There is much at stake.

It’s probably still too early to give precise recommendations, but what should publishers remember when choosing server-side header bidding?

As you said, it’s still a bit early to get into too many details. Still, publishers should be keeping their fingers on the pulse – the server-to-server solution will become mainstream very fast. They should get a good advisor who is familiar with technologies from various providers. Otherwise, they run the risk of buying a black box – in some markets, it may be an excellent thing, while in others not at all. The goal for publishers is clear: adjust technology to suit your business needs and choose a solution that supports your requirements.