In the last year, header bidding has undergone somewhat of a meteoric rise. While it originated as an alternative to “waterfall” bidding, it has since become a solution in its own right, and its evolution has proved to maximise yield for publishers and even reduce webpage rendering times. Today, the programmatic ecosystem is rapidly expanding to include the new video, mobile web, and in-app bidding technologies.
On the multi-medium digital stage, header bidding is well-positioned to provide similar advantages to those seen on standard display advertising in other channels. In this wiki, we endeavour to map out some of the challenges faced in each channel and creative solutions being employed to resolve.
Constraints in Video
In 2016, digital video is expected to reach nearly $5 billion in ad revenue due to developing delivery channels, amplified engagement, and having the highest qualified click-through rate.1 Unlike standard display where DFP is dominant, video ad serving is much more fragmented where the programmatic video economy is split between DFP, FreeWheel, and other video solutions. The video introduces additional complexities in terms of flexibility in passing prices and dealing information since the further fragmented video player space (Brightcove/Kaltura/JWPlayer/etc) themselves act as an intermediary in the flow.
Within the video space, the header tag has the opportunity to make a greater impact due to the highly constrained nature of quality video supply. The vast majority of publisher inventory is sold upfront before it can even reach the market. This means unlocking the full potential of programmatic remains a challenge for buyers. Through the emergence of new technologies, video is moving from a conventional paper direct sale to automated programmatic buying, and the progression is a lucrative one for publishers and buyers alike. By broadcasting all video opportunity, vis-à-vis the bid requests to buyers, sellers gain a unique look into their market and can fulfil their inventory through a new more advanced channel. Header tag makes the buy-side aware of the available supply, so the publisher can broadcast 100% of their inventory and sell it at a price premium rather than a potentially limited price by direct sale.
Constraints in Mobile Web
Header bidding is deployed on mobile alongside desktop in almost all cases, but unique challenges exist when operating on the mobile web side. While desktop header bidding has seen significant improvements in minimising latency, this spotlight has moved onto the mobile web platform where network latencies, data consumption, and battery life present concerns in ensuring the best possible mobile user experience. Google has announced Accelerated Mobile Pages as a step towards resolving some of these issues.
Other factors that contribute to complexity are variations in screen size/resolution/DPI, and operating systems/browser variations. Different operating systems and web browsers determine how the code is interpreted and how the page content is displayed, which can lead to issues in presentation speed if not properly optimised.
The concepts around user matching also differ, specifically in Apple iOS devices where Safari is regarded as an unfavourable environment for data-driven marketers. This is due to cross-domain cookie restrictions that aren’t present within the Google Android-based Chrome environment. Since the Safari mobile web browser blocks third-party cookies, mobile web inventory running within Android will yield higher. Marketers have improved matching algorithms with probabilistic methods to stem these limitations, but those methods are still inferior to a deterministic cookie match.
Constraints in Mobile App (In-App)
The vast majority of map inventory is monetised by incumbent mobile ad serving providers, who use price estimates of bids from demand sources to select who gets to serve an ad. These ad networks tend to have high take-rates and lack transparency into the actual source of demand. This means that publishers do not get access to their own marketplace data, and can lose out on revenue.
The greatest challenges indicated by publishers are implementing one or more proprietary SDKs and the fact that “header” in general refers to a construct of a web page which doesn’t exist natively in apps. These challenges can be alleviated by running a web frame style implementation, either iOS UIWebView or Android WebViewClient, where the browser still exists, embedded within the app. This could be used to facilitate a sticky banner in the footer of the app or a floating overlay type execution.
Using this style implementation reduces the complexity of implementing additional monetisation SDKs. Ongoing changes can also become agile since there is no longer a requirement to push app store updates to edge installs, thereby eliminating a lengthy propagation time for changes. Traditionally the barriers to entry have been high with product teams focusing on core app functionality outside of the advertising experience. By introducing the header concept within the app experience, a number of efficiencies can be unlocked.