Mobile traffic might dominate your GA (Google Analytics) reports, but mobile earnings? Not always the story you’d expect. The behavior difference is severe. Mobile users scroll faster, skip faster, and tap less. That skews everything from viewability to CTR, and by extension, CPC targeting. If you’re using standard 300x250s or mid-content auto ads, you’re painting with a roller on a phone screen. Doesn’t work like desktop.
I once chased a sudden earnings drop thinking AdSense was broken. It was just that my mobile RPM cratered after I switched to a responsive theme. Turns out, that new layout buried the top leaderboard below actual content, dropping first ad FCP (first contentful paint) visibility below the fold on devices under 400px width. Oof.
If your mobile RPM dips below a certain point and your desktop stays relatively steady, you probably surfaced an ad positioning issue—not some deeper algorithm change.
Responsive Ad Units Are Not Actually Fully Responsive
“Responsive” in AdSense doesn’t mean device-context-aware. It just means flexible width and height. But it doesn’t rerun layout logic to optimize fill after the page reflows or resizes client-side. That leads to partial fills or even zeroed-out impressions on certain viewports. Android WebViews especially tend to force early ad loads before full DOM paint, which can cancel requests if the viewport isn’t ready.
I’ve seen ad containers reporting as loaded on Safari iOS, with no ad actually rendering — no revenue, no errors in console, but helpful metrics like 1 impression and 0 fill rate. Cool. Thanks.
What I do now
Avoid in-viewport auto ads at the <body> top — let content breathe first
Preload fonts and key CSS to speed layout stability before ads initialize
Hard-limit ad width to 320px max inside responsive containers on mobile
That last one alone bumped my fill rate on one travel blog by maybe 30% mobile-side, mainly because it gave AdSense a real container size to work with before it had to make fill decisions.
eCPM vs RPM: Understand What You’re Actually Calculating
There’s no headline here—just that most people confuse page RPM (revenue per 1000 pageviews) with eCPM (effective cost per thousand impressions) and assume they’re interchangeable across devices. They’re not. Desktop may win RPM hands-down because one user loads five ad slots at 4K, while a phone barely gets two in-view impressions before bounce.
Also, AdSense will sometimes average eCPM incorrectly across aggregate reports if you blend mobile + desktop without filtering by device. It shows a higher blended desktop eCPM that doesn’t make sense when you look at per-unit performance. It’s misleading—but technically accurate in the way only aggregate stats can be.
If you’re comparing devices, do it like this:
Reports → Ad units → Add filter: Device → Split by Platform
Otherwise you’ll chase phantom RPM cliffs that don’t actually exist. Desktop just gets more milliseconds of eyeball time. It’s not magic.
One Weird Quirk With AMP Pages
AMP basically kills desktop vs mobile comparisons, because it pretends to be mobile on any screen and pipes ad requests differently. If AMP is enabled, AdSense wraps ads in a different loading sequence entirely, and those requests don’t always show up in standard reports. So it may look like mobile is underperforming when half your traffic is on AMP and simply not being counted as cleanly.
There’s an infuriating undocumented behavior: AMP ads ignore parts of your Ad Balance settings, especially around frequency vs user freshness. An ad that should be skipped for repeat users might still show on AMP, because… reasons? I found this after noticing returning users from Twitter kept seeing full mobile banner loads even after I dialed back the Ad Balance throttle to 60%.
If you run AMP and normal pages side-by-side, always use a custom channel just for AMP units. Then combine that with a screen width dimension from GA to approximate true mobile-only AMP performance. Ugly, but necessary.
Fill Rates Vary By Browser More Than Screen Size
Edge case I tripped over: Samsung Internet on some Galaxy phones throttles background iframes differently than Chrome Mobile. This tanked my sidebar ad already performing poorly on mobile; turns out it wasn’t even rendering most of the time, but Google still counted the impression request.
Firefox Focus doesn’t even count. That browser blocks so much JS by default, you’ll get traffic spikes there and wonder why RPM looks like garbage when nothing shows. Not a mobile-vs-desktop issue—just a browser-X-on-device-Y problem that gets lost in typical device reports.
Cross-reference that with your AdSense channel data. If fill rate drops in only one chrome-clone browser, it’s browser-level throttling, not device or layout causing the dip.
Why Auto Ads Are More Aggressive on Mobile
Auto ads on mobile sometimes feel like AdSense got drunk and started placing banners wherever it landed. And in a way, that’s kinda what’s happening.
The algorithm is experiment-heavy. It tries multiple placements based on layout hints and user behavior signals. But mobile pages rarely have the depth of semantic hierarchy desktop layouts do. That means less granularity, fewer clear breakpoints, and more guesswork placement by Google’s crawler.
Auto ads must guess at reading flow, and mobile simply doesn’t give them much margin for that.
Disable overlay ads if you care about bounce rate
Set a visible anchor ad to at least control one slot
Sometimes turning off auto ads completely and hardcoding a max of 2 mobile units performs better by 20-50% RPM-wise
No lie, we did a hard override on AMP with just one mid-article 320×100 and saw more stable CPC and CTR than full auto-ads trying to be smart.
Revenue Sharing Breaks Down Differently by Device Type
Here’s a gross platform logic flaw: If you’re running AdSense through a third-party platform (like a CMS plugin, or through a mediation SDK), the rev share can differ between mobile and desktop—even for the same account.
This sometimes manifests as lower mobile EPC (earnings per click), not because ads are worth less, but because the platform (e.g., WordPress plugins that inject mobile slots) skim more aggressively on mobile where users don’t scrutinize layout as much.
I had a WP plugin that allowed me to drop “mobile fallback” units. Problem was that fallback units ran through their own sub-account, so even though I saw the ads, 85% of the actual earnings were never credited to my publisher ID in the breakdown. Found it by accident while parsing raw ad requests via DevTools network tab. If you’re using any plugins to insert ads dynamically—go sniff request headers. See whose pub ID is actually showing up.
Lazy Loading Ad Units Behaves Inconsistently
Here’s an undocumented edge case: AdSense lazy loading behaves differently depending on scroll container. If your mobile layout uses a nested scrolling container (like some React themes do), ads might never fire even ‘in view’. They technically aren’t inside the top-level scroll listener that AdSense hooks into for lazy logic.
One dev I know ran a full React SPA wrapped in Electron, and their Android version had zero mobile impressions for three months. Ad slots were defined, visible, and loaded—but never requested. Why? Scroll events were trapped inside a framework layer and never bubbled up to the AdSense event hook.
If you’re not seeing loads on lower mobile units, it might help to fire a scroll event manually after DOM ready to nudge things along:
window.dispatchEvent(new Event('scroll'));
I started doing this in production after catching a stack trace in Chrome DevTools that showed loadIfInViewport never actually fired post-mount on mobile Safari.
When Mobile RPM Randomly Surges or Crashes
This stuff just happens. Like, genuinely. Mobile RPM jumps 50% one day—no rollout, no code change, no seasonality. What’s usually going on is:
An advertiser started targeting mobile placements more aggressively (new campaign)
Google ran one of its silent experiments with page-level targeting
An accidental uptick in direct-referral traffic with high CPC signals (Twitter/X, WhatsApp links)
The one time my RPM spiked from 1-digit to almost desktop-level overnight, it turned out someone had posted one of my blog tools on a high-traffic subreddit, and Reddit mobile traffic has unusually high CPC because Reddit users are mid-funnel and weirdly engaged for ~12 seconds per page.
