Server Side Header Bidding Explained

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.

You can see the difference in process in the diagrams below.  Traditional Header Bidding

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

Server side header bidding works essentially the same way as regular header bidding from the publisher perspective, there’s just less implementation work to do.  A publisher still has to put some JavaScript code in their header in order to trigger a request to an exchange before their ad call, but instead of one script per partner, there’s just one script overall that’s needed.

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.

Non Unified Auction Header BiddingThis result is great for Exchange B, OK for the publisher, and bad for the $5.00 bidder.  Obviously the ideal the $5.00 bidder in Exchange A would win the impression, since they were the highest bidder, and pay $3.01, using Exchange B’s bid in the same, unified auction.  Server side header bidding enables this ideal scenario because there is a central platform (vs. just a static JavaScript wrapper) that can see all bids, handle the auction logic, and notify winners of their price paid.  Each exchange is already built to do this within its own system with DSP bids, and other SSP bids aren’t any different.

Unified Auction Header Bidding

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.

Strategic Outlook

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.

13 comments

  1. Thanks Keith; I had a daughter in 2016 which soaked all my time. Still a struggle to get writing done but a bit trying to make it a focus this year!

  2. Who currently offers the server side solutions in the marketplace? When will Google come out of beta?

    Can a tag manager add any value here? I’ve had an SSP demand to have tag on page, but the payback just isn’t there. I see 2017 as the year where publishers get better leverage with the SSP’s forcing either server to server integration or being put into a wrapper.

  3. Interesting point about less data-enriched decisions through lack of cookie sync. Do you think this might prompt publishers to downgrade header bidding to remnant inventory only?

  4. Hm, no I don’t think publishers will do that. Rather, I think it’s more likely for publishers to keep a mix of client side and server side connections, or for exchanges to design a solution to the cookie sync issue, though I’m not sure what that would be right now.

  5. I think pretty much all the exchanges probably have some kind of alpha / closed beta version of S2S header bidding available right now if you were to ask. OpenX, Sovrn, Google and Amazon have publicly announced server side products, and I think other announcements will happen this Q.

    The tag manager question is an interesting one. In many ways a header bidding wrapper is essentially a specialized tag manager so you’d think it would be a natural tech to service header bidding, but wrappers have some additional logic built into it to parse and normalize the responses from each bidder. So for that reason I’m not sure a tag manager can do much out of the box though I won’t claim to be an expert on that tech, so you might have some options.

    Completely agree that publishers will have some major leverage on SSPs this year as they decide who gets tag on page position (wrapper) or goes into the server side. It could really punish some of the smaller players out there who don’t have the fill / response rates to justify a client side connection.

  6. Hi Ben

    Thanks for sharing yet another insightful article on header bidding. Since the winner in this race would be those can bring demand AND controls the most user data (cookie, mobile advertising ID), it seems it would make sense for major agency trading desk say Xaxis to develop server-side header bidding on their own?

    On the other hand though tag management or even DMP might seem to be the perfect middleman yet it would be too high an investment to build out other components to facilitate the auction.

  7. Hi Siyun,

    I can see why you’d think this, but for a variety of reasons I think both buy side tech and DMPs are poorly positioned to build server side wrappers and publishers would be hesitant to adopt any solution they might build.

    The simplest explanation is both of those types of companies would essentially have to build tech that the SSPs already have. It has to integrate with all demand partners / bidders on behalf of a publisher, it has to run auction logic, it has to send win notifications, it has to bill, and so forth. The SSPs have already done the publisher development work, have the implementations largely in place, it’s a major investment for DSPs / DMPs to do this work.

    Doesn’t mean it couldn’t happen, but doesn’t seem like a wise investment for these companies to make in my view.

  8. Hi Ben,

    Very solid points. One more question.

    Another major difference between client-side and server-side header bidding is transparency. While the auction is happening in browser, publishers will have birds-eye view and control over bid price, though there are latency concern. Now the auction moves back to SSP side and it becomes a black-box again. I am sure publishers will get some tools, even sophisticated reporting, to help optimize yield. However, unless they can access bid stream data and have a team of data analyst to monitor and analyze performance, if would be difficult to set the optimal floor price. The trust and transparency issue remain.

  9. Perhaps; my guess is wrappers will continue to allow publishers to pass all prices on a per partner basis into the ad server with a server side approach just as they do (at least prebid.js) today. That would take some of the black box element out of it, but yes you’d still need someone to sit down and do the analysis. I’m not sure you need someone who can do LLD analysis, that’s not really possible today just from data you get from the wrapper.

  10. Thanks. Ben. Yup, agree publishers, big or small, need to do some experiment and testing to find out which is the best for them and when to compromise.

Leave a Reply

Your email address will not be published. Required fields are marked *