Header Bidding for Apps

Our kids are young and rough on their clothes, so my wife often visits what are called “tag sales.” It’s one of those things that I didn’t realize existed prior to becoming a parent. A mother’s club usually organizes a tag sale and it’s basically a large yard sale where everything is tagged with a color-coded price tag.

Because the inventory is sort of random and inherently limited, you’re far better off arriving early. So tag sales often end up looking like a Walmart on Black Friday, with people lined up early in the morning waiting to get in. If you volunteer to help with the sale you can get in earlier and there are even hierarchies within the volunteers that allow access earlier yet. All this to get the most desirable used clothes.

If you’ve been running ads for any length of time, you might have noticed that the competition for your inventory is a lot like that tag sale. There are many entities that want to take the first look at what you have to offer and buy it for themselves before anyone else takes a look. The players are always jockeying for position, in this case creating new technologies that allow them to see the ad requests a few milliseconds before everyone else.

In the web environment, this has been going on for a long time. When Google bought DoubleClick, they took over one of the dominant ad servers and got access to a lot of publisher inventory at the very first step. They then created their ad exchange and gave it first look at all that inventory.

That worked very well for Google for quite some time. In the past couple years, a technology called header bidding has been gaining steam. Header bidding was created specifically to deprive Google of that unfair advantage in looking at all the inventory first. Bids from competing ad companies can be run in an auction that is stuffed into the header of a web page and then lodged as campaigns within the ad server.

This allows companies other than Google to participate at the earliest stage, increasing the bid density and producing more revenue due to the increased competition. Header bidding has been a win for publishers and competitors of Google, but the increased latency required to run that additional auction is yet another reason why users hate ads.

This situation also exists in the mobile app environment. There are ad servers and SSPs with dominant market positions like MoPub who use their optimization layer to give their own exchange the first look at an app’s ad inventory. And there are a bunch of other ad companies that chafe about that to no end.

One of the first header bidding technologies for apps was just released this week when AppNexus introduced their PriceCheck (http://www.prnewswire.com/news-releases/appnexus-announces-launch-of-pricecheck-header-bidding-for-mobile-apps-300209082.html) product. The mobile app world has an additional challenge for ad companies that want you to use their products, which is that they usually require you to install an SDK. It used to be easy to get app developers to throw in another SDK, but those days are long gone. Every SDK comes with potential problems so developers have become extremely selective about which ones to use.

So AppNexus killed two birds with one stone by making PriceCheck available with just a few lines of code. It’s very light and pre-caches ads to contribute “virtually zero latency” to your app’s user experience. That’s a claim that can’t be made about header bidding in the web world.

Other companies will no doubt follow AppNexus’ lead with very similar solutions in the near future. And as long as the latency remains very low and the additions don’t bloat your apps, I don’t see any reason not to participate. My philosophy is that it’s beneficial to be plugged into as many unique demand sources as possible. AppNexus is a huge exchange and no doubt has some demand that is unduplicated by the MoPub exchange and other prominent app inventory exchanges. Header bidding for apps could be a relatively easy way to expose your app to new demand sources.