In a previous blog post, I outlined misconceptions that many app developers have about in-app header bidding. The launch of our in-app capabilities solved many of the referred issues in monetizing apps effectively. However, publishers’ needs have evolved and some challenges remain.
For instance, app developers are limited in the number of header tags they can run from a mobile device. Generally speaking, mobile connections are slower and devices are less powerful than desktops. As a result, an in-app wrapper that calls multiple exchanges / SSPs directly from the device (client-side) creates user experience issues, including added latency when connected through a mobile carrier.
Another issue is related to the app update and approval process. Adding a new demand partner directly in an app requires the developer to update the app on Google Play or the Apple App Store, which requires a non-trivial release process. The extra work on already strained publisher resources makes it difficult for publishers to experiment with different set-ups for their header bidding strategies.
PubMatic addresses these issues with OpenWrap, a wrapper tag supporting server-side in-app header bidding (also known as parallel bidding). The wrapper leverages a lightweight and flexible code that requires a one time installation in the app. Any subsequent exchange / SSP adaptors are integrated within the server, which makes a callout to the respective exchange. The server-side capabilities of PubMatic’s OpenWrap enable app developers to achieve the full benefits of header bidding that desktop and mobile web publishers have been experiencing since the introduction of wrappers to the ecosystem.
OpenWrap’s in-app wrapper installation process is simple:
- Set up
- In-app tag is added to the app
- Exchanges / SSPs are selected
- Line items are configured in the publisher’s existing ad server
- Runtime
- Tag makes a call to the technology provider (PubMatic) when a user opens the app
- PubMatic makes a call to other exchanges / SSPs and collects responses
- Auction is carried out, and a winner is sent to the user’s device
- Ad server call is made from the app, and the winning line item is selected
- Creative is delivered
This methodology has several benefits. First, it simplifies the integration of new demand sources by removing technical complexity to be managed within the app, and also speeds up the activation and deactivation of demand sources. As a result of this simplification, publishers do not have to wait for weeks to modify their app and get Google Play or the Apple App Store to approve their apps. Fewer changes to the app itself means that publishers can spend more time on their core features, limiting the risks introduced by frequent release processes.
The above framework also allows for experimentation. App developers (or their operations teams) can experiment with different demand partner set-ups to find the optimal yield. An experimentation process relies on ability to make several tweaks and should be flexible.
Lastly, latency is reduced as the technology provider’s infrastructure is handling the majority of the ad call process, rather than it being handled on the handheld device. The publisher does not need to rely on the computational power of the user’s device, resulting in better latency controls, potentially more successful bid responses, improved auction dynamics and better monetization. As web publishers have learned, increased competition results in higher eCPMs.
Whether you call it server-side, parallel bidding, or continue to refer to in-app header bidding, it is clear that there are significant benefits to app developers to implement these new technologies. PubMatic is excited to be at the forefront of header bidding innovation, helping to make our publisher partners’ monetization goals possible while ensuring that their user experience is not impacted.
