Why Your Mobile Popup CTR Is Tanking (But Desktop’s Fine)
I chased this rabbit hole for about three days before realizing Google didn’t hate me—it just hated my timing. Mobile AdSense behaves differently from desktop, not just in terms of layout, but also in terms of user engagement expectations. The click-through rate tanks when the popup appears either too early or overlaps content in odd ways.
On desktop, a 5-second delay plus exit-intent trigger works great. On mobile? There’s no exit intent. You’re stuck with time delay or scroll position. But—and here’s the catch—if your scroll percentage logic fires before the page is visually complete (looking at you, lazy images), the popup shows up while the user is still looking at an empty header.
The fix? Switch from “scroll %” to an actual DOM visibility trigger. I use IntersectionObserver to detect when the footer or a specific article block enters the viewport. It reacts to user behavior more naturally.
const observer = new IntersectionObserver(entries => {
entries.forEach(entry => {
if (entry.isIntersecting) {
showPopup();
observer.disconnect();
}
});
});
observer.observe(document.querySelector('#article-end'));
Auto-Blocking Elements That Kill Your Popup
So, here’s what bit me last October: I had a password reset module triggering a full-screen overlay on some post-login flows. Didn’t matter that the login wasn’t mobile traffic—the module’s CSS was injected globally, and yes, it had a rogue z-index: 99999.
Of course, my mobile popup ads wouldn’t show. No errors. No console logs. Just…nothing. Turns out, the popup was rendering in the DOM—confirmed via $('#adx-popup').is(':visible') returning false. But the DOM node was actually under a hidden overlay that hadn’t been cleaned up.
A quick dirty fix is to dump this into your load watcher:
Obviously don’t run this live unless you like chaos. But in dev/investigation? Gold. I eventually just made my ad containers forced to z-index: 2147483647; and moved on.
Handling AdSense Policy Violations Caused by Popups
Around February, one of my recipe blogs got slapped with a policy violation: “Ads interfering with content.” The offending popup was compliant per layout guidelines, but AdSense reviewers still flagged it. I appealed. Denied. Fml.
Digging through support.google.com/adsense, I found a throwaway line: if the popup appears before any interaction or scrolling, it’s more likely to be flagged—especially for mobile-first content.
So now I always tie mobile popup ads to a user behavior, even if it’s minor:
First scroll by 100px
Initial tap on any nav element
Firing it only on article views, not homepage
Tracking bounce rate changes in GA4 weekly
Auto-closing it after 8 seconds on idle
I use a debounce so it doesn’t stack if someone scrolls fast or taps multiple times. The policy system is harsh, but the nuance is in how fast you show attention-grabbing UI before the person feels “settled in.”
Viewport Height Bugs on Mobile Safari Ruining Layouts
This is the one that made me question reality. I had a bottom-fixed popup banner shifting offscreen, intermittently, but only on iPhones—and only when the keyboard wasn’t active. Didn’t happen on Chrome Android, nor on desktop Safari.
Turns out iOS Safari reports window.innerHeight differently depending on scroll state and navigation bar visibility. So your 100vh popup container might suddenly think the screen got taller and politely slide halfway out of sight.
Workaround That Stuck
I hardcoded a CSS custom property on page load:
function setDocHeight() {
let vh = window.innerHeight * 0.01;
document.documentElement.style.setProperty('--vh', `${vh}px`);
}
window.addEventListener('resize', setDocHeight);
setDocHeight();
Then use in your CSS:
.popup {
height: calc(var(--vh, 1vh) * 100);
}
It wasn’t perfect, but it solved the weird margin bleed for 99% of regular use. There’s no perfect fix—the viewport bugs are linked to iOS UI chrome—but this got my layouts back on track.
Don’t Trust Lazy Loading Timelines for Triggering Popups
One thing I learned the hard way: the onload event on mobile doesn’t mean what you think it means. If there are <img loading="lazy"> tags (or worse, dynamically injected ads placed BEFORE your popup logic), then your execution timing drifts.
Example: I had the popup logic tied to window.onload, thinking it’d fire post-page-build. But since lazy images defer, and GPT-style ad units use iframes that load async, some browsers wouldn’t hit onload until after scrollable content appeared.
What finally fixed it was shifting to requestIdleCallback:
if ('requestIdleCallback' in window) {
requestIdleCallback(() => {
initAdPopup();
});
} else {
setTimeout(initAdPopup, 2000);
}
Worth noting: requestIdleCallback isn’t universally supported (hello Safari), but it performs way better than setTimeout-based hacks, and it obeys the paint/scroll behavior better on modern Android devices.
Some Popups Just Aren’t Seen—And You’d Never Know
This one was brutal. Popup reported impressions, but no user clicks. Not even a close button triggered. At first I thought maybe spam traffic or ad blindness—but nope. Chrome Light mode (Data Saver) strips off some non-critical JS when under extreme data-saving thresholds, especially on older Android builds.
The kicker? This behavior wasn’t mentioned anywhere obvious. I found it out from a buried paragraph on Chromium’s tracker, and confirmed it with a phone loaded up with dev builds. JavaScript below ~1kb usually gets through, but multiple nested calls or JIT manipulations (like new Function()) get dropped.
“Popup not appearing unless I serve it from a single .js inline block” — that’s when it all clicked.
I restructured the sequence so that: logic → render functions → assets were inline on mobile, external on desktop. Slightly messy in source, way more reliable in practice.
Oh Right: Cookie Consent Blocks Everything By Default
This one’s obvious, but I ignored it for way too long. A GDPR cookie consent “wait-for-confirmation” for ad-serving blocked my entire popup system because it was technically placing a cookie—just to detect rerenders.
The CMP blocked script execution until user interaction. So the entire lazy load logic was choking silently. No logs, no crash—just nothing.
If your popup depends on cookies or local storage, double-check that your CMP isn’t blocking document.cookie access. Some frameworks like Quantcast or OneTrust go nuclear until user action is confirmed—even if the scripts aren’t serving ads yet.
In my workaround, I disabled cookie reliance until after consent. Just doing const canWriteCookie = navigator.cookieEnabled && CMP.hasUserConsent() was enough to gate the popup init.
