How to Implement Header Bidding in a Mobile App Environment

That’s exactly what we’ll be going over today.

THE PROBLEM

Before we get into implementing header bidding, it’s important to review your traditional waterfall setup. In this case, each ad network will be assigned a specific priority.

We’ll use the example below for reference:

1. Direct Demand
2. Programmatic Demand
3. Admob

At first glance, it all looks well and good. But take a closer look. Did you catch the problem here?

We’re looking at our first downfall. Admob can not compete for first look as it’s always sold to the direct advertiser.

Let’s put Direct and Programmatic Demand aside for a moment and consider the following example:

1. Applovin
2. Mopub
3. UnityAds
4. Adcolony

Better?

Not really. Now we’re onto our second problem. Adcolony is always sitting at the bottom of the waterfall and cannot compete for premium traffic.
But wait! There’s more. Notice how Applovin is at the top. This means they can not compete for leftover traffic as you must be at the bottom of the waterfall to process leftover traffic.

SOLUTION

If all these problems are stressing you out, don’t worry. This is right where header bidding comes in. With header bidding, you can send a preparatory request to each demand source to verify how much they are ready to pay for this impression without actually serving an impression.

Time to update that example:

• Applovin: $10 eCPM
• MoPub: $5 eCPM
• UnityAds: $15 eCPM
• Adcolony: $12 eCPM*

Our winner here? That’s UnityAds with an eCPM of $15. Because we’re not working with a waterfall, UnityAds does not have a fixed position; they can compete for that first look and even win.

*Note: Right now, you’re not serving any ads. You’re just taking in those bids to determine the winners.

For this specific impression, our order would look this:

1. UnityAds
2. Adcolony
3. Applovin
4. Mopub

And if you were using waterfall? You guessed it. You’d serve this impression to Applovin at $10 eCPM, missing the opportunity to sell it to Unity at $15 eCPM. Ouch.
*Please note that the numbers shown here are not related to the actual eCPM of each ad network.

The Mobile Environment and Header Bidding

Header bidding has been around for awhile. It was invented by the desktop publisher as a means to flatten the waterfall. Its underlying purpose was to obligate partners to declare how they value the impression upfront.

The downfall to header bidding in this environment is that it requires special protocol on the supply side. Thankfully, the mobile environment is different.

How so?

It’s very common for mobile apps to request an ad and never serve it. The main reason here is pre-caching, which is used to avoid the delay between a request to display an ad and the actual render of the ad.

Let’s go into pre-caching in a little more detail. In a pre-cache, publishers initialize the advertisement SDK immediately upon app launch and cache the advertisement right way. The benefit here is that you have a cached advertisement to display immediately at any point and time.

There is the risk of a user abandoning the app before he reaches the display of the advertisement. Because of pre-caching, the low render rate is quite common in the world of mobile apps.

The Setup for Header Bidding Implementation

Here’s the good news about implementing header bidding in a mobile app. It doesn’t require a special protocol as with desktop.

You can achieve it using the following setup:

• Create multiple line items across each demand partner and assign each line item a different price floor. This step also applies to some non-programmatic demand partners that support price floors.

But let’s say you want to try it another way. You can achieve a similar result by setting up a frequency cap to each line item. Take the example below that illustrates both of these approaches:

Mopub Marketplace:

• Line Item 1 (Price Floor $0.5)
• Line Item 2 (Price Floor $1.0)
• Line Item 3 (Price Floor $1.5)
• Line Item N (Price Floor $N)

Admob:

• Ad unit 1 (Price Floor $0.5)
• Ad unit 2 (Price Floor $1.0)
• Ad unit 3 (Price Floor $1.5)
• Ad unit N (Price Floor $N)

Applovin:

• Ad Unit 1 (Frequency Cap 1, average eCPM $6.43)
• Ad Unit 2 (Frequency Cap 5, average eCPM $3.52)
• Ad Unit 3 (Open Frequency Cap, average eCPM $0.2)

Here’s the result, which is what really matters:

You end up with a huge waterfall that in essence implements header bidding.

1. Applovin Ad Unit 1 (Frequency Cap 1, average eCPM $6.43)
2. Applovin Ad Unit 2 (Frequency Cap 5, average eCPM $3.52)
3. Mopub Line Item 3 (Price Floor $1.5)
4. Admob Ad Unit 3 (Price Floor $1.5)
5. Mopub Line Item 2 (Price Floor $1)
6. Admob Ad Unit 2 (Price Floor $1)
7. Mopub Line Item 1 (Price Floor $0.5)
8.  Admob Ad Unit 1 (Price Floor $0.5)
9. Applovin Ad Unit 3 (Open Frequency Cap, average eCPM $0.2)

There’s one step left. Now it’s time to walk through this waterfall upon app launch. Do this before users request to display an ad or before it’s time refresh an ad.

Now we’re to the bottom line. As you walk through the waterfall, you’ll see that the first partner who fills a request essentially values your impression more than anyone else. That, in turn, adds up to a very nice boost for your own bottom line.