Mobile app advertisers have been slower than their web counterparts to embrace programmatic-style RTB auctions.
That’s starting to change as more app publishers test in-app bidding and see significant lifts in ARPDAU (average revenue per daily user).
“Publishers are pushing their ad networks to get into bidding, and we’re beginning to see a snowball effect,” said David Gregson, a product manager at MoPub.
But the path to wider adoption of in-app programmatic auctions will be different than on the web, in part because of the long-established dynamics between app publishers and their partners, the emergence of different standards in apps vs. web and the fact that mobile technology is very different from web technology.
Here are five of the main differences between in-app bidding and its web-based sibling.
Ad network dominance
Web publishers took to header bidding like ducks to water when the practice started to gain traction around 2014. Frustration with Google’s advantage in the auction helped grease header bidding’s wide adoption.
“The industry was looking to find alternative solutions to the DFP and AdX monopoly,” said Prajwal Barthur, VP of product at InMobi.
But in the app ecosystem there hasn’t been the same motivation.
In the mobile app world, ad networks dominate, and mediation platforms centralize access to inventory across ad networks. App publishers are accustomed to maximizing their yield in waterfall-based mediation platforms.
One reason ad networks have maintained a strong foothold with app publishers has to do with mobile connection speeds and reliability.
With desktop header bidding, the pricing and bidding happens through multiple exchanges simultaneously as the page loads. But on mobile, where bandwidth might be lower and there is no header, it created a better user experience for publishers to work through an SDK and asynchronously cache ads ahead of time.
“Mediation platforms allowed publishers to choose the order in which they wanted to call ad networks, but didn’t give a per-impression price,” Gregson said.
Ad networks are still usually paid out on a cost-per-install or cost-per-action basis rather than by impression.
“That is why we’re not in a unified auction-centric world yet, although we’re getting there,” Gregson said. “It’s a learning curve for ad networks, trying to work out how to bid on a per-impression basis if expenses are paid out on a CPI basis.”
There’s also isn’t a standard way to bid into apps.
As opposed to the web, where there are shared standards, each mobile ad network applies its own set of rules for how to load an ad, notify publishers of availability, render the ad and pre-cache it. This “makes the adoption of in-app bidding less standardized and hence more complex,” said Nimrod Zuta, VP of product at ironSource.
When demand comes from an ad network SDK, the network has a direct relationship with the publisher. A piece of code is integrated into the app itself. This type of relationship doesn’t exist in web browsing. Mobile ad networks don’t buy on the open exchange or provide real-time bids for available impressions.
And although by now almost all web-based header bidding has been standardized on first-price auctions – that’s even true for Google – in-app auctions don’t clear in a standardized or transparent way, said David Simon, CRO of Fyber.
“It’s common for bidders to bid into an SSP auction via a line item and then again in an in-app header, thus bidding against themselves,” he said.
One of the major selling points of header bidding is transparency. But one of the biggest barriers to wider adoption of unified auctions in apps is the lack of open source standards to support them.
“Desktop rode the open source wave with Prebid.js leading the header-bidding initiative for transparency,” said InMobi’s Barthur. “Lots of SSPs supported the same and started building on top of Prebid.”
But “this is still not the case on the mobile side,” he said.
In the desktop world, there’s Prebid, Index Exchange’s header tag and Amazon’s Transparent Ad Marketplace. But apps didn't get Prebid support until 2017 with the release of Prebid Mobile.
Even with an open source in-app bidding solution available, however, many app publishers still work with mediation platforms to open up their waterfall. And not every mediation platform supports every ad network.
Playing both sides
Also unlike on the web, all app developers are both buyers and sellers of inventory. As a result, the incentive for developers to do “combination deals with their monetization partners is much higher,” Fyber’s Simon said.
“Ad spend credits, revenue and CPM guarantees are much more common,” Simon said. “Monetization and the efficacy of the waterfall or the yield from an auction is often heavily influenced by deals that happen independently of the auction itself.”
At the same time, performance-focused DSPs prefer pricing at scale in their bidding algorithms, which doesn’t jibe with how first-price auctions function, Barthur said.
“We are still in the process of making the programmatic pipes work for unified auctions,” he said. “This is primarily dependent on how demand looks at such inventory.”
But despite the challenges and the gradual pace of adoption, in-app bidding is slowly becoming more the norm for app publishers, Barthur said.
Over the past couple of years, publishers have increasingly been testing a hybrid approach that combines the waterfall and unified auctions to ensure they don’t lose any revenue. Publishers are also using in-app bidding to test different partners to see which ones yield the best revenue for their inventory.
The testing process is creating benchmarks that publishers can use to justify the move to more RTB-like setups.
InMobi, for example, is seeing 20% to 30% of traffic coming in through its unified auction platform.
And “it’s scaling well,” Barthur said.
Mobile header bidding ad spend grew 20% year over year, according to data released by PubMatic on Thursday. In Q2, in-app bidding rose 26% YoY, outpacing the 18% growth rate for mobile web.
Updated Aug. 21 at 6:15 p.m. to reflect the mention of Prebid Mobile.