Real-Time Real Talk

Real-Time Real-Talk: Server-to-Server Header Bidding

Blog Post
The AppNexus Team

Check out our free guide to get our full breakdown on server-to-server versus client-side header bidding and find out which one makes sense for you! 

“Real-Time Real Talk” is an ongoing blog series that seeks to clarify the “what”, “why”, and “how” behind ad-tech innovations.

In 2016, few topics of conversation generated more buzz in the ad-tech world than the one surrounding header bidding. In 12 months, the publisher monetization tool went from relative obscurity to a popular solution that everyone in our industry was expected to understand.

Alas, just when you think you’ve finally learned enough about a new technology to discuss it confidently, ad-tech delivers yet another innovation to wrap your head around. In this case, the latest phrase on everyone’s lips is “server-to-server header bidding,” a tool some people believe could be the future of sell-side technology.

Ready to learn more? You’ve come to the right place.


Okay, so what is “server-to-server” header bidding?

Server-to-server header bidding is a technical fix that allows publishers to include a greater number of demand partners in their header bidding auctions -- without damaging the user experience. Like traditional, “client-side” header bidding, server-to-server tools help publishers sell their inventory to the highest bidder by allowing multiple ad exchanges to bid on an impression simultaneously. The difference between server-to-server and client-side setups lies in where the header bidding auction takes place.

As you might recall, the client-side auction happens in the header of a publisher’s web page. In order to execute the auction, publishers send ad calls back and forth between the user’s browser window and each of the participating demand partners. As a result, the publisher creates an additional burden on the user’s browser with every new partner it adds to the client-side auction. The problem with this is that browsers weren’t designed to make so many simultaneous calls, so the extra burden in contacting so many demand partners slows down how quickly the web page loads for the users. If a publisher includes more than six or seven exchanges in its client-side header bidding setup, the auction will drive readers away with long load times and a terrible user experience.

In a server-to-server setup, the publisher page sends a single ad call to a high-powered server created by a third-party technology vendor. From there, the server calls all the different exchange partners itself, taking the load off the user’s browser. With the right technology partner, publishers can add up to 200 exchanges to the auction without increasing latency.

So it’s basically a better version of regular header bidding?

Well, not quite. Server-to-server header bidding is far from perfect, and its flaws might prevent it from ever achieving the popularity that today’s client-side tools enjoy.

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.

In addition, server-to-server header bidding is much less transparent than its client-side counterpart. In client-side header bidding, publishers have complete insight into their auction mechanics, since the ad calls are made by a piece of open-source javascript inside the header of their own webpages. But in a server-to-server integration, all of this takes place inside a black box owned by a third party. Without the transparency of the client-side, publishers have no way of knowing whether their technology vendors are taking an unfair cut of their ad revenues or prioritizing certain demand sources over others.

Wait, so all this fuss is over something that might not even be as good as what we had before?

Truthfully, the jury is still out. With the exception of Amazon, the only companies offering server-to-server header bidding right now are smaller players working with experimental publishers. Over the next 6-12 months, publishers will have to decide for themselves whether server-to-server is worth implementing, as well as how many demand partners it makes sense to move from the client-side auction. And each publisher business is different. Server-to-server logic has been around for a while.  Depending on a publisher’s business needs, some prefer client-side solutions, while others prefer server-side solutions.  For example, mobile publishers are often quick adopters of server-side technologies since they often reduce the number of Software Development Kits (SDKs) to implement and internet bandwidth is more important on a mobile device

While it’s early days for server-to-server header bidding, one thing is for sure: we at AppNexus are committed to staying ahead of the market with our header bidding solutions, and educating our customers on all of the latest developments in monetization technology. We’ll be following this trend closely throughout the year, reporting back to you whenever we’ve learned something new. And if you’d like more information about server-to-server right now, please don’t hesitate to reach out to your AppNexus representative.


Want to learn more about whether server-to-server header bidding makes sense for your business? Download our guide here.