Header bidding has already proven to be a successful web monetization option on desktop and even mobile browsers. Starting in 2015, this technology has made the programmatic industry landscape stronger and enabled publishers to generate more revenue.
The idea behind header bidding is quite simple; all ad exchanges and demand sources compete for the publisher’s inventory in the auction at the same time. All that the publisher needs to do to implement header bidding is to put JavaScript code within the header tag of any given page, hence the name of the method. As you may already know, a header contains metadata and code that needs to be loaded in before the body of a webpage can appear to the user.
But how does that translate to in-app environments and what does it mean for app publishers?
Quick definitions
In-app header bidding, despite the identical name, has nothing to do with headers. Headers are limited to browsers, which is why we had to wait for so long to get an appropriate header bidding iteration for mobile apps.
Since there is no header to insert JavaScript code into, apps use software development kits (SDKs) to get all the plugins necessary to communicate with servers. SDKs are at the core of the programmatic ads, both the waterfall and in-app header bidding rely on talking to ad networks.
While the auction mechanisms remain more or less the same, it’s the way that in-app header bidding manages partners that makes all the difference. Header bidding removes the need for having too many SDKs in an app.
With in-app header bidding, the auction takes place server-side, freeing up local resources and allowing parallel bidding.
A special server will handle communication with all of the ad networks simultaneously, allowing for more buyers to place a bid. In turn, this increases competition, driving prices higher and making more money for the publisher.
Benefits of in-app header bidding
Now that you know what an in-app header is, we can go over all of the benefits you get by using this approach.
In-app header bidding relies on first-price auctions, meaning the buyers will place bids that show exactly how valuable each user is to them. There are multiple benefits of first-price auctions:
- More transparency and operational stability in the process
- Flexibility to integrate new demand partners easily
- Higher bids on publisher’s inventory
- Real-time competition.
However, the biggest advantage of them all comes from eliminating the waterfall’s ad network prioritization. In the waterfall, you either prioritize the networks yourself or let the historic data do it for you.
With in-app header bidding, the auction that takes place is simultaneous, or parallel (unified auction). All ad networks get an equal chance of winning inventory (not just the preferred ones) and at a better-than-floor price.
It’s worth mentioning that once you replace SDK mediation with in-app header bidding, the number of SDKs you have to install goes down significantly. That equates to better user experience, fewer latency issues, and far less maintenance required to keep all the SDKs up to date.
Tech basics
Here’s how server-side auctions really work.
Let’s take Prebid as an example. If you use this open-source bidding solution, the auction will take place server-side, on Prebid’s server. The only two SDKs you need to install are Prebid SDK and the SDK of your primary ad server.
All the bids and requests will go through Prebid’s server. All that app needs to do is send a bid request to Prebid. The app then just waits for the winning bid which the server returns in form of a key-value pair, and then the app passes the correct pair to the primary ad server.
Inside Prebid, the auction takes place in an optimized environment that is both faster and more efficient. The server sends requests to demand partners who already approved you, the publisher. Supply Side Platforms (SSPs) request bids from Demand Side Platforms (DSPs) that obtain impression goals from advertisers.
All the bids are collected in the Prebid server, the winner is determined, and finally, the key-value pair sent to the app.
The current state of adoption
The in-app header bidding adoption rates were initially quite slow. They were nowhere nearly as high as they were on desktop and even mobile browsers. The reason for that is the difference in implementation, seeing as how header bidding is far more effortless in browsers than it was in apps.
But even with in-app header bidding requirements in mind, this method still beats implementing an SDK for each separate network you’re partners with. For long-standing partnerships, it can easily mean implementing a dozen networks or more.
As soon as publishers recognized the full potential of header bidding, the adoption rate took off. In the third quarter of 2019, in-app header bidding spending doubled. The adoption rates showed no significant variation based on the OS — both Android and iOS platforms were equally represented.
However, this is just taking into account North America and Western Europe, where high connection speeds enabled a massive increase in in-app video ad spend; Asia-Pacific region also saw a 50% increase in in-app header bidding spending in the last quarter. No matter what region we’re discussing, the ad spending has doubled and is much higher than in Q4 of 2018.
Programmatic ad spend amounted to $106 billion in 2019, rising to $126.5 billion globally in 2020. Suffice it to say that the adoption rate is going to keep increasing in the foreseeable future.
Options for setting up in-app header bidding
There are two routes you can take to implement in-app header bidding: you can either build your own solution using open source code or find a partner who’s already built their own open-source solution.
Deciding which path to take largely depends on the technical know-how of your team. If your focus is on advertising and you have the technical resources necessary to build your own header bidding system, then you should invest time and effort into creating your own solution.
However, not every publisher has the resources to dedicate to building an entire bidding environment. In that case, publishers can just get a partner with a prebuilt in-app header solution. Again, it’s best if it’s built on open-source code such as Prebid.org that allows for maximum flexibility and compatibility.
Such a partner will be able to provide all of the in-app header bidding features that are in high demand, such as dynamic floor optimization, different performance campaigns, and integration of all major ad networks.
Conclusion
As in the case with browser header bidding, in-app bidding creates a more open and efficient ecosystem that benefits all parties involved. Both tech solutions reduce ad latency and enable all networks and exchange partners to bid on ad requests evenly, driving more revenue on the publisher side. With all advances and improvements in programmatic advertising, there’s simply no reason to still oppose its implementation in app environments.
