How Cloaking Works Under the Hood

Cloaking isn't a black box — it's a sequence of concrete checks every visit runs through in a fraction of a second. Here's a step-by-step breakdown of how bot detection works, which filters strip out off-target traffic, and how the white-or-offer decision actually gets made.

Step 1: What Gets Checked in the First Second

Before the page even renders, the cloak looks at the raw request data — IP address, User-Agent, HTTP headers, and referrer. This is the first and cheapest filter: a chunk of bots and moderation scanners get caught right here, because their headers and UA don't resemble a real mobile browser. The call gets made in milliseconds, before the visitor even sees the page start to load.

Step 2: IP Intelligence — Datacenters, Proxies, VPNs

Next, the IP gets checked against an IP-intelligence database: does it belong to a datacenter, a known proxy/VPN range, or an ASN that ad-network bots routinely run from. A real visitor on mobile data or a home ISP almost never looks like a hosting provider. This filter alone catches the bulk of automated scans and click fraud that isn't coming from actual devices.

Step 3: Behavioral and Browser Signals

Traffic that clears the first barrier gets checked against subtler signals: does JavaScript actually execute, does the browser respond to markers typical of headless tools, does the device fingerprint match the claimed geo and UA. A real person on a phone leaves natural noise in this data; a script doesn't. A mismatch on even a few of these signals raises the visit's "suspicious" score.

Step 4: Geo and Targeting Filter

Separately, the cloak checks the visitor's geo (from IP) against the geo the campaign is actually targeting. If the ad is bought for a Tier-3 country and the traffic arrives from a different country's IP, that's almost always a bot, a VPN user, or a stray click — and that visit never sees the offer. This filter also protects budget from off-target traffic even when it's technically "human."

Step 5: The White/Offer Fork

After all the checks, the cloak makes its final call: a suspicious or off-target visit gets the white page — harmless content with no connection to the offer's vertical — while traffic that clears every filter sees the real pre-lander and offer. Every decision gets logged, so you can later review who got filtered and why, and tune the filters for a specific traffic source. That's how the same URL shows fundamentally different content to different visitors while staying safe under review.

FAQ

Can the cloak accidentally send a real user to the white page?
False positives can't be ruled out entirely — a user on a corporate VPN, for instance, can get caught by the proxy filter. That's why it's worth watching the filter-out rate in your stats and tuning sensitivity per traffic source instead of leaving defaults in place.
Does a Facebook moderator ever actually see the offer?
Usually not — moderation requests tend to come from server-side IPs or follow patterns the filters recognize, so they typically get routed to the white version instead of the offer.
Do I need to maintain my own bot and datacenter lists?
No — the IP-intelligence database in APEX is maintained on the service side. What you tune manually is specific to your traffic: target geo, filter sensitivity, and what the white page shows.
How does the cloak tell a moderation crawler apart from an ordinary bot or scraper?
It doesn't try to — both are unwanted automated traffic. The cloak isn't identifying "moderation" specifically; it just filters out anything that doesn't look like a real target user, which works equally well against both.
Build your PWA in APEX in minutes

Cloaking, anti-bot, push, split tests and your own domains — in one service.

Get started free

Read also