How Cloaking Works: The Path of a Click from Ad to Offer

A cloaker works like a checkpoint between your ad and your website. How cloaking works in one sentence: for every visit from an ad link it collects visit signals, runs them through network, browser, behavior and address list checks, adds up the suspicious signals into a trust score and decides who gets the offer and who gets a neutral White Page. Every decision gets a clear reason and lands in your reports.

All of this takes a fraction of a second, and the visitor notices nothing. Below we walk through how a cloaker works step by step, at the level of concepts, without "settings for the review" and without secret thresholds. If the term itself is new to you, start with what cloaking is.

How cloaking works: the path of one click

The path of a visit through a filter looks almost the same with every service:

1. The ad click. The platform sends the person to your ad link and usually appends its own parameters: fbclid, gclid, ttclid, UTM tags.
2. Meeting the filter. The cloaker's code sits on your page or server and intercepts the visit before any content is shown.
3. Collecting signals. Address, network, ISP, request headers, click IDs, and with a browser check, the properties of the browser itself and behavior.
4. Checks. Hard rules that drop a visit immediately, and soft signals that only lower trust.
5. Scoring. Suspicious signals add up to a final score.
6. Decision and reason. The offer (which one is decided by branches and weights) or the White Page, plus a reason code.
7. Tracking. The click gets its own ID, lands in the log and stats, and if a lead comes in later, it is linked to it.

Now each step in more detail.

Step 1. Connection: where the cloaker meets the visitor

For the filter to decide anything, it has to sit on the visit's path. There are only a few options, each with its own specifics:

• A JS tag on the page. A small script goes on the first line of the landing's <head>. It hides the page until the decision arrives and only then shows the offer or sends the visitor to the White Page. You cannot add such a tag through tag managers or with async/defer: the script would run later, and the page would be shown to everyone before the decision.
• A PHP file on the server. The file goes into the site root and asks for a decision before the server sends a single byte of the page. It sees the request before the browser does, so it also suits those who need tracking without filtering.
• A CMS plugin, which usually installs the same server-side method, just without handling files manually.

Importantly, your site stays with you: a cloud cloaking service does not host pages or take over your domain; it only answers the question "who goes where". Choosing a method is covered in how to install a cloaker on your site.

Step 2. Collecting visit signals

Before drawing any conclusions, the cloaker collects everything about the visit that can be learned honestly and quickly. The signals fall into several groups:

The first four groups are available immediately, from a single request. The last two need the check code to run in the browser, so they exist only where the filter has a page: with the JS tag and with the server file plus a check page.

Step 3. Checks: network, browser, behavior, lists

The collected signals pass through several layers of checks. Order matters: cheap checks run first so that obvious junk does not waste time on expensive ones.

Network and request

The fastest layer. It establishes where the visit came from: a data center network, a VPN or proxy, no recognizable ISP. Server networks are the main source of scanners and scrapers, and a VPN often masks the real country. How such addresses are recognized is covered in VPN, proxy and data center IP detection.

Campaign rules also belong here: country, device, language, ad schedule. If the ad targets Germany, a visit from another country is not your target visitor, whoever it is.

Browser

The check script looks at whether JavaScript runs and whether there are traces of automation: windowless controlled browsers, spoofed properties, mismatches between the claimed system and its real capabilities. This layer catches bots pretending to be humans. More in headless browsers and fingerprinting.

Behavior

A human spends at least a little time on the page, moves the mouse, touches the screen. A simple bot opens the page and leaves within a fraction of a second. The behavior check is more accurate but adds waiting, so it is turned on where there really are a lot of bots.

Address lists

In parallel, the visit is matched against lists: addresses already caught automating, your own blacklist, a whitelist for your own tests. Lists are the filter's memory: a bot that was confidently identified once does not need to be checked again on its next visit. It is handy to add to your own list straight from the click log when you spot a persistent address.

Step 4. Scoring: why one rule is not enough

If a cloaker cut on every signal separately, it would lose a lot of real people. An office network without a recognizable ISP, a person with a VPN on, a link opened in a social app's in-app browser: each of these also occurs among normal buyers.

So checks come in two kinds:

• Hard cutoffs: the visit goes to the White Page right away. An address from the blacklist, an obvious robot browser, a program instead of a browser, a breach of an audience rule.
• Soft signals: each adds a penalty to the trust score. A visit survives one weak signal, but not a combination of several.

How much each signal weighs and where the line runs depends on the strictness you choose and on the traffic source platform. Different sources have a different "normal": traffic from a social in-app browser often loses the referrer, native ads produce many repeat impressions from the same address. A good cloaker accounts for this and does not punish real people for a platform's quirks.

Tip. Do not hunt for the "perfect threshold". Look for the strictness at which the filtered visits in your log are dominated by server networks and automation, not ordinary phones on mobile data.

Step 5. The cloaker's decision and its reason

Based on the checks, the cloaker chooses one of two paths.

The visit passed. Next it needs to decide which page to send it to. If the campaign has several offers, distribution kicks in: by conditions (country, device, parameter) and by weights. The display itself varies: loading the page under your ad address, a redirect to the offer address or embedding it in a frame.

The visit was filtered. The visitor sees the White Page, a neutral page with no offer on it. It can be your own site, a ready-made page or just a status code.

In both cases the decision gets a reason: "Allowed", "VPN or proxy blocked", "Country not allowed", "Search or platform crawler", "Trust score too low". The reason is what separates a filter you can manage from a black box: it shows that a rule is cutting bots, not your buyers. How to read reasons and what to do with them is covered in why a click went to the White Page.

Step 6. Tracking: what happens to the click after the decision

The decision is not the end of the road. Every visit gets its own click ID, and by that ID it can be found both in the log and linked to a lead:

1. The click ID is passed into the offer link, usually in an affiliate network parameter such as sub1 or aff_id.
2. When the visitor submits a lead, the network sends a postback, a message saying "click such-and-such converted".
3. The tracker finds the click, records the lead or sale, counts revenue and, using the click cost, spend, profit and ROI.

Without this link, the cloaker only knows how many people it let through, not whether they made any money. The mechanics are explained in postback URL and S2S tracking.

For example, in the offer link it might look like this:

https://track.partner.com/click?offer=55&sub1={click_id}

The cloaker replaces the {click_id} macro with the ID of that specific visit, and the postback comes back to exactly that click.

What it is all for: the purpose of filtering and platform policies

How cloaking works is now clear. Why you would need it is a question worth answering honestly.

The legitimate value of filtering is to:

• stop paying for bots: auto-clickers and fake traffic eat budget and spoil stats; the signs of such traffic are covered in bot traffic;
• weed out fraud: repeat visits from the same addresses, server traffic, competitor click fraud;
• hide your funnel from spy tools that collect other people's creatives and landing pages to copy them; more in protection from spy tools;
• get clean stats you can make decisions on: CR and EPC calculated without bots honestly show whether an offer works.

At the same time, ad platforms explicitly forbid showing their review something different from what the user will see, and they ban accounts for it, together with linked profiles and payment methods. Search engines demote sites for the same thing; see cloaking in SEO. A cloaker does not make a prohibited offer allowed and does not relieve the advertiser of responsibility for ad content. The sensible approach is to advertise what the platform allows, by its rules, and use the filter against bots, fraud and copying.

How cloaking works in ArtisanClo

In ArtisanClo each campaign is a flow: offers, White Page, filtering rules and tracking. The site connects with the JS tag or the PHP file; WordPress has a plugin that installs the same PHP method; and if your traffic already runs through Keitaro or Binom, the filter plugs into them.

The visit then passes checks in order, top to bottom, and the first matching condition fires:

Strictness is set with a single switch (Soft, Balanced or Strict) and adapts to the traffic source platform: Facebook, Google, TikTok, native ads or others. Every click in the log gets one of dozens of reasons, and the stats show at which stage visits were filtered: network and request, browser check, or a check that never came back.

If an address is confidently caught as a bot for one customer, its next visit to any flow in the service gets the White Page right away. Real visitors with a questionable network, a VPN or no JavaScript are not added to this shared list; only proven bots end up there.

Alongside the filter runs a tracker: clicks, leads, sales, cost, profit and ROI, postbacks from affiliate networks and sending conversions back to ad accounts. The full list is on the ArtisanClo features page, and plans are on the pricing page. If you are comparing services, see buying a cloaker: what to look for.

Important. The share of visits passed to the offer is not a score in itself. With paid traffic and a verified click ID, most visits may reach the offer, and that is normal. Worry when the pass rate is very low: that is usually what a filter looks like when it cuts real people along with the bots.

The bottom line

• How cloaking works: it intercepts the visit before the page is shown, collects signals, checks network, browser, behavior and lists, adds suspicions into a trust score and chooses the offer or the White Page.
• Hard rules drop obvious junk immediately, while soft signals only count in combination, so the filter does not lose real people over one random signal.
• Every decision has a reason, and strictness is tuned by those reasons.
• After the decision, the click gets an ID that the tracker uses to link it to a lead and count the money.
• The value of filtering is saving budget, protecting your funnel and clean stats, not getting around platform policies.