In recent months there has been a spike in conversations taking place around "header bidding for apps" and "flattening the waterfall". As is often the case in ad-tech, this has led to a wave of new acronyms and terminology entering the ecosystem, as each platform’s marketing teams race to convince publishers that their approach is the only way forward.
But what are the actual product changes that are taking place and more importantly, how might these changes affect a publisher’s ad revenue?
To recap, the ad monetization landscape for many publishers has not changed a great deal in recent years. The majority of in-app inventory is still monetized through SDK-based ad networks, which do not provide a real time bid for each available impression. This is in contrast to the programmatic marketplaces which exist in the ecosystem that are able to provide real time bid data at the user level.
However, the highest eCPMs are still achieved through "black box", SDK-based ad networks, due to a combination of ad unit innovation and strong advertiser relationships. Whilst the data publishers have access to under these conditions is limited, ultimately the revenue is what matters most, and SDKs still win here.
In an attempt to move closer to a "programmatic" solution, several SDK-based demand sources have added support for multiple ad placements / zones, through which publishers are able to assign a hard eCPM floor (or in some cases a fixed price). Whilst this does ultimately provide greater control over the eCPM a publisher can attempt to fill an available impression at, there are still a number of issues:
- Setting up and managing multiple zones and eCPM floors is time consuming when applied across multiple countries, ad formats and networks;
- There is still a need for an "ad waterfall", as many network price floors simply involve a "yes" or "no" approach to filling an ad request at a certain minimum price -- very few are dynamic in nature.
As a result of the above, many publishers are not utilizing floors at all, and leave prioritization of each network to be determined by a mediator’s "auto eCPM" features.
This too has its downsides, as it means that a network with a predicted price of $20 will actually contain a range of campaigns paying out significantly more / less than this value. The mediator has no way of cherry-picking the highest campaigns from across multiple SDK-based demand sources to ensure the highest paying are shown first.
Mediation’s New Era
Advanced Bidding, Fair Bids, Unified Auction, Parallel Bidding. These are just a handful of the product names that have appeared in recent months when it comes ad monetisation’s new era.
Essentially, they are all describing the same end goal; a landscape where all enabled demand sources, including SDK-based networks, are able to simultaneously submit a real-time bid for an available impression.
The key change happening on a technical level is that some SDK-based ad networks are now working with mediators to provide a real time bid price, meaning more premium demand can partake in a single auction.
Whilst this new movement is exciting for the app industry as a whole, it’s worth noting some fundamental differences between a true Open RTB auction, and the SDK bidding model which is currently unfolding.
Firstly, in traditional RTB marketplaces, the bid price that is submitted by programmatic demand sources is a hard (committed) CPM bid, and represents the amount an advertiser will actually pay the publisher. This differs to SDK-based ad networks, where the majority of demand is performance based (CPI/CPA).
This means that if networks want to provide a hard minimum bid price, they need to rely on their own bid optimization to ensure they can accurately convert performance-based bids to CPM bids.
Alternatively, some networks will look to provide a soft, estimated bid, where the actual price could be higher or lower than the bid they submit to the auction. This puts a responsibility on the mediator to ensure the estimated bids are accurate, and if not, that they are discounted accordingly when the auction is run.
Whilst upfront, it’s natural to think a hard bid price would be a better option over a soft bid price, there are 2 sides to every coin, as explained by Colin Behr, VP of Business Development at Vungle:
"The difference between working on a hard bid vs soft bid model comes down to the rev-share alignment with the publisher. Let’s take a traditional antiques auction house as an example. An antiques dealer who shares the proceeds with the seller is motivated very differently to one who must pay upfront before selling the item at auction.
When working on a revenue share, the dealer will be motivated to get the maximum price possible for both themselves and the seller. However, should the dealer be required to pay for an item upfront, their motivation will be to pay as little as possible in order to maximize their own later profits. This dynamic is exaggerated by the delayed outcome - the antique dealer won’t know the price the item will fetch in auction until a later point, thus requiring them to widen their predicted margin to compensate for potential losses.
In a similar vein, many publishers currently work with ad networks whose primary advertiser base is comprised of CPI/CPA advertisers. Those networks, therefore, must operate in a similar manner to the antiques dealer, predicting the potential value of each impression. In a revenue sharing arrangement, both the publisher and network share in the upside, while the network continues to improve advertiser results (soft bid model). In a hard bid model, the network must factor in additional risk before deciding how much to bid."
But surely, competition should eliminate excessive margins? Or so at least the theory goes. In reality, SDK-based ad networks are naturally able to yield higher results than non-SDK based companies. Given technical restrictions, publishers typically work with less than 5 ad monetization SDKs. In a world with limited competition, this may lead to a downward pressure on prices if interests are misaligned.
Demand sources want to ensure that despite providing real time bid data, they are still able to retain their SDK penetration. One way in which they are doing this is by obscuring the actual ad serving logic from the mediator/publisher.
In a standard OpenRTB auction, the ad ID/markup is provided before the auction takes place via an API response, and proves that a demand source is able to fulfil the available request.
In SDK bidding the majority of demand sources will provide a bid token in response to an ad request from a mediation layer. This bid token can then be taken to the auction, where it is sent to the network’s bidder. The network’s bidder will then respond to the mediation layer with a bid price and an ad ID.
The benefits to the publisher are that demand sources are able to continue innovating on their ad formats in order to increase eCPMs and the overall ad experience. The downsides are that multiple ad network adapters are still a reality, and granular bid and frequency capping data is not yet easily available on an advertiser level.
It’s also worth noting that there is one comparison which is inaccurate when talking about this new era, and that is to define this new advancement as "header bidding for mobile". As many know, in-app content is structured in a very different way to web pages, and fundamentally the concept of "headers" does not exist. In-app inventory can gain a lot of value from removing inefficiencies for publishers, in a similar way to what header bidding did for traditional web, but on a technology level it needs to be approached from the ground up.
The End of the Waterfall?
Publishers want higher levels of real time competition between ad sources, which means a parallel bidding model where multiple demand partners are called to compete simultaneously is gaining greater traction. As a result, many think the traditional ad waterfall will become obsolete.
In time, this may well be true. However, I believe it’s premature to say this is the end of the waterfall for 2 main reasons.
Firstly, as already mentioned, the transition period between legacy mediation and SDK bidding will be slow. Many networks are still on the fence as to whether they will support what is a big change both technically and strategically. If, as a publisher, you have a mix of demand types in your monetization stack, then this will likely use a hybrid model, where the auction occurs and the highest real time price is compared to the highest paying predicted price / floor.
Secondly, many publishers are unsure of the potential negatives associated with running a model where all demand sources are competing in real time. Technically, it would be the ultimate form of pricing efficiency, but as mentioned previously, could this also lead to a "race to the bottom" price war? The jury is still out, but many publishers want the option of preserving the first call (and potentially subsequent calls, too) for a specific demand partner at a specific price, to ensure their premium impressions still sell at what the publisher deems to be a fair price.
"Whoever will end up as the winners, and whatever it'll end up being called, the next generation of in-app mobile ad tech is a genuinely transformational opportunity for publishers & developers. Firstly, it has the potential to open up the floodgates of brand spend. Secondly, it'll provide opportunities for SDK-consolidation and to reduce the ad-tech stack size. Lastly - and perhaps most importantly - having access to bid-stream data will provide an opportunity for hugely exciting user-level optimizations; moving away from historic averages and into actuals & predictions."