Since client-side header bidding emerged, publishers have often had to decide between monetization and user experience. Adding more partners to their wrappers meant improved monetization but could result in increased latency as additional connections were needed to solicit bids from those additional SSP partners. Thankfully, client-side isn’t the only option. Server-to-server (S2S) header bidding means publishers no longer need to trade-off between monetization and user experience.
With S2S header bidding, the browser makes one connection to a header bidding server which then makes connections to all the SSPs the publisher is working with. It gets the bids and then sends them back to the browser. Because the connections are from one server to another, additional partners do not slow the browser down with additional connections. Faster page loads mean higher ad viewability, increasing yield.
S2S header bidding has generated a great deal of enthusiasm across the industry given its benefits. However, a couple of issues have slowed S2S adoption. Here are a few of the industry concerns:
Cookie Match
The biggest concern publishers have about S2S header bidding in the web environment is how much their cookie match rate will decline. This in turn fuels their fears about the corresponding decline in monetization.
With client-side header bidding, connections to SSPs go straight from the browser to the SSP so the SSP’s user id cookies are included in the requests. With S2S header bidding, the browser does not send the SSP cookies since the header bidding server and the SSPs are in different domains.
For the header bidding server to get access to the SSP cookies, a cookie sync needs to be done between the header bidding server and each SSP. This extra hop means the server-to-server cookie match rates are slightly lower than the client-side cookie match rate.
However, as S2S header bidding becomes more widely adopted cookie match rates will improve. When multiple publishers use the same S2S header bidding service, the cookie match rises because visits to any participating site will trigger a cookie sync with that header bidder service.
Server Infrastructure Needed
A key difference between client-side header bidding and server-to-server header bidding is the need for server infrastructure. With client-side header bidding, all a publisher needs to do is include the wrapper code in its web pages. No header-bidding-specific server infrastructure is required. Conversely, with S2S header bidding, publishers need a header bidding server.
At PubMatic, we are proponents of open source header bidding technologies since they provide transparency to all parties as well as increase access to demand. Using open source wrapper code does not mean a publisher needs to take responsibility for running its own server infrastructure.
Multiple vendors provide hosted header bidding services using Prebid Server. PubMatic, for example, provides a hosted S2S service as part of our OpenWrap offering, which is built on Prebid Server.
Emerging Channels Driving Adoption
The benefits of S2S header bidder will drive wider adoption. However, expect two emerging header bidding channels to accelerate S2S adoption over the next months: Accelerated Mobile Pages (AMP) and mobile in-app. With AMP, changes made in November 2017 removed the ability to use client-side JavaScript with the DoubleClick for Publishers (DFP) ad server. This has left S2S as the only header bidding option for publishers with AMP pages.
For mobile in-app, many of the leading header bidding solutions, including Prebid Mobile and OpenWrap In-App, are S2S only. Without S2S, in-app header bidding means getting bids directly in the app, which usually means running an SDK for every bidder. This adds bulk to the app and introduces stability risks.
S2S header bidding is extremely well suited for in-app advertising as it gives publishers the ability to add or remove demand partners without releasing new versions of the app. Additionally, because apps use advertising IDs, rather than cookies, to identify users, the cookie-match issue does not impact monetization.
New Options
At the beginning of April 2018, Google announced general availability of its Exchange Bidding offering. Google’s Exchange Bidding offers publishers using DFP an easy-to-implement header bidding alternative. However, as a proprietary closed-source header bidding solutions, Exchange Bidding is a black box and offers fewer demand partners than open-source solutions.
S2S header bidding adoption will keep rising. According to ServerBid’s Header Bidding Index (HBIX), the percentage of header bidding sites using S2S for at least some of their monetization rose to 42 percent in May 2018 from 28 percent in September 2017. Over the course of 2018, we can expect S2S adoption to continue to rise both as it improves latency and as S2S mobile header bidding channels gain traction.
PubMatic’s Solution
When choosing a vendor for S2S header bidding, there are a few factors publishers need to consider. For instance, publishers need to evaluate how difficult it might be to add new demand partners. It is also important to consider the ease of configuration. Shifting from client-side to server-side, and back again, allows publishers to experiment and find the optimal configuration for their monetization and user-experience needs. Another key factor is the level of analytics the vendor provides for monitoring and optimizing S2S header bidding setups. The richer the analytics, the better the publisher can optimize monetization.
Many publishers will find a hybrid solution—with a few partners running client-side to maximize match rate and additional partners running server-side—works best.
To learn more about S2S header bidding, check out our solutions page or reach out.
