Last week, Facebook announced that it would begin allowing mobile web publishers to access demand on the Facebook Audience Network (FAN) via header bidding, a method of ad fulfillment that it had previously not permitted publishers to use. Facebook, which is often seen as operating a walled garden with respect to access to its inventory, user data, and tools chain, is partnering with six ad tech firms that operate header bidding tools to give publishers access to FAN demand.
Header bidding has instigated a massive sea change in the world of desktop and mobile web advertising, but it has had almost no impact on in-app advertising. Whereas most web ad inventory used to be rendered via waterfall fulfillment — querying ad exchanges in decreasing order of historical average bid CPM — Facebook claims that about 70% of web publishers now use header bidding to serve ads.
It should be noted that the header bidding paradigm emerged as a response to Google’s primacy with AdX, since AdX is given the first look at inventory when a publisher works with DoubleClick for Publishers (DFP) using a setting called Dynamic Allocation. But this dynamic is changing slowly with Google developing products to make the process of serving ads with DFP more transparent, although many people still think that header bidding has advantages over working directly with Google through their “header bidding killer” product, EBDA.
What about apps?
On mobile, header bidding is really only applicable to the web: while a few exchanges / SSPs offer in-app header bidding solutions for mobile app developers, the approach still isn’t very popular for publishers. Right now, the mobile monetization landscape looks much like the pre-header bidding desktop ecosystem did a few years ago: a middle layer of ad mediation, often run by companies that also own demand sources, operating waterfalls of demand pools (ad networks) that can only be optimized in a very onerous, time intensive process.
One reason that in-app header bidding hasn’t taken off is that most developers are loath to experiment with new tools that require an SDK implementation. App size bloat is one consideration, but the main problem is implementation and maintenance overhead, which requires engineering resources. For a lot of smaller and even mid-sized developers, an SDK for an advertising-related tool, especially for an esoteric technology like header bidding, is a non-starter: even as advertising monetization generates an increasing amount of revenues for many app developers, the advertising ecosystem is viewed with a skeptical eye (probably rightfully so), and the implementation, testing, and maintenance of external SDKs can be a deal breaker given that most of the ad tech tools pitched to publishers are suspicious and often of dubious value.
The second reason that in-app header bidding hasn’t taken off is simply that most demand is pooled in Facebook and the big networks with direct access to inventory (check Singular’s 2016 ROI report for a reasonable list of the largest 20 mobile ad networks) and generally isn’t available on exchanges. These big networks don’t stand to gain from a header bidding environment, and they control the vast majority of inventory on mobile. Mobile mediation provider Appodeal put together a guide to simulating in-app header bidding via a mediation platform, but until exchanges become a reliable and considerable source of impressions on mobile, this kind of manual, short-term optimization is probably the closest to header bidding that app publishers can get.