Header Bidding Goes Server-Side: 6 Things You Should Know

server-side-header-biddingHeader bidding, make way: In the next year, more publishers will switch to server-side header bidding.

The solution offers clear advantages – while introducing other disadvantages – with which the industry will grapple as publishers update their tech.

Like with header bidding, publishers run a pre-auction before the ad server to create a level playing field for demand. However, server-to-server header bidding is much faster because all the heavy lifting happens on a remote server, not on a user’s browser.

“Header bidding is great, but it’s not a panacea,” said Chip Schenck, VP of programmatic sales and strategy at Meredith. “It has its own warts, including the latency in the call. Server-to-server is the next step in the evolution of auction dynamics.”

Other industry experts agree that server-side header bidding represents an improvement from client-side header bidding.

“Server side calls are better,” said Alanna Gombert, GM of the IAB Tech Lab. Google, Amazon and Media.net are developing server-side technology, and many other supply-side platforms (SSPs) are building this tech.

Here are the six things to know about the technology.

1. Server-to-server integrations are technically superior – and faster. In order to get a head start before the ad server, header bidding “uses JavaScript a way it was never intended. JavaScript is terrible at parallelism,” said Sonobi President Tony Katsur. The obstacle means bad news when publishers’ header bidding partners need to send out multiple bid requests at the same time.

And browsers send and receive information through a limited amount of ports, so when a publisher integrates more partners than it has browser ports, technical issues can challenge some partners.

“It’s like LA traffic,” Schenck explained. “All 10 partners may return in a lickety-split time frame, but the first five made it because they cut off another car and the other five are sitting behind [the browser ports], not getting back into the wall.”

But server-to-server connections can call multiple partners at the same time, and bids don’t get stuck going in and out of the web browser, which means they can collect more bids. More bids means higher yield for publishers.

2. Server-side header bidding requires teamwork in a nontransparent environment. Publishers work with one vendor to do server-to-server header bidding. Because that vendor in turn rounds up bids from all the other demand partners, they must trust the vendor to run the auctions fairly.

While code run on the browser is visible to all, what happens on the server is invisible to both the publisher and the buyers. It’s possible that auctions could be conducted in a way where one demand partner gets preference or a final look. Or data could be leaked or hidden fees be taken. And that lack of transparency makes technical glitches more difficult to fix.

Adoption “hinges on the openness of other companies,” said Hussain Rahim, a product marketing director at PubMatic, which is developing a server-side technology and working out these partner onboarding issues.

Many publishers won’t implement server-side bidding unless they can get the same demand sources they had while doing browser-based header bidding. For example, sources considered OpenX Meta dead – or never real to begin with – because without cooperating partners the tech was useless.

So who will move server-side first? Index Exchange CEO Andrew Casale said he expects partners who don’t command a large share of wallet to be pushed inside of server-side integrations, while the companies that deliver publishers revenue will earn their spot in the header.

3. Cookie matching is more complex – and favors the vendor who owns the server-to-server connection.

This one is a little convoluted, but bear with us.

When a SSP offers up an ad to a DSP, it must match its cookie ID with the DSP’s cookie ID. Without a matching cookie showing a user is a 30-year-old female in Ohio, for example, the DSP is unlikely to buy (or to pay much) for an ad.

Of course, not all cookies match up, so some IDs fall off every time IDs sync. With server-side bidding, an SSP would have to match up first with the SSP rounding up all the bids and then with the DSP. With every additional ID sync, more cookies slip through the cracks.

Even if they could work together to sync IDs, they may not want to. “SSPs do not currently have user syncs with each other,” noted Jordan Mitchell, CEO of DigiTrust. “They don’t really want to because it exposes too much information between them.”

“There will be more auctions in the future in which the DSP doesn’t know what it’s buying, and that will do bad things for yield,” said Chris Kane, founder of programmatic consultancy Jounce Media.

The only entity who’s advantaged by this extra hop is the vendor who manages the server-side header bidding connections to all the other partners.

This vendor is the only one with a tag on the publisher’s page and needs to cookie sync just once.

“The company that makes the wrapper has a huge advantage in bringing its own demand to the table,” Kane said.

To sidestep that unfairness, Tom Kershaw, Rubicon Project’s chief product and engineering officer, is advocating that “the cookie-matching process should be operated by a neutral third party that does not gain advantage from operating the system.”

4. For mobile apps, server-to-server is old news. “The mobile in-app world has always had server-to-server connections,” said Tanuj Joshi, VP of strategic media enablement at MediaMath. “We see companies taking the best practices of mobile back into the browser and desktop world, and that’s a good thing for the industry.”

App developers must limit the number of SDKs they install, because mobile is a more speed-sensitive environment. And apps use IDFAs, not cookies, so syncing user IDs never posed an issue the way it still does in desktop. Smaato’s mobile ad server, for example, makes more than 450 server-to-server connections with demand sources, according to Garrett McGrath, SVP of product at Smaato.

But McGrath warned that some mobile in-app header bidding solutions in development require too many steps too work – think an SDK on top of an SDK that in turn has to make calls in each direction. “These clunky attempts to string together SDKs for ‘in-app header bidding’ just aren’t going to work at scale,” McGrath cautioned.

5. Auction dynamics could change. Server-to-server header bidding brings publishers close to a unified auction.

The problem with browser-based header bidding setups is that winners of smaller auctions compete against each other, which is inefficient, and the buyer who submits the highest bid can still lose the auction.

Here’s how it works: Each DSP submits a final bid to the SSP, which runs an auction and submits its second-price bid to the publisher. A publisher with seven partners chooses the best price from seven different auctions that already ran.

But here’s where this can go wrong: Buyer 1 submits a top bid of $15 to SSP 1. Because the second-highest bid was $2, SSP 1 submits a $2.01 bid.

Meanwhile, in SSP 2, Buyer 2 submits a winning bid of $11. Because the second-highest bid was $5, SSP 2 submits a $5.01 bid.

So even though Buyer 1 was willing to pay more than Buyer 2, the dynamics of the second-price auction awards the impression to Buyer 2.

If these dynamics changed to where everyone submits the first and second price, the publisher would pocket $11.01 instead of $2.01. Because server-to-server works faster, creating new rules for how auctions run is now a possibility.

6. A bunch of ad tech companies are building server-to-server products

Google’s exchange bidding in dynamic allocation, announced last April, uses server-to-server connections. And news of Amazon’s server-side header bidding wrapper leaked in December. Media.net has attracted publishers like The Atlantic and Forbes, while publishers like Purch tackled the project on their own.

Most supply-side platforms are in the game. AppNexus, Index Exchange, PubMatic and Rubicon Project all are developing projects. The majority of, the companies told AdExchanger they’re open to working inside of others’ solutions. Sonobi’s solution attracted The Guardian, and PulsePoint supports server-to-server integrations. At least one cautionary tale already exists: OpenX announced its server-side tech, OpenX Meta, a year ago, but has had difficulties onboarding partners to the project, making it useless.

The Takeaway

Server-side header bidding improves speed, which lets publishers increase bid density and yield.

But the cost of that speed is cookie loss.

“If the speed benefit is big enough, it could offset that audience coverage gap,” Kane said. “There is the downside risk of auctions where audience targeting would have been possible in a client-side setup, but will not be possible in a server-side setup.”

The second major challenge will be getting all the companies pursuing server-side header bidding – Amazon, Google, OpenX, PubMatic, Rubicon Project and Sonobi, to name a few – to integrate with each other’s offerings. Some, like AppNexus, have already publicly turned their nose at working with a company like Google. But others, including PubMatic and Rubicon Project, told AdExchanger they’re willing to work with other vendors who manage the server-to-server connections.

Rubicon’s Kershaw, for example, wants server-side solutions to be “standard-based and not proprietary. All elements of the solution should be open-sourced to ensure that any solution is fair to all participants, transparent and auditable.”

These details might cause contractual problems.

“The challenge with server-to-server will be how all the vendors interoperate and how they adhere to a code of conduct around things like transparency, direct publisher payments, audit rights, and non-gamification of the auction,” Sonobi’s Katsur said. But he’s optimistic these issues will be overcome. “We think traditional header bidding, tag on page, is dead. It has 18 months, maybe.”

But in the ultra-competitive world of ad tech, cooperation is easier said than done. Being on the page offers advantages many won’t want to give up.

“All these guys want to be on page, and not all of them will get to be on the page. Everyone else will have to connect server-side,” Kane said. “And that will be the big fight over the next year.”

Enjoying this content?

Sign up to be an AdExchanger Member today and get unlimited access to articles like this, plus proprietary data and research, conference discounts, on-demand access to event content, and more!

Join Today!


  1. Great article Sarah, thank you.

    It may be worthwhile to note that the leading proponents for server-side header bidding are big proponents for a standardized user ID/token as well, for a number of the reasons you point out. Both are efforts to improve the consumer experience while improving programmatic efficiency for sellers and buyers. A standardized ID which all SSPs (all “bidders”, for that matter) have access to, and which can be passed between them, is a much cleaner alternative — no user syncs, and no data loss disadvantage — so long as the ID is provided by a neutral third party industry consortium that doesn’t have shareholders, investors or can’t/won’t be acquired.

  2. Most of the time, I feel informed after reading Ad Exchanger, but every now and then an article makes me angry…that they beat me to writing it! Incredible article Sarah, lots of smart points in here and highlights the nuances of server side header bidding really well.

  3. Royi Porat

    Good article Sarah. I think Server side header bidding is basically what ad exchanges (were and still) are all about.

    Just wanted to second @Jordan Mitche’s comment about the importance of an industry standard user id and to emphasize that in order for this to really work, it has to be cross channel and persistent (mobile browsers don’t access device/user ID, IDFA can be reset by user)..
    Unsurprisingly, the two vendors that can actually DO something about it are Apple and Google (if they only wanted to of course).
    The alternative for the former however, could be an introduction of a new innovative Mobile browser that accesses Google/Apple’s device/user id and shares it with any requesting website.
    Ohh and the minor fact of having this browser checkmate Chrome and Safari.

  4. I disagree that the cookie matching will favors the wrapper’s vendors.
    We do cookie matching with all our vendors Today, DSP or SSP, from within our server-side HB wrapper (BidderExpress). The matching pixels are triggered client side, and the ID is forwarded to the server which runs the auction.
    This said, I am totally supportive of Digitrust. But because it get rid of the convoluted cookie matching process entirely, NOT because of server-side HB.

  5. Steffen

    I’m late to the party bug maybe someone can answer the following question. 🙂

    What is the difference between today’s SSPs and tomorrow’s companies hosting the Server-Side Header Bidding wrappers? Or to put in another way: Why do you think every DSP which today only talks to a select number of SSPs tomorrow be willing to talk to all Header Bidding wrapper providers out there? Will Google really offers its inventory through a header bidding wrapper provided by Amazon?

    I suspect that won’t happen and we’ll require some new kind of client-side meta-header-bidding JavaScript… and have come full circle.

  6. Anastasia

    Can you explain me what is the difference between server-side and server-to-server side?