Of all things 2019 could be labeled—the year of privacy regulation compliance, the year the third-party cookie crumbled, the year of DSPs being acquired on the cheap—it will not be remembered as the year client-side header bidding died.
Not for lack of effort from its arch nemesis, Google. The tag team of Open Bidding (now featuring more of your favorite demand sources) and Unified Auction’s restricted floor controls looked set to deliver client-side header bidding a beating… but interestingly enough, many publishers reported an uptick in their client-side header revenue after the Unified Auction’s launch.
Still, the world is changing fast—and the third-party cookie’s accelerating fade in particular makes us ponder the future of client-side header bidding, even if troubles with ID-matching and a lack of transparency and flexibility continue to mar the adoption of server-side bidding.
I queried Lucie Laurendon—Smart’s Senior Product Marketing Manager and resident header guru—about the future of the header and the cookie crackdown; whether publishers still need header partners on the page; how publishers should evaluate their client-side to server-side demand ratio; and much more.
GAVIN DUNAWAY: What are the most important factors in determining a client-side-server-side header balance? Are there certain monetization priorities that might make a publisher prefer one to the other?
LUCIE LAURENDON: What is the best balance between both? Unfortunately today, too many publishers don’t even ask themselves this question!
They just plug into as many demand sources as possible without being guided by an overarching strategy. Sometimes a little bit of less is more, which can deliver more sustained impact. There is no one “best” solution. For a publisher, the choice between client-side header bidding and server-side header bidding depends on its monetization strategy and the type of inventory it is prioritizing. The calculus typically involves weighing user experience (latency), control, revenue as well as internal resources in terms of implementation capabilities.
Compared to client-side header bidding, server-side bidding produces a better user experience with fewer latencies. The server-side wrapper calls the SSP’s server-side in a single call. The implementation also requires fewer internal technical resources thanks to an easier setup and management, which is even easier in in-app environments.
The type of inventory publishers monetize can also drive the decision. Take video as an example. Video ads are rich media files and, as a consequence, require more time than other formats to be loaded on a web page. Same thing goes for publishers with in-app inventory. Publishers don’t even need to install an SDK as everything is handled on the wrapper side.
On the downside, server-side bidding only allows for limited access to user cookies, which means limited user match rates with the demand and consequently lower bid density as compared to client-side header bidding. As all the auction management that determines the winner is done server-side, publishers also lack transparency and control over their inventory.
They also have less granularity in the set-up of their inventory with their SSP partners: websites, pages, formats, and creative types are only available in an aggregated form; thus, reporting and optimization strategies based on these criteria are less granular.
To achieve the two main goals of a publisher—maximizing revenue and fill rate—I would recommend starting by plugging into both solutions. Carefully evaluate performance per format and inventory type as well as which demand sources need to plug into which wrapper. On the one hand, client-side header bidding helps maximize cookie matching, thus increasing eCPM and on the other hand server-side bidding guarantees a high bid density and thus a good fill rate.
GD: Why is client-side STILL more transparent than server-side?
LL: Transparency is one of the key benefits of client-side header bidding, but still it depends on the type of header bidding you have implemented. With header bidding, you are more likely to understand the auction dynamics since you have a chance to reverse engineer the code of the wrapper.
"Publishers and big ad tech players need to collaborate to take back control of their data and their audiences. And why not build new standards to make sure everyone would benefit from this and maintain the value of client-side header bidding?"
When header bidding is implemented client-side using prebid.js, it relies on an open-source piece of code executed directly from the publisher’s site which then sends requests to several demand partners. This way publishers are able to check themselves directly in the code to confirm everything is fair.
Server-side bidding is more of a “black box,” with few triggers for optimization on the publisher’s side. It’s hard to understand how the prioritization logic works between the different demand sources or whether the wrapper applies hidden fees.
GD: Will the cookie’s dwindling relevance entice more publishers to embrace server-side header bidding options?
LL: If client-side and server-side header bidding become equal in terms of user identification, some publishers would probably go for server-side bidding. But transparency could still be the key asset of client-side header bidding that would appeal to publishers.
It’s important to remember however that client-side header bidding was a hack developed primarily to reduce dependency on Google. Many publishers with Google as an ad server won’t give up client-side header bidding for Google Open Bidding only.
Also, the client-side wrapper offers unique possibilities to implement innovative identification solutions and new alternatives to third-party cookies. Publishers and big ad tech players need to collaborate to take back control of their data and their audiences. And why not build new standards to make sure everyone would benefit from this and maintain the value of client-side header bidding?
GD: How important is it for partner code to be “on the page” now?
LL: Being on the page not only gives a likely advantage when implementing potential identity solutions, but also allows the publisher to implement much richer advertising experience strategies. In server side, header bidding setups are very standardized—it is the “one size fits all approach” where client side integration allows for much more personalization. This is a way for a publisher to leverage unique ad format capabilities.
GD: Do you think 2020 will find more DSPs popping up in publisher headers?
LL: One of the major 2020 market trends will certainly be the decrease in the number of players in the value chain. In this scenario, SSP value could be challenged.
But, while vertical integration may be the goal, SSPs can still offer great advantage as they have a unique understanding of the inventory and advertising integration in their pages. Most larger SSPs also integrate data science technologies to protect the queries per second of the demand platform.
SSPs also bring innovative solutions, such as dynamic revenue share, lazy loading, safe frame, high impact and custom formats, and personalized customer experience. DSPs won’t be able to access these features when integrating directly with the publisher.