What is Server Side Header Bidding?
Server side header bidding promises to improve latency, scalability, and auction logic issues seen in traditional header bidding by moving communication with exchanges away from the browser and into servers. The process is essentially the same way SSPs and DSPs integrated for years, except this time the SSPs are integrating with each other.
In my view, server side header bidding has been slow to see adoption for a few reasons but is poised to take off in 2017.
Publishers Will Demand It
Most publishers saw big increases in programmatic revenues over the past year by moving to a header bidding setup. But those gains were as much driven by adding new partners as they were by header bidding tech itself. The more partners publishers worked with, the more unique demand they were able to capture. Now, however, many publishers are starting to run into technical limits on the browser side which prevent them from adding new companies in the header.
This limit is the maximum concurrent connections a browser is designed to handle at once. Chrome for example will only make six requests per host and ten overall before it waits to issue new requests. Basically the browser renders the page in batches of ten requests at a time, so it doesn’t matter if you put fifteen header bidders in an asynchronous wrapper if the browser can only call ten at once. So for publishers, server side header bidding looks like a great solution to add as many partners as they like without having to worry about paying a price on user experience.
Technology Providers Won’t Have a Choice
To date, header bidding has been a fantastic catalyst on the sales side for technology providers. They no longer had to outperform their entrenched competition at a publisher or maneuver for waterfall position. Any fill was incremental fill in a header bidding world, and publishers were eager to add new demand to their networks. Similar to the publisher predicament however, because most customers have already filled their available positions in the header, technology providers are back to having to earn their relationship. Vendors want to go back to a world where they can still sell their services as “no cost” to the publisher and they can have it through a server side point of entry.
Finally, there are some publishers who have been sitting on the sidelines with header bidding because they see it as a a fundamentally inefficient concept. These could be big, brand name publishers who run advertising as a side business. Think big e-Commerce players who are laser focused on how pageload impacts checkout rate. Those media companies are the last whales left for many of the technology providers, and a server side approach puts them back in play for sales organizations.
How Server Side Header Bidding Works for Publishers
On the ad server side, there’s really no change; publishers can decide to setup one set of line items across all partners, or a set of line items per partner. However, because there are often hundreds to thousands of line items required per partner and as mentioned before, a key benefit with server side header bidding is being able to add many more partners, it’s more likely for publishers to pick the former option and consolidate the ad server setup into a single set.
How Server Side Header Bidding Works for Exchanges
The real difference is on the exchange side, especially for the exchange that has the ‘tag-on-page’ position and is the platform that calls out to all other platforms server side. This might seem confusing, but with server side header bidding, at least one platform has to keep a traditional or client side setup with the publisher. Only AdX maintains a 100% server side connection with the ad server, though it does offer 3rd party exchanges a degree of server side access through its Exchange Bidding Dynamic Allocation (EBDA) product.
For the server with tag on page however, they also need to manage integrations with all other SSPs the publisher wants bidding on their inventory. This integration works much like the OpenRTB integration between SSPs and DSPs in that bidders (whether they are DSPs or server side SSPs) submit their true bid and not the close price of their auction. This allows the tag on page exchange to run a true, unified auction across all server side connections on behalf of the publisher.
Why a Unified Auction Matters
One of the key benefits to header bidding is that it allows publishers access to more demand; the problem is that with the traditional header bidding setup, the demand remains fragmented in each exchange. This creates weird scenarios where the highest bid doesn’t always win the auction. Take the example below:
Here, Exchange A has bids of $5.00 and $1.50, while Exchange B has bids of $3.00 and $2.50. If they both conduct a 2nd price auction, Exchange A will submit a winning price of $1.51 to the publisher, while Exchange B will submit a winning price of $2.51 to the publisher. Exchange B wins because it had a better second bid. This is exactly what happens today in the header bidder setups most publishers are using.
So more good news for publishers is that server side header bidding has the potential to improve revenues with the exact same partners already in place simply through this unified auction. It’s the same impact traditional header bidding had on AdX exchange by exchange; now those gains can happen collectively and across any exchange.
So Does Server Side Header Bidding Reduce Latency?
The answer here is yes, absolutely it does – but where you really see the gains is on the scalability side. These things are intertwined; header bidding isn’t scalable beyond six to eight partners because of the browser’s concurrent connection limit, and the problem that limit creates is latency. The server side approach essentially creates unlimited scalability without any price on latency. Not only can you reduce the latency you have now, but you can add as many partners as you want server side without worrying about impacting pageload again.
About Those Cookies, Though
Sadly, server side header bidding is not all good news. The biggest downside to this new technology is that it has the potential to harm monetization through poor cookie match rates. This happens because the SSPs that move from a client side setup to a server side setup lose access to the end user and can’t assign or read their cookie any longer. With traditional header bidding every user calls every exchange on every page, which might be lousy from a latency perspective but is fantastic from a user sync perspective. Each exchange can constantly and directly identify each user’s anonymous cookie.
When exchanges move to server side they have to identify each user by keeping their cookie in sync with the tag on page exchange’s cookie. This adds a middle man to the equation and makes the server side exchanges entirely dependent on the tag on page exchange syncing with them often. An unsynced users is the same as a cookie-less user, and often worthless to an exchange. There’s no data attached to the user, so bidders can’t value it at much more than a blind prospect, which isn’t worth much. Unsynced users are likely to get extremely low bids or no bid at all, so the impact is significant.
How much worse sync rates are server side vs. client side is hard to say, because it depends on who the two parties are. But, safe to say that the larger the exchange, the better their sync rate is likely to be with every platform, so publishers would be wise to anoint a major SSP to their tag on page position vs. a smaller platform.
As you can probably guess, the tag on page SSP has some major advantages over the server side SSPs. Because their code sits on the publisher’s site, they have a much stickier relationship with the end customer, not to mention they’re the only platform that maintains access to the end user (and their cookie), so they’re likely to monetize better.
Speaking of monetization, because of the cookie sync issue it’s not clear to me if server side header bidding will actually make publishers more money than traditional header bidding. Sure you can add more partners and save on latency, but those increases may not pay for the losses incurred by fewer data-rich users. I would not take it as a guaranteed that server side header bidding will make publishers more money, as much as SSPs might decide to position it that way.
In my view, the bigger strategic impact of server to server header bidding is a continued push toward total commoditization of supply and what the buy side reaction to that could be. In contrast to the waterfall where DSPs had to listen to all SSPs because they all had access to different inventory, header bidding has shifted the industry to a world where every platform has access to all supply. That makes the exchanges less distinctive and less valuable to DSPs. This duplicative supply burdens DSPs without providing any incremental value and that can’t last forever.
If buyers start pulling demand from smaller platforms and consolidating onto large marketplaces though, it’ll eliminate the need for so many partners in the first place.