- Header Bidding
- Header Bidding
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.
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”.
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 of $.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 that 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 platform like Flutter which is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop from a single codebase or React Native where you can create platform-specific versions of components so a single codebase can share code across 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 Prebid Server, which acts more as a data repository then the Primary Ad Server which is something like Google Ad Manager that is specifically set up for serving ads. 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.
1.There must be a mobile app built.
a) What it does: A mobile app is specifically built for iOS or Android– it is released in the app store. It is not built on a browser like Chrome or Safari.
b) Why it matters: An app has an entirely different setup than mobile web– so the ads are built into the app via SDK vs on mobile web browser like Chrome and still use the <head> to insert ads.
c) How to set it up: Start by setting up the Prebid Server.
2. Setup Your Prebid Server
a) What it does: This is what allows the bids to be sent and returned in a different environment and the Prebid auction is held on the Prebid Server
b) Why it matters: It is able to talk to the demand partners and your mobile app while also decreasing latency because the bidding is done in an optimized environment, separate from your app
c) How to set it up: You can either use a member of Prebid that hosts a server like Rubicon or Appnexus or create your own. If you would like to be a company that hosts a Prebid server and allows other publishers to use it then just register for an account for a hosted Prebid server here or just use the open-source Prebid Server – host it for yourself and use it for your app(s).
3. Setup Your Primary Ad Server
a) What it does: you have a waterfall with your ad sources set up, among which are the line items from the Prebid – they are just like any other ad source competing in the waterfall. It has thousands of line items you create depending on which demand partners you decide to work with and at what price granularity you decide to have integrated. It can be anywhere between a penny to $20. Typically you can just run a script to create these at a “high” price granularity of $.01 each line item.
b) Why it matters: This is your hub for where everything actually runs through and transacts upon. Your ad server, let’s assume Google Ad Manager for this example, takes the bids you receive and parses them through the system to return the ad creative to be returned through Prebid. When this is set up correctly it makes it easy to report on deep-dive analytics for the performance of your demand partners and each ad unit, size, by date, etc.
c) How to set it up: A single Order is set up for the whole In-app bidding integration. Demand partners are connected on the Prebid server. Once the winning bid is sent to the Primary Ad Server and wins in the waterfall – then the creative wrapper is received and rendered on the client – and it resolves whose winning bid was it and requests and renders the corresponding final ad creative which comes from the Prebid-cache server usually. You can set up each of the demand partners uses an “Order” to organize things.
Try our PubMonkey extension to speed the setup.
4. Integrate Prebid SDK
a) What it does: This is what allows your app to talk with the Prebid server and your primary ad server.
b) Why it matters: Without this, your app could not communicate to get or send bid and ads
c) How to set it up: Download the SDK from which then passes them to the Primary Ad Server Prebid GitHub then configure your ad units in the Prebid Mobile Framework
5. Integrate your Primary Ad Server SDK
a) What it does: Prebid SDK communicates the bids in the form of key values to the Primary Ad Server SDK, which then passes them to the Primary Ad Server.
b)Why it matters: This allows your Primary Ad Server to communicate with the Prebid Server.
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.