Header bidding created a big buzz in ad-tech spaces and the mobile app eco-system could not stay indifferent to it. There are quite a few problems slowing down the adoption of header bidding in mobile apps and it’s even possible that it’s the wrong model for mobile apps.
Header bidding – what it is
Header bidding works a bit like the role of SSP in the RTB model but different. In both SSP and Header Bidding – the publisher wants to get the best price for an ad impression that will be served to the customer. He runs an auction between the potential advertisers. Each advertiser submits a bid and the winner gets to serve the impression. This process is repeated for each impression.
There are a few differences however:
- In SSP the auction is managed on the server side and in header bidding it’s on the client side
- In SSP the winner pays the price of the highest losing bid (2nd price auction) while in header bidding the winner pays the full price
- Header bidding allows combining a few SSPs in the same web page or mobile app
- Direct deals can be treated according to their actual CPM and be added to the auction
Why was header bidding created in the first place
The HB and SSP models are so similar that one might wonder why header bidding was created in the first place. This is partly related to unfair behavior by some SSPs. Specifically, Google was mentioned in a few conversations I had about the subject. The most popular SSPs including Double Click by Google has their own horse in the race – for Google that horse is Ad-x. Any SSP that is running the auction but at the same time placing a bid has motivation for to bend the rules. Real time bidding might appear to be a transparent process in which bending the rules is harder, however, when there is a will there is a why. Specifically in Google’s case it was a feature called “enhanced dynamic allocation” that allows Ad-x to cherry pick inventory from auctions being run by Double Click (their SSP) by seeing the other bids first.
Header bidding in mobile apps
As you can guess from the name. Header bidding was created for web pages and “header” refers to the part of the html code that is loaded first. As of July 2017, none of the top 200 mobile apps has implemented header bidding according to our checks and most vendors who focus on mobile apps as opposed to mobile web don’t support pre-bidding at the moment.
3rd party vendors moving in but diminishing the benefit
Of course, the opportunity for in-app advertising is huge and the players are giants such as FB, Google and Twitter among others. With billions of dollars on the table, there are strong forces who try to push the mobile app eco-system towards header bidding. This can benefit DSPs who are interested in more direct access as well as the exchange providers. However, the adaptation of header bidding to mobile apps is not trivial and some of the offered solutions are “Header bidding in a box” where the auction goes back to the server side. This of course, diminishes the benefits of header bidding as the auction is outsourced to a party that may have bias.
Mobile app advertising is CPI driven
There is a bigger problem that is clouding the future of header bidding in mobile apps. It is not even certain that header bidding can be applied successfully? One might be surprised that not many mobile app companies are pushing for header bidding despite the trend that it created in the mobile web and desktop space. The situation in mobile app advertising is a bit different than that of web advertising. Specifically, mobile app monetization relies heavily on CPI campaigns. These are campaigns that pay only if the user installed the promoted app after he watched an ad. On the other hand, header bidding requires all the parties who are interested in placing the ad to come up with a bidding price upfront. This creates an adoption problem for header bidding. As of now, not many CPI networks are willing to commit to an upfront bid before they know what their payout is going to be. At the same time, mobile app advertisers got very comfortable with the CPI based model as it minimizes the risk. On top of that, for header bidding to work it’s not enough that one CPI network will send bids upfront. You need all of them to do it. This creates a critical mass problem and no one benefits from being the first one to move.
Someone has to take the risk
Going back to the dilema of advertisers that want to pay per install and publishers that wants to earn per impression. This is one of the oldest struggles in advertising:
- In CPI or CPA models – the publisher takes the risk and the advertiser enjoys guarnteed results
- In the CPM model – the advertiser takes the risk and the publisher enjoys guarnteed payout
CPC used to be the middle ground but click fraud killed it and the only ones that can afford to do it is Google due to size, brand and massive investment into fraud prevention.
If header bidding gains traction while advertiser continues to pay CPI, the risk will have to be taken by the ad-networks. For example, the ad-network might be bidding $5 CPM. Let’s say they serve 1,000 impressions but these impressions don’t generate a single install. The advertiser will not be paying anything in this situation but the publisher should still be earning $5. At scale, this is a very dangerous position for the ad-network to be in. The ad-networks today have different tools on the advertiser side to monitor fraud and traffic quality and adjust the revenue retroactively. Header bidding will require a similar set of tools to be developed on the publisher side in order to minimize risks for both sides.
Monitoring of header bidding
One area that is still unsolved for header bidding is measurement. In RTB, the SSP manages the auction on the server, collects the money and pays the publisher. In header bidding, this responsibility falls on the publisher side. The auction is managed on the client side and each bidder pays the publisher seperately based on the aggregated amount in all the bids he ended up winning. This requires a system that will billions of impressions on the client side, collect all the winning bids and aggregate them to determine how much the ad-network should be paying. Without such system, the header bidding becomes useless as it will be too exposed to abuse. At the same time, the ad-networks who are now taking the risk will want more visibility into the context in which the ads are shown and to their viewability. The requirement for better measurement will come from both sides.