EEltaCrew
HomeBlog

Same app, same users, native ads paid 38x more per 1,000 impressions than banners, and why I stopped short of deleting the banner units

Published 2026-09-16Measured 2026-09-03About 3 min readelta · EltaCrew

Seven days of AdMob data from two TV remote apps, comparing revenue per 1,000 impressions for banners and native advanced ads. How over-exposure kills the rate, how to read native's low fill rate, and why I aborted deleting the banner ad units the next day.

I wanted to know how much the ad format alone changes revenue, so I compared two remote apps with the same kind of users over seven days. The gap was bigger than I expected.

The measurements

App Format Impressions Click-through Revenue per 1,000
Genie TV remote Native advanced 99 4.04% $8.85
Genie TV remote Banner 524 4.39% $2.98
U+TV remote Banner 11,645 0.24% $0.23

Inside Genie TV alone, native pays 3x the banner. U+TV's banner against Genie TV's native is 38x.

Why the U+TV banner was worth $0.23

98.5% of U+TV's impressions were banners, and it was showing them 16 times a day per user. Genie TV's banner showed 0.8 times a day. Same format, click-through 4.39% versus 0.24%, an 18x difference, for that reason. A person who sees the same banner 16 times a day stops looking at it. Push impressions up and the rate comes down, so total revenue does not scale with impressions.

The lesson is not "make more impressions". The previous post said session time creates impressions, but if you inflate those impressions with banner refreshes, the rate takes it back. One banner view for the whole app, not a new one per screen. Creating one per screen resets the refresh timer every time, which adds impressions and subtracts rate.

Native's catch: fill rate

Switching everything to native is not the end of it either. Over the same period the show rate (impressions divided by matched requests) was 98% for banners and 21% for native. Native fills one request in five. The ad space is often empty.

So the verdict is total revenue, not impressions and not the rate. A 38x rate with one-fifth the fill is a much smaller real difference. I switch one app at a time, fix a re-measurement date in advance, and compare total revenue. As I write this, that date is 18 September. Nothing gets reverted before then.

Implementation notes

Why I stopped short of deleting the banner units

The day after switching the code from banners to native, I went to clean up the banner ad units in the AdMob console. Before deleting, I pulled the previous seven days of revenue by format.

The code had moved to native, but most of the revenue was still coming from banners. Users who had not updated were still requesting ads with the old ad-unit IDs baked into the APK on their phones. Deleting the unit in the console would have zeroed those requests on the spot, and ad-unit deletion cannot be undone.

The ad unit in the console and the ID constant in the source are two different things. Removing it from the source leaves the ID alive in every installed APK, and the revenue keeps arriving. Before deleting a unit, look at its recent revenue and wait until old-version users have thinned out. This is one of the reasons I later put forced in-app updates into every app.

Summary

AdMobad revenuenative ads

Related

My AdMob account had zero GDPR consent messages: adding UMP to 21 apps in one dayA new app's release log said "no form(s) configured". The AdMob account had no European-regulation consent message at all, and only 3 of 17 live apps even contained UMP code. The order of operations to create the message, add the code to 14 apps and re-release, plus the traps along the way.Ad revenue is set by session time, not downloads: AdMob numbers across 15 appsEleven apps with more monthly users produced 27 times fewer ad impressions than four TV remote apps. Where the gap between 7.68 and 0.18 impressions per user per day comes from, and how it changed the order I do marketing in.