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. 
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.
This 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.
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.
Very informative. You are a great source of info. I missed you when you went dark for much of 2016.
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!
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.
This is fantastic, really well done. Thank you.
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?
Thanks Jon!
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.
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.
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.
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.
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.
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.
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.
Ben, thanks for another fantastic post on a timely topic that clears up a lot of the fog. Congratulations on the birth of your daughter. Please ask her not to take up so much of your time, so we can learn more from you 🙂
-Yair
Thank you Ben for this insightful work. Very nicely put and makes things clear.
Do you happen to know where can i learn more about the tech specs/ documentation of integrating as a buyer to a server side wrapper?
What are the main obsticles for a buyer to overcome when wanting to start buying on a s2s hb auction?
Are there any s2s providers that have completed beta and provide full access to inventory in this way?
Thanks again !
Do all header bidding wrappers still allow buyers to drop their own first party cookie, or does the wrapper prevent it?
Hello Ben,
First of all, you are doing an amazing job!
I may have a stupid question. Is it required for SSP’s to integrate with other SSP’s to facilitate server side header bidding. From what i understand, in server side header bidding, once the wrappers are called by the user, it redirects to the programmatic auction server (not necessarily an SSP, could be publisher’s server too) which calls multiples SSP’s calling different demand sources. In the diagram given above explaining server side header bidding, the user calls the header to an SSP which calls other SSP’s and each relays the inventory to the demand sources. Is that accurate? What if a publisher like MSN redirects the header tag to their own server instead of an SSP? Is that possible? Please help me understand this.
Thanks,
Mike
Thanks Mike!
To answer your question, yes, SSPs have to cooperate with each other to facilitate S2S header bidding. Basically, the tag on page SSP with access to the client has to integrate with all the other SSPs that want to be able to bid on that inventory server side. It’s a lot like the typical DSP integrations an SSP would perform, since the SSP is submitting a bid and expecting a win notification and price reduction, just like a DSP would.
If a publisher were to host their own auction server – which incidentally I think will be rare and unwise for a variety of reasons, they would essentially act as an SSP and have to perform all the other SSP integrations for server side communication. From a process side, you are right – the user would hit the page, have the code to the tag on page SSP served to them, call that SSP, and then that SSP would call the other server side integrated SSP partners. The tag on page partner would then process all server side bids alongside it’s own bid, and respond back to the user with the result, which would be fed to the ad server and decisioned in the same manner as regular, client side header bidding.
Hope that helps,
Ben
Technically speaking, the server side SSPs only have access to the user if they win an impression, so they typically cannot drop a 1st party cookie on that user. This is why monetization is likely to get worse moving a partner from the client side to the server side, because they won’t be able to identify and sync as many users as before. Now, there is still platform cookie syncing processes in place, such that eventually, the client side SSP will redirect a user to other SSPs to facilitate user syncing, but this happens on a much less frequent basis.
Hi Alon,
I would point you toward the OpenRTB specs: https://www.iab.com/guidelines/real-time-bidding-rtb-project/ which describe the typical way programmatic platforms communicate with each other. You might find nuances with how different partners work, but that will give you a good foundation of what to expect. I would say you are far more likely to have success integrating as a demand source within a supply side platform however than directly in the wrapper, unless you are an enormous buyer.
The main challenge you’ll have is you are one of hundreds of potential buyers, and platforms just aren’t going to want to do that many integrations. Certain large buyers will be able to push their weight around and demand this, but most won’t. Not only that, but most DSPs are going to be integrated with the existing SSPs in market already, and going direct to header won’t really change their access to supply, just their fee structure perhaps, which the wrappers are likely to resist.
I believe the only S2S buyer (DSP) integrations right now are Amazon and Criteo. Large buy side concerns that also own their own wrapper tech.
Thanks Ben, this is helpful stuff. Will the tag on page (wrapper) dynamics you talk about lead to a winner take all exchange or is there room for multiple exchanges to thrive? Which exchange(s) do you think will be the ultimate winner(s)?
Thanks!
Good question; my general POV is that supply side platforms will consolidate in the next few years leaving just a few in the market. What made room for many exchanges was the fact they all vied for access to supply, and different platforms had access to different supply. But now header bidding has commoditized this supply – everyone is selling the same thing. It’s only a matter of time before buyers act on this and just bid on the platform that has access to lots of supply with low fees and transparent auction mechanics. SSPs will battle over incentivizing demand to run through their platform and create a price war among each other that will starve some companies out of business. What’s interesting is that server side header bidding will probably just accelerate this, since it will just speed up commoditization across more platforms as publishers chase quick dollars before buyers crack down.