Header bidding has become the de facto approach to programmatic ad auctions since it was introduced in 2014.
When a user visits a webpage, header-bidding auctions occur in real time as a page loads, which allows all exchanges to submit bids on an ad impression simultaneously.
But running so many real-time auctions requires an immense amount of processing power, and publishers often have a choice for how to implement header bidding.
With client-side header bidding, the bulk of that processing occurs on the user’s device in the web browser itself. With server-side header bidding, the processing happens on a remote server.
Here are the pros and cons of each approach and some typical use cases.
The basics
But first, a quick refresher on some programmatic basics is in order.
Ad auctions start with a bid request being sent from the publisher page to SSPs, which run the auction. JavaScript code running on the publisher page, known as a header-bidding wrapper, determines the rules of the auction, including which bidders can participate, what the minimum bid should be and – crucially – how long bidders have to respond to a bid request before the auction times out.
Prebid provides the most widely used header-bidding wrapper, and it offers two different solutions: Prebid.js, which is used for client-side auctions, and Prebid Server, which is used for server-side auctions. But there are also other wrappers, including some created by individual publishers – for example, CBS uses a proprietary wrapper called BidBarrel.
Meanwhile, Google Open Bidding and Amazon’s Transparent Ad Marketplace are examples of server-side setups.
Today, the overwhelming majority of header-bidding auctions are run client-side within the browser. Server-side header bidding is newer, more complicated and more expensive to set up and maintain, and therefore less established.
In a client-side auction, the end user’s web browser provides the computational memory required to run all of the processes for an ad auction – including all of the bid requests sent from the publisher site to SSPs.
Header bidding requires a lot of memory to run because of the sheer amount of data being sent back and forth between publishers and SSPs. And the more memory used by the browser, the more likely it is that the webpage will take longer to load.
Publishers want to keep their page load time as short as possible, because users are more likely to leave a website if it doesn’t load quickly. Server-side header bidding was born primarily from the sell side’s desire to reduce page load times, said Heather Carver, CRO at Freestar, a publisher monetization platform.
In a server-side auction, the publisher site only makes one call to a dedicated server to start the auction process, which then calls the individual SSPs so they can run their auctions. That server takes the bulk of the computational load off the browser, which allows webpages to load more quickly.
But for server-side header bidding to work, publishers must either maintain their own server or have a third party – typically Prebid or an SSP – run and manage it for them. And SSPs can only run server-side if they’ve whitelisted the intermediary server. For example, if a publisher is using Magnite’s SpringServe server to run server-side header bidding, other SSPs like Index Exchange and Xandr have to whitelist it.
Client-side: Flexibility and transparency
The complexity of setting up server-side integrations means client-side header bidding makes more sense for the vast majority of publisher use cases, said Dennis Colon, head of product and strategy at enterprise automation provider JIFFY.ai. Assuming a publisher is using a header-bidding wrapper maintained by a third party like Prebid, he said, a client-side approach is easier to set up and doesn’t require much support or maintenance on the publisher’s part.
Client-side header bidding also provides some benefits for SSPs. Because SSPs can access the browser and drop their own tracking pixels on the page, they’re able to find out “as much as they can within legal limits” about the user on the other side of an ad impression, such as IP address and the browser version used to access the page, said Jared Siegal, CEO of publisher tech startup Aditude.
Also, in a client-side approach, SSPs have “complete control” over cookie matching, Siegal said, allowing them to find matches between the advertiser’s audience and that of the publisher by using third-party cookies – while third-party cookies are still in play, that is.
When an SSP has this level of transparency, it usually translates into higher CPMs for the publisher, because advertisers are willing to pay more for audiences they know more about.
Plus, client-side header bidding also gives SSPs the flexibility to customize their header-bidding adapters, whereas the server-side approach requires that adapters stick to OpenRTB standards, said Patrick McCann, SVP of research at Raptive and chair of Prebid.js.
In contrast, when a publisher includes an SSP’s adapter in its client-side header-bidding wrapper, the SSP can customize the adapter to suit the needs of its clients. This helps advertisers win more of the publisher’s auctions, which makes the SSP more money.
For instance, an SSP’s client-side Prebid adapter could include the video.plcmt field that specifies whether a video placement is instream or interstitial, encouraging more bids from advertisers that are seeking either placement type. Or the adapter could be set up to ping the browser API for information that isn’t included in OpenRTB formats, like a device’s screen size or connection speed.
DSPs can also directly integrate their demand via a header-bidding adapter. For example, The Trade Desk’s OpenPath relies on client-side Prebid.js adapters, McCann said.
However, client-side header bidding doesn’t offer unlimited flexibility. Each browser imposes limits on how many concurrent bid requests can be sent to SSPs and how many scripts can function on the page, Siegal said. And the header-bidding wrappers used for client-side auctions limit the number of pixels an SSP can drop on the page, such as viewability and measurement pixels. Prebid usually allows around five pixels per bid, he said.
Server-side: Demand and emerging channels
In terms of flexibility, server-side header bidding allows publishers to add more SSPs. In a client-side setup, publishers have to balance the demand brought by any additional partners against the impact to their page loading times.
(It’s worth noting, however, that many industry experts – including McCann and Colon – say the effect of adding SSPs on page load times is somewhat overblown, and factors like broken tags or oversized ad creative files are the main culprits.)
Because adding SSPs to a server-side header-bidding stack doesn’t place more of a burden on the browser, publishers can add an almost unlimited number of SSPs and other demand partners, Freestar’s Carver said.
More SSPs means higher bid density, which can result in more revenue for the publisher – but there is trade-off. SSPs will have less transparency into server-side auctions, Carver added.
Third-party cookies can also be used server-side to match data sets, but because there’s an intermediary server between the publisher and the SSP, the signal won’t be as strong, McCann said.
Alternative IDs like UID2 or LiveRamp’s RampID, which rely on finding email address matches between advertiser and publisher data sets instead of using cookies, compensate for the signal loss in server-side setups. Alternative IDs can also be used client-side, but they’re not as necessary because of the ease of cookie-based matching when there’s a direct connection between the SSP and the browser. Therefore, client-side integrations are far more dependent on cookies and much more threatened by cookie deprecation.
Server-side header bidding is also the only option for media environments that don’t rely on a web browser – including CTV (meaning streaming video on a connected TV set), digital out-of-home and anything app-based.
But, while server-side header bidding is becoming more popular and is the only option for certain emerging media channels, it’s arguably the less environmentally sustainable option. Publishers or SSPs maintaining their own physical servers rather than relying on a virtual instance within the browser has a bigger impact on their sustainability rating, Colon said.
Why not both?
While each approach has its respective strengths and weaknesses, publishers don’t have to choose between only client-side or server-side header bidding. Both can be used for the same auction.
It makes sense for publishers to set up client-side integrations for their top-bidding SSPs, Carver said, while relying on server-side integrations for other SSPs. Some SSPs even perform better server-side, she added.
Most publishers can handle eight to 12 SSPs running concurrent auctions before they would need to move additional demand sources server-side to ensure page load times won’t be affected, McCann said.
The balancing act of deciding which SSPs to integrate and how has led sell-side tech vendors to offer AI-driven solutions that determine which SSPs perform better under a client-side or server-side setup and optimize accordingly.
But, although client-side integrations are still exceedingly common, third-party cookie deprecation might force a mass migration to server-side integrations because it will render client-side header bidding’s single biggest advantage – the ease of cookie matching – obsolete.
“The second cookies are less relevant,” said Matthew Whaley, COO at Freestar, “it’s a no-brainer: client-side shouldn’t even be there.”
