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. 

There are very few industries that create as many acronyms as the advertising industry. We rapidly produce new ones and knowing what they all mean is the mark of an insider. Over my nearly 20 years in advertising I've seen them all. One that has been very durable over much of that time is the SSP. 

What Is an SSP for Mobile Apps?

SSP is an acronym for Supply Side Platform. It is a technology platform that enables app developers to sell their advertising inventory at the highest possible rates by optimizing across different demand sources (advertisers). 

Now, let's dive a little deeper and see how SSPs fit into the advertising ecosystem.

Understanding the Marketplace

The advertising ecosystem is typically described in the most basic terms of a marketplace: demand and supply.

Advertisers and their entourage of assistants (trade desks, agencies, DSPs and other middle men) are the demand side. They want to buy advertising space. 

Publishers of apps or websites and their (much smaller) entourage are the supply side. They have advertising space to sell. 

The SSP is in between the two and usually pitched as an aid to publishers; they intend to help publishers get the most money for their ad inventory. In practice, it's often more complicated than that because the largest SSPs usually operate exchanges as well, so they are operating the marketplace and helping publishers monetize their ad inventory. 

There Are Many DSPs and Very Few SSPs

You may have heard of DSPs, or Demand Side Platforms, because there are a lot of them. DSPs are the technology platform that allows advertisers to more efficiently buy ads.

In the middle is an exchange where the ads are actually traded. So in the simplest terms, SSPs allow app owners to sell ads programmatically and DSPs allow advertisers to buy ads programmatically. 

There are hundreds of DSPs in existence and only a relative handful of SSPs. There are a couple reasons for that.

One reason is that the barrier to entry to become a DSP is pretty low. You can use off-the-shelf technology, get a seat on an exchange and you’re ready to start buying ads. Actually making money at it will be another matter, but getting in the game isn’t that hard compared to creating an SSP.

An SSP needs to build a base of app developers that use their technology. But to compete, an SSP needs a lot of functionality that actually works well if they want to retain that base of developers. Also, with very few exceptions I can think of, SSPs also operate the exchange. So there is a lot of technology that must be built to become a competitive SSP.

The second reason is that having a lot of marketplaces is inefficient. Each DSP is a bidder on the exchange. You need a lot of bidders (DSPs) to run an efficient marketplace, but you don't need a lot of marketplaces (SSPs). 

How Does an SSP Sell Ad Inventory?

At a high level, there is a three-step process for clearing (selling) an ad impression in an SSP.

The first step is to check whether it can be sold directly. SSPs usually allow you to insert direct deals and flight them with a higher priority level than other inventory. That ad serving functionality is typically not as robust as a traditional ad server. The targeting options might be more limited and there’s usually no ability to forecast the future availability of inventory. 

However, unless you have several direct ad salespeople on staff, those limitations shouldn’t come into play very often. The SSP checks an impression against any direct campaigns in the system and if it matches it will be cleared there, if not, it goes to step two.

Step two is where the inventory is cleared in the SSP's auction. The SSP auction is too complicated to cover here, but it often includes one or more exchanges and one or more ad networks that compete with one another for the impression. The SSP determines the winner of the auction and sends the impression to the winning partner for final display.

Step three is dealing with remnant inventory, which means no one in the auction wanted the impression. In that case it comes back to the publisher, where they can clear it using house ads, cost-per-action offers or remnant deals struck with ad networks.

The execution of this process is much more complicated and not as linear as I’ve described it here. But any given impression is usually offered to direct buyers and to one or more exchanges and ad networks at various price points until it is sold (or not).

Other SSP Responsibilities

Ad Quality

That’s only one facet of what an SSP does. Another important aspect is allowing the app developer to control the quality of the ads users see on their apps. This is an area where the capabilities of SSPs vary more widely.

It is possible to block ad campaigns or advertisers on any exchange. It’s also possible to block whole categories of advertisers, like those running ads for gambling. There are relatively few situations in which you can’t block the ads you want to remove in an exchange environment.

The issue is that you still have to monitor ad quality because bad ads will always get in one way or the other. If the impression gets to the ad network mediation level, then the problem gets harder. The SSP isn’t responsible for ads that come from the mediated networks, so if the bad ads originate there you have to track down the responsible network and block the ads within their system.

Reporting

Another facet of what an SSP does is to provide reporting so that you can analyze and improve the performance of your ad monetization. The features will vary but the SSPs reporting on direct campaigns and anything that happens on the exchange should be quite good.

Reporting on mediated ad networks is usually fraught with errors and discrepancies that have to be sorted out because different systems will always count things a little differently. I’ve worked with most SSPs in existence and have never seen any with rock solid network mediation reporting.

One question that I hear from app owners is about the type of ads they see delivered in their apps from ad networks. The ads they see are often not really relevant to the content of the app, which seems like a huge missed opportunity when the app has a well-defined theme. 

How Can I Get Relevant Ads to Show in My App?

You can do this by manipulating the categories of content that are allowed to show in your app. However, it is unwise to do that beyond the bare necessities of protecting the user experience because it will reduce the monetary performance of your ads.

That's the short answer, here's a longer one.

For example, a friend of mine has a fitness app and he wants to run ads in it that are related to fitness. Makes sense right? Health and fitness is a huge niche with a lot of money and advertisers in it.

You know the user is interested because they downloaded your app in the first place. It seems like a perfect fit IF you could just force the ad network to show relevant ads.

FYI, It Can Be Done

It is possible to do this. All ad creatives (meaning the actual image that you see when the ad displays) are categorized according to the standardized Internet Advertising Bureau (IAB) categories. You can see the IAB categories here.

Because there are certain categories of ads that many developers may want to specifically exclude such as dating or gambling, most SSPs and some ad networks will allow you to block IAB categories. This is also true for the ad buyers, who make a lot more use of this blocking capability.

If you put a block on a category, no ads from that category will appear in your app. So, if you block all categories other than the health and fitness category, then ads from that category are all you’ll see in your app!

But...Don’t Do It

Now that you have the know-how to do it, I’d strongly advise you not to do so. There are a lot of reasons why a given user may not see ads that are contextually relevant to the site.

The goal of an ad network or an SSP is to show the most profitable ad at any given moment, not the most contextually relevant ad. And as the person who receives most of that money, it’s in your best interest as well.

Here are some reasons that you might see ads that appear irrelevant:

Retargeting

Even if you haven't yet to run your first ad, you’re probably familiar with retargeting as a consumer. You go to Amazon, put an item in your cart, then leave the site. You then see the item in numerous ads all over the place because Amazon is “retargeting” you to bring you back and get you to complete the purchase.

Those ads are extremely effective because you’ve already shown a serious interest in the product. You can probably figure out why you are seeing certain ads on your device, but when you look at the ads other people see, retargeted ads generally look irrelevant because they’re personalized to other people's interests.

Short attention spans and varied interests

If you go to the Huffington Post and click on an article in their politics section, on the right hand side you get recommendations for other articles on their site. Do this and you’ll notice that you get some suggestions for other political articles but you also get suggestions from their entertainment, business and other categories on their site.

News sites have figured out that people have short attention spans and varied interests so they show articles from other categories. It’s the same with mobile ads. Just because someone is using a fitness app doesn’t mean that the best course of action is to pummel them with Nike ads.

Frequency capping

This is the ad tech term for only showing a given ad to a given user a certain number of times. This is done to increase performance of the ads.

Early in an app session on the example fitness app you might see some Nike ads, some Fitbit ads and some ads for other fitness apps. As you hang around longer and longer on the app (which developers of the app tend to do) those ads will hit their frequency caps and you’ll start to see other ads that come from deeper in the ad line up.

Contextual relevance isn’t the only targeting concern for advertisers

In fact, it’s not even the primary concern. Advertisers can choose from a wide range of targeting options when they buy ads.

They can target based on demographic data like age, gender and location, on behavioral data such as the retargeting example above, or really any other data available (which is a vast pool).

If an advertiser sees that a user is in the small target audience they’ve defined—say a 50-year-old male model train enthusiast from El Paso, TX—then they will show their ad and they won’t care that it happens to be inside a fitness app because that dude is hard to find.

Conclusion

That’s hardly an exhaustive list but it’s enough to give you an idea of why your ads don’t appear relevant to your app. What you’re really seeking as an app publisher is good-looking, high-quality ads that detract as little as possible from the user experience and pay you as much as possible. 

You can block a few categories to make sure no ads appear that are offensive in some way, that's a best practice. But aside from that you should let your ad demand source do what they need to do in order to make you the most money from your ad space.