Header Bidding Programmatic

What header bidding containers mean for the industry

By Andrew Buckman, Managing Director EMEA

May 20, 2016 | 5 min read

Header bidding - the cases both for and against - has turned out to be one of the key debates in the digital advertising industry in 2016, with key stakeholders in the business drawing lines in the sand. Here, Andrew Buckman, OpenX's managing director, EMEA, explains some of the industry dynamics at play.

Andrew Buckman from OpenX explains header bidding

Despite Google opening up dynamic allocation to outside demand, header bidding is still growing rapidly and discussions around the impact of the technology dominate the ad tech conversation.

The Guardian is just one of the latest high profile publication to test the technique, which allows publishers to offer their inventory to multiple demand sources simultaneously before calling their ad server - maximising yields, minimising wastage, and allowing publishers to understand the true value of their inventory.

However, header bidding isn’t without its drawbacks, as it can be complex and time consuming to implement. It can increase page latency when multiple demand sources are involved, causing a negative impact on viewability and the user experience. Header bidding containers – also known as header bidding wrappers – are hailed as the answer, so what exactly are they, and do they live up to their promise?

Header bidder containers are designed to manage multiple header bidding partners, with one container tag placed in the header rather than an individual tag for each demand source. This allows publishers to update header tags without having to change website code. Most containers include functionality for setting auction timeout thresholds – limiting the time the publisher waits for a bid – and for translating bids into a common language for the ad server.

The containers allow the site content to load before the ads, and they protect high performance partners being impacted by poorly integrated demand sources.

Operationally, the containers make implementation easier by simplifying line item creation and management, and the process of adding and removing demand partners.

Phase One: Browser-side containers

The majority of header bidding containers are built on the browser, and have so far fallen far short of expectations. Despite the ability to set timeout thresholds, the additional weight of each demand partner – as well as the container itself – can still increase loading times. Calls to demand partners can be slowed by mobile network speeds, device processing speeds, and the limited availability of browser ports, ultimately having a negative impact on the user experience. Designed to reduce complexity, these containers actually add technical challenges where demand partner, publisher, and container code must all interact to achieve the desired yield optimisation.

Selecting a browser-side container can also be problematic. As a relatively new technology, containers are often built as open-source projects by new technology companies meaning security, stability, and reliability – as well as the ability to scale as a business grows – are all questionable.

Many header bidding containers pass only the winning bid to the ad server, opening up the potential to manipulate the auction process by giving its provider ‘last look’ to beat the highest bid. To be effective a container solution must operate with complete transparency and must also add an additional layer of ad quality protection through the ability to block bad ads, which the majority do not currently possess.

Phase Two: Server-side containers

In an industry that evolves as quickly as ad tech, an alternative to browser-based header bidding containers was never going to be long in the making. Echoing a regular theme in ad tech – where intrinsic weaknesses in client-side solutions are addressed by moving server-side – server-side solutions have already emerged as the next generation of header bidding container, resolving many of the issues faced by their browser-based forbearers.

Server-side solutions transfer all activity from the user’s browser to the container’s server, resulting in a faster ad call process and addressing the most significant concern of page latency. Through this new generation of enterprise-level smart containers, publishers also benefit from stable, proven technologies operating transparently according to accepted industry standards. All bids are passed to the ad server, not just the winning bid, which removes the potential for manipulation and allows accurate measurement of partner performance. Through functionalities such as control panels, demand levers, and integrated analytics, they provide the publisher with a greater level of control and insight.

Header bidding is already an established part of the programmatic landscape that allows publishers to level the playing field. It simplifies the auction process and enables direct and indirect demand to be effectively combined in an RTB environment for the first time. The development of header bidding wrappers – specifically their evolution from client-side to server-side – will increase the scalability of header bidding across multiple partners, further boosting adoption rates, and taking the industry as a whole to the next level of efficiency.

Click here to read more opinion on the debates surrounding header bidding

Header Bidding Programmatic

More from Header Bidding

View all


Industry insights

View all
Add your own content +