To put it simply, header bidding is a way to help publishers make more money from the ads on their site. Publishers can also refer to the ads on their site as “inventory”.
Header bidding takes very different forms on desktop and in-app. It originally started on desktop browsers where header bidding was an entirely new, round-about way to get more competition on each ad impression since the publisher’s goal is to make the most money on each impression.
To implement header bidding on web environments, there is a piece of javascript that is placed in the <head> of the website.
All websites consist of:
This is why this strategy on increasing price competition is called a “header” bidding — the javascript is placed in the <head> of the site. This javascript code in the <head> would call multiple Supply Side Platforms (SSPs) to ask if they each wanted to place a bid on the impression on an ad.
Since this piece of code calls multiple ad sources it increases competition which drives up prices on each of the impressions by introducing more bids on each ad impression. Furthermore, each of the SSPs already holds their own internal auction before they even respond to the call from the publisher. So it is the same as holding an entirely secondary auction to bid multiple supply sources against each other.
One of the most commonly used wrappers is an open-source code called “Prebid” which was developed by Appnexus and Rubicon. There are other header bidding wrappers that include self-serve so you can run and manage your own demand including building relationships with demand partners. Others just give you the code to plug into your site and have the demand relationships already and you just optimize from there.
There are also fully managed wrappers so you just tell them your domain and they onboard, manage all demand generation, optimize and provide analytics. Prebid allows you to manage everything yourself, although you need a developer’s help to set it up and someone who knows or is willing to spend some good amount of time learning AdOps to set up the functionality and get all the other pieces together.
The Header Bidding wrapper allows the auction to be executed by allowing for a single impression to call multiple bids across the supply landscape.
Header bidding has many moving pieces. We will expand in detail in the “Let’s get technical” section below. In-app header bidding is different from desktop or even mobile web. Desktop header bidding is able to run the entire auction within the <head> of the website whereas in-app cannot do that. That is why in-app is often referred to as “parallel bidding” or “unified auction”.
Let’s go through this assuming you will be using the Prebid wrapper. The code on the actual site includes:
This allows the space on the site to act as a picture frame in which ads can come and go relatively independent of the rest of the site.
The next touchpoint is the primary ad server, which can be something like Google Ad Manager. Google Ad Manager can also be used by the publisher to serve direct orders and other custom ads to a publisher’s site alongside the Prebid inventory.
Prebid uses Google Ad Manager to house all the possible combinations of bids and bidders that could win. Within Google Ad Manager there is a complex set up of Orders and Line items that correspond with demand partners that are enabled.
So it basically holds parking spaces for every demand partner you have enabled ie Sovrn and AppNexus at the price granularity you set so it could be at $0.10 increments or $.01 increments. So Sovrn would have an Order of “Sovrn $0.01 – $4.00” which would contain 400 line items at $.01 each so one would be $.01 the next would be $.02 etc. up to $4 all for the demand partner, Sovrn. Then you would use the targeting to set a grouping called a “placement” to show the ads to.
Also, key values need to be set up correctly so the bids returned can call the corresponding line items. The creatives are auto-created along with the line items if you use this handy PubMonkey Chrome Extension to create the line items automatically. The primary ad server essentially holds all possible combinations of price and bidder so it’s possible to track who won each auction at what price.
In order to work with a demand partner, like Sovrn, the publisher must first reach out to that demand partner to establish a working relationship. From there they send their site URL for approval, at which point the demand partner ie OpenX approve or deny the URL or app on the basis of vetting for traffic amount, brand safety, geolocation, etc.
So typically for a site to be approved it must have over 2 million unique impressions per month for the past three months– demand partners typically look at Similar Web since they don’t have direct access to your Google Analytics account to verify traffic volume. Once your domain is approved within that demand partner’s site, they create IDs for you to plug into your Prebid setup.
The difference lies in the way the apps are built, which is entirely different than having a mobile browser on a phone.
The mobile browser is basically just a minimized version of a desktop browser, so it is built the same with <head> and <body> and a <footer>. An app, however, is built on an entirely different platform and has no browser functionality, so no <head> element to add code into that will place it across all pages.
To build a native iOS or Android app – you would use a corresponding native SDK and code it in a compiled language (s.a. Objective-C or Swift for iOS and Java or Kotlin for Android). In recent times there are more compelling options that allow you to develop one single app that can be deployed to either of the platforms:
Since apps are built differently they require an SDK to communicate with the web. There is also app-specific inventory that monetizes better on mobile than banner or video in mobile web environments. So although they both show up on phones, in-app inventory lives within apps only and is confined to that app environment, whereas mobile web lives on any browser on a phone.
A seemingly ever-increasing amount of time is spent by users on mobile phones these days. In fact, according to E-marketer, the average time spent in the US on a smartphone is over 3.25 hours. This means that since users are on their phone, your publisher site should be there too. Furthermore, users spend 86% of time more in apps than in mobile web environments.
In-app header bidding allows for the most unified competition of demand in real-time. Previously publishers would have to integrate directly with the ad networks, one at a time for in-app monetization.
Then came mediation which allowed for a single integration point for the full stack of the many ad networks, but still relied on a “waterfall” approach where the order and prices were manually adjusted for each ad network.
Header bidding allows for all networks with RTB integrations to compete in real-time, equally against each other so less money is left on the table.
So the way that in-app header bidding works is kind of a “hack”. In the case of Prebid, it uses the Prebid server to create what is known as a “server-side” auction. This means that all bids are requested and received on an entirely different server. This has to happen in-app, because there is no header to run the auction in.
What happens in-app is the bid request is sent to the server, then the server runs the auction and returns the winning bid to the Prebid SDK, which then passes it to the Primary Ad Server SDK as a key-value to target the corresponding line item setup on the Primary Ad Server SDK.
Desktop header bidding can also use this server-side technology to create a structure that creates an environment that can decrease “latency” or how slow the page takes to load. It also can send and receive bids faster since it has an environment dedicated solely to the auction instead of utilizing the resources of the browser when it is loaded. This server-side auction sends requests to demand partners that the publisher has been approved by and those demand partners send bids back that match the targets of their demand-side partners.
So the SSPs request bids from the DSPs or Demand Side Platforms that then work with Advertisers to gain budgets and CPM (cost per thousand impressions) goals. These CPM goals dictate how much the advertiser is willing to spend on each impression. The advertiser also sets targeting on their programmatic campaign that then aligns with which impressions they bid on that match their targeting subset. This can include anything from demographic (age, gender, etc.) to location data. These bids are aggregated on the Prebid server and the winning bid is then sent back over to the Prebid Mobile code where the Ad Server SDK then parses that information and sends the bids and corresponding bid and targeting information to the Publisher’s Primary Ad Server.
There are two servers:
The Primary Ad Server then acts exactly the same as the Ad Server acts in Desktop Header Bidding where it sends the bids to match the line item that is set up and the key value that corresponds with the winning bid to serve an ad back to the Ad Server SDK which then shows an ad on the app.
Let’s take a look at each of the components that must be present for the in-app header bidding auction to take place.
You can tell if it is working by looking at the analytics behind it. Currently, Prebid does not offer any advanced analytics to view. However, you can see data through your primary ad server or if you have an analytics integration with your app.
You can also look at the mechanics to make sure bid requests are being sent, if bid responses are received, are they converted into the key values and sent to the Primary Ad Server, if the creative is received, and if it is rendered. You can view requests through a MITM proxy like Charles. Creative can be observed directly in the app running on your simulator/ emulator or device.
Ok, so now you have an understanding of how Prebid works– now you can start setting up your own instance of it. There are also managed wrappers that you can use so you don’t have to spend so much time getting everything integrated and building relationships with each new demand partner you would like.
To find out more about the current state of the AdTech market, in particular, about ad source distribution among publishers and their apps, check out Postindustria’s comprehensive in-app advertising research.
Our team of AdTech experts analyzed 1,805,444 mobile apps and revealed that no more than 10% of publishers monetize their applications with ads. To find out how your business can benefit from the trend, book a call with us filling in the form below.
