- In-app WebViews (from social and messaging apps) report user agents and behave differently from standalone mobile browsers.
- Referrers are frequently missing on mobile, so any rule that requires a referrer will misroute real users.
- Mobile fingerprints are coarser, so device-level rules should be looser than their desktop equivalents.
- Test both surfaces from real mobile in-app contexts, not just a desktop browser, before trusting a rule set.
In-app WebViews are not standalone browsers
A large fraction of paid mobile clicks open inside an in-app browser — a WebView embedded in a social or messaging app — rather than the phone's default browser. WebViews report distinctive user agents, sometimes lack features standalone browsers have, and pass along app-specific headers. Rules written to expect a normal mobile browser can misread these as anomalies. Because WebView behavior is one of the signals routing engines weigh, it is worth understanding how those engines read a client — see the architecture overview.
The practical implication: an App-package or user-agent allowlist tuned only for standalone browsers can exclude a big chunk of legitimate in-app traffic. If you allowlist by App package, make sure the packages your campaign actually runs in are covered.
Missing referrers are normal on mobile
On desktop, a referrer header is a reasonable signal. On mobile, it is far less reliable: in-app browsers, privacy settings and certain link types routinely drop the referrer entirely. A rule that requires a referrer to pass a visitor to the real surface will therefore misroute a meaningful share of genuine mobile users to the safe page. For mobile-heavy campaigns, referrer requirements should be relaxed or removed and replaced with signals that survive the mobile context.
Fingerprints are coarser on mobile
Device fingerprinting is less granular on mobile than on desktop — many phones of the same model look nearly identical, and privacy features further flatten the signal. That means a fingerprint or request-integrity rule tuned aggressively for desktop can group real mobile users with automated traffic. As a rule of thumb, device-level checks should be looser on mobile. How strict to set each rule, and how to read the resulting split, is covered in tuning pass rate.
Test from real mobile contexts
The most common mobile failure is invisible on a desktop test: everything looks fine in a desktop browser, but real in-app mobile users land on the safe page. The fix is to test the way traffic actually arrives — open your link inside the in-app browsers of the platforms you run on, with and without a referrer, and confirm which surface you reach. The general approach to checking a page under different conditions is in how to check a page.
Reading the analytics by device type closes the loop: if the real-surface ratio is far lower on mobile than desktop, a mobile-specific rule is likely over-filtering. See reading the analytics.