Have you been noticing ‘in-app headerbidding’ appearing more frequently in your feeds lately? It's because ad monetisation in apps is gaining momentum, as it should. Consider this: counting both the App Store and Google Play, over seven million apps cover every genre and niche you can think of (Business of Apps). On top of that, an average American spends 276 minutes or 4.6 hours on the phone daily (Statista). Well, 2 + 2 = it’s natural for in-app ad monetisation to grow, and Prebid Server could be just what you need as a Publisher to tap into this revenue source economically.
Over the past three years, Relevant Yield has actively supported publishers through the adoption of Prebid Server and Prebid SDK. It’s not just about slapping ads into an app; it’s about finding a more innovative, cost-effective way to implement header bidding. This journey has provided valuable insights, uncovering both challenges and opportunities.
We present this article as your trusty guide through the jungle of jargon and technical tangles. We've trodden this path before, dodging the pitfalls and gathering golden insights. Now, we're here to share those treasures with you.
It’s actually quite simple…
It is best to start by laying down the basic ground rules on how the Prebid server & Prebid SDK function. Let’s remind ourselves how Prebid on desktop works, as it is easy to draw parallels between the two:
Imagine the process of implementing prebid.js on your desktop & web mobile pages. At a macro level, this can be broken down into:
- Setting up the auction (ad units, bidders, floor prices, etc).
- Building prebid.js & implementing it on the page.
- Associating the auction to your ad units.
When setting up prebid in a ‘classic’ manner for desktop, these three steps all occur on the client side, in the website’s code.
With this as a frame of reference, we can then relate these to how things happen with Prebid SDK & Prebid Mobile implementations:
- Setting up the auction: This is handled ‘server-side’ via the Prebid server.
- Building Prebid: Once again, this occurs server-side, with the version of the Prebid server used being the equivalent to the prebid.js version.
- Associating the auction with the ad unit: All managed within the ‘client,’ specifically in the iOS or Android app code, using the suite of tools provided by the Prebid SDK.
Regardless of the toolset chosen for implementation (GAM Original, Rendering, Mediation, etc), these key principles remain unchanged.
Meticulous attention to detail…
Okay, that was simple, wasn’t it? However, just because it is simple doesn’t mean we can overlook the need to be attentive to Prebid Server & Prebid SDK’s ‘special’ requirements. It’s always the details that count!
Unfortunately, the fallacy that any solution is ‘plug & play’ within ad tech is never more true than with in-app header bidding.
Why? Because SSPs all want different things delivered in different ways, only available via a solution you haven’t implemented…yet.
Effectively utilising Prebid Server in-app necessitates a keen eye for these details and a great rapport with your account managers. Unique bid request requirements by SSP, specific endpoints based on geography, and device-specific SSP IDs are just some of the details that require attention.
Factors such as diminishing support for legacy standards, considerations for the latest Privacy standards & iOS vs Android disparity, all underscore the importance of planning & communication and highlight the nuanced nature of in-app monetisation.
Once these aforementioned details have been addressed, minor adjustments can have a significant impact with potential ramifications in both positive and negative directions. However, when done right, a publisher can expect to see incremental ad unit request value growth accompanied by increased AdX revenues.
Incremental Growth & Uplift
What's this all worth to a publisher, you may ask? Well, here you go, a couple of case studies proving our points:
Case 1:
- +100M app installs
- 6M unique users per day
- 16M page impressions per day
Publisher 1 had already implemented Prebid in-app via a 3rd-party SDK. They made the switch to a ‘house’ implementation of the Prebid SDK framework & took on the Relevant Prebid Server. Publisher 1 has seen a YoY growth of 19%.
Case 2:
- +5M app installs
- 2.2M unique users per week
- +100M page impressions per month
In contrast to Publisher 1, Publisher 2, without in-app bidding before Prebid SDK integration, achieved substantial growth of 51%.
For both cases, the value of each ad unit request continues to rise as SSPs become more and more comfortable bidding on their inventory, with fill rates rising as a consequence.
Conclusion
As you can see, Prebid in-app functions are relatively simple, so publishers should not be wary of this. Instead, they should ‘go in with eyes wide open.’ However, to unlock the full potential of their inventory, they will need to be attentive to the nuances of prebid in-app and the specific requirements of the SSPs.
Venturing into new territories can be daunting; we understand. Trying something new, especially in the vast and fast-paced programmatic industry, often feels like stepping into unknown waters. But remember, every great adventure starts with that first step of courage, and having an experienced ad tech partner like Relevant Yield can make the journey smoother.
We actively support publishers through the adoption of Prebid Server and Prebid SDK, providing them with a cost-effective means and much less headache to monetise apps with header bidding. Imagine the relief of not having to invest heavily in building and maintaining an in-house Prebid server!
The initial setup is complex, but ongoing maintenance is the real challenge. It's a task that demands continuous work and advanced knowledge, often requiring the full-time attention of at least one senior developer. We take on this demanding role for you. This way, you can concentrate on what you do best as a publisher—creating engaging content and delivering a great experience to your audience.
Feel free to reach out if you'd like to learn more.
