Header bidding has been around for several years already and quickly became a hot topic for publishers, advertisers, and all people ad tech. Today, it is well adopted by the industry, promising fast and fair competition and higher returns. The beginning, however, wasn’t one without flaws, and the technology is still developing. For example, in the early days of header bidding, publishers had to put numerous tags in their headers in order to increase demand, which in turn, led to latency issues. A fix for this issue was quickly discovered with header bidding wrappers. Over time, further innovation brought the trading process to the server itself, whereas in the beginning, it was an in-browser solution only (known as client-side header bidding). In this article, we’ll dig deeper into server-side header bidding, its advantages, and disadvantages.
What is Server-Side Header Bidding?
Also known as server-to-server header bidding, or S2S, server-side header bidding is the latest development in header bidding, which allows the auction to happen at the server, instead of the browser, thus minimizing latency and allowing for increased demand partner capacity.
To better understand the differences between browser- and server-side header bidding, let’s first take a quick look at the browser(client)-side. With this option, advertisers place their bids inside the header of the webpage. A high number of header bidding partners in the auction can mean more delays, thus publishers will often put a cap on demand and end up with somewhat inefficient ad performance. The technology is limited by the slowest bidder in the process, who would determine the overall speed of the auction, and the latency can become a real nuisance to users, if not managed with timeouts.
With S2S the entire bidding process happens at the server (hence the name). The publisher chooses a technology partner who hosts the solution. Instead of having multiple ad requests from the webpage, just one call is sent to the server, which then calls the demand partners, holds the auction, and returns an ad creative without an influence on page load time. Overall, a cleaner and simpler process. However, it comes with its own set of strengths and foibles.
Let’s look at the upsides of server-side header bidding:
- Reduced latency
As there will be a single ad call for each impression by the webpage’s browser, the impact on page load is eliminated. Moving the bidding to the server solves the latency issues of client-side header bidding that come from calling multiple advertising partners. This also makes S2S the right fit for video and rich media products, as they can load faster.
- Unlimited demand partner capacity
Without the latency issue, adding as many header bidding partners to the auction is no longer a problem. Thus, competition can be boosted, resulting in fewer timeouts and better fill rates.
S2S integrations come with some limitations, too. Here’s what can stop you from using server-side header bidding:
- User matching issues
As you know by now, client-side header bidding happens in the browser. This gives advertisers access to the cookies, which in turn allows them to match their ads to the specific user profile and translates to higher rates. Unfortunately, with server-side header bidding, most of this data is lost as cookies need to be matched between servers. The result most often is lower CPM rates.
- Limited transparency and control over the bidding process
With S2S the real-time auction happens at the server and publishers have no access to it. They cannot see which buyers participate in the bidding and the process depends on the partner the publisher has chosen for server-side header bidding. Thus, publishers are left with limited control and depend heavily on the S2S partner’s integrity.
Are client-side and server-side header bidding your only options?
The short answer is no. Ultimately, it is possible to run both client-side and server-side simultaneously and this can be achieved with separate wrappers or hybrid wrappers. That is, however, not a permanent solution as you’re effectively adding twice the load for pretty much the same demand.
Server-side header bidding is a solution that allows the bidding for the publisher’s inventory to happen out of the browser, within a selected server. This takes away the page load, ultimately reducing latency. It allows publishers to increase demand in the auction for their inventory, thus boosting fill rates. However, S2S lacks transparency and more often than not results in cookie loss, driving CPMs down. There is also a hybrid model which allows publishers to utilize both client- and server-side header bidding for their inventory, which however is more of a temporary solution to be tested upon interest.