The Future of Header Bidding is Server-Side


It’s been a little over a year since header bidding became mainstream, and the technology has been adopted by half US premium publishers to deliver ads programmatically.

As a result, competition is heating up. Where previously tech companies were looking for a solution to appease their publishers, there is now a battle for market share. AppNexus announced PreBid pro last month as an enterprise-class upgrade to its popular Prebid.js open source wrapper. OpenX has announced header bidding for in-app. Index is betting the farm on its black-box, fully supported solution. Inversely, Rubicon admitted its costly mistake in not developing an offering.

Yet as these offerings hit the market, a fault-line is emerging between two distinct camps: the client-side wrapper versus the server-side wrapper. Client-side wrappers gives publishers full control over their monetization without costly data centers. SSP-managed server-side wrappers gets publishers up and running quickly, but the SSP has a say when adding new demand sources.

Ultimately, publishers will pick server-side.

Once upon a time, wrappers were all client-side

Client-side wrappers have been around since the early days of header bidding. Pioneers like RTK didn’t have the infrastructure to handle complex real-time bidding (RTB) auctioning within their data centers, so writing client-side software was an easier start.

On the pub side, early adopters were willing to deal with the complexity and limited feature set of these early javascript wrappers, attracted by the transparency and revenue gains offered by header bidding’s holistic yield management.

But as more of publishers’ traffic shifted to header bidding, the complexities built up. Robust analytics became a priority, more buyers needed to be added and finally privacy came to the forefront. Not surprisingly, header bidder wrappers are now big, hairy pieces of software, delivering mission-critical functions from the inherent flimsiness of browsers. The Prebid.js open source framework saw 17 releases in one year, and now comes with 27 built-in demand partners.

Operational Management and Latency Concerns

Some vendors responded to this complexity by moving the most critical functions of header bidding away from the user’s browser and into their data center. Moving the most complex functions of header bidding to the server presents several advantages.

First, powerful vendor servers provide a more reliable and scalable environment for executing really complex tasks like real-time bid optimization and fraud detection.

Second, server-side wrappers are a lot easier to implement. In many cases, header bidding tags are like regular tags that publishers can copy from a self-service console and paste into their CMS. That’s all it takes.

Third, complex client-side code is more likely to slow down publisher pages. Beside the bandwidth required by a bigger payload, there are limits to the number of connections the browser can keep open, obliging some level of serialization of the bidding workflow beyond a certain number of real-time buyers.

Whose Data Center?

It’s therefore no surprise that server-side wrappers are becoming more popular. But that does not mean that client-side wrappers will go away. Far from it. For publishers with deep technical resources, client side wrappers will stay the preferred header bidding implementation for the foreseeable future. Client-side wrappers stay fully within the control of the publishers, allowing them to build and maintain the checks and balances that suit their business.

At some point, publisher will have the expertise to host server-side header bidding within their data center.

But for now, SSP-managed header bidding is the best solution for publishers who want to embrace header bidding rapidly and with minimum tech investment.

Leave a Reply

Your email address will not be published. Required fields are marked *