Mobile-Only Cloaking
Mobile-only cloaking sends only phone and tablet visitors through to the offer, while desktop traffic and bots get routed to the safe page instead. For PWA offers this isn't optional — the whole mechanic (home-screen install, push notifications) is built for mobile OSes, and desktop traffic is almost always a moderator, a scanner, or wasted budget. Here's which signals separate real mobile traffic from the rest, and what you risk cutting off by mistake.
Why cut desktop specifically on PWA offers
A PWA installs to the home screen and only listens for push notifications on mobile OSes — on desktop the offer simply doesn't work as designed, and conversion there is close to zero. On top of that, some ad-platform reviewers and anti-fraud systems check ads from desktop browsers or from emulators that present as desktop. Cutting desktop at the door both raises traffic relevance and lowers the odds of a ban for showing unapproved content to a reviewer.
What signals identify mobile traffic
The baseline is device and OS User-Agent — Android/iOS versus Windows/macOS/Linux — but UA alone isn't enough since it's trivial to spoof. Filters also check for touch events, screen aspect ratio, and headers typical of mobile browsers. Stacking several signals together — UA plus behavioral and technical checks — catches an order of magnitude more fakes than checking one parameter alone.
Where the mobile-only filter tends to break
The weak spot is emulators and DevTools 'mobile view' on desktop, which spoof the UA but not the rest of the mobile signals. The second is tablets and large phablets, which are technically mobile but sometimes behave like desktop in specific browsers — decide up front whether to let them through. The third is mobile-emulator traffic used by some QA bots and moderation crawlers.
Setting this rule up in APEX
In APEX's anti-bot cloaking, the device-type filter works as a display condition: only mobile OSes reach the offer, and everything else — bots, datacenter IPs, plain desktop — gets routed to a safe white page. The rule stacks with the rest of the cloaking filters — UA, IP-intel, geo — so mobile detection is one layer, not the only line of defense. Setup takes a couple of minutes and needs no extra code on the landing side.
What you might cut by mistake, and how to check
An overly strict filter sometimes blocks legitimate mobile users too — non-standard firmware or the built-in browsers some launchers use are common culprits. Checking is simple: watch the share of white-page shows within mobile traffic in the cloaking logs, not just final conversion. If false positives on mobile run noticeably above zero, loosen one of the secondary signals and keep UA plus touch detection as the core check.
FAQ
- Should tablets pass through along with phones?
- Depends on the offer: for most mobile PWA setups tablets can stay in if their conversion holds up. If analytics show a drop, split them into a separate cloaking rule and test them on their own.
- Can mobile traffic be identified from User-Agent alone?
- Technically yes, but UA is easy to spoof — that's not enough against a careful reviewer or crawler. Pairing UA with touch-event and other technical signals holds the filter much more reliably.
- What does a desktop visitor see instead of the offer?
- A safe white page — usually informational content with no trace of the arbitrage funnel, giving a reviewer nothing to flag.
- Does mobile-only filtering interfere with split testing?
- No, device filtering and visitor-level split testing are separate layers: cloaking first decides who sees the offer at all, then the split test distributes the mobile visitors that pass through across variants.
Cloaking, anti-bot, push, split tests and your own domains — in one service.
Get started free