Mediation vs Prebid Server vs Open Bidding: Choosing the Right Mobile In-App Monetization Architecture

Mobile in-app monetization has three competing architectures, each with a different set of trade-offs around auction mechanics, transparency, and operational burden. Most publishers end up using some combination of all three, but few understand where each one actually fits or how they interact.

This guide breaks down waterfall mediation, Prebid Server, and Google Open Bidding for mobile apps. The goal is to help you understand what each does, where they overlap, and how to choose based on your team size, demand needs, and tolerance for platform lock-in.

---

Table of Contents

1. How Each Architecture Works
2. Side-by-Side Comparison
3. Latency Comparison
4. SDK Footprint Comparison
5. Control vs. Convenience Trade-off
6. Things Worth Knowing in Practice
7. Revenue Share and Fees by Mode
8. Which Solution by App Type
9. How to Choose
10. Why BiddingStack
11. Getting Started

---

How Each Architecture Works

Mediation (Waterfall)

A mediation SDK calls ad networks sequentially based on historical eCPM tiers. Each network gets a "first look" at its set price. If it doesn't fill, the next network in line gets a chance.

The mediation provider handles the decisioning client-side. You install the mediation SDK plus adapter SDKs for each network you want to include. Configuration happens in the mediation platform's dashboard, where you set up price tiers, priority rules, and network credentials.

The core limitation is sequential execution. A network at tier three never gets a chance to bid higher than a network at tier one, even if it would have. Revenue is left on the table whenever a lower-priority network would have paid more than the network that won by position alone.

Prebid Server (Prebid Mobile SDK + PBS)

Prebid Server is the open-source, server-side header bidding solution adapted for mobile apps. The Prebid Mobile SDK sends a single request to a Prebid Server instance, which fans out that request in parallel to all configured SSPs and exchanges. Each bidder returns a real-time bid, and the winning bid competes inside your primary ad server or mediation layer.

The key advantage is full transparency. You get complete bid logs, you control the auction rules, and you are not locked into any single vendor's ecosystem. The challenge is operational complexity: running a Prebid Server instance, configuring adapters, and mapping line items in your ad server requires significant engineering investment and ongoing maintenance.

This is where a managed Prebid Server solution changes the equation. BiddingStack's Managed Prebid Server is fully compatible with the Prebid Server ecosystem but works out of the box. You get every benefit of Prebid Server, full bid transparency, the broadest demand pool, and no platform lock-in, without provisioning or maintaining any infrastructure. The BiddingStack Mobile SDK is a lightweight drop-in client that connects to the managed server, and it goes beyond what the standard Prebid Mobile SDK offers: built-in first-party data integration, an analytics and insights dashboard, automated floor price optimization, and ad quality controls are all included out of the box.

Open Bidding (Google, formerly EBDA)

Open Bidding is Google's server-side unified auction inside Ad Manager and AdMob. Approved demand partners bid in real time alongside Google's own demand, and Google operates the auction.

From an integration standpoint, this is the lightest option. There are no additional SDKs to install beyond Google's. Demand partners onboard server-side through Google's platform, and the auction runs automatically. You configure it through your Ad Manager or AdMob account.

The trade-off is control and transparency. Google runs the auction, takes a revenue share from each Open Bidding partner, and you get Google's reporting rather than raw bid-level data. Your demand pool is limited to Google's approved partner list, which is more curated than the open set of PBS adapters available.

Side-by-Side Comparison

Dimension	Mediation (Waterfall)	Prebid Server	Open Bidding
Auction model	Sequential, price-tier based	Parallel, real-time, server-side	Parallel, real-time, server-side
Who runs the auction	Your mediation provider (client-side decisioning)	You or your managed PBS provider	Google
Demand transparency	Low: tier prices, not true bids	High: full bid logs available	Medium: Google reports, limited raw access
Latency profile	Worst case is high (each tier waits for timeout)	Low: single parallel call	Low: single parallel call
Integration effort	One mediation SDK + adapter SDKs per network	Lightweight with a managed solution like BiddingStack	None beyond Ad Manager setup; partners onboard server-side
SDK footprint	Heavy: each network needs its own SDK	Light: no per-bidder SDKs (server-side)	Light: no per-bidder SDKs
Demand pool	Whatever networks your mediator supports	Any SSP or DSP with a PBS adapter (very broad)	Google's approved partner list (more limited)
Fees	Mediation rev share (often 0 to 5 percent) + each network's take	Managed-service fee; no auction tax	Google takes a rev share from each Open Bidding partner
Optimization burden	High: manual tier tuning unless using bidding-enabled mediator	Low: price discovery is automatic	Low: auction handles it
Control and portability	Tied to mediator's roadmap	Open source, fully portable	Google-locked
Best fit	Smaller apps wanting plug-and-play, or as the host that consumes Prebid and Open Bidding bids	Publishers wanting transparency, custom demand, and no platform lock-in	Apps already standardized on Google Ad Manager or AdMob

Latency Comparison

How long does each architecture take to resolve an auction? Waterfall mediation chains timeouts sequentially, while parallel approaches resolve in a single round trip.

SDK Footprint Comparison

Each additional SDK in your app binary increases build size, cold start time, and privacy surface area. Mediation requires the most SDKs; server-side approaches keep the client lightweight.

Control vs. Convenience Trade-off

Each architecture sits at a different point on the control-versus-convenience spectrum. More control means more operational investment; more convenience means more platform dependency. BiddingStack's managed approach uniquely delivers both: full Prebid Server control with managed convenience.

Things Worth Knowing in Practice

Waterfall Mediation Is Largely Deprecated as a Pure Approach

Modern mediation platforms now offer "in-app bidding" where supported networks bid in parallel inside the mediation layer. Architecturally, this is closer to Open Bidding than to a classic waterfall. When people say "mediation" today, they usually mean a hybrid: bidding-enabled networks bid in parallel, while non-bidders sit in a residual waterfall.

This matters because comparing "mediation vs. Prebid Server" is often comparing two parallel bidding systems with different governance models, not a sequential system against a parallel one. The real question is usually who runs the auction and what demand you can access, not whether bids happen in parallel.

Prebid Server and Open Bidding Are Not Always Either/Or

A common production setup uses Google Ad Manager as the primary ad server, with Open Bidding partners bidding through Google and Prebid Server demand plugged in as another line of bids in the same auction. They coexist; the question is whether you want a second, non-Google bidding stream.

Running both gives you the widest demand pool. Open Bidding provides easy access to Google-approved partners. Prebid Server lets you add SSPs and exchanges that are not on Google's approved list, or that you want to transact with directly without Google's revenue share applied to those bids. BiddingStack makes running both straightforward: the Managed Prebid Server plugs directly into your existing GAM setup alongside Open Bidding, so you can layer in additional demand without building new infrastructure.

Mobile Prebid Requires Server-Side Infrastructure

If you have experience with Prebid.js on the web, mobile Prebid will feel familiar in concept but different in execution. App auctions flow through the Prebid Mobile SDK to a Prebid Server instance, then back to SDK rendering or video VAST. The server-side component is not optional in mobile the way it can be avoided on web.

Running a Prebid Server instance means maintaining a production service that handles real-time bidding traffic with strict latency requirements. This is the primary barrier that keeps many mobile publishers from adopting Prebid Server, even when the demand and transparency benefits are clear.

BiddingStack's Managed Prebid Server removes this barrier entirely. The BiddingStack Mobile SDK is a drop-in client that connects to a fully managed Prebid Server instance, compatible with standard Prebid Server adapters and protocols. You configure your demand partners in the BiddingStack dashboard and start receiving parallel bids without provisioning a single server.

Revenue Lift Depends on Your Baseline

Moving from pure waterfall to any parallel bidding system, whether Prebid Server, Open Bidding, or in-app bidding inside a modern mediator, usually shows meaningful CPM lift. The gains come from true price discovery: every bidder competes on every impression instead of waiting in a queue.

Moving between parallel bidding solutions tends to show smaller, demand-mix-dependent differences. The incremental lift from adding Prebid Server to a setup that already has Open Bidding depends on which SSPs and DSPs you add through PBS that were not already bidding through Google. The reverse is also true. The key is maximizing the number of unique demand sources competing in your auction and making sure each bidder sees the richest possible signal. BiddingStack's built-in first-party data integration and automated floor price optimization help on both fronts: more bidders see better signals and bid higher, while dynamic floors prevent impressions from clearing below their true market value.

Revenue Share and Fees by Mode

Exact figures are mostly NDA-protected and negotiable, but the structural pattern is well understood. The key insight is that fees stack at multiple layers: mediation or auction tax, SSP or network take rate, and sometimes an ad server fee.

Mediation (Bidding-Enabled or Waterfall)

Mediator Type	Mediation Fee	Notes
Most mediation platforms	0% on third-party demand	The mediator earns through their owned-and-operated network's take rate (typically 10 to 20 percent) when their own demand wins

The mediator earns through their owned-and-operated network's auction take, not a per-call fee. Each third-party network keeps its own take rate, typically 10 to 25 percent, before paying out to the publisher.

Prebid Server (via BiddingStack)

Layer	Fee
Prebid software	Free, open source
BiddingStack Managed PBS	Managed-service fee; no auction tax, no per-call fees
Each participating SSP/DSP	Their own take rate (typically 10 to 20 percent per SSP)

No "auction tax." You pay the managed-service fee and each SSP's natural take. With BiddingStack's Managed Prebid Server, you get the most cost-efficient path per dollar of demand: no hidden fees, no platform rev share on bids, and no infrastructure costs to manage yourself.

Open Bidding (Google)

Layer	Fee
Google Ad Manager / AdMob ad serving	Standard GAM/AdMob terms
Open Bidding partner fee	Google takes a rev share from each OB partner, widely reported at roughly 5 to 10 percent, not officially disclosed but confirmed during DOJ antitrust proceedings to be in that range
Each OB partner network	Their own take rate (10 to 20 percent)

Each Open Bidding partner's bid has had Google's cut shaved off the top before you see it. The convenience is real (no SDK per partner, parallel auction, server-side), but you pay for it.

Stacked Example: Same One Dollar Bid, Three Paths

This is a rough illustration. Actual splits vary by partner, format, and negotiated terms.

The reason Open Bidding still wins in many setups is that it brings additional demand that would not otherwise compete. Even after the fee, an extra bidder lifting clearing prices is worth more than the tax costs you. The best outcome is stacking both: BiddingStack's Prebid Server demand alongside Open Bidding, so you get maximum competition without paying Google's rev share on the Prebid Server bids.

Which Solution by App Type

App Type	Primary Recommendation	Why
Hyper-casual / casual games	Bidding mediator	Gaming demand is concentrated in mediation platforms; rewarded video is mature in bidding mode
Mid-core / hardcore games	Bidding mediator + BiddingStack for premium video	Same gaming demand, plus Prebid Server demand via BiddingStack lets you tap brand video for higher-eCPM rewarded slots
News / content / publishing	BiddingStack Managed Prebid Server + Open Bidding	Brand programmatic demand flows through GAM; BiddingStack adds broad SSP demand; banner, native, and interstitial all well-served
Streaming / video apps	BiddingStack Managed Prebid Server + Open Bidding	Premium video demand (CTV-adjacent SSPs) is much broader via Prebid Server; VAST/VPAID handling matters
Utility apps (weather, tools)	BiddingStack Mobile SDK or a single bidding mediator	Keep it simple. Fill rate matters more than auction sophistication at typical eCPMs
Social / UGC apps	Bidding mediator primary, add BiddingStack as you scale	Performance demand dominates early; brand demand via Prebid Server becomes worthwhile past meaningful DAU scale
Dating apps	Bidding mediator + BiddingStack for native	Performance-heavy demand similar to social; native ads via Prebid Server work well in feeds
E-commerce / shopping	BiddingStack + GAM if monetizing	Brand-safe programmatic display is the natural fit; most e-commerce apps prioritize self-promotion
Fintech / health / kids	Curated direct deals + GAM, minimal third-party SDKs	Brand safety, compliance (COPPA, financial regs), and data minimization push you toward fewer SDKs; BiddingStack's single-SDK approach helps here
Large premium publisher	BiddingStack Managed Prebid Server + Open Bidding	Maximum transparency, no lock-in, full demand competition, without needing an in-house PBS engineering team

Decision Shortcuts

• No dedicated ad-ops or eng resource? Use BiddingStack's managed solution. You get Prebid Server demand with zero infrastructure overhead.
• Already deep in Google stack (GAM/AdMob)? Add BiddingStack's Managed Prebid Server alongside Open Bidding for the lowest-effort demand expansion beyond Google.
• Want maximum demand? Stack BiddingStack Prebid Server bids plus Open Bidding partners plus mediation residual demand, all competing in GAM.
• Privacy-sensitive vertical (kids, health, finance)? Fewer SDKs is safer. BiddingStack's single lightweight SDK with server-side bidding minimizes your client-side footprint.
• Gaming-first? Start with a bidding mediator, then add BiddingStack for premium video and brand demand as you scale.

How to Choose

Small or mid-size app, no dedicated ad-ops team. Start with a bidding-enabled mediator for plug-and-play monetization, or go directly with BiddingStack's Mobile SDK if you want Prebid Server demand without the operational complexity. Either way, you get parallel bidding without running infrastructure.

Already on Google Ad Manager and want more demand quickly. Add BiddingStack's Managed Prebid Server alongside Open Bidding. BiddingStack plugs directly into your GAM setup, adding broad SSP and exchange demand without Google's rev share on those bids. You keep Open Bidding for Google-approved partners and layer BiddingStack on top for everything else.

Large publisher, wants transparency, custom demand, no lock-in. BiddingStack's Managed Prebid Server gives you the full Prebid Server demand pool and bid-level transparency without the infrastructure investment. You get complete auction control, full bid logs, and no platform lock-in, plus capabilities that a raw Prebid Server setup does not include: first-party data activation, analytics dashboards, automated floor pricing, and ad quality controls.

Want maximum competition. Stack them. BiddingStack Prebid Server bids, Open Bidding partners, and mediation residual demand all compete in the same primary auction. This produces the most competitive auction dynamics and typically the highest yield.

Why BiddingStack

Most mobile publishers understand that Prebid Server delivers the best transparency, the broadest demand, and the most cost-efficient auction economics. The problem has always been the operational barrier: running PBS infrastructure, configuring adapters, mapping line items, and maintaining a production service with strict latency requirements.

BiddingStack removes that barrier entirely, and goes further. The BiddingStack Mobile SDK is not just a wrapper around the Prebid Mobile SDK. It is a more complete solution that adds capabilities Prebid Mobile does not offer on its own.

BiddingStack Mobile SDK vs. Prebid Mobile SDK

Here is what that means in practice:

Out-of-the-box Prebid Server compatibility. BiddingStack's Managed Prebid Server runs the same Prebid Server protocols and adapters. Any SSP or DSP with a PBS adapter works with BiddingStack. You are not locked into a proprietary ecosystem.

First-party data integration. The BiddingStack Mobile SDK has built-in support for passing first-party audience signals, user segments, and contextual data directly into bid requests. With Prebid Mobile SDK alone, wiring first-party data into the auction requires manual configuration and custom development. BiddingStack handles the plumbing so your first-party data actually reaches bidders and lifts CPMs.

Analytics and insights. BiddingStack provides a dedicated analytics dashboard with auction-level visibility: bid density, win rates by partner, latency breakdowns, fill rate trends, and revenue attribution across demand sources. Prebid Mobile SDK gives you raw bid logs but no built-in tooling to interpret them. With BiddingStack, you make optimization decisions based on clear data rather than parsing server logs.

Floor price automation. BiddingStack includes automated floor price optimization that adjusts floors dynamically based on real-time auction data, demand patterns, and historical performance. Setting floors with Prebid Mobile SDK alone means manual configuration and guesswork. Automated floors consistently recover revenue that static or manual floor strategies leave behind.

Ad quality and brand safety. BiddingStack provides ad quality controls that let you block categories, advertisers, and creatives before they render in your app. Prebid Mobile SDK has no built-in ad quality layer, so you are relying entirely on each SSP's individual filtering.

Lightweight single SDK. A single, lightweight SDK replaces the multi-SDK mediation approach. Smaller app binary, faster cold starts, and reduced privacy surface area compared to installing adapter SDKs for every network.

No auction tax. Unlike Open Bidding, BiddingStack does not take a rev share from each bid. You pay a transparent managed-service fee and each SSP's natural take rate. More of every dollar reaches you.

Works alongside your existing setup. BiddingStack does not replace your ad server or mediator. It plugs into GAM, AdMob, or your mediation layer as an additional demand source. You can add it to an existing stack without ripping anything out.

Fast integration. Most publishers go from SDK integration to live Prebid Server demand in days, not months. No servers to provision, no adapters to configure, no line items to map manually.

Getting Started

The right starting point depends on where you are today:

If you are running a pure waterfall, the fastest path to meaningful CPM lift is adding parallel server-side bidding. BiddingStack's Mobile SDK can plug into your existing setup and start delivering Prebid Server demand without changing your mediation layer or ad server configuration.

If you already have parallel bidding through a mediator or Open Bidding and want to expand your demand pool, BiddingStack's Managed Prebid Server adds broad SSP and exchange demand as a new competitive line in your auction. You can test the incremental revenue impact without any infrastructure commitment.

If you are evaluating architecture from scratch for a new app, start with BiddingStack as your Prebid Server layer and add Open Bidding through GAM for Google-approved demand. This gives you the widest demand pool with the least operational complexity from day one.

Whichever path you take, the principle is the same: more bidders competing in parallel on every impression produces better price discovery and higher yield. BiddingStack makes it possible to get there without the engineering overhead that has historically been the cost of entry.