“It was always a bit too hard to tell which bids I should accept, that’s why I moved to Header Bidding!”
Header bidding was, in many ways, an inevitable step forward for the online advertising industry.
So long as a single Server-Side Platforms can’t provide access to the totality of potential Demand sources, publishers were going to want to work with several at once.
“Waterfall,” then Client-Side Header Bidding, and now Server-Side Header Bidding are all strategies conceived to improve efficiency and maximize a publisher’s potential revenue.
In this article, we’re going to look at how and why these technologies came about and what their limitations are.
Failure to fill
With the implementation of Real-Time Bidding and the development of Supply-Side Platforms, digital advertising became much more efficient.
Publishers were able to offer unsold ad space to potential buyers on a per-impression basis. In terms of matching the right advertiser to the right impression at the right price, this system was a huge leap forward.
But it wasn’t perfect.
One of the primary issues that publishers faced is that a given SSP couldn’t always fill all requests from a publisher. Sometimes their demand partners (Demand-Side Platforms, Ad Networks, etc.) just weren’t very interested in a given impression.
That is to say that either the SSP had nothing to provide or the winning bid was below the “floor price.” The floor price is the lowest price that a publisher would accept for an impression.
This system could, and often did, lead to requests for ads not being filled, meaning that the publisher missed out on potential revenue.
In order to minimize revenue lost through failure to fill ads, publishers began using the “Waterfall” method.
Waterfall
Before we can start looking at Header Bidding, what it is, and how it works, we need to look at what came first. Before the development of Header Bidding, there was an industry-standard process called “waterfall.”
Waterfall partially solved failure to fill ads by allowing a publisher to make requests to various Service-Side Providers in succession.
When an impression arrived, the publisher would prepare an ad request and sent in to its first supply partner. It would ask the Service-Side Provider to auction off the impression, and it would return its winning bid.
But the publisher had a floor price.
If the SSP couldn’t meet the publisher’s floor price, then the client would move onto a second Service-Side Provider. If the winning bid there didn’t meet the floor price, then it would move onto a third SSP. This process continued until the floor price was met.
This process of moving from one SSP to another in succession is called “waterfall.”
The order by which the publisher’s site would send the impression to SSPs depended primarily on their historical return. The SSPs that generally returned the best winning bid would be asked first. Publishers would manually optimize the chain of SSPs that would be utilized based on their performance.
This game of manual optimization, however, was endless. SSPs were always being reshuffled in the waterfall stack as their bid performance changed over time. So it was never totally efficient.
This is where waterfall’s biggest problem lies. Since it makes requests one at a time, it doesn’t know which is best. Just which met the floor price first.
The SSP that generally had the best winning bid didn’t always have the best winning bid. So the first to meet the floor price wasn’t always the best.
Problems with waterfall
Waterfall is essentially a bunch of requests that occur in a series until a condition, the floor price, is met by the SSPs’ demand sources.
While Real-Time Bidding did significantly increase efficiency in online advertising placement, it was still far from wholly efficient. Total efficiency was impossible because no one SSP had access to every single demand source. Therefore there is always the potential that the best bid is still out there and the publisher just isn’t being connected to it.
This why publishers utilized SSP waterfalling.
Each SSP works with a different range of Ad Networks, Demand-Side Platforms, Ad Exchanges, etc. And therefore the winning bids they return vary. Often considerably.
But since it went through the SSPs one at a time with a set floor price for the fill, there was always the chance that the publisher would miss out on the best price.
Example of waterfalling
Say, for example, that a publisher wanted to fill an impression. The first thing the publisher would do is see if there were direct buys for that ad space.
This is the beginning of the waterfall.
If direct buys didn’t fill all the inventory for that impression, the remaining inventory would flow down to the first SSP partner. From there, it would continue down the waterfall until the floor price is met.
Say the floor price is $2.20.
Maybe the first SSP returns a winning bid of $1.90, the second $2.30. The second would win, and the waterfall would stop there. But what if the third SSP would have returned $4.10?
The second bid was already accepted, even though the offered price wasn’t the highest. It won simply by meeting the floor price first.
This kind of inefficiency could quickly add up over time, costing the publisher a lot of potential revenue.
The natural solution was to make a request to all of a publisher’s partner SSPs and then, only after having looked at all of them, choose a winner.
Header Bidding did just that.
The Browser-Based Bid
Header Bidding was a veritable revolution.
By putting a JavaScript wrapper into the header of a publisher’s HTML page, they gained the ability to call multiple SSPs at once and compare the bids returned on the spot.
Instead of waterfalling down a series of SSPs until a returned bid meets the floor price, the publisher sends a request to all of them at once. Once it receives a response from each, the software then compares all of the offers and chooses the best.
Header Bidding wrappers are also extremely easy to install. Publishers just copy the wrapper into their HTML header and link it to their SSP partners. Then they were ready to go.
They don’t even need to pay for the wrapper since the most popular ones are open source.
This little bit of JavaScript allowed publishers to eliminate the inefficiency of waterfalling. Publishers no longer risked missing out on the best price since they saw them all before accepting.
Sounds great right?
Publishers make more money. Advertisers get the impressions that they want most. It’s win-win… well, except for the end-user.
Latency
The primary issue with Client-Side Header Bidding is that it’s… on the client side. By shifting the work to the client, latency immediately became a major issue.
The advent of Header Bidding a lot more strain was put on the client’s browser. The generation of the ad request, the connection to all partner SSPs, the judging of the responses, and the retrieval of the ad content itself all became dependent on the user’s device.
Between the connection and the workload required, Client-Side Header Bidding could have a substantial effect on page load time since the ads had to be ready before the page could load.
Internet users are fickle when it comes to loading time, and even relatively small increases in page load time can lead to noticeable user loss.
Because of this, publishers had to perform a balancing act. They wanted to connect to as many SSPs as possible to make sure that the winning bid itself was as high as possible.
But at the same time, they didn’t want to increase page load time substantially as that would lead to a loss of users and reduced revenue.
This situation is aggravated because end-users often have an already strained relationship with digital ads.
With the ever-present threat of adblockers, annoying users is one of the last things that publishers and advertisers can risk. Because once a user installs an adblocker, it’s going to block ALL ads, not just the most annoying ones.
So addressing the latency issue was on everyone’s mind almost as soon as Header Bidding was developed.
But this wasn’t the only issue that Header Bidding presented.
Maximum Requests
While the creation of a Client-Side Header Bidding system allowed for simultaneous ad requests and near-instant comparisons, there were still limits (beyond end-user patience).
The primary limitation is that browsers restrict the number of concurrent connections that a tab can make when a page loads.
This means that connections to some SSPs might immediately be nixed if the number of attempted connections goes over the limit. One of the nixed connections to an SSP might have offered the best price if the connection had gone through.
The result of this is potential lost revenue.
Browsers set this maximum number of connections to protect users and also to prevent their browser from being slowed down too much.
Cumbersome Wrapper updating
Though a much smaller problem than latency, Client-Side Header Bidding also brought about another significant inconvenience.
The actual wrapper had to be updated every time the publisher added or removed an SSP partner.
So whenever something changed insofar was who the publisher was working with, he then had to go through and make sure that the headers on all of his properties were updated.
These three issues (browser latency, maximum concurrent connections, and manual wrapper updating) drove publishers to look for another, better solution.
One thing was for sure, though. Header bidding was here to stay. Publishers loved it and the revenue increase that it brought with it.
But these problems had to be solved.
Users had no tolerance for ads slowing down their online experience, and there was still room for improvement insofar as connecting to more SSPs.
The solution to the problems caused by the solution to another problem
The newest iteration of Header Bidding is a massive improvement both for publishers and their end-users.
Server-Side Header Bidding (or Server-to-Server Header Bidding) solves the latency issues and allows Publishers to submit simultaneous ad requests for a single impression to a practically unlimited number of SSPs.
How does this work?
By moving the heavy lifting away from the browser. Serve-Side Header Bidding is exactly that, on the Server Side. That is to say that the actual bidding is no longer occurring on the client’s device.
One of the reasons that Client-Side Header Bidding could be so slow (beyond resource usage on the client’s computer itself) was that all of those different bids and responses to various SSPs had to go through the same internet connection. If that internet connection were slow, then all of those different requests to various servers could substantially increase load time.
With Server-Side Header Bidding, the preparation and sending of the request to various SSPs – as well as the judgment of the winner – all occur on the server.
The server, naturally, has ample processing capacity and access to excellent internet speeds. This allows for the work to be done in a fraction of the time.
From the client’s perspective, the browser sends one request and receives one answer in return; rather than the many requests and answers and sorting that had to be done with Client-Side Header Bidding.
This situation is ideal for both the publisher (who wants to maximize revenue) and the end-user (who wants his content ASAP). It is less than ideal for today’s Supply-Side Platforms because Server-Side Header Bidding pushes SSPs to become increasingly integrated.
Conclusion
Prior to the advent of Client-Side Header Bidding, publishers had little choice but to use the very inefficient “Waterfall” method.
The Client-Side Header Bidding wrapper was itself a huge improvement over the “waterfall” method. But it created several problems for the end-user and still had a maximum number of SSPs that could be utilized.
Server-Side Header Bidding is starting to change that. By moving the bidding process between different SSPs away from the browser, most of these problems were solved.
Now it is just a matter of the industry partially reorganizing around this new technology.
Above all, Header Bidding is yet another step in the march of programmatic progress.
Mobinner is a High-Performance Demand-Side Platform. We drive high-quality Growth and incredible ROAS. Come check out what we can do for you!
