Cloaking for Webview Ads
A large share of ad clicks never land in a real mobile browser at all — they open inside the advertiser platform's own in-app webview (Instagram, Facebook, TikTok, Line, KakaoTalk, WhatsApp, WeChat, Gmail, and others each ship one). Webview traffic strips or reshapes standard browser signals in ways a naive fingerprint check misreads as automated, which is exactly the population Cloaking X's in-app-browser recognition exists for.
Why In-App Webview Traffic Looks Different From a Normal Browser
A genuine in-app browser often strips tokens a real desktop or mobile Safari/Chrome session always carries — Facebook's iOS in-app browser (FBAN/FBAV) and X's iOS in-app browser both drop the Version/Safari tokens a standard fingerprint check expects; Google's own Search app in-app browser (GSA) and Gmail's in-app browser carry neither Mozilla nor AppleWebKit tokens at all. A fingerprint rule built only from a normal browser's shape would misjudge every one of these as suspicious.
Client Hints (the newer, opt-in Sec-CH-UA family of headers) is a real signal of a scripted, non-browser client on a normal desktop/mobile browser — but many in-app-browser hosts never wire that feature up at all, real or not. Treating its absence as automatically suspicious would false-positive an enormous share of genuine webview traffic, so it isn't scored that way here.
How Cloaking X Filters Webview Traffic Without Blocking Real Buyers
Cloaking X's browser-recognition layer carries dedicated, anchored signatures for the real in-app-browser population — Instagram, Facebook (FBAN/FBAV), TikTok (musical_ly/BytedanceWebview), Line, KakaoTalk, WhatsApp, WeChat (MicroMessenger), Google Search App (GSA), Gmail, Yandex Browser, and X's iOS in-app browser — so a genuine visitor tapping an ad inside one of these apps isn't hard-blocked for carrying a non-standard UA shape.
Recognition is not exemption: passing this check only clears the browser-shape gate. IP intelligence (datacenter/VPN/Tor/proxy), click-ID verification, spy-tool/scraper blocking, and full risk scoring all still run on top — a bot spoofing a known webview UA from a datacenter IP is still blocked on that separate signal. Header-consistency checks are tuned the same way: a missing Client Hints header is expected on webview traffic and isn't penalized, but Accept-Encoding — a header every browser's underlying HTTP client sets automatically, webview or not — still has to be present, since its absence is a much stronger signal of a bare scripted client than of a genuine app.
In-App Browser Recognition
Dedicated signatures for Instagram, Facebook, TikTok, Line, KakaoTalk, WhatsApp, WeChat, Google Search App, Gmail, Yandex Browser, and X's in-app browsers — real visitors, not treated as bots.
Recognition Is Not Exemption
A recognized webview UA still passes through full IP intelligence, click-ID checks, and risk scoring — a spoofed webview UA from a datacenter IP is still blocked.
Webview-Aware Header Scoring
Missing Client Hints headers (never wired up by many in-app browsers) aren't penalized; missing Accept-Encoding (set by every real HTTP client) still is.
8 Delivery Modes
Proxy, 302 redirect, meta refresh, iframe, cross-origin iframe, JS redirect, click-reveal, or mirror — pick whichever renders correctly inside a webview.
Setting Up Webview Ads in 3 Steps
- 1
Create a stream
Set your fallback page (or use the built-in generator) and your money page(s) for this campaign.
- 2
Choose a delivery mode
Test your destination inside the actual in-app browser you expect traffic from — some delivery modes render more reliably than others inside a constrained webview.
- 3
Point your ad's destination URL at the stream
Use the stream link (or your own domain, if you're on a plan with custom domains) — works the same whether the click opens in a full browser or an in-app webview.
Filter Webview's Reviewers, Not Your Real Traffic
Start on the Free plan — one stream, 300 clicks/day, no time limit — and see how Webview review traffic gets routed differently from real visitors.