Header Bidding: is it worth it?
Header Bidding: is it worth it?
In ad-tech new doesn’t always mean better
Veterans of the mobile ad space are no stranger to the introduction of new cutting edge technology promised to “revolutionize the industry.” There have been many changes in ad-types, new platforms, new buying strategies through the years. Some have been successful (reward video, real time bidding ) some less-so (remember real-life rewards?) and some that are hit-or-miss (*ahem* native). And while the actual monetization achieved from each new technology is varied, one commonality with all new mobile ad technology is the effort required for making early-level iterations work: new serving technology, new problems to test, and new methods to measure. Each new technology can create problems easily offsetting any gain. The industry is abuzz with the merits of header bidding but question we get most often is “should I try it?”
What is header bidding (really)?
The definition of header bidding and the details have been covered by many pundits and the various companies who offer a variation of the technology, so we’ll suffice with a publisher-centric summary:
Mobile Header Bidding can be defined as technology allowing buyers to dynamically buy early-level inventory, with the aim of increasing access to top-tier inventory.
Or even more generally: “allow more buyers to compete for inventory.” In the monetization game we know more competition is better for your inventory and liquidity can help your efforts in increasing prices so one can argue the benefits of header bidding can be achieved by simply directing traffic towards price floors in a waterfall – something that most sellers in the market already do. However, the chief benefit for header bidding is targeted buying means you can reduce latency in your waterfall and increase liquidity without the negativity of adding unnecessary client-to-server calls to your waterfall. We’ve found in most cases a waterfall caps out somewhere around 16 hops before adding undue latency to your waterfall, with header bidding you can—in theory—create hundreds of price floors without excess waste. If you can leverage header bidding on your inventory by offering high-tier pricing to a big-enough market, you could—conceivably—increase revenue by increasing competition for this premium inventory.
So how does it actually work?
In most cases the header bidding tech comes up with a clever way to deliver prices or instructions to the ad-server to sell off the desired traffic before it gets sent off to the incumbent exchange or another high bidder. There are a variety of players that exist in the market, but from what we’ve seen Amazon’s Transparent Marketplace has managed the most traction from MoPub publishers, so we’ll look into their platform for this example:
- Price Request: On app-start up Publisher invokes a “Pricing API” request to the header bidding platform.
- Price Response: The Header bidding platform delivers price(s) for this impression.
- The Ad Request: When an ad is called (up to 10 minutes later), the price(s) are sent to the ad server.
- Ad Request via Ad Tag: The ad server is instructed to request impressions valued at that price point to header bidding platform via an ad tag.
- Ad-delivery: Since the buy was previously committed, there should be a 100% fill-rate by the header bidding provider and the header bidding platform returns ad to be served by MoPub.
While easy to conceptualize, the down-side of this integration is the potential for overhead it will add to your monetization technology stack and optimization process. Here are some factors to consider when integrating header bidding:
- Another SDK: the pricing SDK will need to be invoked early in the ad-serving process, in most cases before the ad is called to ensure no latency is added to the already painful ad serving process.
- Key Value Pair Juggling: Amazon will return one or more pre-agreed “price points” with their response. You will need to store these price points on the device until the ad is called, then send them in the ad-request to MoPub as a “key value pair.”
- Line items: The preferred method for setting up access is to create a line item for each price point: while straight-forward, (and hopefully relatively static) this could result in hundreds of line items that you must maintain along with any other partners you might be running.
- Price-points vs CPMs: Amazon key-value pair price points don’t correspond 1:1 with CPMs. You’ll be given a list of price points and their corresponding CPMs – it’s not clear on whether these are variable but it’s not outrageous to assume they could be altered.
- The reporting: This was a tough nut to crack: if you want any ability to granularly report on line item fill rates, discrepancies you’ll need to hard-code price-points and work backwards to the key value pair line items as reported by Mopub.
- Country & Format Restrictions: We’ve only seen amazon buy in a few countries, and only on leaderboard and banner formats; be sure you have enough relevant inventory.
So, is it worth it?
Anecdotally, the general consensus amongst publishers is they haven’t been able to overcome technology hurdles to get header bidding to work on their inventory. But we’re firm believers in data-driven decisions, so let’s look at the numbers for the publishers who have run this in production:
The good news: Revenue potential shows promise:
- At 1.5 – 3X the average CPM stands for a promising showing on premium inventory.
- Scale: Among those running Amazon Header bidding, revenue can make up 10% of total earnings — given the country-restrictions this is a promising number of impressions.
The bad news: Serving discrepancies are sobering:
- Discrepancies are rampant. The average discrepancy is 25%, header bidding approaches 90%.
- When basing CPMs on ad-server counts header bidding CPM falls to 60% of average CPMs, or 33% total industry CPMs.
“Ad serving discrepancy refers to a difference between the number of ad impressions counted by a publisher or ad network adserver and the one counted by the agency or advertiser ad server. Ad serving discrepancy can be the source of billing issues.”
There’s a huge caveat to our findings: discrepancies. And as you most likely know, discrepancy is an ugly word in advertising. As best it’s confusing and revenue impact is unclear, at worst its massive amounts of lost impressions and lost revenue. The reality and revenue impact of serving discrepancies will depend on the cause for the actual discrepancy, your integration and the ad-servers involved, one item is clear: discrepancies need to be addressed before rolling into major scale with header bidding.
Header bidding will take a lot of overhead to implement and maintain.
There exists a strong potential for revenue gains for publishers with US banner traffic, provided they can manage serving discrepancies.
Publishers interested in embarking on this technology should have the appetite for the technology challenges, because although the tech is unproven there exists a strong revenue potential with the performance we’ve seen in the market so far.
The name AdLibertas comes from our motto “ad victoriam mercaturae ducit libertas” which is Latin for “the free market wins.” As former app-developers we’ve designed a publishers-first solution to help app developers earn more from their in-app ads. Contact us or sign-up to learn how other app developers are earning more by automating their current advertising platforms with AdLibertas.
What our customers say:
“Partnering with AdLibertas has turned out to be one of our most important strategic decisions. Their automatic waterfall management and market expertise resulted in a massive revenue increase while saving us a huge amount of time and resources from the very first day of working together.” Matthias Kloss, Co-Founder, PixelTrend