How Adtraxo detects bot traffic — the five rules, explained

Adtraxo bot detection works by scoring every click against five independent rules: IP velocity, datacenter IP, bot user agent, uniqueness conflict, and invalid referer. Each rule answers a different question about the same click — how fast it arrived, where it came from, what it claimed to be, whether it behaved like a human, and whether it was referred honestly. A click that trips one rule gets flagged. A click that trips several gets blocked before it ever reaches your offer. This article walks through each rule, what it catches, what it misses, and how to read the flags in your campaign reports so you can act on them.

If you're running paid traffic on PropellerAds, EvaDav, RichAds, Taboola, MGID, or solo ad placements, you already know the problem: a chunk of your spend is going to clicks that were never going to convert. The question isn't whether bot traffic exists in your account. It's whether you can see it, isolate it, and cut the source. That's what these five rules are built to do.

Why rule-based detection beats a single "bot score"

Most traffic filtering tools give you one number — a quality score, a trust rating, a percentage. That's convenient and almost useless for troubleshooting. When a campaign underperforms, you need to know why. Was the traffic coming from a datacenter? Was it arriving in bursts? Was the user agent spoofed? A single score collapses all of that into one opaque figure.

Adtraxo's approach is to keep the rules separate. Each click gets evaluated against all five, and each rule produces its own signal. That means when you open a campaign report and see a spike in flagged clicks, you can immediately see which rule is doing the flagging — and that tells you what to do next. High datacenter IP flags point at a source serving you server traffic. High IP velocity flags point at a source that's rotating through a small IP pool. High bot user agent flags point at a source that isn't even trying to disguise the traffic.

Five separate rules also means fewer false positives on any single dimension. A legitimate user on a VPN might trip the datacenter rule but pass the other four. A fast-loading landing page might produce rapid clicks from real users that trip velocity thresholds — but those clicks will pass the user agent and referer checks. Isolated flags are usually noise. Clusters of flags are usually fraud.

Rule 1: IP velocity — catching clicks that arrive too fast

IP velocity measures how many clicks arrive from the same IP address inside a rolling time window. Humans don't click the same ad twenty times in a minute. Bots and click farms do.

The rule works by maintaining a counter per IP. Every incoming click increments that counter. If the counter crosses the threshold within the window, the click is flagged. The window and threshold are tuned so that normal browsing behaviour — a user clicking two or three links from the same network — passes cleanly, while automated patterns fail.

What this catches:

• Click farms running scripts from a handful of IPs
• Botnets that haven't rotated their exit nodes
• Retargeting loops that fire the same pixel repeatedly from one device
• Accidental double-fires from a broken tracking setup (which is worth knowing about even though it isn't fraud)

What it misses: distributed botnets that use a fresh residential IP for every single click. Velocity is a pattern rule, so it only fires when there's a pattern. If each click comes from a unique IP, there's no velocity to measure — which is exactly why you need the other four rules running alongside it.

Rule 2: datacenter IP — traffic that shouldn't exist

Real consumers browse from residential and mobile connections. Bots usually run from servers. The datacenter IP rule checks each incoming IP against known hosting ranges — AWS, Google Cloud, DigitalOcean, Hetzner, OVH, and the long tail of smaller providers.

This is one of the highest-signal rules in the set, because it's binary. An IP either belongs to a hosting provider or it doesn't. There's very little ambiguity. When you see a campaign where a large share of clicks are flagged as datacenter IPs, you're not looking at a subtle quality problem. You're looking at a source that is routing automated traffic through cloud infrastructure, and no amount of optimisation will turn that traffic into buyers.

A few caveats worth knowing:

• Some corporate networks and privacy tools route through datacenter ranges. A small percentage of datacenter flags on an otherwise clean campaign is normal.
• VPN users are a mixed bag. Some are real buyers. Many are not, because VPN traffic is cheap to generate at scale.
• The rule is most useful in aggregate. One datacenter flag is a data point. Forty percent datacenter flags on a source is a verdict.

Rule 3: bot user agent — the traffic that tells on itself

Every browser sends a user agent string identifying itself. Real browsers send strings that match known patterns for Chrome, Safari, Firefox, Edge, and the mobile equivalents. Bots frequently send something else entirely — a headless browser default, a scripting library identifier, an empty string, or a mismatched combination that no real browser would produce.

The bot user agent rule checks the incoming UA against known bot signatures and against internal consistency. A UA that claims to be Chrome on Windows but is paired with a Linux-specific header set is suspicious. A UA that's completely blank is almost always automated. A UA that identifies as a scraping library or a headless browser is a straight flag.

This rule catches the lazy end of the bot spectrum. It's the cheapest traffic to generate and the easiest to detect, which is why sophisticated operations spoof their user agents to look like real browsers. When they do, they pass this rule — and then they have to survive the next two.

Rule 4: uniqueness conflict — when the click doesn't add up

Uniqueness conflict is the rule that catches traffic trying to look human. It looks at whether the identifying signals attached to a click are consistent with each other and with a plausible real user.

The core idea: a real user has a stable identity fingerprint. Their IP, device, user agent, and behaviour line up. A bot trying to fake uniqueness often produces combinations that don't. The same device fingerprint appearing across many different IPs. The same IP producing clicks with wildly different device profiles in a short window. A click that claims to be a fresh user but carries a fingerprint that's already been seen dozens of times.

This is where a lot of otherwise-clever bot traffic falls apart. Spoofing a user agent is trivial. Spoofing a user agent and rotating IPs and generating a fresh-looking device fingerprint for every click is expensive — and at that point, the operator is spending more per click than the traffic is worth.

Uniqueness conflict is also the rule most likely to produce false positives if you're not careful about what you're comparing. Shared devices, public wifi, and heavily-used corporate networks can all produce legitimate collisions. The signal to watch is the rate of conflicts, not the existence of any single one.

Rule 5: invalid referer — traffic with a bad alibi

The referer header tells you where a click came from. When a user clicks an ad on a publisher's page, the referer should point at that page — or at the ad network's redirect chain, depending on how the click is routed. The invalid referer rule checks whether the referer makes sense for the traffic you're buying.

Flags here come in a few flavours:

• No referer at all, when your traffic source always sends one
• A referer pointing at a domain that has nothing to do with your placement
• A referer that's been obviously spoofed — a malformed URL, a placeholder string, a domain that doesn't resolve
• A referer that contradicts the sub-ID or placement data your traffic source reported

That last one is the most useful. If PropellerAds tells you a click came from placement X, but the referer points somewhere unrelated, something in the chain isn't honest. This rule is particularly valuable for catching sources that are reselling traffic or mixing in inventory you didn't buy.

How the five rules work together in Adtraxo

Running five rules independently and then reading them together is what makes Adtraxo bot detection useful in practice rather than just theoretically. A single flag is a note. Two flags on the same click is a pattern. Three or more is a near-certain sign that the click wasn't a human.

In your campaign reports, the flags appear per campaign and can be broken down by geography and device. That breakdown is where the money is. If bot flags are concentrated in one country, you can geo-block that country without touching the rest of the campaign. If they're concentrated on one device type, you can exclude that device. If they're spread evenly across everything, the problem is the source itself, and the fix is to cut it or renegotiate.

Turning flags into action: a practical workflow

Detection without action is just expensive reporting. Here's the loop that actually recovers budget:

1. Set up postback tracking first. Without conversion data flowing back into Adtraxo, you can see bot flags but you can't tie them to spend that failed to convert. Postback URL tracking and sub-ID parameter passing (sub1–sub5) are Pro features, and they're the foundation for everything below.
2. Let the campaign run to a meaningful click volume. Rules need data. Judging a source on a few hundred clicks will give you noise.
3. Open the campaign report and look at the flag distribution. Which rules are firing? Are flags clustered by geo or device?
4. Cross-reference flags against conversions. If a placement has heavy bot flags and zero conversions, cut it. If it has some flags but a healthy conversion rate, the flags may be noise — leave it alone.
5. Adjust placements, not just campaigns. Use sub-IDs to isolate the specific placement, zone, or creative that's producing flagged traffic, and block at that level. Killing a whole campaign because one placement is dirty throws away working traffic.
6. Re-check after changes. Bot traffic adapts. A source that cleaned up after you blocked a placement may reintroduce the problem through a different route a week later.

Adtraxo's AI Campaign Optimizer can run part of this loop for you — it watches performance signals across campaigns and surfaces where budget is being spent without return. Combine that with the fraud flags and you get a fairly complete picture: the optimizer tells you where money is being wasted, and the bot detection rules tell you why.

What bot detection can't do

Worth being straight about the limits. Rule-based detection catches automated traffic and low-effort fraud well. It struggles with:

• Sophisticated residential proxy networks that rotate real-looking IPs, spoof consistent user agents, and generate plausible fingerprints. These pass most rules and are usually caught by conversion data instead — the traffic looks fine but never buys.
• Human click farms. Real people clicking real ads from real devices are, by definition, indistinguishable from real users at the click level. Only conversion analysis catches them.
• Attribution fraud that doesn't generate fake clicks at all — it just claims credit for conversions that happened elsewhere. That's a different problem with different tooling.

The honest framing: bot detection removes a large, cheap, easily-identifiable slice of wasted spend. It does not make your traffic clean. It makes your traffic clean enough that your optimisation decisions are based on real data instead of noise — and that's the difference between a campaign you can scale and one you keep throwing money at.

Frequently asked questions

If you're spending money on traffic and you can't see which clicks are real, you're optimising blind. Set up Adtraxo, wire your postback, pass your sub-IDs, and let the five rules show you where your budget is actually going. Start at adtraxo.com.