Header Bidding

Better Monetisation with Header Bidding

Increase ad revenue by simultaneously collecting multiple bids from a variety of demand sources each time a new impression is available

Header Bidding

Server-Side Header Bidding: Everything You Need to Know

Before getting into server-to-server header bidding (here on out referred to as S2S header bidding), let’s quickly talk about its predecessor: Client-side header bidding.

Client-side header bidding is a revenue optimization technology that many publishers have adopted to get around the problems associated with the traditional RTB waterfall set up.

By opening up the ad inventory for multiple demand partners to bid on simultaneously, header bidding promotes greater transparency, reduces latency, and therefore increases ad revenue for publishers.

Want to know more about Header Bidding? Click here

Adoption over the last two years has been strong, with over 70% of top publishers using client-side header bidding to monetize their websites, as reported by BI Intelligence. The same report also states that publishers who implement client-side header bidding witness an average revenue uplift of 20 to 30%, a figure that can really add up to a lot of money.

This is all great, and even though client-side header bidding has claimed its rightful place in the ad tech ecosystem, it is bogged down with technical bottlenecks that make it difficult to implement and scale, thereby still keeping some publishers wary of it.

The Problems with Client-Side Header Bidding

Or why client-side header bidding isn’t the holy grail of revenue optimization

> Browser request limitations

Header bidding in its original form is a client-side technology, which means that all the request calls needed to facilitate the ad auction are sent from and received by the user’s browser—which is why it’s called header bidding—the code resides and is executed within the header of the web page rendered on the browser.

This becomes a problem because browsers have a limit on how many calls they can send and receive concurrently. For instance, Chrome will only make six requests per host and ten overall before it waits to issue new requests.

This puts a theoretical limit on how fast the auction can be executed, regardless of how many demand partners you add into the mix; after a certain number, diminishing returns kick in.

> High ad and page latency

Latency in client-side header bidding comes in many shapes and forms, given, it’s a significant improvement over the RTB waterfall set up—but latency still exists in enough measure to become a point of concern for developers, exchanges, and publishers.

Sure, adding more demand partners increases the bid competition and therefore revenue (up to 10% per additional partner), but that is offset by performance issues—not only is the page heavier because of the extra header tags, each tag means an additional request that has to compete with page content for bandwidth.

The other factor that increases latency is network speed of the connection that the user is requesting the page from, on a slower connection (such as 2G on mobile), the problem is compounded.

> Limiting response times

Demand partners have varying response times, and since the auction cannot be completed before all the bids are collected, the networks that is the slowest to respond decides the final time taken to complete the auction and serve the impression.

What if one network is taking a disproportionate amount of time? Such an incident could hold your entire ad operation hostage to the slowest network. The workaround is to configure timeout requests that don’t wait on networks to respond beyond a cutoff. These parameters have to be carefully configured for optimal results, making the setup complex.

> Auction discrepancies

They way client-side header bidding is set up introduces discrepancies in how the bids are selected, making the end result less than optimal both for the publishers, who lose money, and ad exchanges, who lose the bid despite being willing to pay a higher amount.

The reason this happens is because client-side header bidding only executes a second price auction due to technical and speed constraints, which means exchange B will lose the bid to exchange A even if it places a greater first bid—this problem is solved by a unified auction in S2S bidding.

> Negative UX impact

Although this point is interlinked with a couple of points above, it deserves a mention simply because of its relative familiarity and importance to publishers. While considering any new tech implementation, rather than think about “response times” and “latency”, most publishers would simply choose to say that, “It’s a bad move for our user experience.”

It’s the same thing, just a simpler way to say it. Since the code for Header Bidding resides on the user’s browser, it increases page load times, and the incremental increase in revenue that client-side header bidding promises is simply too much of a trade off for big publishers who track page load speeds in milliseconds with a laser-like focus on reducing bounce rates.

How S2S Header Bidding Works

What has changed?

S2S header bidding works in pretty much the same way as client-side except for one change: Instead of the user’s browser, the auction now happens outside on a server provided by a technology partner.

Only one code needs to be inserted in the header now to communicate with the server instead of one code for every demand partner. This small change makes a big difference, let’s see how in the next section.

Note: Our technology team has built an agile S2S header bidding solution from scratch, email us at hb@adpushup.com if you would like to know more about how we can help you implement client-side header bidding and S2S Header Bidding.

See if you can go for hybrid header bidding rather than choosing between client-side and server-side:

The Case for S2S Header Bidding

Or what makes it the next evolution of header bidding

Early adopters are getting good results with S2S header bidding, Media group Purch is working with multiple partners on server-to-server connections and has witnessed its latency reduced by almost half a second.

What’s great about header bidding is that it adds more demand sources and competition. What’s not good about it is that the entire process takes place on the user’s browser. Moving server-to-server, we get rid of all that back-and-forth on the client side and remove a lot of clutter and latency from the user’s page.

John Potter, CTO, Purch

> Faster ad and page loading

Since the code hosting, execution, and heavy lifting of the auction has now been outsourced to a technology partner instead of the header of your own website, the page is lighter, and both ads and content load faster. The page now only has one code in the header as opposed to one for each demand partner, this eliminates a lot of network speed related dependencies including the connection that the user is accessing the page from. Server-to-server connections between SSPs and DSPs also ensure a relatively faster response time.

To put it simply, S2S header bidding improves user experience significantly, a big point of consideration for publishers.

> A fairer auction

Remember how we talked about how second price auctions associated with client-side header bidding create suboptimal auction scenarios for both publishers and ad exchanges?

S2S header bidding solves that problem by being able to view and consider all bids submitted by all participating demand partners, and then conducting a unified auction, which means that the auction is more fair to all concerned parties and no one gets shortchanged.

With the auction inefficiencies gone, both publishers and exchanges will feel more secure switching from client-side to S2S header bidding.

> It’s the next step

When client-side header bidding replaced the RTB waterfall set up in ad stacks, it was a bit of a revolution, the way auctions were being conducted was in a sense reinvented—each ad impression was now being sold at its best possible value by receiving and comparing bids simultaneously in real time.

While S2S header bidding is not exactly that big a leap, it’s an important step towards removing some of the inherent latency issues of client-side header bidding while making the auctions fairer. Increased tech integration and communication between SSPs and DSPs also means that eventually ad inventory will stop existing in individual pockets and instead float in one central pool, the long term implications of this are unknown but it’s a step towards uniform commoditisation of supply, something that has so far known to be highly fragmented in the ad tech ecosystem.

Sound Great, So What’s the Catch?

Isn’t there always?

Well, these are still early days for S2S Header Bidding, most analysts and publishers believe that it will take another 12-18 months for it to really start seeing representation in the average ad stack.

In the meantime, most publishers will probably continue to use a mix of multiple ad technologies including S2S header bidding, client-side header bidding, and even the RTB waterfall, which is still being used by many to sell remnant ad inventory.

While more publishers continue to adopt server-to-server connections, few go all in. With server-side bidding in its infancy, publishers use a mixed model because they’re still working out server-to-server kinks, some agreements stipulate that the bidding partners’ code remain on page and vendors refuse to integrate with other companies’ technology.

Ross Benes, Platform Reporter, Digiday

Besides, even though S2S is a huge improvement over client-side, it introduces a couple of new problems that could undermine its effectiveness.

First, in case of client-side header bidding, publishers have free and complete access to auction data because the transactions are happening on their website, in case of S2S header bidding, transparency could become a problem unless the technology partner is willing to share the data openly.

Another problem could be related to a possible decrease in the contextualisation of ads due to lower cookie match rates, this happens because the direct link of communication between the publishers and advertiser is broken by a third-party technology partner.

The biggest issue is that server-to-server header bidding decreases publishers’ cookie match rate. Since client-side publishers communicate directly with their exchange partners, they’re able to match cookies for just about every user they see, allowing advertisers to identify the human beings they’re paying to reach. But since server-side integrations put an intermediary in the middle, this cookie match rate falls to around 70%. And because cookie-less impressions are basically worthless to advertisers, publishers who adopt server-to-server setups risk seeing a decrease in both the number of bids they receive and the CPMs advertisers are willing to pay.

via AppNexus Blog

To sum up, while it’s hard for anyone to conclusively say how greatly S2S header bidding will work for publishers or how fast it will be adopted, given all the improvements it provides over the existing technology, it’s worth experimenting with in your ad stack.

AdPushup’s Header Bidding Solution

Merely deploying header bidding in your ad stack isn’t enough. Consistently optimizing it with technical improvements is the need of the hour. This is what AdPushup’s header bidding solution does. Through our multiple optimization features using data science and machine learning, we help publishers maximize their yield. 

With our header bidding solution, you get: 

  • Automatic demand partner selection according to optimum requirements
  • Smart timeout management
  • Freedom to bring your own demand
  • Bid monitoring and discrepancy resolution 

Read more about our product capability: Header Bidding