Whether it’s a custom header bidding platform or adding additional capabilities, our AdTech developers will help you plan, design, and build the right header bidding solution.
A few short years ago it was a radical idea to have programmatic header bidding on mobile. Now it’s a requirement in order to get the maximum yield from a publisher’s inventory. Even though cookie mapping is crippled in the header bidding scenario the benefit of getting all your demand bid on your terms makes a lot of sense and speeds things up.
We work with Prebid to set up a hosted solution for the publishers and work with them to improve the creative loading even further by caching the winning creative and rendering it ourselves. Combined with our efforts in SDK development, it easily cuts the creative rendering time by 30% while ensuring the best possible bids thanks to header bidding auction.
Header Bidding Process for the Publisher
- Demand identification
The main question: is your demand supporting prebid requests or blocking them? Also what is the media support per platform? In some cases, like OpenX, the demand source only supports video on desktop not mobile.
- Test apps
We will need a test app so that we can see how well it performs as part of your waterfall. To be a meaningful test, it has to have at least 50K DAU and have similar segmentation to your main app.
If there is just one app, the same can be performed with caution there. When we do this integration, we usually plug it into MoPub or AdMob waterfall so that if it wins the bid, you get paid from Prebid. If it doesn’t, you still have your waterfall bidding.
Test apps are more of a convenience here rather than a necessity.
- Infrastructure setup
Based on your MAU/DAU, we estimate your requests per second ratio and set up Prebid infrastructure: servers, cache server and configuration.
We work with both AWS and GCP.
Prebid doesn’t provide any configuration tool, so we have to create JSON files and use a prebid config server to serve them.
Depending on your setup and analytics stack, we can also use a patched prebid version that is faster than the original, because it doesn’t perform additional queries.
At this stage we also configure your mediation waterfall to include the Prebid demand.
We use the PubMonkey tool for that.
Prebid allows us to export all the bid requests to different formats and our solution would depend on your existing analytics stack. This may be as simple as logging to the Firebase and using Google Data Studio or as advanced as a custom extension to funnel this to your data lake.
We launch the app and evaluate how it performs in terms of monetization and user retention.
Once the project is completed, we are still available to assist with tweaking and refining the configuration as well as other possible integrations (like analytics or additional demand sources)
Header Bidding Process for the SSP
- Understanding the goals
Our AdTech Manager works with you to identify your goals and to clarify your objectives with publishers.
It is important to clearly define the monetization approach at this stage, as it will define the necessary billing modules.
We will create the Customer Journey Maps and plan the architecture. Iterative requirements specification is also part of this stage.
- Planning and estimating
The usual approach is to deliver an MVP or minimal version that would run with publishers signed up for beta testing and continue to work based on their feedback.
Either way, the result of this stage is an estimate of the resources required to achieve the first milestone.
In the case of Prebid, development is actually an infrastructure deployment and UI for demand configuration (the one we use JSON for in case of Publishers).
If monetization of this solution takes into account winning bids or the number of requests per second, then a billing module is also created.
- Deployment and support
Book a strategy session
Get actionable insights for your product