Mobile App Header Bidding

Header bidding represents both the implementation of the general concept, and, alternatively, an approach to digital advertising where multiple vendors compete on an impression level - which we've discussed several times as listed here. When discussed in the mobile app concept, some say that because there is no "header" - referring to the HTML- and javascript-specific implementation - there can be no header bidding. This view substantially misses the point. Header bidding isn't about whether the web browser, through javascript loaded in the HTML "head" section, calls various header bidders. Instead, mobile header bidding is the notion that multiple sources of demand are competing concurrently for an impression - as opposed to the more traditional model of backfills and mediation that are currently more prevalent in app. 

MobileAppHeaderBidding-Banner.jpg

As alluded to above, there are material differences between how app "header bidding" works and how it works in web. Specifically, in the app context, there is no browser (for the sake of this discussion - this isn't exactly true). Instead, ads in apps are often served through an SDK (software development kit - plugins that the app developer adds to their app for certain functionality). The SDK is written in the language of the app's operating system (again... more or less), and exposes certain functionality to the app developer. For example, the SDK can be called to initiate an ad auction and cache the resulting ad, so that it's available for the app without a wireless connection in the future. This means the developer doesn't need to implement this functionality and it also ensures a malicious app developer doesn't undermine the integrity of the calls being made by the SDK. Thus viewability, click, and similar pixels are only delivered when they should be, as regulated by the SDK. 

Historically, mobile app advertising has been done through SDKs. Major app advertising providers have worked aggressively to distribute their SDKs, including the largest players - AdMob (Google), MoPub (Twitter), FAN (Facebook), Millenial (Oath), InMobi and AppLovin'. SDKs can be integrated into mediation platforms that can trigger ad calls and, based on the capability of the SDK platform, cache the results. Some SDKs can bid on a CPM basis, and some do not - meaning the mediation platform sometimes estimate that likely value of those SDKs based on historical data. The SDK then renders the resulting ad. This requires that the SDK be installed in the app to participate in the mediation.

The shift from mediation to "header bidding" can be best considered through prebid mobile's implementation. Here, the app developer installs only the prebid mobile SDK, which makes impression-level calls to prebid server. Prebid server is a server-side auction, and every bidder bids into the auction held on the prebid server rather than having an SDK in the app itself. The winner's ad contents are delivered to the app's primary ad server (which also must be installed - but only 2 SDKs are needed here) as javascript, which can be cached and delivered as appropriate. This means, much like as in header bidding on the web, the barriers to entry for each bidder are lower and the customizations that each demand partner can bring go down. 

Currently, app advertising includes highly custom integrations. This includes, for example, incentivized video views in exchange for in-game currency, moments, etc. Much like we're seeing in the web context, the appeal of header bidding will spread as far as it can. For simple display advertising, it is inevitable that a single SDK frontend for header bidding will grow materially through the app ecosystem, despite relatively limited traction today - this will likely change in 2018. Compelling existing apps to install new SDKs is always challenging, though as Prebid gets more partners, it will likely proliferate. In turn, this means that both TripleLift's standard exchange and Header Direct (as well as its potential competitors) will have an easier time accessing an increasingly large pool of apps without requiring app-by-app SDK installation. Some companies that rely on exclusive publisher relationships may not participate in this ecosystem, but much like header bidding on web, this is a tenuous position for such companies. It is also inevitable that header bidding SDKs will expand in the app functionality that they expose to developers, meaning SDKs will increasingly need to offer additional non-monetization functionality - or deliver particularly stronger CPMs when installed - to justify being installed as app header bidding catches on.