Header 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.”
