The Hold-Up — Why it’s taking so long to adopt in-app bidding

In-app bidding has been the talk of the mobile industry for well over a year, yet only a small percentage of revenue today is generated through this method. While everyone can agree that the long-term benefits of in-app bidding will propel the whole industry forward, the short-term impact has been limited. What’s holding up development and adoption of this new technology, and why? There are two main factors to consider here — the technology itself and the industry players.

Technological challenges

Part of the problem involves the sheer complexity of the technology itself, and how it gets applied to the in-app environment. In the web ecosystem, there was an established technological standard for a long time before header bidding came along, making for a stable environment with shared standards across the industry. Header bidding over the web began as a client-side js wrapper (prebid.js among others), and as it evolved into server wrappers, the RTB protocol was put in place to facilitate communication between the various SSPs and ad exchange servers, and their designated header bidding wrapper solutions. As for demand side platforms, they were relatively agnostic to the inner workings of header-bidder-to-ad-exchange communication, and once that part of the funnel was up and running, the process of actually rendering the ad of a demand partner was unconnected to how that ad was then delivered.

When looking at the mobile app space, it’s important to bear in mind that the mobile gaming industry has a huge influence in shaping the ecosystem and the technology underpinning it. This is largely because games make up such a big part of the app ecosystem both in terms of user base and time spent, and even just overall number of apps. Since the game industry is heavily reliant on ad networks (and video ad networks in particular) to monetize their inventory, the shift to bidding on in-app inventory involves SDK networks, which provide service using proprietary client-to-server protocols.

Due to the magnitude of capabilities that SDKs can enable for native apps in comparison to what’s standard for web browsers, this ecosystem is primarily API-based. Each ad network applies its own set of rules on how to load an ad, notify availability, render the ad, and pre-cache it (as the vast majority of ads over games are video and playable ads) — effectively working in an off-standard-innovation mode, very different from the shared standards world of the web.

No wonder then, that in the mobile apps space, in-app bidding solutions are being provided by ad mediation platforms, which have already had to deal with creating a way to support each unique SDK’s capabilities within one platform.

In an in-app bidding environment, the mediation platform backend server is required to connect with various SDK ad networks over server-to-server communication, using a standard protocol, yet they still have to maintain support for all the various non-standard-proprietary ‘goodies’ that ad networks provide via their SDKs. This complexity has lead to adoption cycles that are only now coming to maturity.

The Players

While most industry stakeholders agree that in-app bidding will push the industry forward and drive greater efficiency and automation, it brings with it specific challenges for each of the main industry players, which has held back development and adoption rates.

Networks

Bidding brings many benefits to SDK networks, such as increased visibility into ad inventory (which in a waterfall environment is currently somewhat obscure), the ability to compete with other demand sources on the impression level, and therefore ultimately more opportunities to place ads of their advertisers. But it also brings with it higher risk on profitability, since the level of complexity increases significantly. Today, advertisers pay for performance and evaluate ad networks on their ability to hit those performance goals, and that is unlikely to change. This means that ad networks which for years have operated on a rev-share basis, will now be required to commit to a bid for an impression on the auction level, regardless of how that ad will perform and whether or not the advertiser’s goal will be met.

In addition, for SDK networks who currently own and run their own full technology stack, the transition to in-app bidding represents a shift to an increasing reliance on in-app auctioning platforms. Instead of handling ad serving and delivery in-house end-to-end, SDK-based ad networks will have to integrate directly into the mediation platforms’ servers, which is heavier and requires a more labour-intensive integration and testing process. Today, joining a mediation platform simply involves developing a client-side adaptor, but in an in-app bidding world, the integration necessitates building a highly-complex asynchronous client-to-server-to-server-to-client flow.

Mediation Platforms

For the platforms, developing the technology to support in-app bidding represented a chicken and egg situation. Without any SDK networks ready with bidders, a solution to support in-app bidding wouldn’t have driven additional revenue for the publisher. Only once networks took meaningful strides towards developing bidders which could plug into a monetization management platform, did it open the doors for platforms to develop their solutions.

Publishers

While publishers have been the biggest advocates for the adoption of in-app bidding, the truth is, many are already leveraging multiple instances in sophisticated configurations which essentially function like a semi in-app bidding environment. Since the primary focus for publishers is ultimately performance, and because not every major network has developed a bidder, transitioning fully to in-app bidding is unlikely at this stage to result in an increase in performance. In a situation where publishers can use multiple instances to effectively create a setup which closely mirrors a bidding environment, we’re unlikely to see them fully adopt in-app bidding technology across all their traffic until the biggest networks support bidding, and they can be assured of no loss in revenue.

Having said this, as the increase in complexity created by in-app bidding is also driving an increase of risk for the ad networks and/or their advertisers, publishers are the real winners of this shift. There will be more competition for their inventory, bidding will drive a commit-to-pay per impression reality, and all those benefits will take place while also simplifying and optimizing a publisher’s operations. Manually setting up a waterfall will eventually become a thing of the past, and monetization teams will be able to shift to more sophisticated activities, such as higher level cohorts analysis, more extensive A/B testing, and working to better fuse monetization efforts with marketing activities.

While the ramp up to adoption for in-app bidding has taken some time, it has nevertheless picked up considerable speed in the last year. 2020 is likely to see much wider implementation of the technology, with publishers increasingly moving more of their inventory into a bidding environment as more of the major networks debut their bidders, and the potential of increased revenue and efficiency is realized.