Header tags have been in use by Rubicon Project since 2012. Now its header bidding solution is going into beta-testing for in-app advertising.

ExchangeWire: What is in-app header bidding and, more importantly, how does the process work?

Joe Prusz: Rubicon Project operates one of the largest mobile exchanges in the world, connecting thousands of brands and marketers to more than one billion users across tens of thousands of mobile applications and the mobile web. Accordingly, we’re uniquely positioned to deliver the industry’s first and only header bidding solution, FastLane, available for both in-app mobile and desktop inventory, covering the entire ecosystem.

The backend auction fundamentals of FastLane are the exact same whether it’s Mobile App, Mobile Web, or Desktop. However, Fastlane for Mobile Apps requires significantly more technology on the mobile device itself and, therefore, requires bullet-proof tech inside our SDK in order to efficiently call our exchange and return a header bid to the publisher’s ad server of choice (if it isn’t our own Mobile Ad Server). This is a game changer, and a first for the industry, as Mobile App Developers are often victims of an overly complex and burdensome mobile mediation waterfall with myriad disparate demand sources that do not effectively compete with each other, and in turn deliver a sub-optimal CPM for the Seller. These Mobile App Sellers are in desperate need of a high-quality exchange to maximise mobile revenue from the increasingly powerful programmatic buyers, so bids compete at every price point directly in the ad server, as opposed to only inside one or two line items.

Importantly, many of our desktop-first competitors in header-bidding have limited (or likely zero) experience working on mobile devices directly. We have over half a decade of experience working with SDKs on the mobile device directly, and this experience is hard to come by.

How will publishers/app developers deploy the technology? What's the process involved?

App developers will integrate our SDK and ensure that Rubicon Project is called first on every impression via our SDK. Our SDK will call our exchange to run an auction on every impression, identifying the highest bidder that satisfies all of the app developer’s business rules (e.g., approved advertisers, price floors, private marketplace rules, etc) and then return a key/value pair corresponding to the approved bid back to the device. Our SDK will then hand the request over to the app developer’s primary Ad Server, along with the key/value pair, which in turn lights up the corresponding Rubicon Project line item in the ad server. The mobile ad server then executes its decisioning logic, and if our line item is chosen as the winner, the ad server will invoke our SDK to deliver the cached ad. It’s important to note here that we aren’t changing the logic of the publisher’s mobile ad server, but rather sending more accurate data into the ad server to ensure the most optimal decision.

Why do mobile app developers/publishers need in-app header bidding?

Header bidding, at its core, allows demand to break out of the waterfall it’s trapped in, so that it runs in the ad server at the exact priority it deserves. The more high-value demand that exists, the more critical it is that it runs at the correct priority. Given that Rubicon Project is the clear leader in Mobile Private Marketplaces – with over 1,400% growth over the last year – header-bidding is critical in delivering this high-CPM demand to the exact priority in the publisher’s mobile ad server. And not to mention PMP buyers will accelerate their spend on Rubicon Project’s Orders platform when their PMP campaigns are being delivered more efficiently within a publisher’s mobile ad server.

Additionally, in mobile, we see a diversity of demand that makes header-bidding extremely important. For example, inside of one standard mobile interstitial ad unit, a seller can request a standard 320x480 banner, a 300x250 banner, a rich-media ad, a full-screen video, a native ad, not to mention all of the additional private marketplace demand that can drive up the CPM of any of these creatives. However, this diverse demand often lives within separate buyers, using separate SDKs, server-to-server networks, ad tags, DSPs, etc. This means that a seller might have to execute a waterfall with many different buyers, each running disparate auctions, ensuring a sub-optimal CPM, not to mention a poor user experience for the consumer. With Fastlane for Mobile Apps, the highest programmatic buyer is identified quickly, and then accurately delivered to the appropriate line-item in the ad server, bypassing the byzantine mobile waterfall.

And, of course, the publisher always has the option of calling the existing waterfall – that never has to change if the publisher doesn’t want it to. What does change is the ability to maximise revenue for the app developer and create a better user experience for the consumer by decreasing latency from the inefficient mediation waterfall.

What problems are you solving with this?

FastLane for Mobile App is a key solution for app developers to realise additional resources, as we’ve seen with publishers utilising FastLane for desktop, who have experienced CPM rates increase of up to 300% versus standard tag implementation. It also solves for the inefficient and byzantine mobile mediation waterfall that is a burden on mobile app developers, as with FastLane we’re ensuring that high-quality demand is elevated to the proper priority in the ad server, delivering better performance for the advertiser and higher CPMs for the publisher. And, lastly, we're making sure that mobile demand, which is often more diverse than desktop demand, can efficiently compete for inventory within the mobile ad server.

Is this a mechanism to introduce external demand?

FastLane, whether in mobile or desktop, helps advertisers more effectively reach their desired audience, increasing their performance and increasing the value for sellers. Accordingly, we expect FastLane to drive even more high-quality demand, especially via private marketplaces, into our Orders platform, the most widely adopted orders solution in the industry, and into our Sellers’ pockets.

Some have argued that header-bidding on the web is a DFP-hack to allow external demand to compete with 'dynamic allocation'. Is this a similar situation with in-app monetisation being a closed process?

Without question FastLane helps to efficiently bring more demand to the seller, whether they’re using DFP, MoPub, or any other ad server across both mobile and desktop. And because we now operate one of the largest exchanges in both mobile and desktop (and a Top 3 exchange for 'seller quality' across both as well, according to Pixalate), we’re continuing to see more buyers consolidate their spend on our platform – a platform that they trust to deliver the highest-quality inventory and premium audiences at scale across both mobile and desktop.