You are running traffic to Poland, yet the visit log shows Ireland, the US and the Netherlands. Some of these are bots and scanners from data centers, some are spy tools, some are users on a VPN. The offer is Polish, and the affiliate network will not accept a lead from Ireland. The easiest way to cut these visits is a geo filter: a rule that does not try to guess whether it is a bot or a human, it just checks whether the visitor fits the audience.
Together with language, device and schedule filters, this is the safest layer of traffic filtering: it barely touches your target buyers and does a good job of cutting the rest.
Why you need your own targeting on top of the ad account
Ad account targeting decides who sees the ad. A filter on your side decides who sees the offer once the person has arrived. These are different things:
- the platform targets by its own data about the user (stated country, history, interests), not by the address of a specific visit;
- scanners and scrapers run from clouds and data centers, which are usually in other countries;
- spy tools and bots emulate the right geo, but not always completely;
- users travel, use a VPN, or open a link forwarded from another country.
A geo filter on your side closes this gap. Who else follows ad links is covered in signs of bot traffic.
Geo filter: how the country is detected
By IP address
The main source is IP geolocation. Databases map address ranges to countries, regions and cities. Accuracy varies a lot by level:
| Level | How reliable | Pitfalls |
|---|---|---|
| Country | high accuracy | VPN, proxy, roaming |
| Region / state | good for home ISPs | mobile carriers route traffic through central hubs |
| City | noticeably lower | mobile traffic often "lives" in the capital |
So a country filter is a reliable tool, while a city filter should be used with care and only where the offer is genuinely local.
Cross-checking with the browser
An IP can be spoofed, but the system time zone and language not always, and not everyone remembers to. If the address is German but the browser time zone is in Asia and the language is Vietnamese, that is a reason to trust the visit less. A mismatch alone does not prove a bot, but combined with other signals it is a very strong one. Network signals are covered in detail in VPN, proxy and data center IP detection.
List modes: allow or block
- Allow: let through only the listed countries. Suits the vast majority of offers, since every offer has a list of accepted geos.
- Block: let everyone through except the listed countries. Suits a worldwide offer when certain countries send junk or mass checks. And if you have different offers for different countries, you do not have to cut the visit at all; you can redirect it, the way a TDS does.
Choosing a geo for your offer is covered in Tier-1, Tier-2 and Tier-3 countries.
Filtering by language and time zone
Browser language is a good indicator of your target audience. For an offer with a Spanish landing page, a person whose browser is in Spanish converts better than a tourist in the same country. A language filter is useful:
- in multilingual countries where the offer only works in one language;
- for cutting bots and scrapers whose system language does not match the geo.
Time zone works in a similar way. There is a technical catch: some time zones have an old and a new name, for example Europe/Kiev and Europe/Kyiv, Asia/Calcutta and Asia/Kolkata. Browsers often send the old one. A good filter treats them as one zone; otherwise you will accidentally cut off real people.
Device, OS and browser targeting
Device type, operating system and browser are detected from what the browser sends and refined by a script.
When to filter by device
- The offer is mobile only: apps, mobile subscriptions, PWA. Desktop will not convert anyway, and desktop traffic has a higher share of scanners and server bots.
- The offer is for one OS only, for example an Android-only app.
- Off-target devices: Smart TVs, game consoles and wearables produce no conversions in most verticals.
When not to
If the offer opens on all devices, do not cut them in advance. Check conversion by device in your report and decide based on the data. Sometimes "unexpected" desktop traffic in nutra or finance converts better than phones.
Tip. It almost always makes sense to block the "Bot / crawler" device category: these are visits that announce themselves as robots.
Ad schedule (dayparting)
The campaign schedule is the time window during which visitors can see the offer. Outside the window everyone sees a neutral page. Why you need it:
- the call center works certain hours: leads that come in at night go cold by morning and get approved less often;
- night hours in the geo are prime time for bots and checks: few real buyers are awake, and automation does not care what time it is;
- the budget is limited: better to spend it during the hours your audience converts.
It matters whose time the schedule runs on. It is more convenient when the window is set in the campaign's time zone rather than the visitor's: you see the window the same way your call center does. If you run traffic to several time zones at once, split the campaigns into separate flows so each window matches the audience's local time.
Tip. A schedule in your cloaker does not replace the schedule in the ad account: outside the window you still pay for clicks, the offer just will not see them. Set the window in both places.
Audience rules versus the trust score
Audience rules are hard rules: if the country is not on the allowed list, the visit goes to the safe page right away, without further checks. Where these rules sit on the visit's overall path is explained in how cloaking works. That is both their strength (no scoring errors) and their weakness (no exceptions).
So set them based on the offer's requirements, not "just in case". Leave ambiguous signals (VPN, time zone mismatch, missing referrer) to the softer trust score. How these layers work together is covered in how to filter bot traffic.
How to set up audience filters in ArtisanClo
In ArtisanClo, audience rules live in the Audience block at the "Filtering" step of the flow form. Each list has "Allowed" and "Denied" buttons, and an empty list restricts nothing.
| List | How to fill it in |
|---|---|
| Countries | pick from a searchable list |
| Devices | Mobile, Desktop, Tablet, Smart TV, Game console, Wearable, Bot / crawler, Unknown |
| Operating systems, browsers | pick from a searchable list |
| Languages, time zones | pick from a list; the old and new names of a time zone count as one |
| Cities | the name as it appears in the click log, for example "Berlin" |
| Regions | the region name or ISO code, for example "Bavaria" or "BY" |
| Networks (ASN), providers, referring sites | network number, provider name or referring domain |
A visitor who fails a list sees the White Page with a clear reason in the log, for example "Country not allowed".
The campaign schedule is turned on with a toggle. Time runs in the campaign's time zone; for each day you can choose "Around the clock" or a from–to window. Outside the schedule every visitor sees the White Page, with the reason "Outside campaign hours".
A set of rules that works well can be saved as a filter preset and applied to new flows: it carries over the audience lists, the schedule and the protection settings. Applying it is a one-off: the flow keeps its own copy, and later edits to the preset no longer change it.
Auto-tuning, when it is on, never touches geo, devices or the schedule: those rules stay yours. The full list of settings is on the features page, and the steps for creating a flow are in setting up a cloaker step by step.
Example setup for an offer
Take a hypothetical nutra offer with phone-confirmed leads. The network's terms: geo Poland and Czechia, mobile traffic preferred, the call center works weekdays and Saturday daytime, Central European Time. The example is purely illustrative.
- Countries: "Allowed": Poland, Czechia. Everything else goes to the safe page.
- Devices: "Denied": Smart TV, Game console, Bot / crawler. We do not cut desktops: if desktop produces leads, we want them; we will check the report in a week.
- Languages: no restriction, since a noticeable share of browsers in Czechia and Poland are set to English.
- Schedule: campaign time zone
Europe/Warsaw, weekdays and Saturday, with a window slightly wider than the call center's hours so morning leads get processed during working time. Sunday off. - Ad account: the same geo and the same schedule, so you do not pay for impressions outside the window.
After a week, check the report by device, hour and country. If some slice brings no approvals, tighten the rules based on data, not gut feeling. If you work with several geos in different time zones, set up a separate flow for each.
Common mistakes
- A city filter on mobile traffic. Mobile carriers often "register" subscribers in the capital, so you cut off the regions.
- Forgetting the offer's neighboring geos. If the network accepts several countries, allow all of them, or you lose leads.
- A schedule in the visitor's time zone across several geos. The window drifts, and the call center gets leads at night.
- Blocking desktops "because that's where the bots are". Bots are everywhere; if the offer is desktop-friendly, you are cutting buyers.
- A hard language filter in a multilingual country. Some real people browse with their browser set to English.
- Tightening rules because the pass rate is high. If almost every visit gets through to the offer, that is no reason to add rules: with paid traffic and correct targeting, it is normal. Worry when almost nobody gets through.
How to review filtered visits is covered in why a click went to the White Page.
The short version
Geo, language, device and schedule filters are hard rules that cut off-target traffic based on the offer's requirements: the wrong countries, unsuitable devices, hours when nobody can take the lead. They complement the ad account's targeting rather than replace it. Set them according to the offer's terms, use "Allowed" mode for geo, run the schedule on the campaign's time zone, and do not use a city filter where geolocation is unreliable.
