You cannot switch off bots in paid traffic with a single setting: they come in very different shapes, from a primitive script hitting your link from a server to a full browser driven by a program and launched from a home network. That is why bot traffic filtering is built as a funnel, where each layer removes its own class of automation and a real person passes every layer without noticing.
Below is the scheme mature bot protection systems follow, plus practical advice on tuning it for a specific traffic source.
Why filter bots from your ad traffic at all
A media buyer (the specialist who purchases ads) has three reasons to keep an anti-bot on every campaign:
- Money. A paid click from a bot is spend with zero chance of a conversion. On CPC models you pay for every such visitor directly.
- Protecting your funnel. Spy tools and scrapers crawl ad links to collect creatives, landing pages and offers. If they see your whole funnel, competitors are running it within a week and your click price goes up.
- Clean stats. Optimizing on data polluted by bots is optimizing on noise: you kill working campaigns and scale junk placements.
How spy tools collect funnels is covered in the article on protection from spy tools, and fake clicks in click fraud and how to protect your budget.
What kinds of bots arrive through an ad link
Before building a filter, it helps to know what it protects against. The signals of each class are covered in detail in bot traffic: signs and how to detect it; here is a short classification.
| Class | Who they are | How they usually give themselves away |
|---|---|---|
| Preview robots | crawlers that fetch a link's title and image | known user agents, platform and messenger networks, no click ID |
| Spy tools and scanners | systems collecting other people's creatives and landers | data centers, repeat visits, automated browser |
| Programs instead of a browser | curl and Python scripts, scrapers | do not run JavaScript, odd headers |
| Headless browsers | windowless Chrome driven by a program | traces of automation in the browser environment |
| Click fraud | clicks inflated by competitors or the placement | bursts of visits from similar addresses, zero behavior |
| Untargeted humans | competitors, visits from the wrong geo, forwarded links | no ad click ID, another country, VPN or corporate network |
The last class is the hardest: technically it is a human, but there is no point paying for them or sending them to the offer. The network will not accept a lead from the wrong country, and a competitor will not buy anything. Here the visit context matters more than bot signals: geo, click ID, network.
Layer 1. Network and request
The first and cheapest layer checks what is known before the page even loads: the IP address, the network, the request headers and the link parameters.
IP address and network (ASN)
Every IP belongs to an autonomous system, an ASN: the network of a particular operator. A home ISP, a mobile carrier, a cloud host and a VPN service are different networks with different reputations. A visit from a hosting network in ad traffic almost always means a server, not a person holding a phone. How such networks are told apart is covered in the article on VPN, proxy and data center IP detection.
Address blacklists
If an address has already been confidently caught automating, there is no reason to check it again. Shared lists of known bots and your own IP blacklist stop repeat visitors instantly, without spending anything on checks.
Headers and click ID
User agent, browser language, presence of a referrer, parameters such as fbclid or gclid: all of this is cheap to check. Simple scripts often send an incomplete or contradictory set of headers. And a missing ad click ID on a visit that supposedly came from an ad is a reason to look closer.
Campaign rules
Your own restrictions belong here too: country, device, language, schedule. If you are running traffic to Germany, a visit from another country can be dropped without working out whether it is a bot. More in the article on geo, language, device and schedule filtering.
Tip. The network layer hurts real people the least: it triggers on signals an ordinary buyer almost never has. Start your setup here.
Layer 2. Browser check
The second layer is a script that runs in the visitor's browser and collects information about the environment. This is where an advanced bot finds faking much harder.
- Whether JavaScript runs at all. Programs like curl do not execute scripts, and that is where they stop.
- Traces of automation. Browser control flags, mismatches between the claimed browser and its real capabilities, details typical of headless mode. More in the article on headless browsers and browser fingerprinting.
- Data consistency. Browser time zone versus IP country, system language versus geo, screen size versus the claimed device. Each mismatch alone means nothing; together they form a picture.
An important caveat: this is the layer where filters make mistakes most often. In-app browsers of social networks and WebViews inside apps sometimes look "odd" while bringing real people. So a single signal should not decide the fate of a visit; it should only add suspicion.
Layer 3. Behavior
The third layer is how the visitor behaves on the page: mouse and finger movement, reaction speed, how long it took before an action. A human moves unevenly and with pauses; a program either does not move at all or moves too perfectly.
Behavioral checks catch the most expensive bots, but they cost more too: they need a little time to gather observations. They make sense on expensive traffic, where every bot that slips through costs real money, and on sources with a lot of advanced automation.
A trust score instead of a single rule
The main mistake of home-made filters is the rule "saw a signal, blocked the visit". That is how real people get cut: ordinary users have VPNs, referrers get lost in in-app browsers, mobile carriers use IPv6.
A better approach splits checks into two types:
- Hard checks: an obvious bot, a known address, a breach of your audience rule. Such visits are dropped immediately.
- Soft checks: questionable signals. Each adds a penalty to the trust score, and only when the total crosses a threshold does the visitor see the safe page.
With this scheme one weak signal does not send a person to the White Page, while a bot with five things "off" at once goes there with confidence. Any anti-fraud system works on the same principle: rules, scoring and lists.
How to set up bot filtering: step by step
- Identify the source. Facebook, Google, TikTok and native networks have different traffic profiles: in one the referrer gets lost, in another there are many repeat impressions. One-size-fits-all settings are almost always worse than settings tuned to the platform. For an example of such a breakdown for search ads, see the article on bots in Yandex Direct.
- Pick a strictness level. Start with balanced: known bots, VPNs, proxies and data centers are filtered, but signals that real people often trip on are left alone.
- Define the audience. Countries, devices, languages, according to the offer. This is the clearest and safest filter.
- Prepare a White Page. Filtered visits have to land somewhere: an ordinary page on the site's topic, not a blank screen or a 403. A bot reads an empty response as a cue to reconfigure, and an accidentally filtered human sees a broken site.
- Launch and watch the log. The first few hundred clicks will show who the filter blocks and why.
- Adjust precisely. If obviously real people are being filtered, loosen that specific check, not the whole protection.
How it works in ArtisanClo
In ArtisanClo, bot filtering is configured on the Filtering step of the flow form. The main levers:
- Check strictness: Soft, Balanced and Strict. When you choose a traffic source, the protection is tuned to the platform: for Facebook, for example, the referrer check is off because the in-app browser often loses it.
- Protection toggles: blocking by IP blacklists, VPN and proxy, datacenter ASN, headless browsers, required JavaScript execution, the live interaction check and more.
- Audience rules: lists of countries, devices, OS, browsers, languages, time zones, cities and regions in allow or block mode.
Some checks drop a visit immediately: blacklists, an obvious robot browser, an audience rule. The rest add up to a trust score. Spy tools, programs posing as browsers and link preview robots go to the White Page under any settings. And an address confidently identified as a bot for any customer lands on a shared list, so its next visit to any flow gets the White Page right away.
Every decision is explained with a reason in the click log: "VPN or proxy blocked", "Headless browser detected", "Trust score too low" and dozens of others. Above the list of reasons, the stats show at which stage visits were filtered: network and request, browser check, or a check that never came back. If the share of rejections at the browser check grows, it is time to revisit strictness, because that is where mistakes are most likely.
Not sure whether the filter is cutting real people? Turn on Shadow mode for a few hours: when you connect with the PHP file, the filter blocks nobody and only marks whom it would have blocked. The full list of capabilities is on the ArtisanClo features page.
Common bot filtering mistakes
- Maximum strictness "just in case". Harsh settings cut part of your real buyers along with the bots. Strict mode is justified on sources with a large share of bots, and after you have looked at your own traffic, not everywhere.
- Judging the filter by its pass rate. A high share of visits reaching the offer is not a sign of weak protection: with paid traffic and a verified click ID it can be very high, and that is normal. The worrying case is the opposite, when almost nobody reaches the offer.
- Blocking on a single signal. VPNs, missing referrers and IPv6 each occur among real people too.
- The protection script loads asynchronously. If the check runs after the page is shown, the bot gets to see the offer. The code must load first; see how to install a cloaker on your site.
- No feedback loop. A filter without a reason log is a black box. You will not learn what your settings cut until conversions drop.
How to check that bot filtering works
Setting up protection is half the job. The other half is making sure it filters the right visitors. A few simple checks before launch and in the first days:
- Open the link as a bot. Visit the landing page from a hosting network or through a VPN, without an ad click ID. You should see the safe page, not the offer.
- Open the link as a buyer. From a phone on mobile data, using a link with the platform's click ID. The offer should open, with no noticeable delay.
- Check the in-app browser. Send the link to yourself in a messenger or open it from a social app: real traffic often arrives exactly this way.
- Review the first few hundred clicks. Which rejection reasons show up most? If the leader is something bots almost never have, the filter is overdoing it.
- Compare with conversions. If clicks pass but there are no leads, look beyond bots: check the offer, the form and conversion tracking.
Tip. Add your test devices to the flow's IP whitelist. Otherwise you will be fighting your own protection and mixing up your visits with everyone else's.
The bottom line
Reliable bot filtering only works in layers: network and address, browser check, behavior, and a trust score on top so that one random signal does not cost you a real buyer. Tune protection to the source, start with the balanced level, read the decision reasons and tighten things precisely. A filter does not guarantee your account will not get banned, since creatives, domain and the offer itself all play a role, and it does not replace following platform policies. Its job is different: to make sure your budget goes to people, your stats show the real picture, and spy tools do not walk away with your funnel.



