This page gives an overview of steps you need to take, either as an ad ops user or as a developer, to start using Prebid Mobile.
If this is your first time working with header bidding, we recommend that you read What is Prebid? before diving into Prebid Mobile.
Further Content:
Further Content:
Before you begin using Prebid Mobile in your apps, you need to prepare your end-to-end system. The first step is to set up your Prebid Server host. Prebid Mobile works in conjunction with Prebid Server to request and receive bids. Here are the options:
Prebid Server is an open source project. This allows you to host your own implementation of Prebid Server, though it’s not as easy as downloading Prebid.js, because it needs to be hosted. The source code is available for Prebid Server Go and Prebid Server Java.
See the Prebid Server documentation for more information on setting up your own server host.
Several pages and examples in the mobile documentation refer to entering a “Prebid Server Account ID”.
There are actually two important concepts:
Work with your Prebid Server team to determine which scenario to implement:
See the “integration” pages for each platform for details on how to set up both scenarios.
Working with your Prebid Server host, you will need to create at least one “account settings” block. Prebid Server calls this a top-level stored request. Each top-level stored request contains parameters that are global to the entire auction, not just one adunit. The configuration will be in the form of a JSON structure that will be merged into the OpenRTB. Something like this:
{
"cur": [
"EUR"
],
"ext": {
"prebid": {
"cache": {
"bids": {}
},
"targeting": {
"pricegranularity": "dense",
"includewinners": true,
"includebidderkeys": true,
"includeformat": true
}
}
}
}
Your Prebid Server team should be able to help you decide which parameters are needed and how to get them into Prebid Server.
Again, working with your Prebid Server host, there are likely to be many adunit configurations. Prebid Mobile calls this thing a “Config ID”, while Prebid Server calls it an impression-level stored request. Each stored request configuration contains a list of bidders and their parameters. The configuration will be in the form of a JSON structure that will be merged into the OpenRTB imp
element. Something like this:
{
"ext": {
"prebid": {
"bidder": "bidderA",
"params": {
"placementId": 1111111111
}
}
}
}
Each block of JSON like this is called a “stored request” and gets an ID called a “stored request ID”. This ID is then linked to an adslot using the iOS or Android SDKs, which refer to it as a “Config ID”. Doing it this way allows the publisher to change bidders and parameters without having to change the app.
In general, the recommendation is to create different imp-level stored request for each adunit in your app so that you can manage the bidders and their inventory parameters separately.
If you want to verify the SDK integration with test placements, you can add some Stored Responses to your Prebid Server:
Ad ops users configure the primary ad server with Prebid Mobile line items targeted to key/values.
To begin using Prebid Mobile follow the instructions for the respective platforms and integration approach:
The following resources are available for further information on working with Prebid Mobile: