Thirteen months of server-side header bidding in production: a report from the trenches
After more than a year of running large inventories of display and mobile traffic through our in-house built server side solution, the results are clear: more control and transparency for the publisher, increased revenue through better yielding and a drastically improved user experience.
During this time I have become convinced that the server side approach is at least part of a solution against the walled gardens created by Google and Facebook. Moving server side will allow our sector to further professionalize and offers true transparency for both publisher and user. This is an important step in rebuilding trust between publishers and users since it tackles some of the grievances that lead to installing ad blockers.
Introduction
Server side header bidding and how it affects the SSP auction model is currently a hot topic. Every day more and more experts on digital advertising are expressing their views and what strikes me often is that many voices seem to treat two very distinct subjects as one and the same. Time to bring some clarity.
Server side header bidding combines two things. First “how to implement your ad services from a technical stance ~ server side”. Secondly, “how to monetise your inventory on multiple SSPs ~ header bidding”. Both subjects encompass different goals, their outcomes are determined by different parameters and they are usually not the responsibility of the same people within one media organisation. How to implement advertising is a technical decision, how to monetise is a strategic commercial decision.
In this post I will to discuss the server side of header bidding from my experience at Adhese, a holistic ad serving platform used by various media companies across many domains, platforms and applications.
An ad serving platform is typically a tech solution that sits between two or more departments within large media companies: editorial/webdesign and sales.
For the editorial and design teams, the ad server deals with the online real estate that is outsourced to the commercial department, at another floor or building. The ad serving solution is usually implemented once, and if all goes well, no more changes are needed in the next months or years to come.
For the commercial department the ad server is one of their sources of information and one of the tools they need to master to get all their campaigns running.
Both stakeholders have different KPI’s and operate on different timelines. This difference is key in the understanding of server side header bidding.
Content != Advertising
Web design teams and product owners often work in planned sprints guided by the constant evolution of their products and their technical needs. Their KPI’s might be more visitors, more page views, longer time-spent, publishing on multiple platforms, … . From this perspective, ad serving is considered as a hole in a page or app that needs to be filled by an external source. It should correctly occupy its space, without interfering with or slowing down the app or site. In the most ideal of worlds, it shouldn’t interfere with development!
Before the rise of header bidding, webmasters would implement the ad server scripts, usually a JavaScript library and some code in the body of the html page. For mobile, ad servers provide libraries as well (called SDKs) and a similar process takes place. Programmatic would get implemented as a campaign in the ad server, running at a specific priority as part of the waterfall system, receiving whatever traffic was left. Yielding programmatic was basically limited to picking the priority of a campaign.
As programmatic revenue started to rise, SSPs started to look for more and more valuable traffic. To break out of the waterfall, they provided ad servers with JavaScript tags that would still run as a campaign in the ad server, but could return unsold traffic. By doing so the programmatic team could increase the priority at which they were running their SSP campaigns, without affecting direct sales too much.
Part of the cost of this change was also paid by the user, as it was her/his device that needed to execute the extra requests back to the ad server, in the case the SSP didn’t sell the impression. Which leads to latency issues, jumping layout after page load and other nuissances, often cited as reasons for installing an ad blocker.
But it also leads to ever more complex scripts on each site or app, leaning more on the webmasters and designers to get things implemented correctly. This approach culminated in header bidding, where most of the “programmatic” logic is directly implemented in a page in the form of a Javascript library and some function calls.
And even with these pass back scripts, or with client side header bidding for that matter, we are still running some kind of slightly optimised waterfall model, while at the same time making it worse for the user. We can now send some more traffic to the SSP, but we are still not optimally yielding between direct and programmatic.
On the server side
Somewhere in 2014, we realised at Adhese that we needed to start working on a server side implementation of external revenue sources, if we ever wanted to efficiently yield direct campaigns and programmatic in a manageable way. Triggered by this insight, we started to think about what possibilities moving all the client side logic to the server could open up. Some of the things we came up with and have developed in the meantime were:
1/ An efficient and manageable implementation. One ad server request from the page for all types of ads, a standardised response, not matter what the source of the ad is. And a guaranteed maximum latency.
2/ Exact yielding per impression, using the actual e-cpm for direct campaigns and bid responses. Expose the e-cpm of direct campaigns to the SSP to allow a unified auction. No more waterfall and impression-level control.
3/ Vendor flexibility. As all connections to external sources are part of a server side component, updates to these connections, or adding new ones, are a job to be done on the server, without updates on the client side. Granular controls allow using a specific SSP based on any kind of request parameter, from mobile over geolocation to video content duration.
4/ Clean user synchronisation. SSPs need to be able to recognise their users. Through a server setup, we can provide access in a controlled way, matching their users with the publisher’s and storing this data in one place. Doing this through a single point enables simpler privacy compliance becomes simpler and publishers can offer users transparency and control over their own settings.
5/ Stable and reliable reporting. As everything passes through a single point before it reaches the user, we know exactly what was served to who allowing us to provide detailed reports. These reports can give insight into each user’s experience.
We started working on this list of features in 2014, based on the OpenRTB standard, and in connection with Rubicon’s XAPI. A process that eventually resulted in a new product, put into production in the summer of 2015 and running at several of our publisher clients since.
So how did it turn out?
Moving to the server had an immediate effect on a publisher’s page load and the user’s experience at each of the implementations we have done so far.
Imagine this: a publisher has 3 formats on one page that are sold both through direct campaigns and programmatic. In the waterfall setup, taking into account a fill rate of fi. 15%, 85% of requests return empty from the SSP, and need a second request to get a direct campaign.
Moving server side, you are able to cut the number of requests in half for 85% of your traffic. In a client side header bidding setup, the gain is even higher, as multiple requests to SSPs are sent out.
After several months of high load production traffic we have seen persistently lower ad loading times. In our current implementations, our platform receives all ad placements in one request. It then fetches all direct campaigns and sends out parallel bid requests for each placement. In 99% of the cases this is done in less than 300ms.
By moving all these requests from client to server, the user experience improves substantially through a much faster page build-up.
We have gone through various update cycles since moving to server side, have had changes in data to be sent to the SSP, updates to the inventory structure, etc… All were setup, tested and deployed without the need for updating the client applications. It did take some time to develop the right debugging tools to make sure the whole process could be tested and monitored correctly.
We have seen various effects on revenue, from retargeting campaigns finding more matching users, over smarter delivery of direct campaigns based on value, to increases in e-cpm due to the proxy bidding of the direct campaigns. For my thoughts on yielding per impression and the header bidding part of the story more in an upcoming post.
Some warn for user matching pitfalls when moving server side. Our experience learns that in strictly controlling the user matching through a centralised service, we get reliable stats, can identify issues easily and continuously improve the percentage of matched users.
An approach like this is almost impossible in a client side setup, where each player needs to sync directly with the client, and nobody has an overview.
I for my part would love to see a broad adoption of an initiative like www.digitru.st, and I think we could do well with a European version of it to address specific privacy sensibilities.
Conclusion
After more than a year of running large inventories of display and mobile traffic through our in-house built server side solution, the results are clear: more control and transparency for the publisher, increased revenue through better yielding and a drastically improved user experience.
During this time I have become convinced that the server side approach is at least part of a solution against the walled gardens created by Google and Facebook. Moving server side will allow our sector to further professionalize and offers true transparency for both publisher and user. This is an important step in rebuilding trust between publishers and users since it tackles some of the grievances that lead to installing ad blockers.
Next stop: inject all ads server side, so that a user gets a really clean page!
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!
