Let’s just get this out of the way: Google AdSense does not like pop-unders. Even if you’re surgically careful about how they launch, Google’s filters are basically trained to nuke anything that smells like a window trying to sneak past Chrome’s precious UX priorities. Officially, they give you an evasive line like “No site should interfere with user navigation,” but in practice that includes any link that opens a new tab behind the current one… even if you didn’t initiate it.
One time I had a fitness blog (don’t ask) that had been running like a champ on AdSense. I added one highly-optimized pop-under ad via a custom JS handler that only triggered on a second pageview per session. Next morning: policy violation. And not just for the pop-under unit — they disabled the entire ad inventory across all pages temporarily, because, quote, “site behavior misleading user.”
What’s weird is they didn’t flag any malicious domain — just the technique of opening windows behind the user’s current tab without active intent. Even vanilla JS window.open calls that passed Chrome’s rules still got AdSense in a moral panic.
The kicker? No public policy page clearly defines the boundary. You’re reverse-engineering acceptable interaction patterns based on accumulated rejections. It’s like debugging a linter that changes its mind every 48 hours.
PropellerAds and the Trade You’re Actually Making
When I hopped over to PropellerAds for pop-under inventory, I immediately made more per thousand sessions — not dramatically more, but enough to notice. Honestly, I traded earnings stability for payment reliability. Propeller does pay on time, and they’ll run whatever variants of pop-unders you want — tabunders, onclick triggers, mobile re-directs. As long as the user eventually gets back to your main content, they don’t care.
The real trap is frequency capping. Their default settings show pop-unders per user like it’s 2012 Flash game monetization again. You need to go into the individual zone configs and clamp down the frequency to something semi-tolerable. I do 1 per 6-hour session window. Otherwise you’ll wake up to people begging in comments to remove the scammy redirect behavior, and your bounce rate will spike past any usable analytics value.
The CPC tanked slightly on generic pages, but CPMs held up. It turns out even low-quality pop-under networks aren’t stupid — they’re optimizing for regions and time-of-day models like everyone else. And Propeller is no longer the wild west third-tier network it used to be. Just don’t get attached to clean UX principles. They’re optional here.
How Pop-Unders Behave Across Browsers (Spoiler: They Don’t)
There’s something darkly hilarious about testing pop-unders on modern browsers. Firefox handles window open calls like a bitter negotiator — sure, you can open one window if the user actually clicked, but screw you if you try to position it behind the current tab. Safari? Sometimes it lets you create a delay-open popup, sometimes it eats it with a silent fail, sometimes it opens an occupied domain in a new tab and logs an error asynchronously without warning. Edge behaves mostly like Chrome but throws diagnostics if you get silently blocked.
On Chromium-based browsers, pop-unders technically work if user gestures are present — this means click, keydown, some touch inputs. But even then, Chrome will focus the new tab, so it’s no longer a pop-under in the classic sense. You now have a rude tab redirect. There’s no winning here unless you abuse iframe contexts or invisible anchors, which gets you flagged at the ad network level eventually.
If you’re doing cross-browser behavior checks, just prepare for disappointment. Different security settings, different default flags (like window.open permissions on incognito), and random webview shenanigans on mobile leave you with maybe 65% coverage at best.
That Time Chrome DevTools Saved My Ad Revenue
I once spent three very stupid hours debugging why my pop-under wasn’t firing consistently on my downloads page. Turns out the event listener was Passive by default. I had a touchstart event that launched the ad, but the `passive: true` setting quietly means you can’t call `preventDefault()` — so the browser instantly navigated instead of launching the window.
You’ll never see this in error logs, it doesn’t break anything explicitly — just fails silently. It wasn’t until I opened DevTools, went to the Event Listeners tab and saw that tiny passive flag that it clicked. Switching the listener back to passive: false fixed it immediately. Easily my biggest “oh that’s why” moment with pop-unders in the past few years.
This sort of deep debugging is how you eventually end up mumbling version numbers in Chrome feature logs out loud at 2 AM.
Referral Leakage and Analytics Poisoning
Pop-unders regularly confuse Google Analytics. When you use JS to launch a new tab in the background, most analytics setups count the session as a bounce — sometimes even as a direct exit. Worse, depending on your redirect chain and how quickly the user returns to your tab, you can get weird double counting across GA properties.
One edge case I hit last winter: when I used a smart redirect-backed URL in a pop-under (served via Propeller’s rotating links), the visitor’s origin became “referral from own domain” in about 1 in 10 cases. I suspect it’s due to Chrome’s referrer downgrade behavior on non-HTTPS links combined with caching. It poisoned some A/B test data for weeks before I caught it.
If you’re serious about clean data and still want to run pop-unders, you’ll need:
Hard-coded referral exclusions for your own URL paths
Event tracking on outbound pop-under triggers
A wait-and-resume timer if the user returns within 5–10 sec
Separate hostname profiles for analytics cleanroom testing
Dedicated session segmentation buckets for pop-fired traffic
Otherwise, GA4 will show ghost interactions and misattribute engagement times like it’s on hard drugs.
Script-Level Differences You Actually Need to Know
AdSense’s official JS is airtight. Async, non-blocking, visually obvious when broken. Propeller’s scripts? Way more chaotic. Their auto-generated snippet for pop-unders sometimes doesn’t lazy-load correctly on pages with long async chains. I’ve had it quietly fail when bundled after heavy third-party scripts like Intercom or Segment.
Also worth noting — their loader can trigger a console error on some versions of Safari due to unescaped postMessage calls. They don’t impact functionality, but I had a client who thought they meant the ad was broken. Nope, just Propeller being a little careless with browser messages.
The weirdest part is their documented trigger config doesn’t always match behavior. For example, the official way to delay the pop-under until second pageview is to pass `rdnFreqCap: 2` into the config object. But if you do that on a single-page-app (like Gatsby or Nuxt), it’ll never trigger, because it caches the first load as persistent session even across virtual routes. For SPA sites, you have to fake a real page reload via an internal route reset before the config gets reevaluated on the second path.
I Framed Myself Off the Page
This one is honestly painful. I was experimenting with nested iframes for a digital textbook site, trying to see if I could scope pop-under launch logic to a lower frame off the main thread. I naively thought putting the trigger handler in a 3rd-party frame would isolate it from Google’s crawler logic on the main URL.
What actually happened? The page failed to render the iframe in Chrome because of CSP header inheritance — I had X-Frame-Options: SAMEORIGIN on my main domain, but the iframe was being loaded via a proxy. End result: no pop-unders, no iframe, and a blank content space where my textbook viewer used to go.
Chrome’s dev console was charmingly vague too: just “Refused to display in a frame”. Yeah, cheers. Let me just reverse engineer your CSP normalization logic in my head.
Why Pop-Unders Still Work (Sort Of)
If you make like ten bucks a day with pop-unders, the compounding value from even minor UX tradeoffs can be worth it. Yes, people get annoyed. Yes, bounce rates suffer. But on very transactional traffic — like file downloads, single-click tools, or short dwell-time utilities — they basically convert guaranteed revenue where AdSense would eek out cents at best.
What surprised me more: mobile performance. I assumed pop-unders were DOA on mobile, but Propeller actually uses redirect-based openers rather than literal new tab launches. Some of them work via pushState abuse, others use jump redirects that look like voluntary nav changes. Questionable? Totally. But they worked for me on cheap Android devices in India where even banner impressions barely loaded.
It’s a mess, but it’s a controlled mess that pays rent. Just don’t run them on anything you care about in Google Search. Seriously. They will tank your Pages Experience scores and batch you off into the low-quality bin within weeks.
