Why are developers transitioning to in-app header bidding? Monetization is a prime motivation; advertisers are spending a staggering $286B on mobile in 2020, and are doing so programmatically. Developers who started their monetization business with legacy ad solutions are also running into challenges when trying to scale, resulting in:
- SDK bloat: The average number of SDK integrations per app has ballooned to 18.2, in part caused by client side integrations per demand partner and integrations for measurability support.
- App performance issues: 40% of developers reported that it takes over two seconds for their ads to appear, which leads to poor user experience. This is caused by multiple pass backs in auctioning methods which run sequentially across multiple ad network SDKs.
By running parallel auctions server-side, in-app header bidding solves these scaling challenges, as well as increases demand for app inventory.
In-app header bidding options
If you’re thinking about making the transition to in-app header bidding, there are three main options to consider:
- Build with open source: Prebid.org promotes transparency and fairness, with easily verifiable code, and provides publishers a wide choice of partners. It enables collaboration to develop flexible, effective solutions.
- Choose a partner who is built on open source: At PubMatic, we have taken the approach of building a solution from the ground up to support Prebid. Partnering also includes integration support, testing, troubleshooting, and optimizing yield.
- Choose a partner who has a proprietary solution: Some solutions are based on proprietary technology, which offers less transparency and control than options in the open source space.
What to consider if you’re new to the domain
Evaluate your investment priorities: Open source has a wealth of control and innovation, but success requires technical specialization and management. The main question developers should to ask is how much they want to invest in-house. If they intend to make advertising central to their product strategy, it makes sense to build in–house. If advertising is meant to fuel their product strategy, developers may end up diverting dev resources and time away from core priorities.
For context, we’ve been working in advertising technology for over 10 years, with a hundreds of technical specialists in-house. This includes technologists within our engineering teams, as well as dozens of technical implementation experts across the globe. Each of these in-house specialists have spent at least 3 years working on Prebid directly, some contributing to the Prebid codebase and review.
You don’t know what you don’t know: In mobile ad tech, there is a clear divide between legacy solutions like ad networks and waterfalls, and in-app header bidding. Developers working on the one may not have a full understanding of the challenges involved in the other. As a result, many who attempt to move from legacy methods to in-app header bidding on their own have faced issues. Below are a few examples of challenges we’ve seen from mobile developers new to in-app header bidding:
- Deployment: Client Side SDK integration troubleshooting (especially with Android)
- Maintenance: Technical fixes around banner refresh mechanisms – this involves figuring out how to make the in-app header bidding solution work seamlessly with a primary ad server SDK
- Optimization: Primary ad server line item management issues, such as missing certain parameters and mis-configuring keywords or parameters, can lead to poor yield
- UI/Reporting: Developers are on their own to set up reporting analytics that gives header bidding auction level insights as well as aggregation of data across multiple demand sources
Not only are developers new to the domain, and building with open source, more likely to run into mistakes and issues, but they will also face challenges trying to resolve them alone. Most app companies have small monetization teams, so these types of friction points can heavily impact operations.
Bridging the skills gap
Our approach has been to invest on building a stable, enterprise-grade SDK that supports Prebid. That way, app developers new to the space can boost their speed to deployment and smoothly transition to header bidding that’s rooted in the open source. Here’s how OpenWrap SDK works under the hood:
- OpenWrap SDK makes a call to the OpenWrap server (built on Prebid)
- OpenWrap Server executes cloud side auction across multiple demand partners and exchanges simultaneously to find the highest bid
- Winning bid is sent back to SDK, and sends call to ad server
- If ad server finds an ad that is of higher price, then ad server’s ad is rendered. Otherwise, OpenWrap SDK renders the winning bid from OpenWrap Server side auction.
By leveraging solutions like PubMatic’s OpenWrap SDK, developers can
- Avoid common growing pains
- Quickly capture programmatic spend and brand budgets
- Reap the benefits of innovation from open source-based technology
We’re excited to announce that OpenWrap SDK is now generally available. To learn more, contact us or visit our documentation page.
