What Is In-App Header Bidding?

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. All this to get the most desirable used clothes.

If you’ve been running ads 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. 

What Is Header Bidding for Apps (in-app header bidding)?

Header bidding for apps is an auction that runs before the ad server auction and produces a single winner with the highest bid for the ad impression. That bid then competes inside your normal ad server auction for the final win of the impression and delivery of the ad.

That was a mouthful. Let's break that down a bit. 

The Fundamental Conflict

The incentives of the players in the ad ecosystem are usually misaligned. Buyers want to cherry pick ad impressions at the lowest price possible, and sellers need to sell all their inventory at the highest possible price.

For ad buyers, their ideal situation is to look at every ad impression and then take the ones they want before anyone else sees them (i.e. the tag sale). However, most ad servers can only accommodate ONE buyer in that coveted position.

That's bad for the ad seller (publisher) because while they can demand that the price be above a certain level (called a "floor" price), they can't take advantage of auction dynamics to drive up the price. 

There is one entity that is in a position to see all inventory and pick off what they want...the company running the ad server. That's a very profitable position to be in, so companies like Google and MoPub have done very well for themselves by running the ad server and the auction for impressions. 

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. They then created their ad exchange (AdX) and gave it the first look at all that inventory. Other ad exchanges view that as an unfair advantage (and I agree that it is). 

That worked very well for Google for quite some time. In the past few 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.

Header bidding allows competing ad companies to bid in an auction that is run in the header of the web page, before Google gets a chance to see the impression. The winning bid from the header auction is entered in Google's normal auction as a line item and only becomes an ad impression if it also wins Google's auction. 

This allows companies other than Google to participate at the earliest stage, increasing the bid density (more bids is better for the seller, like any other auction) and producing more revenue due to the increased competition. Header bidding has been a big win for web publishers.

This same exact situation also exists in the mobile app environment. There are ad servers and SSPs with dominant market positions--like MoPub, and again, Google--who use their optimization layer to give their own exchange the first look at an app’s ad inventory. This of course benefits those companies and aggravates competitors and app publishers seeking the highest price for each impression.

In early 2016, AppNexus introduced their PriceCheck product. To my knowledge, that is the very first time a product was released for in-app header bidding. I'm not sure if that product is still around, but suffice it to say that it didn't catch on. Here we are years later and in-app header bidding is still in its infancy.

Why Is It So Slow to Catch On?

Someone asked me this a couple years ago and I didn't have a great answer. It seems like this is a no-brainer and the upside is huge, so why hasn't it caught on faster?

SDKs Suck

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.

One way of implementing in-app header bidding is client side, by installing the SDKs of the various bidders. That can add a lot of bloat to the app though. The other is server side, which has limitations that the buyers dislike and it requires a lot of coordination between the SSPs bidding and the company running the auction. So there's no perfect solution yet. 

Focus of App Developers

Website owners love to get under the hood and tinker with the ad monetization of their sites. App developers like to improve their apps and just plug in monetization that works without a lot of fuss. Those are broad generalizations, but there's some truth to it and the products reflect those preferences. AdMob is a much less robust and convoluted interface than DFP, for example. Header bidding has traditionally been a heavy lift from a technology and ad operations perspective so it has been slow to catch on with app developers. 

Number of Bidders

There are plenty of SSPs that websites can choose as bidders in a header bidding auction. Mobile apps have fewer choices, there aren't as many mobile app ad exchanges and there has been a fair bit of consolidation in the past few years. 

Bottom Line

My philosophy is that it’s beneficial to be plugged into as many unduplicated demand sources as possible. Header bidding for apps could be a relatively easy way to expose your app to new ad demand sources. There is a big "IF" though. IF you can use in-app header bidding without introducing a lot of new SDK headaches and it can be done fairly easily, it could be well worth pursuing.