How To Manage The Compromises In Server-Side Header Bidding

adamhechtThe Sell Sider” is a column written for the sell side of the digital media community.

Today’s column is written by Adam Hecht, vice president of publisher monetization at Operative, a SintecMedia company.

It seems like only yesterday that publishers were excited for header bidding, the new innovation in programmatic ad management. Actually, it was only yesterday, but today is a new day, and server-side header bidding is now the hot topic.

Server-side header bidding refers to programmatic bid management that occurs off of the web page directly between the buyer’s and seller’s servers – or at least between the middlemen representing them.

Theoretically, server-side header bidding should speed up page load times, decrease the number of bids that time out and improve cookie recognition, increasing the amount of data-targeted bids. It could also help resolve header bidding’s issues with video and native ads.

These are all good reasons to embrace the server-side header bidding concept, but there are also complexities to consider.

Don’t Throw Away What Header Bidding Has Provided

While many have called header bidding a hack or an interim step to more stable programmatic bid management, it gives publishers the most choice and control over their inventory. Publishers can track the bidding process for themselves and select any partners they want. Header bidding has also been popular because it allows publishers to see a broader swath of data with more visibility into things like bid density and win rates.

Given that header bidding does have its issues – it can be unwieldy to manage and optimize and interferes with user experience – it’s important for publishers to test server-side header bidding. Even then, they must not lose sight of the importance of access and control.

Server-side solutions offer limited reporting and still don’t provide a breadth of demand, blame for which can be laid squarely at the feet of vendors. The vendors are ramping up with integrations to demand sources, but will never reach full demand access. Selecting a server-side partner might allow a few partners to be moved out of the header, but it rarely solves the entire programmatic management problem. This leaves publishers in a familiar situation: juggling a variety of demand sources without a lot of insight across the board.

Pick The Least-Worst Compromise 

Purch is one publisher that built its own server-to-server programmatic solution to manage all of its demand sources in one place. While that’s a possibility for digital publishers with decent engineering resources, it will require a lot of maintenance, partner management and expansion to new channels, such as video, native and mobile.

For publishers that don’t have their own engineers to build a complete server-side solution, they can choose from a few early players, including Media.net, OpenX, Google, Sonobi and potentially Amazon.

All of the current solutions require a compromise. Media.net has been providing server-side solutions for two years, but The Atlantic, an early client, still also uses Google’s exchange bidding in dynamic allocation to increase fill rates, and reporting is still relatively limited. Google is easy to use, but reportedly takes a double revenue share and already has a chokehold on ad serving, which publishers should try to unwind, not embrace.

Sonobi promises more direct access to demand sources, such as trading desks and demand-side platforms, but cutting out competing supply-side platforms could lower fill rates for publishers, as well as any unique demand other partners can bring to the table. OpenX has a solution built mostly for its own ad server clients, which is a nonstarter for many pubs tightly bound to Google DoubleClick for Publishers or AppNexus. And Amazon could be the most amazing thing in the world, except it won’t discuss who is connected or what its reporting looks like.

Get Your Analysts Prepped

Managing server-side header bidding will require granular reporting and diligent analysis. Don’t expect to get that directly from the server-side header bidding providers. Publishers should demand direct access to full data sets from partners. Publishers should also have a reporting stack at the ready. STAQ and Tableau are miles better than individual vendor reports and Excel and can give publishers a lot more control over their management and optimization process.

Simply looking at top-line revenue every day isn’t enough to really understand how advertiser bids are responding to a new, faster channel. Trading desks are well aware of the different channels by which they can access the same audience or even the same ad impression. They can game the system, for example, if publishers don’t monitor activity to make sure floors are set consistently.

What’s more, publishers must remember to calculate the true CPM of the server-side header bidding partner, accounting for win rates and any kind of true ups, conditional metrics and other changes to the total revenue at the end of the month. These are all still unknowns that need to be factored in.

While page speed, fill rates and win rates might improve, there is no reason to believe that server-side header bidding will be any better for publisher control in the long run unless publishers remain steadfast in their need for transparency, data and optimization management.

Any partner that optimizes for its own gain across publishers, operates on a variable margin or has its own revenue stream from the buy side is ultimately out for its own gain and will develop its solution to increase its profits first – precisely the issue with the rest of the ad ecosystem.

Follow Adam Hecht (@OpinionatedAdam), Operative (@Operative) and AdExchanger (@adexchanger) on Twitter.

1 Comment

  1. What are your thoughts on the cookie matching discrepancy issue? This is the biggest compromise of server side. Publishers with clean pages and a reasonable amount of header bidders are not seeing latency due to header bidding. For them, moving to server side could increase cookie loss by 20% for those vendors who aren't managing the server side wrapper. In theory server side is the right solution for these types of auctions, but publishers need to weigh the pros and cons of revenue loss due to latency on the client side vs. user sync on the servers side.

    Reply

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>