In a previous blog, I shared the top three ways publishers can get the most out of their header bidder. These tips highlighted the importance of working with a partner with the lowest response times and timeout rates, has direct access to demand, and can represent your supply. In this blog, I want to focus on the first – speed and efficiency – and introduce the rationale for server-to-server header bidding.
Before diving into what server-to-server header bidding is, let’s review how traditional header bidding works. For most publishers, the auction in header bidding happens in the client (browser). Bids are requested concurrently from demand partners (bidders). Since the browser limits the number of simultaneous concurrent tasks, it limits the number of bidders that can be added to the auction. It looks like this:
So how can a publisher increase speed and efficiency with their header bidder? That’s where server-to-server header bidding comes in. Moving the auction to the server-side involves keeping only one partner in the client and allowing this partner to conduct the auction via its server. This server requests bids from other partners’ servers (partners that would traditionally have been on the client) and conducts an upfront tier 1 auction. This server-to-server communication gets past client (browser) side limitations mentioned earlier. This, in turn, reduces latency and allows for making calls to many-many other partners eventually enhancing user experience and increasing yield. It looks like this:
Paraphrasing my previous blog entry, latency affects the user experience. Whoever you partner with on a server-to-server header bidding solution should have the lowest response times and timeout rates. Remember - a partner that controls their own infrastructure and has direct peering connections (through an autonomous system number) into their demand sources, while rarer, is optimal.
What server-to-server header bidding is not
Server-to-server header bidding can be confused with server-to-server integration. For example, a publisher may want to make an API call from their server to a demand partner’s server (instead of using tags). This removes the disadvantages associated with tags and brings in the generic benefits of server-side communication. While this can improve speed and efficiency, there isn’t necessarily a competitive auction being conducted – which can limit revenue and yield. It is important to remember the philosophy behind header bidding and understand that while this is a server-to-server integration, it is not server-to-server header bidding. It’s just a programmatic integration with a single partner. True server-to-server header bidding, like client side header bidding, provides for a competitive auction amongst multiple demand partners and maximum revenue opportunity for a publisher.