Click Fraud & Bot Traffic: How to Detect and Filter It on Paid Campaigns

A nutra campaign geo’d to Germany is posting a 4.8% CTR — nearly triple the account average — with a 22% click-to-registration rate that would normally justify doubling the budget on the spot. Then someone actually opens the raw click log. Two hundred and eleven of the day’s registrations completed between 2 and 4 seconds after the click. Sixty-eight percent of those clicks came from the same /24 subnet, resolving to a data-center ASN in a country that isn’t the targeted geo. None of it converted past step two of the funnel. That campaign wasn’t performing — it was being hit by click fraud, and every dollar spent on it trained the algorithm to buy more of the same garbage traffic.

This is the quiet failure mode of paid acquisition: bot traffic and invalid clicks don’t just waste the ad spend they consume directly, they corrupt the optimization signal the platform uses to find your next batch of users. A campaign polluted with 15-20% invalid traffic doesn’t look broken — it looks like a campaign with mediocre creative, so you kill it, or worse, it looks like a winner and you scale it. Either way you’re optimizing against noise. Fixing this isn’t about paranoia, it’s basic traffic quality control — the same discipline you’d apply to any input that determines where money goes next.

What Counts as Invalid Traffic on a Paid Campaign

“Bot traffic” is the catch-all term, but the sources of invalid traffic on a real paid campaign break into a few distinct categories, each with a different signature:

• Bots and crawlers — automated scripts, scrapers, and monitoring tools that click links without any human behind them. Some are malicious, some are just badly-behaved SEO or uptime tools that happen to hit your redirect chain.
• Click spam — high-volume, low-intent clicking generated by malware on infected devices, click-injection SDKs bundled into low-quality apps, or bot farms running on residential proxy pools to look less suspicious than data-center traffic.
• Data-center and proxy/VPN traffic — clicks originating from hosting providers, cloud regions, or commercial proxy/VPN exit nodes instead of real residential or mobile ISPs. Some real users do run VPNs, but a spike concentrated in a handful of ASNs is a different story than background noise.
• Incentivized or fake-converting traffic — traffic that’s technically “real” (a human tapped something) but was paid to click or paid to fake a conversion, often from click-exchange rings or offer-wall abuse. This is the hardest to catch because it clears simple bot checks.
• Competitor click attacks — deliberate, repeated clicking on your ads by a competitor or a hired service to burn your daily budget before real prospects ever see the ad.

None of these show up as “0 conversions, obviously fake.” The costly ones actually convert a little, which is exactly why raw CTR and CR aren’t enough to catch them.

The Signals That Actually Expose Bot Traffic

Every category above leaves a fingerprint somewhere in the data you already collect. The trick is looking at combinations, not single metrics in isolation.

CTR and CR anomalies. A CTR that’s 2-3x your account average on one placement or one traffic source, paired with a conversion rate that’s either suspiciously high (fast, uniform, too-good) or a flat wall of clicks with zero downstream activity, is the first flag. Real traffic has variance; fabricated traffic tends to be unnaturally smooth.

Session depth and time-on-page. Human visitors browse. They scroll, they pause, they bounce between two or three pages before converting or leaving. Bot traffic frequently shows a single-pageview session with near-zero time-on-page, or the opposite extreme — a session that “stays” open for hours because nothing ever actually closes the connection.

IP reputation and ASN. Cross-reference click IPs against known data-center ranges, public proxy/VPN exit lists, and ASN ownership. A cluster of clicks from AWS, DigitalOcean, or a VPN provider’s published IP ranges is a strong invalid-traffic signal on its own, and a near-certain one when combined with anything else on this list.

Click-to-conversion timing. Real users take time to read a landing page, consider an offer, and fill in a form — even a fast, well-designed one rarely converts in under 3-4 seconds. A conversion firing 1-3 seconds after the click, repeatedly, points to a script completing the funnel programmatically rather than a person doing it.

Device and user-agent inconsistencies. A user agent claiming to be a specific mobile browser but missing the touch-event and viewport signals a real device of that model would send. Identical, outdated, or malformed UA strings repeating across “different” sessions is a classic bot fingerprint.

Geo mismatches. IP-derived geo that doesn’t match the targeting geo, or matches it but sits in a data-center block registered to a hosting company rather than a consumer ISP in that country, both indicate the click isn’t coming from who the platform says it’s coming from.

A Worked Example: Reading the Signals Together

Back to the German nutra campaign. On their own, none of the four data points below would be a hard stop — together they’re conclusive:

1. Click-to-conversion time: median 2.8 seconds (account baseline: 94 seconds)
2. Source subnet concentration: 68% of clicks from one /24
3. ASN: registered to a data-center/hosting provider, not a residential ISP
4. Session depth: 1 pageview, 0% scroll depth, on 100% of flagged sessions

Any single signal could be a coincidence — maybe there’s a legitimate reason for a fast form-fill, maybe one office network shares an IP block. All four stacked on the same slice of traffic isn’t coincidence, it’s a fraud pattern, and it’s exactly the kind of thing that should get filtered from both spend and reporting before it drags the account average down or convinces the algorithm this is where your buyers live.

Click Fraud Types, Signals, and Filter Actions

Building a Filter Rule: From Signal to Action

Turning these signals into something enforceable means expressing them as conditions your tracker can actually evaluate per click or per session, not just eyeballing a spreadsheet after the budget is already spent. A basic invalid-traffic flag combines several weighted checks into one suspicion score:

fraud_score =
    (asn_is_datacenter_or_vpn ? 40 : 0) +
    (click_to_conversion_seconds < 4 ? 30 : 0) +
    (session_pageviews <= 1 && scroll_depth == 0 ? 20 : 0) +
    (clicks_from_source_ip_last_hour > 25 ? 25 : 0) +
    (ua_missing_expected_device_signals ? 15 : 0)

if fraud_score >= 60:
    action = "exclude_from_spend_and_reporting"
elif fraud_score >= 30:
    action = "flag_for_review"
else:
    action = "pass"

The exact weights matter less than the structure: no single signal auto-kills a click, but signals stack, and only traffic that crosses a real threshold gets excluded. This is also where a custom metrics layer earns its keep — instead of manually recomputing this score in a spreadsheet every week, you define it once as a formula against your own click and conversion data, and it becomes a standing column you can sort, alert on, and filter by, per source, per campaign, per day.

Detection vs Filtering: Why You Need Both as Ongoing QC

Detection tells you a problem exists. Filtering is the part that actually protects the account, and the two need to run continuously, not as a one-time audit after a campaign already tanked.

Detection means surfacing anomalies as they happen — a source suddenly spiking in click-to-conversion speed, an ASN showing up that wasn’t there yesterday, a placement whose session depth collapsed overnight. This is a monitoring problem: you need analytics that break performance down by source, ASN, and device rather than one blended campaign number, because the blended number is exactly what hides a 15% invalid slice sitting inside an otherwise-fine campaign.

Filtering means acting on what detection finds, before the bad traffic pollutes spend allocation or gets credited as a real conversion that feeds back into platform optimization. That’s the job of dedicated traffic quality rules sitting in front of your funnel — evaluating inbound clicks against exactly the signal set above and routing flagged traffic away from both your ad spend efficiency numbers and your “real” conversion count, automatically, on every click, not just the ones someone happened to review manually.

Run only detection and you get a very informative postmortem on a campaign that already lost you money. Run only filtering with no detection loop behind it and your rules go stale the moment fraud sources rotate IPs or ASNs, which they do constantly. You need both, running together, as a permanent part of how traffic gets evaluated — not a one-off cleanup project.

Common Mistakes

• Judging traffic quality by CTR and CR alone. A high CTR with a matching CR looks like a win right up until you check session depth and find every session lasted under two seconds. Blended top-line metrics hide exactly the anomaly you’re trying to catch.
• Blocking by country instead of by ASN. Excluding an entire GEO because of a fraud spike also kills every real user in that country. The signal was never the country — it was the data-center ASN inside it.
• Treating a single red flag as proof. One VPN click doesn’t mean fraud; VPN usage among real users is common and rising. Filtering on a single signal instead of a stacked score generates false positives that quietly cut good traffic along with the bad.
• Reviewing traffic quality monthly instead of continuously. Fraud sources rotate infrastructure fast — the ASN block that was clean last week can be a bot farm this week. A monthly audit catches damage well after the budget is already gone.
• Crediting conversions without checking what happens downstream. A “conversion” that never turns into a deposit, a qualified lead, or retained revenue isn’t a conversion — it’s a number a fraud ring or an incentivized traffic source fed you to look legitimate.

FAQ

How much of my paid traffic is actually invalid?

It varies enormously by vertical, geo, and platform, but figures commonly cited land somewhere around 5-10% of paid clicks as a rough baseline, with individual campaigns or specific traffic sources running far higher when they’re actively targeted. Treat any fixed percentage as a starting assumption to verify against your own data, not a universal constant.

Can I fully stop click fraud, or only reduce it?

You can’t eliminate it — fraud sources adapt as fast as filters improve. The realistic goal is continuously cutting the invalid share down to a level that no longer distorts your optimization signal or meaningfully drains budget, and re-checking that level regularly rather than assuming a filter set from six months ago still holds.

Does filtering invalid traffic hurt my reported volume?

It reduces your top-line click and conversion counts, yes — but those numbers were already inflated by traffic that was never going to produce revenue. Reported volume built on invalid traffic isn’t an asset; it’s noise you were about to optimize toward.

Is a fast conversion time always fraud?

No. Some real funnels — a one-tap subscribe, a pre-filled form on a returning user — genuinely convert fast. That’s exactly why click-to-conversion timing should be one weighted signal in a combined score, not a standalone rule that auto-rejects every quick conversion.

Keeping the Data Clean

None of this is about hiding anything from anyone — it’s about making sure the numbers driving your next budget decision reflect real people who might actually convert. DarkCore’s tracker evaluates inbound traffic against ASN, device, timing, and session signals as it arrives, so invalid clicks get filtered out of spend and reporting before they skew a single campaign average, and custom metrics let you define exactly which combination of signals matters for your own verticals instead of trusting a generic bot checkbox.

If you’re not sure how much of your current traffic would survive this kind of check, talk to us on Telegram and we’ll walk through what your click logs are actually showing.