PubMatic OpenWrap SDK: AdMob Integration, eCPM Benchmarks, and an Honest Comparison to Prebid Mobile

OpenWrap SDK is PubMatic's wrapper on top of Prebid SDK. It adds PubMatic's managed demand layer, cloud-based config UI, and SPO relationships, then plugs into AdMob mediation as a bidder or waterfall line item. Most operators integrate it for the demand mix, not the wrapper. The decision is whether PubMatic's specific demand pool fills a gap in your existing stack.

OpenWrap SDK in your stack

PubMatic ships OpenWrap SDK as a Prebid wrapper. The Prebid Mobile internals do the auction work. The OpenWrap layer on top adds three things you don't get from vanilla Prebid: PubMatic's programmatic demand and SPO buyer relationships, cloud-based config management for floor prices and partner toggles without app store pushes, and PubMatic's analytics dashboard.

The two operational details that actually matter in production:

• Cloud config management. You can adjust floor prices, toggle which partners serve, and modify ad unit settings from PubMatic's UI without shipping a new app build. Worth a real amount of operational time over the lifecycle of an integration. Most teams underuse this.
• Open Measurement and SKAdNetwork pre-integrated. Saves you from doing those integrations separately, which matters for iOS post-ATT and for any vendor measurement requirements your demand partners enforce.

Format coverage is what you'd expect from a serious mobile demand SDK: banner, interstitial, rewarded, native, outstream video, MRAID. Android API 23+ and iOS supported. The current SDK is on version 5.1.0 with 55 public releases on GitHub, which matters mainly because the version number you read in any blog post (including this one) is stale within weeks. Always check the current Maven Central or PubMatic docs for the actual integration version.

OpenWrap SDK vs Prebid Mobile: the actual difference

Both are built on Prebid SDK internals. The difference is what wraps around them.

Prebid Mobile is fully open source. You configure all demand partners yourself, you write or use community-maintained adapters, and you take on the operational work of maintaining the integration. There's no managed layer and no vendor dependency. If you have a strong ad ops team that wants full control, this is the path.

OpenWrap SDK is PubMatic's managed wrapper on top of Prebid. You get access to PubMatic's programmatic demand network, their SPO (supply path optimization) relationships with major buyers, their analytics dashboard, and their cloud UI for config management. The trade-off is that you're relying on PubMatic's infrastructure and demand quality.

If you're already running Prebid Mobile with PubMatic configured as one of your bidders, there's no point adding OpenWrap SDK on top. That's redundant demand from the same source.

Comparison: OpenWrap SDK vs Prebid Mobile vs MAX/LevelPlay

Open source: OpenWrap SDK: Partially (Prebid core) · Prebid Mobile (vanilla): Fully · AppLovin MAX / LevelPlay: No

Demand network: OpenWrap SDK: PubMatic + OpenRTB buyers · Prebid Mobile (vanilla): Any configured SSP/bidder · AppLovin MAX / LevelPlay: AppLovin / ironSource + adapters

Config management: OpenWrap SDK: Cloud UI, no app store push · Prebid Mobile (vanilla): Code-level, requires release · AppLovin MAX / LevelPlay: Dashboard plus release for some changes

Setup complexity: OpenWrap SDK: Medium · Prebid Mobile (vanilla): High · AppLovin MAX / LevelPlay: Low to medium

SKAdNetwork support: OpenWrap SDK: Yes · Prebid Mobile (vanilla): Partial (depends on bidder) · AppLovin MAX / LevelPlay: Yes

Open Measurement SDK: OpenWrap SDK: Pre-integrated · Prebid Mobile (vanilla): Separate integration needed · AppLovin MAX / LevelPlay: Included in most adapters

Best for: OpenWrap SDK: Apps wanting PubMatic demand with managed infra · Prebid Mobile (vanilla): Publishers wanting full control · AppLovin MAX / LevelPlay: Apps already in MAX or LevelPlay ecosystem

eCPM lift vs waterfall: OpenWrap SDK: +11% to +197% in PubMatic case studies · Prebid Mobile (vanilla): Varies entirely with bidder mix · AppLovin MAX / LevelPlay: Competitive, varies by vertical

The real question is rarely "OpenWrap SDK or Prebid Mobile?" It's "Do I already have a strong mediation setup with multiple bidders, or am I starting from a thin waterfall?" Those two situations call for different answers.

How OpenWrap SDK works inside AdMob mediation

Two integration modes exist: bidding and waterfall.

Bidding mode is the recommended path for new integrations per Google's current docs. PubMatic competes in real time inside AdMob's unified auction, alongside whatever other bidders you have configured. The winner is decided per-impression based on actual bids, not on static CPM tiers.

Waterfall mode is available as a fallback. PubMatic gets a CPM-ranked line item in your traditional waterfall. It's the older model, still works, but it locks PubMatic out of real-time auction competition. If your mediation group supports bidding, use bidding. Use waterfall only if your mediation group doesn't, or if you want PubMatic as a specific fallback layer for unfilled inventory.

The cloud UI side is where most operators don't realize they're underusing the integration. Once the adapter is installed, you can toggle PubMatic on or off, change floor prices per ad unit, modify which partner accounts serve, and tweak almost every setting from PubMatic's dashboard. No new app build required. Most teams ignore this and treat OpenWrap SDK like a static integration.

Setting up OpenWrap SDK in AdMob, step by step

Google's official docs walk through the SDK code. What follows is the same flow with operator annotations on what to watch for.

1. Create a PubMatic account. Select OpenWrap SDK as your product. Add your app (Android or iOS). Note the Profile ID and Publisher ID from PubMatic's Analytics section. You'll need them in step 3.
2. Create an ad unit in PubMatic. Note the OpenWrap Ad Unit ID. Update your app-ads.txt file with PubMatic's authorized entries before you start testing. This is the most commonly skipped step. Without it, PubMatic demand will not flow at all, and the failure mode looks like "low fill" rather than a clear error. Check your app-ads.txt at https://yourdomain.com/app-ads.txt and confirm PubMatic's lines are there.
3. In AdMob: Navigate to Mediation, create or edit a mediation group, and add PubMatic OpenWrap SDK as an ad source. Enter the Ad Unit ID from step 2. Choose bidding or waterfall mode based on what your mediation group supports.
4. Add PubMatic to your GDPR and US state regulations ad partners list. This is required, not optional. Skipping it causes PubMatic demand to be suppressed for any traffic in GDPR scope, which is most of Europe. Symptom: strong fill in US, near-zero fill in EU. Easy to misdiagnose.
5. Install the SDK and adapter via Gradle (Android) or CocoaPods/Swift Package Manager (iOS). Current versions: PubMatic SDK 5.0.0, adapter 5.0.0.1, Google Mobile Ads SDK 25.2.0. Keep these aligned. Version mismatches between the adapter and the SDK produce silent failures that look like low fill, not visible errors.
6. Test, then ship. Enable test ads, verify fill, check that PubMatic demand is showing up in your AdMob revenue reports. Once verified, disable test mode before production.

One note on Google's docs: the integration is currently labeled "Beta." That label reflects Google's documentation update cadence, not OpenWrap SDK maturity. The SDK is on version 5.1.0 with 55 public releases and is in production use across major apps. The "Beta" tag is a Google labeling choice, not a stability signal.

What eCPM lift to actually expect

PubMatic publishes case studies on their product page. The numbers look good but they need context.

Published PubMatic case studies:

• Sofascore: +197% revenue
• Veraxen: +165% revenue growth, +23% eCPM
• AutoScout24: +34% revenue uplift
• Dwango: +27% CPM, +11% revenue
• Hungry Studio: +8% banner ARPDAU, +10% banner eCPM
• Talkatone: +3X fill rate

Two things to note about those numbers. First, the high-end results (Sofascore +197%, Veraxen +165%) come from apps that were either moving from a weak waterfall setup or had no programmatic at all. The big gains are mostly the result of switching from "almost nothing" to "something real," not the result of OpenWrap SDK specifically being magic.

Second, when you have an already-optimized mediation stack with several bidders, the marginal lift from adding one more bidder is smaller. The case studies don't tell you what your incremental lift will be. They tell you what's possible from a low baseline.

Realistic expectations for an app with an existing AdMob mediation stack:

• Tier 1 markets (US, UK, DE, AU, CA): 10-30% eCPM improvement on PubMatic-filled impressions. Fill rate from PubMatic alone won't cover 100% of inventory. PubMatic competes for impressions, doesn't replace your other bidders. Total revenue impact depends on what share of your traffic PubMatic wins.
• Tier 3 markets: Minimal demand density from PubMatic in many regions. The integration overhead may not be worth the marginal return.
• If your existing setup is already strong: 5-15% incremental on the slice PubMatic wins.
• If your existing setup is weak (waterfall-only, few bidders, no header bidding): Higher gains, but most of the lift is "starting to do header bidding properly," not OpenWrap SDK specifically.

The pattern is consistent. The format unlocks demand that was previously gated. How much demand was previously gated determines your specific lift.

When OpenWrap SDK makes sense and when it doesn't

This is the section PubMatic's product page won't write for you. The honest version:

Worth adding if:

• You want PubMatic's programmatic demand specifically. Their buyer relationships skew toward brand-safe, SPO-oriented advertisers, which differs from the AppLovin or ironSource demand mix.
• Your current mediation stack has fewer than 3-4 bidders. Adding another real-time bidder usually pays back the integration cost.
• Cloud-managed config without app resubmissions matters to you. Useful for small dev teams or slow release cycles.
• You operate primarily in Tier 1 markets where PubMatic has bid density.
• Your ad formats include rewarded video or outstream video. PubMatic has historically been strong on video CPMs.

Not worth adding if:

• You're already running 5+ bidders with strong fill. The marginal return on the sixth bidder is rarely worth the integration cost.
• Your primary markets are Tier 3. PubMatic's demand density there is thin and the integration overhead is disproportionate to the return.
• You don't have an ops resource to manage another SDK and monitor for revenue discrepancies. Multi-bidder setups need ongoing tuning, not just a one-time install.
• Your app is pre-revenue or very early stage. The integration overhead is not proportionate until you have consistent impression volume.
• You're already running Prebid Mobile with PubMatic as a configured bidder. Adding OpenWrap SDK on top is redundant demand from the same source.

The decision is rarely about OpenWrap SDK in isolation. It's about whether your mediation stack has room for another real-time bidder, and whether PubMatic's specific demand mix fills a gap your current bidders don't.

What most developers get wrong during integration

The same mistakes show up across most integrations. None subtle. All cost revenue.

1. Skipping app-ads.txt before testing. PubMatic demand won't flow until your app-ads.txt has PubMatic's authorized entries. The failure mode is silent: you see low fill and assume the SDK isn't working, when really the auction is rejecting bids because the publisher isn't authorized. Update app-ads.txt first, then test.

2. Choosing waterfall mode when bidding mode is available. Adding PubMatic as a static-CPM waterfall line item locks them out of real-time competition. They win only when no higher-CPM source is available, which is the scrap heap of your inventory. If your mediation group supports bidding, use bidding.

3. Version mismatches. The PubMatic adapter and the OpenWrap SDK must be compatible with each other and with your Google Mobile Ads SDK version. Mismatches produce silent failures that look like low fill rate. Check the version compatibility matrix in PubMatic's docs before each upgrade.

4. Forgetting the GDPR partners list in AdMob. If you don't add PubMatic to AdMob's GDPR and US state regulation ad partners list, all GDPR-scope traffic will have PubMatic demand suppressed. Symptom: strong fill in US, near-zero in EU. Common, easy to misdiagnose.

5. Treating the cloud UI as optional. The cloud-based config management is one of the most useful features. You can adjust floor prices, toggle demand, modify ad unit settings without an app release. Ignoring it means every optimization requires a dev cycle, which is exactly the kind of friction that kills monetization tuning.

Most issues I see aren't with the SDK itself. They're with what got skipped during setup or what got forgotten during the first week of optimization.

Does OpenWrap SDK work for web publishers?

No. OpenWrap SDK is mobile-only, Android and iOS. It's not a solution for web or blog monetization.

If you're a web publisher looking for PubMatic's programmatic demand, the relevant product is OpenWrap for web (a separate JavaScript-based wrapper) or standard Prebid.js with a PubMatic bidder adapter configured.

This matters because several queries around "OpenWrap SDK" come from web publishers who landed here by mistake. If you've been trying to integrate it on a web property, that's why nothing's working. The SDK and the web wrapper share a name but are entirely different products.

Frequently asked questions

Is OpenWrap SDK free to use?

There's no direct licensing fee. PubMatic takes a revenue share on impressions they win, similar to how any SSP operates. You pay nothing to integrate. Your cost is the share of winning bid revenue that goes to PubMatic. There's no public standard rate. It varies by publisher agreement and depends on volume and deal type.

Does OpenWrap SDK work with AdSense or only AdMob?

OpenWrap SDK is a mobile SDK and integrates with AdMob mediation specifically. It doesn't work with AdSense, which is a web publisher product. If you're a web publisher looking to add PubMatic demand, the relevant product is OpenWrap for web, which is a separate JavaScript-based wrapper.

What's the difference between OpenWrap SDK and Prebid Mobile?

OpenWrap SDK is built on Prebid SDK internals but wraps PubMatic's managed layer on top. With Prebid Mobile, you configure all demand partners yourself, full open source, no vendor dependency. With OpenWrap SDK, you get PubMatic's programmatic demand specifically, plus cloud-based config management and PubMatic's analytics, in exchange for relying on PubMatic's infrastructure. If you're already running Prebid Mobile with PubMatic as a configured bidder, adding OpenWrap SDK would be redundant.

How long does it take to integrate OpenWrap SDK with AdMob?

For a developer familiar with AdMob mediation, the integration is a few hours of focused work. The steps are: create a PubMatic account, configure an ad unit, update app-ads.txt, add PubMatic as an ad source in your AdMob mediation group, add the SDK and adapter via Gradle or CocoaPods, and add PubMatic to your GDPR ad partners list. The app-ads.txt update and the GDPR partner step are the two most commonly skipped. Skip either and demand won't flow correctly.

Can I run OpenWrap SDK alongside MAX or LevelPlay?

Yes. OpenWrap SDK integrates as an AdMob mediation source, either as a bidder or waterfall ad source. It's additive to your existing mediation stack. You can run it alongside AppLovin MAX adapters, ironSource and LevelPlay adapters, and other AdMob bidders simultaneously. Bidding mode lets PubMatic compete in real time with the other bidders in the same auction.

Is OpenWrap SDK labeled Beta by Google? Should I be concerned?

Google's official Android integration guide labels the PubMatic OpenWrap integration as "Beta" as of mid-2026. This reflects Google's documentation update cadence, not PubMatic's SDK maturity. The OpenWrap SDK itself has 55 public releases on GitHub, is on version 5.1.0, and is in production use across major apps. The "Beta" label means Google's mediation adapter documentation isn't yet finalized, not that the SDK is unstable for production use.

What to do this week

If you're running an AdMob mediation stack and OpenWrap SDK isn't on it, here's what I'd actually do:

1. Decide whether OpenWrap SDK fits your situation using the criteria in the "When it makes sense" section above. The honest answer for a lot of mature stacks is "no, but not because OpenWrap is bad. Because you're already at diminishing returns from adding bidders."
2. If it fits, set up the PubMatic account. Update app-ads.txt the same day. That's the step that gets skipped most often.
3. Choose bidding mode in AdMob, not waterfall. Don't bury PubMatic in static CPM tiers.
4. Add PubMatic to AdMob's GDPR partners list before testing. Skipping this is the second most common reason "the integration doesn't work."
5. Run the SDK in test mode, verify fill, ship.
6. After two weeks of production data, look at the PubMatic-filled impressions specifically. Compare eCPM against what those impressions would have earned under your old mediation. That's the actual number that tells you whether OpenWrap SDK is paying off, not the gross revenue line.

If you're evaluating whether OpenWrap SDK fits your specific setup and you'd rather talk it through than read another docs page, book a 30-minute call. I'll tell you whether it's worth the integration effort based on your current mediation stack and traffic mix.