In-App Header Bidding Guide for Publishers

For more info, check out our comprehensive downloadable guide on in-app advertising here!

We’ve already covered in-app advertising and its benefits on this blog. If you figured that in-app advertising is the right choice for you, you might want to look at in-app header bidding, as it’s a top strategy for publishers to monetize their apps.

In-app header bidding was introduced in the middle of 2015 and gained popularity almost immediately. This article will cover the benefits of in-app header bidding, how it works, and how to implement it for your app. 

Let’s begin!

What Is In-App Header Bidding?

In-app header bidding is a programmatic advertising strategy in which publishers can sell ad inventory in real time through an auction that takes place within their mobile app. 

Publishers simultaneously distribute ad space to multiple supply-side platforms (SSPs) or ad exchanges. It allows multiple demand sources to bid on ad inventory simultaneously.

• The role of the demand-side platform (DSP)

In-app header bidding automatically generates bids from multiple advertisers by placing the publisher’s inventory on multiple demand-side platforms (DSPs).

With the waterfall method and open real-time bidding (RTB), each DSP enters the auction in turn. 

On the other hand, header bidding enables equal participation from all DSPs, enabling publishers to charge the highest price for their ad space.

How in-app header bidding differs from traditional header bidding?

In-app header bidding and traditional header bidding are similar in that they both involve an auction in the header of a webpage or app, allowing multiple demand sources to bid on ad inventory simultaneously. 

In terms of mechanics, in-app header bidding differs from traditional header bidding. 

You need to use a software development kit (SDK) to initiate the auction rather than embed a piece of code as you would with traditional header bidding.

What is software development kit (SDK)?

SDK is a set of tools that allows developers to incorporate ad-serving technology into their mobile apps. The SDK handles tasks such as making ad requests, displaying ads, and gathering data about ad efficiency.

Typically, an ad network or DSP provides an SDK that developers can use to integrate their platform into the app. When an app is opened, the SDK will communicate with the ad network’s servers to request and serve ads to the user.

For websites, header bidding technology sits on top of a header bidding wrapper, which is a JavaScript tag responsible for making ad calls to demand partners, evaluating bids, and communicating with the ad server.

In the table below, you can see the 3 key differences between in-app header bidding and traditional header bidding:

Unified Auction VS In-app Header Bidding

Unified auctions are a trading system designed specifically for mobile app context. They are conducted on the server side as opposed to the client side, which results in quicker load times than a conventional header bidding wrapper. 

An example of a unified auction is Google’s Open Bidding which takes place on Google’s ad exchange–Google AdX. 

One bidding session per impression is guaranteed through a unified auction. In contrast, header bidding chooses a bid before sending it to the header bidding wrapper from various auctions.

All demand sources are combined in a unified auction environment to fight for each ad impression actively. This comprises client-side (SDK-based) mobile ad networks and server-side programmatic demand sources.

Since all demand sources can bid in real-time in a unified auction, app publishers can determine how much each demand source will pay per impression for their inventory.

Client-side header bidding can cause longer page loads because it takes place inside users’ browsers, which is a problem that unified auctions would never experience. 

The Benefits of In-App Header Bidding

Header bidding already provides publishers with a number of revenue benefits. First, publishers who use header bidding methods benefit more from higher demand.

There are 5 benefits of in-app header bidding for publishers:

• Increased revenue for app publishers. Increased ad revenue is one of the main benefits of in-app header bidding. By presenting ad inventory to more advertisers, ad exchanges, SSPs, and other networks through in-app header bidding, web, and mobile app publishers have the opportunity to maximize their cost per mille (CPM) and generate more income.

• Improved user experience. Unlike the waterfall method, running parallel server-side auctions lowers latency issues and speeds up page loading times. Therefore, increased ad quality and quicker load times enhance user experience and lessen the danger of losing users. 

• Increased inventory value. Publishers can increase the value of their inventory through in-app header bidding because advertisers will naturally bid more for it to get the placements. Publisher profits may rise further as a result of higher inventory prices.

• Greater transparency and fairness in the ad bidding process. In-app header bidding promotes better transparency because all bids are public, and everyone can see which bids are winning. You can view the publisher’s whole inventory, and publishers can learn precisely how much advertisers are ready to pay for each impression. This enables publishers to determine the value of each impression and make simultaneous bids to numerous advertisers. The winning demand source also receives the benefit of increasing CPM when they make the highest bid.

• Improved targeting. By using in-app header bidding, advertisers can view ad inventory more effectively. The report includes information on the demographics and impressions of website visitors. An advertiser can use this data to create a more successful targeting plan.

How In-app Header Bidding Works?

The whole technology for header bidding originated in the world of desktop advertising. 

Publishers would put a wrapper (code that allowed them to submit an ad request to multiple demand partners) in the header area of their website. 

However, there is no header in the app. In-app header bidding utilizes an SDK integration that creates the ad requests for the publisher’s app rather than depending on the header of a website. 

Once a bid is received, the ad request is auctioned in the cloud with server-side demand partners, with a response being sent back to the client-side SDK.

Depending on the other elements of the publisher’s mobile ad stack, in-app header bidding can function in two ways–with direct demand in the primary ad server or with no primary ad server.

In-app header bidding with direct demand in the primary ad server 

A mobile app with a sales team devoted to selling in-app inventory to advertisers will frequently have a primary ad server. This type of demand generation is referred to as direct demand.

A primary ad server (e.g., Google Ad Manager) often fulfills this direct need. Within the primary ad server, direct demand falls into “orders” and “line items”:

• Order is an arrangement outlining the specifics of an ad campaign between an advertising buyer and a seller. 

• Line item is an advertiser’s agreement to pay a set price on a certain date for a specified number of ad impressions (CPM) and user clicks (CPC). A line item specifies the locations and potential timing of ads. 

As mobile publishers start to have multiple orders and line items set up in their primary ad server, their operations team needs to determine the order in which they are served. Priority levels and prices of the line items manage it. 

This is where header bidding SDKs are integrated into primary ad servers. They bring more competition for inventory against direct demand. 

Header bidding SDKs make an ad request to the header bidding server, which then runs a cloud-side auction and sends the winning bid to the client. 

Afterward, the SDK passes the winning bid price to the publisher’s primary ad server. If the primary ad server finds an ad higher than the bid price, the primary ad server SDK will render the ad. 

If not, the header bidding SDK will render the winning bid from the header bidding server-side auction.

In-app header bidding with no primary ad server

App developers often use ad network SDKs without a sales team to sell in-app inventory. To increase ad revenue, a publisher can add multiple ad network SDKs and set them up in a manual waterfall, where one ad network SDK is requested to serve an ad.

If there is no ad from that SDK, the app code will go to the next ad network SDK. 

Many app developers want to replace their inefficient ad network SDKs with a single SDK that can connect to multiple cloud-side demand sources.

This strategy can be supported by header bidding solutions, which eliminate the waiting period for ad network SDKs and cut down on client-side latency by utilizing considerably faster cloud-side auctioning.

Header bidding solutions can support this strategy, reducing the client-side latency by having a much faster cloud-side auctioning and removing the wait time for ad network SDKs. 

By integrating a header bidding solution without an ad server, accessible cloud-side demand sources are increased, inefficient ad network SDKs are decreased, and SDKs that are still active and generating income are maintained.

How to Implement In-app Header Bidding?

To implement in-app header bidding, you need to have a mobile app built for iOS or Android and released in the app store. You must also set up the Prebid server and your primary ad server.

Here are the next 5 steps to create a functioning in-app header bidding setup for your app:

1. Choose a header bidding solution. 
2. Integrate necessary header bidding SDKs (e.g., Prebid SDK, Google IMA SDK). 
3. Set up demand partners. 
4. Configure your ad inventory. 
5. Test and optimize.

Although some may find it simple to comprehend how these elements operate together, the technical setup can be complicated if you lack any prior ad tech experience, technical knowledge, or access to all required platforms.

Below we provide 3 possible options to help with in-app header bidding, such as Prebid Mobile, Google AdMob, and Setupad.

Prebid Mobile

Prebid.org is the standard choice for open-source header bidding. It provides an easily verifiable code and offers publishers a variety of partners. 

• What is Prebid Mobile? 

Prebid Mobile is an open-source library that offers mobile app publishers a complete header bidding solution. It’s freely available and customizable by the publisher. 

Prebid Mobile can require more technical knowledge to implement, and it might not have the same level of support as managed alternatives. 

Prebid Mobile supports such ad formats as native, interstitial, and banner ads. It offers features like ad targeting and user segmentation and is integrated with multiple demand sources and ad exchanges.

• How Does Prebid Mobile work?

To request and receive bids over RTB, use the Prebid library together with your ad server’s Mobile SDK. These bids then directly compete with those coming from your main ad server.

Here are 7 steps that show how the Prebid Mobile header bidding solution works:

1. Prebid Server receives a request from Prebid Mobile. The Prebid Server account ID and config ID for each tag in the request are both provided in this request.

2. Prebid Server creates an OpenRTB bid request and sends it to the demand partners.

3. Prebid Server receives a bid response from each demand partner. The bid amount and the creative material are both included in the bid response.

4. Prebid Server sends the bid response to Prebid Mobile.

5. Through the primary ad server mobile SDK, Prebid Mobile configures key/value targeting for each ad slot. One or more Prebid line items that were previously set up in the main ad server will be activated as a result of this targeting.

6. If the line item associated with the Prebid Mobile bid wins, the primary ad server returns the Prebid Mobile creative JS to the ad server’s SDK.

7. The Prebid Mobile creative JS will fetch and render the corresponding creative content from the winning Prebid.

Source: Prebid

Google AdMob Mediation

AdMob Mediation is a platform from Google that allows publishers to monetize their app inventory by integrating with multiple ad networks and demand sources. 

AdMob bidding calls all involved ad sources simultaneously. On each impression, the advertising providers place a live bid. All networks receive equal priority. Therefore, the highest-paid advertiser is always the winner for any given impression (including Google).

Here are 3 benefits of Google AdMob:

• Real-time CPMs. Bidding pulls real-time CPM data from demand partners so you can save time, increase profit, and avoid costly mistakes. 

• Simplified billing and payments. AdMob provides a centralized dashboard to overview partner and ad data, and they consolidate payouts from multiple partners. 

• Less SDKs: You can access demand from participating partners without adding new SDKs to your app. All you need is the Google Mobile Ads SDK.

Here are 4 steps that explain Google AdMob’s bidding process:

1. Ad unit generates an ad request. Your app’s ad units generate ad requests and send them to AdMob with targeting details like platform and ad type.

2. AdMob matches the ad request to one of your mediation groups. AdMob mediation compares the ad request to the targeting settings and priority of the defined mediation groups. It matches the ad request to the mediation group with the appropriate targeting settings and the highest priority.

3. AdMob initiates a bidding auction. Once the ad request is matched to a mediation group, the bidding ad sources in the group compete in an auction to fill the request. The ad source that submitted the highest eCPM bid will then be placed in the mediation waterfall according to the eCPM value.

4. Mediation waterfall functions as usual, and the ad request is filled. If a bidding ad source is placed first in the mediation waterfall, it will serve the ad. If the bidding ad source is not the highest eCPM in the mediation waterfall, the waterfall ad sources will be called first.

Choose the right in-app header bidding solution

The best solution for a specific publisher depends on multiple factors, such as the type of app, target audience, the most appropriate ad formats, and the technical expertise and resources available.

Here are a few tips for different types of app publishers:

• Small app publishers. If you are a small app publisher with limited resources and technical expertise, consider a solution that is easy to implement and offers extra support, such as Google AdMob.

• Large app publishers. Suppose you are a large app publisher with a significant user base and more resources and technical expertise. In that case, you may want to consider a more customizable solution, such as Prebid Mobile.

• News or content app publishers. If you publish a news or content app, you may want to consider a solution that supports native ads and other ad formats that blend seamlessly with the content, such as Setupad.

• Games app publishers. If you publish game apps, consider a solution that supports video ads and other ad formats that are particularly well-suited to the gaming audience.

Setupad’s In-App Header Bidding Solution

Setupad’s advanced technology allows multiple demand sources to bid on your inventory simultaneously, resulting in higher CPMs and increased revenue. We offer our clients advice on their mobile apps’ most effective ad formats and layouts. 

Due to the connection we make between Google demand and Open Bidding, the publisher must incorporate the Google IMA SDK. To use header bidding, the publisher must additionally integrate the header bidding SDK. 

In terms of in-app advertising, we provide the following ad formats:

• Interstitial ads.
• Native ads.
• Banner ads.
• In-stream ads.
• Rewarded video ads.
• App open ads.

Conclusion

In-app header bidding is beneficial for both publishers and advertisers. It can increase the mobile app’s revenue, but it’s more challenging to set up than traditional header bidding.

You can implement it yourself if you have the necessary time and experience. Still, it’s a time-consuming and complex task, leaving little time for the most crucial goal–producing the greatest content for your audience.

Acerca deAnete Jodzevica

Anete is a content marketing specialist at Setupad. In addition to writing articles, she works at gathering information, verifying data, and explaining complex concepts to others. Anete believes that simplicity is the key to brilliance.

Ver todas las publicaciones de Anete Jodzevica