Header bidding is so immensely popular among publishers at this point, there’s a call to adapt its core principles to as many environments as possible. Naturally, vendor companies have been hustling to bring products to market to sate publishers’ appetite for demand that header bidding has piqued.
Some of these new implementations push the limits of what we’d normally consider header bidding, per se—server-to-server implementations, header for video, bidding for apps. In the app, there isn’t even a header.
But of course, major industry players wouldn’t let something so trivial as the absence of a page header get in the way of applying the header bidding concept to the booming app space. In-app bidding is a thing now. But at this early stage, there’s no industry consensus about the “right” way to do in-app bidding, and publishers need answers to a lot of questions about what sort of strategy they should take, and why.
AdMonsters Staff Writer Brian LaRue called up OpenX’s Director of Product Management, Justin Re, and the company’s VP of Business Development, Maggie Mesa, for a full introductory briefing. Justin and Maggie explained how in-app bidding differs from header bidding in a web browser environment, what resources publishers need to get started, what goes into different implementations, and how the practice dovetails with what publishers may already be doing.
BRIAN LaRUE: How does in-app bidding work, particularly compared to web-based header bidding?
JUSTIN RE: While there is no header in-app, the concept is ultimately the same as the technology powering header bidding on desktop. A key difference is that there are currently two ways to approach the in app implementation.
The first relies on a full SDK that is implemented along side a publisher’s primary monetization SDK. It takes complete control of the impression by intercepting the initial request, sending it out to the exchange or server-side mediation, returning the price as a key value into the primary SDK and finally rendering the ad-view if the bidder is successful. The second approach, considered a lighter more flexible version, involves code that sits directly inside a publisher’s primary SDK that is controlled via an API. That code fires off a request to the mediation partner or exchange and they send back a price as a key value in the same way as the other implementation.
The main difference between the two relates to control. With the lighter implementation a publisher can control all aspects of the bidder via an API. For example, they have control over when the exchange is called and how the ad is eventually rendered. As a result of having control over when the exchange is called, they also have control over how they cache the response.
So far we’ve seen a strong gravitation towards what we consider a lighter implementation. Importantly, both options deliver publishers the desired benefits of header bidding — increased competition and more revenue.
BRIAN: What are the benefits of either implementation, and what kind of publishers do you see reaching for each?
JUSTIN: A publisher’s level of sophistication is largely responsible for the divide between adoption of the different implementation types. At OpenX we work directly with our publisher partners to find the best fit for them. Even though each type of implementation can benefit publishers, as the technology becomes more widely adopted we expect more publishers to benefit from the lighter implementation.
Because MoPub’s SDK is open source, a lot of the larger, more sophisticated publishers have already customized their own versions of it and are, in turn, more comfortable incorporating the lighter implementation into their existing SDK. Emerging publishers often don’t have the insight, engineering resources, or comfort level to do that.
MAGGIE: To that point, the decision to go with one method of implementation over another depends on several other factors beyond size. Ultimately, publishers are interested in maximizing competition on an ad request or impression-level basis, but there is still a need to validate “header bidding” technology as a big market on the mobile side like we’ve done with desktop.
Mobile publishers are eager to test new partners and ideas, however they must also be sensitive to the size of their app. There are certain SDKs they have to work with, for tracking, attribution, a variety of things, and they have to balance those needs with new partnerships. This is where having a lighter version benefits publishers, it provides a way to introduce another partner without adding too much weight to the app.
Publishers that choose to adopt the out-of-the-box SDK, or standard implementation, are usually more focused on the content and less focused around the monetization effort. Alternately, the lion’s share of larger apps we work with have a very robust and mature strategy around mobile in-app monetization. When MoPub launched, they didn’t have support for some formats like rewarded video and native that a lot of publishers were already utilizing in their monetization strategies. Those publishers were already tweaking MoPub’s SDK for reasons outside of header bidder graphs.
BRIAN: On the publisher side, how is the integration different from a web-based header integration?
MAGGIE: Learnings from desktop helped speed up the integration process in-app, with the understanding that it is going to be slightly different on mobile. I’ve been selling mobile SDKs for so long that it’s kind of a running joke: “Integrate our SDK with three easy steps.” But that’s really more set around the primary SDK. Pieces of code that get added to specific libraries aren’t a full-blown SDK. Our solution is an adapter.
JUSTIN: At the start of integration, publishers receive a one-page integration doc and a package of code, and access to the bidder manager API. They also benefit from OpenX’s automation script that helps them create all the new line items required for each price bucket. With up to 90 of these recommended, this can save them a ton of time. Publisher’s can get up and running and testing within a couple of hours.
It’s also important to keep in mind that if you’re adding anything into the app, an app store update is required. So, most of the time it isn’t about how long it takes to integrate the code, rather it is about fitting into the app developers’ version life cycle. Code can be sitting inside a number of apps for months waiting for that new version to go up.
MAGGIE: I actually know folks on iOS that update only once a year. From a pure integration standpoint, that is different for mobile in-app versus desktop.
BRIAN: How might in-app bidding help sellers manage varied demand sources and all the different ad formats in the app space?
MAGGIE: The rise of this kind of technology is a reflection of where the mobile ecosystem is going in general. Four years ago, 99.9% if not 100% of the demand flowing through the mobile programmatic marketplace came from app install campaigns from gaming advertisers, or oftentimes the publisher’s competition. As the market matured, players like Uber and Lyft, travel and leisure apps like HotelTonight and Expedia, emerged. Now amazing new verticals, like fantasy sports, and shopping apps such as Wish, are being really aggressive with their programmatic strategies.
Publishers are asking: How do we access brand demand, gaming demand, rewardable video, native, plus inventory we wouldn’t see from existing SDK partners? Gaining access to differentiated demand without having to integrate a full-stack SDK with multiple libraries, complements their existing strategy without adding a lot of weight to their app. This is one area where working with players like OpenX, who have existing relationships with several of the leading brand advertisers, can add incremental value.
BRIAN: That said, is it possible to leverage a wrapper in-app the way that publishers are doing with web?
JUSTIN: Yes, but there’s one main difference: Publishers have been creating their own containers in mobile app for a really long time. An app monetization SDK’s job is to manage multiple mediation partners. A lot of the sophisticated app publishers have already had the ability to call multiple different server-side partners and have them bid into their mediation stacks—so they’ve inherently created their own containers, they’re just not necessarily containers for bidders.
A container concept within the bidder-specific side of mediation in-app is probably going to happen. But it’s probably not going to be productized in the same way that it has been in desktop. Our bidder API is technically a wrapper, except it only controls our bidder for the moment. Eventually as the market matures we will likely add the ability for our Bidder API to manager other bidders as well.
BRIAN: I’m curious what you’ve been hearing from publishers about latency.
JUSTIN: We haven’t heard about any concerns at all—almost to the contrary. Latency concerns have been taken right out of the conversation in mobile by pre-loading or pre-caching ads. Every time the SDK needs a new ad, there is already one ready to go and in the chamber, so to speak, for that next call as it comes up. The publisher has complete control over the timing of this via the Bidder API.
Initiatives to create a better, faster experience for the user, like what we’ve seen so far with AMP, will potentially lead to more innovation on the desktop side. Google AMP allows Google to deliver pages at super speed, because they’ve cached the whole page upfront in their CDM. They load the content first and the ad second, which is where the whole Internet is eventually going to go. And they’ve now just released AMP for Ads, which pre-caches an ad inside AMP pages. I think that tech will become standard long-term.