Anyone who starts filtering traffic runs into the same choice: a cloud cloaker or your own cloaking script. A cloud cloaker is a cloaking service that keeps only a small piece of code on your site, while the decision on every visit is made on its side, using shared databases and checks. A self-written script is your own code, usually PHP, that inspects the request and decides on its own where to send the visitor.
At first the difference looks like money: the script is free, the service is a subscription. In practice the difference is who maintains the bot databases, who is responsible for mistakes, and whether you can explain why a particular click went the wrong way. Let us go through it point by point, with no cloaker source code and no sales pitch.
Cloud cloaker vs cloaking script: what is the difference
Both setups sit in the same place, between the ad click and the page view. What differs is where the logic lives:
- A self-written cloaker keeps the rules and data on your server. The script looks at the IP, user agent, country from a local database and maybe an address list you maintain yourself.
- A cloud cloaker puts a JS tag or a small PHP file on the site. It passes visit data to the service and gets back an answer: "offer" or "White Page". Databases, browser checks, click logging and reports run at the service.
"Cloud" does not mean the service takes over your site. Your pages and domain stay with you; the service only answers the question of who should see what. The underlying principle is covered in how a cloaker works.
How a self-written PHP cloaking script works
Described at the level of the idea, a PHP cloaking script does three things:
- Reads the request data: address, headers, language, referrer, parameters in the link.
- Compares them with its rules: country from a local database, a list of banned strings in the user agent, a list of addresses.
- Serves one of two pages or redirects.
That is enough to stop the most primitive visits: scanners with a telltale name in the user agent and hits from "foreign" countries. But such a script only works with what is visible in a single request. It does not check whether there is a real browser on the other end, does not see on-page behavior, and knows nothing about the fact that the same address behaved like a bot on another site an hour ago.
Cloud cloaker vs self-written script compared
| Criterion | Self-written script | Cloud cloaker |
|---|---|---|
| Network and bot databases | You maintain them, they often go stale | Updated by the service, shared across all clients |
| Browser and behavior checks | You write them yourself, or none at all | Usually built in |
| Updates | Your job, forever | Handled by the service |
| Load | On your hosting | Heavy checks run at the service |
| Decision transparency | Only if you build logging yourself | Click log with a reason for every decision |
| Tracking and money | Separate tracker and manual integration | Often a built-in tracker |
| Dependency | Only on your server | On the service being available |
| Control over logic | Full | Within the service's settings |
| Upfront cost | Developer time | Subscription |
Neither column "wins" on every row. Below is what actually decides the matter.
Data and signals: the main weakness of a DIY cloaker
A DIY cloaker almost always hits a wall with data, not code. To tell a bot from a human you need to know:
- which networks belong to hosting and cloud providers — there are thousands, and they keep changing;
- which addresses belong to VPNs and proxies, including residential proxies that look like home internet;
- which addresses have already been caught automating;
- what fresh versions of automated browsers look like.
A script on one site only sees its own traffic. A cloud service sees the traffic of many clients and recognizes a bot that is visiting you for the first time but got caught somewhere else yesterday. This is not magic, just scale, and you cannot reproduce it on a single server. The signals involved are covered in how to filter bots and IP reputation.
Updates and maintenance
Bots change faster than you think. A browser engine gets updated and the signs of automation change. A provider hands out new address ranges and your network database goes stale. An ad platform changes the format of its click parameter and a rule that relied on it starts making mistakes.
With a self-written script all of this is your job, and you usually learn an update is needed from sagging stats or a "conversions disappeared" complaint. With a cloud cloaker updates are part of the service. One honest caveat: if the service has a server-side file on your hosting, the file itself may need replacing when a new version comes out. It is good when the service tells you plainly what changed and what your current version cannot do.
Load and speed
A simple script is fast: it makes no external calls and answers instantly. But as soon as you add lookups in an external address database, logging every click to a table and counting repeat visits, the load lands on your hosting. During a spike of traffic from a push or pop source, cheap hosting can slow down, and a slow landing page means lost conversions.
A cloud cloaker takes the heavy part on itself. The price is a short network request before the page is shown. Usually it is a fraction of a second, and it is worth keeping in mind if your source is especially speed-sensitive.
Decision transparency
This is the most underrated point. "Why did this click go to the White Page?" is a question every media buyer asks in the first week. A self-written script can only answer it if you built in a reason record for every rule in advance and made a convenient way to view it.
In a decent cloud cloaker a click log with the reason for each decision is a basic feature. It shows you that a rule is cutting server networks rather than ordinary phones, and lets you loosen a specific check instead of tweaking everything blind. How to read those reasons is explained in why a click went to the White Page.
Tracking and money
A filter without tracking answers "how much did I block", but not "is this traffic profitable". For the second question you need a click ID, passing it to the affiliate network, receiving postbacks, conversion statuses, spend and ROI.
A self-written script is usually placed in front of a separate tracker, which adds one more point where the click ID can get lost. A cloud cloaker often has a built-in tracker or a ready integration with popular trackers. How to connect filtering and tracking is covered in cloaker vs tracker: what is the difference.
When your own cloaking script makes sense
Honestly, there are such cases, but not many.
- A learning exercise. You want to understand how filtering works on your own test site.
- The simplest geo filter. You only need to keep out traffic from other countries, and bots and fraud do not worry you.
- An in-house dev team. You have someone ready to maintain databases, checks and tracking on an ongoing basis, and that costs less than a subscription.
In every other case the time spent maintaining a script usually costs more than the service.
Risks of ready-made free scripts
A separate story is the "free cloaking script" from chats and forums. Besides outdated databases, such code can hide nasty surprises: sending your links and offers to someone else's server, swapping your affiliate link for another one, vulnerabilities that let attackers break into the site. If you install someone else's code, read all of it. More on the risks of "free" in free cloaker.
Checklist: questions to ask before choosing
Before writing your own script or signing up for a service, answer a few questions:
- Who will update the network and bot address databases — and how often are you willing to do it?
- What happens on failure — does the visit go to the White Page, or does the offer open to everyone?
- Can you see the reason for a decision on any click a week after it happened?
- How does the click ID reach the affiliate network and come back as a postback?
- Will your hosting survive a traffic spike if the checks run on it?
- Who else sees your links and offers — on the team, at the service, in the code you downloaded?
If the self-written option has no confident answer to the first four questions, a cloud cloaker will almost certainly cost you less. A detailed checklist for picking a service is in how to choose a traffic filtering service, and what to find out before paying is in buying a cloaker: what to check.
Ad platform rules are the same for both options
Choosing between cloud and script is a technical decision. Ad platform rules do not depend on it: showing reviewers something other than what the user will see is prohibited, and accounts get banned for it together with linked profiles. Neither a cloud cloaker nor your own script makes a prohibited offer allowed.
The legitimate value of a filter is the same in both cases: not paying for bots and click fraud, hiding your funnel from spy tools, and getting stats without junk. The only difference is how well the filter does it.
How the ArtisanClo cloud cloaker works
ArtisanClo is a cloud traffic filtering and routing service with a built-in tracker. Here is how it is set up:
- Connection — a JS tag as the first line in
<head>or a PHP file on your hosting; for WordPress there is a plugin that installs the same PHP method. If your traffic already goes through Keitaro or Binom, the filter plugs into them. Details in how to connect a cloaker. - A failure does not open the offer. The tag hides the page until a decision arrives and falls back to the White Page if there is none; the Keitaro filter and the Binom gateway send the visit to the White Page if the service does not answer within a few seconds.
- File updates are visible. The PHP file on your server does not update itself, but when a new version comes out, the connection window shows a notice listing what your version cannot do.
- Shared memory of bots. An address confidently caught as a bot at one client gets the White Page right away on its next visit to any flow. Real visitors with a questionable network or a VPN are never added there.
- A reason for every click. Dozens of clear reasons in the log and a breakdown of rejections by step: network and request, browser check, check never came back.
- Tracker included. Clicks, leads, sales, spend, profit and ROI, postbacks from affiliate networks and sending conversions back to ad accounts.
All capabilities are on the features page, and terms are on the pricing page. There is a free trial that shows the whole product.
Summary
- A cloud cloaker makes the decision on the service side using shared databases; a cloaking script decides on your server by your rules.
- The main weakness of a DIY cloaker is not code but data: network, VPN and bot address databases need constant updating.
- The cloud takes load off your hosting and gives you a log with decision reasons, but adds a dependency on the service being available — make sure a failure sends the visit to the White Page.
- Your own script makes sense for learning, a simple geo filter, or when you have an in-house dev team.
- Ad platform rules are the same for both: a filter is for bots, fraud and copycats, not for getting around review.
