Adaptive Banner Ads for AdMob: What They Are, Which Type to Use, and What to Expect

If your app still serves fixed 320x50 or smart banners in 2026, adaptive is the upgrade and you're leaving 27-200% eCPM on the table per published AdMob case studies. The decision isn't whether to switch. It's anchored vs inline, how to test the change without breaking fixed-height container layouts, and what to expect across geo tiers. The article assumes you've decided to switch and need the operator answer on type selection, integration, and realistic lift.

Why fixed 320x50 caps your eCPM

The technical mechanism: standard 320x50 locks creatives to one aspect ratio. Inventory that wants to bid taller creatives (richer formats, higher-CPM advertisers) can't compete in a 320x50 box and routes elsewhere or doesn't bid. Adaptive's SDK calculates the best height and aspect ratio per device based on the creatives actually in the demand pool at request time. The banner takes full device width. Height is chosen to match what advertisers are willing to pay most for. Demand previously gated by the format limit becomes addressable.

That's the entire economic story. Apps still on fixed banners aren't earning less because Google deprecated the format (smart banners are deprecated, standard 320x50 isn't). They're earning less because their format choice is filtering out higher-CPM creative inventory.

The mistake I see most: teams know they should switch, decide it can wait until the next big release, and "next big release" never comes. The integration is small. The economic cost of waiting compounds.

Anchored adaptive vs inline adaptive: the difference that actually matters

Most developer questions about adaptive banners get stuck right here. Picking the wrong type either breaks your UI or leaves money on the table. Here's the practical version of the distinction.

Anchored adaptive

Anchored adaptive sits at the top or bottom of the screen with a max height of 150dp on Android, 150 points on iOS, or 20 percent of the device height, whichever is smaller. The size gets calculated once based on device width and stays consistent across sessions. Pick anchored if:

• Your banner sits in a persistent UI slot (game HUD, app bottom bar, dashboard footer)
• Your layout has a fixed-height container baked in (most games, most utility apps)
• You don't want the banner height shifting between sessions

Inline adaptive

Inline adaptive lives inside scrollable content, has no hard height cap by default, and the height can change between page views. The SDK picks a taller creative whenever one's bidding higher. Pick inline if:

• Your banner is in a news feed, article body, or list view
• Your container can flex to whatever height the SDK returns
• You want maximum eCPM and your UI can absorb the variance

Comparison

Height: Fixed 320x50: Fixed 50dp · Anchored adaptive: Variable, max 150dp · Inline adaptive: Variable, no hard cap

Placement: Fixed 320x50: Anywhere · Anchored adaptive: Top or bottom fixed · Inline adaptive: In scrollable content

Layout shift risk: Fixed 320x50: None · Anchored adaptive: Low · Inline adaptive: Medium (variable height)

eCPM vs 320x50: Fixed 320x50: Baseline · Anchored adaptive: +20-48% typical · Inline adaptive: +20-200% (content apps)

Best for: Fixed 320x50: Legacy, mediation fallback · Anchored adaptive: Gaming HUDs, persistent app UI · Inline adaptive: News, content, list feeds

Fill rate: Fixed 320x50: Lower · Anchored adaptive: Around 99% (Google demand) · Inline adaptive: Around 99% (Google demand)

SDK min version: Fixed 320x50: Any · Anchored adaptive: GMA Android 18.3.0+, iOS 7.52.0+ · Inline adaptive: GMA Android 20.x+

What I'd actually do first

Inline is the higher-eCPM choice. It also has a cost: layout variance. If your UI has fixed-height placeholder slots, switching to inline without a redesign will clip the ad or break the surrounding layout. So for any app with rigid UI containers, especially games, start with anchored. Validate the lift. Then plan inline for the content surfaces where your layout already flexes.

What the data actually shows: eCPM lift from switching

The "up to 20 percent" figure floating around blogs and answer threads came from Google's 2019 launch post. Six years later, that number is the only one most articles cite. It's stale. The current case study data is more honest about the range.

Zaim (Japanese household budgeting app, hybrid IAP plus ads model)

• 27 percent eCPM increase on iOS versus standard AdMob banners
• 48 percent eCPM increase on Android versus their previous non-AdMob solution
• 33 percent CTR increase on Android
• Match rate close to 100 percent

Source: AdMob's own published case study. The 27 percent iOS number is the cleanest apples-to-apples comparison because it benchmarks adaptive against standard AdMob banners, with everything else held constant.

NiBG (Nightingale Business Group / Proficient Games, gaming studio in Lahore, Pakistan, around 1M MAU across 12 RPG and strategy titles)

• 200 percent eCPM increase over standard 320x50 banners
• 99 percent fill rate
• 20 to 30 percent user engagement increase
• Test method: Firebase A/B test, 50 percent user split, landscape mode, ten game titles tested simultaneously

The 200 percent number sounds extreme but it makes sense given the baseline. NiBG was on the standard 320x50 with default mediation. The combined effect of larger creatives and better demand competition produced the lift.

What you should actually expect

The case studies are real but they're outliers. The typical pattern I see across stacks is more boring:

• Apps already on AdMob with a clean mediation setup: 20 to 40 percent eCPM lift in Tier 1 markets (US, UK, AU, DE)
• Tier 3 markets: usually single digits to low teens. Demand depth is shallower
• Apps moving off a poorly configured baseline (still on smart banners, no mediation, or running a non-AdMob banner network): closer to the Zaim and NiBG range
• Floor pricing matters. If you have aggressive floors set against standard 320x50, adaptive will surface higher-paying creatives that your old floors were filtering out

The format unlocks demand that was previously gated by size. How much demand was gated determines your specific lift. There's no universal number.

Adaptive banners vs normal banners: should you switch?

Almost always yes. The honest answer just depends on what you're starting from.

If you're on standard 320x50 and your SDK supports adaptive (GMA Android 18.3.0 or later for anchored, 20.x for inline; iOS 7.52.0 or later): switch. There's no scenario in 2026 where staying on fixed 320x50 beats anchored adaptive.

If you're on smart banners: switch. Smart banners are deprecated. Adaptive is the direct replacement.

If you're on a mediation SDK (AppLovin MAX, ironSource LevelPlay, Unity LevelPlay): less straightforward. AdMob's adaptive sizing applies only to AdMob's demand inside the waterfall. Other networks in your stack will keep serving their own banner sizes. Check each network's docs for their adaptive or flexible banner support before assuming the whole stack behaves the same way.

If your app has a fixed-height banner slot baked into the UI: anchored is the safer starting point. It caps at 150dp so the variance is bounded. Inline in a fixed-height container will clip or overflow.

If you're already on adaptive but only running anchored: look at inline for your scrollable surfaces. Inline routinely earns 30 to 50 percent more eCPM than anchored on content-heavy apps. The larger creatives compete and the SDK picks the highest bid that fits.

How to implement adaptive banners in AdMob (Android and iOS)

This isn't going to be a copy-paste code tutorial. Google's developer docs are the right source for full SDK code samples and they update faster than any editorial article ever will. What's worth covering here is the configuration layer, the test methodology, and the gotchas that the official docs don't.

The minimum integration

In AdMob, an adaptive banner is loaded by calling the size-calculation function with the actual device width, then loading the ad request against that size. On Android, that's typically AdSize.getCurrentOrientationAnchoredAdaptiveBannerAdSize(context, width) for anchored or AdSize.getCurrentOrientationInlineAdaptiveBannerAdSize(context, width) for inline. On iOS, the equivalents live on GADAdSizeFromCGSize with the helper functions GADCurrentOrientationAnchoredAdaptiveBannerAdSizeWithWidth and GADCurrentOrientationInlineAdaptiveBannerAdSizeWithWidth.

The width you pass should be the actual screen width minus any safe area insets, not a hardcoded value. Hardcoding 360dp or similar produces sub-optimal creative selection. Use Resources.getSystem().getDisplayMetrics().widthPixels / density on Android, or the equivalent on iOS.

Capping inline adaptive height

The most common bug after switching to inline adaptive is the banner rendering taller than expected on tablets or large-display phones. The fix is using the variant that takes a max height: getInlineAdaptiveBannerAdSize(width, maxHeight) instead of getCurrentOrientationInlineAdaptiveBannerAdSize(width). A max height of 100 to 250dp covers most use cases without clipping competitive creatives.

Test before full rollout

NiBG used Firebase A/B testing, splitting users 50/50 between their existing setup and adaptive. That's the right pattern. Don't flip all placements at once. Pick your highest-impression placement, run a one-week A/B, then expand if the eCPM lift exceeds your threshold. Somewhere between 10 and 20 percent is a reasonable bar to call it a win.

No Firebase A/B testing wired up? The next-best path is a phased rollout by app version: ship adaptive in the next release, monitor eCPM and crash rates for 7 to 14 days, commit or revert.

What most developers get wrong when switching

The same handful of mistakes show up across most stacks. None subtle. All cost money.

1. Inline adaptive in a fixed-height container. The banner gets clipped or the container overflows. Switch to anchored, or refactor the container to flex.

2. Hardcoded width. Passing a static value (360, 375) instead of the actual device width. The SDK can't pick the best creative if you lie to it about the size. Use the runtime width.

3. Switching all placements at once. Now you can't attribute which placement drove what. Test your highest-impression placement first in isolation, then roll out by placement priority.

4. Benchmarking against the wrong number. Comparing your eCPM after switching against your eCPM from six months ago. Seasonal demand variance, geo mix shifts, and ad-quality changes all affect that number. The A/B test isolates the format effect. The year-over-year comparison doesn't.

5. Expecting the same lift across all geos. The 27 percent and 48 percent case study numbers come from apps with majority Tier 1 traffic. If 70 percent of your audience is South Asia or Southeast Asia, your absolute lift will be smaller because demand depth is shallower in those markets.

6. Forgetting that mediation only applies to AdMob's demand. If your adaptive unit is configured but your waterfall has Meta Audience Network or Unity Ads in it, those networks aren't bound by AdMob's adaptive sizing. They'll keep serving 320x50 or their own equivalent.

Most of the issues I see aren't with the format itself. They're with how the implementation was tested. Or, more often, that it wasn't.

Frequently asked questions

What is the difference between adaptive banners and smart banners?

Smart banners were Google's previous automatic-sizing format. Adaptive banners replaced them in 2019. The key technical difference is that adaptive banners consider the aspect ratios and performance of available advertiser demand when choosing a height, not just the device screen size. Smart banners are deprecated. If you are still using smart banners, switch to adaptive.

Should I use anchored adaptive or inline adaptive banners?

Use anchored adaptive if your banner is positioned at the top or bottom of a fixed app screen (typical for games and utility apps). Use inline adaptive if your banner is embedded inside scrollable content (news feeds, article detail screens, list views). Inline adaptive typically earns more eCPM because the variable height allows larger creatives to compete, but it requires a scrollable content container and introduces height variability your UI needs to handle.

How much can I expect my eCPM to increase after switching to adaptive banners?

Published AdMob case studies show 27 to 48 percent eCPM improvement (Zaim, a Japanese finance app) and up to 200 percent improvement (NiBG, a gaming studio in Pakistan) over standard 320x50. For an app already on AdMob with a reasonable mediation setup, 20 to 40 percent improvement in eCPM is a realistic expectation in Tier 1 markets. Tier 3 markets typically see smaller gains. The floor is close to 0 percent if your current setup is already near-optimal.

Do adaptive banners work with mediation platforms like MAX or LevelPlay?

Adaptive banners are a Google AdMob feature and apply to AdMob's demand within a mediation waterfall. Other networks in your mediation stack (Meta Audience Network, Unity Ads, AppLovin's own demand) may serve standard-sized banners even when your AdMob placement is set to adaptive. Check each network's SDK documentation for their adaptive or flexible banner support. AdMob's adaptive sizing only applies to the AdMob-filled impressions.

Why are my inline adaptive banners showing as very large on some devices?

Inline adaptive banners have no hard height cap by default. On large tablets or specific screen configurations, they can render significantly taller than a typical phone banner. To set a maximum height, use getInlineAdaptiveBannerAdSize(width, maxHeight) instead of getCurrentOrientationInlineAdaptiveBannerAdSize(width). Set maxHeight to a value that fits your UI, typically 100 to 250dp depending on your layout.

Is it worth switching to adaptive banners if I am a small developer with low traffic?

Yes. The implementation effort is low (it's a configuration change, not a rebuild) and the fill rate impact is immediate. At low traffic volumes the absolute revenue gain is small, but there is no downside to switching. The format is Google's recommended standard and 320x50 is effectively legacy. Switch once, then focus your optimization energy on placement, mediation setup, and floor pricing where the bigger gains live.

What to do this week

If you've made it this far and you're still running standard 320x50 or smart banners on a meaningful share of impressions, here's what I'd actually do:

1. Confirm your SDK version supports adaptive (Android GMA 18.3.0+ for anchored, 20.x+ for inline; iOS 7.52.0+).
2. Identify your highest-impression placement. That's the one you test first.
3. Set up an A/B test, Firebase Remote Config or your own server-side flag, splitting users 50/50 between existing and adaptive.
4. Run for at least 7 days to clear weekly seasonality. 14 is better.
5. Compare eCPM, fill rate, and viewability against the control. If the lift exceeds 15 to 20 percent in Tier 1 markets, commit. If it's smaller, look at your geo mix and decide whether to roll out anyway or dig in further.
6. Once the first placement is committed, repeat for the rest in priority order.

The format change itself is easy. Doing it right means running it like an experiment with a proper baseline, not a one-line code swap on a Friday afternoon.