A Publisher’s Guide to Getting Started with Prebid Mobile: Setup, Accounts, and Best Practices

As mobile programmatic monetization continues to mature, header bidding is now expected across web, app, and CTV environments. Yet implementing header bidding in mobile apps still brings confusion for publishers—especially when translating web-based Prebid practices into the mobile ecosystem.

This guide clarifies how to get started with Prebid Mobile and Prebid Server—covering everything from server setup and accounts to stored request management. If you manage app monetization or ad ops, you’ll find clear steps, best practices, and real-world examples as you prepare your inventory for mobile header bidding.

Prebid Mobile and Prebid Server: Core Concepts and Flow

Prebid Mobile brings the concept of header bidding from web to in-app environments. Unlike Prebid.js, which runs in-browser, Prebid Mobile relies on an SDK within your app and a centrally hosted Prebid Server. The app SDK sends bid requests to the server, gathers responses from multiple demand sources, and updates the ad server (like Google Ad Manager) with key targeting information.

Example Flow: How In-App Bidding Differs from Web

In a typical setup, an app loads the Prebid SDK and initiates a bid request before an ad slot renders. The SDK communicates with Prebid Server, which then reaches out to relevant demand partners. Responses are returned to the SDK, which passes targeting keys to your primary ad server, allowing for a unified auction across programmatic and direct demand.

Unlike web integrations, the app and server must be tightly coordinated. Any change to bidders or ad unit configuration typically requires updates in Prebid Server, not the app code—simplifying updates but requiring new operational procedures.

Prebid Server Setup and Account Structure

Getting Prebid Mobile off the ground starts with a Prebid Server host. You can either rely on a managed Prebid Server (offered by some Prebid.org members) or operate your own. The choice affects your direct control, technical resources required, and troubleshooting approach.

Account IDs and Settings: Avoiding Common Confusion

There are two identifiers to manage in Prebid Mobile workflows: the account ID (identifying your organization in Prebid Server) and the account settings ID (sometimes called the auction settings ID). The account settings ID is linked to configuration parameters like timeout and targeting. Sometimes these IDs are merged for simplicity, but larger setups may use separate IDs for each app or site.

Example: Managing Multiple Apps or Partners

If you publish several apps or want to run tailored setups for different business units, use separate account settings IDs. This isolates settings like price granularity and bidders per app, making troubleshooting and reporting much clearer.

Stored Requests: Centralizing and Simplifying Configuration

Rather than hard-coding bidder logic into app releases, Prebid Mobile uses “stored requests” in Prebid Server. These are JSON blocks—linked to IDs—that define how each auction or impression behaves. This enables you to add or remove bidders, tweak parameters, or run tests without pushing a new app version.

Top-Level (Auction) vs. Impression-Level (Config ID) Requests

Top-level stored requests (auction settings IDs) apply to the entire auction (e.g., timeouts, currency, global targeting). Impression-level stored requests (Config IDs) map to individual ad units—defining bidder parameters, placements, and expected formats. Each Config ID links directly to a specific slot in your app via the SDK. For example, a banner ad in your news app uses a stored request like “news-banner-320×50” with its own set of bidders and parameters.

Best Practices: Granular Config for Better Control

Create a separate impression-level stored request (Config ID) for each in-app ad unit. This approach gives flexibility to adjust or test bidders at the ad-slot level and makes troubleshooting much more straightforward.

Ad Server Setup and SDK Integration: Linking Prebid to Delivery

Once stored requests and accounts are set, the last major step is integration with your ad server (GAM, AppNexus, etc.) and app code. You’ll set up line items in your ad server mapped to Prebid targeting keys, ensuring Prebid’s bids can compete in the auction. The SDK in your app initiates bid requests and passes the correct Config ID for each ad slot.

Example: Testing with Stored Responses

For QA or troubleshooting, you can use stored responses—a feature that lets Prebid Server return pre-set bid responses. This ensures stable test data as you confirm correct setup without relying on live demand. Assign a test Config ID in your app to match the stored request containing the desired test response, and set your line items in GAM to respond to that. This is especially useful for validating new demand partner integrations or price granularity changes before pushing live.

What this means for publishers

Properly configuring Prebid Mobile and Prebid Server gives publishers unified control across in-app and web inventory, streamlining partner changes and operational troubleshooting. Ad ops can deploy or modify demand partners without relying on mobile app updates—significantly reducing turnaround time and risk. Understanding stored requests, clear account structures, and ad server mapping are all essential for both revenue growth and troubleshooting efficiency.

Practical takeaway

To get started with Prebid Mobile, coordinate with your technical team or provider to deploy Prebid Server and define all necessary account structures. Prioritize creating detailed and well-labeled stored requests for each ad slot—these give you the flexibility to optimize, test, and troubleshoot demand sources rapidly without repeated app releases.

Ad ops teams should ensure line item and key-value setups in your primary ad server mirror Prebid Mobile targeting logic. Use stored responses for robust QA cycles and sanity checks when onboarding new partners or making major config changes. Document your stored request IDs and configurations, and build a process for periodic review and optimization as your monetization strategy evolves.