Bot detection

Every click is judged, scored, and stored with the verdict. Two rules shape all of it:

Bots are flagged, never silently dropped. A blackholed request tells a scraper it was detected, and losing the row loses the evidence. Every click is kept, with is_bot and a reason; the reports exclude them from your figures.

No single signal decides. A datacentre IP is strong but not proof — some corporate proxies egress from cloud ranges. A missing Accept-Language is weak alone and damning next to a headless user agent. So signals combine into a score, and the score meets a threshold you control.

#The signals

Every one of these appears in the Bot reason column of the clicks log. A click excluded from your totals says which signal excluded it, rather than leaving you to guess whether the traffic or the tracker is at fault.

#Network origin is the strongest one

Real buyers browse from residential and mobile networks. Traffic arriving from AWS, Google Cloud or a VPS provider is a scraper, a monitoring probe, an ad-network reviewer, or a competitor — almost never a customer.

User-agent matching only catches automation that identifies itself. Anything trying not to be seen sends a real browser's string, and where it connected from is what still gives it away.

#Spoofed against verified

crawler_ua says something called itself Googlebot. verified_crawler says it really is one, and spoofed_crawler says it is not.

The difference matters: a competitor scraping your funnel sends exactly the string Googlebot sends. The only way to tell them apart is whether the address belongs to Google, and Google publishes its ranges. A user-agent regex records both as a crawler and learns nothing.

#Click flood

One address producing dozens of clicks a minute on one campaign is not a person. This catches automation presenting a perfect browser fingerprint — the case both user-agent and network checks miss.

It is the one signal that needs to count across requests, which is why it is the only asynchronous part of detection.

#The threshold

The score has to reach a threshold before a click is called a bot, and both the threshold and which signals are switched off are yours to set.

Raising it lets more through and keeps your figures closer to what the platform billed you for. Lowering it excludes more and makes your CR and EPC describe people rather than machines. Neither is correct in general; what is correct is knowing which way you have set it when you compare a report against a platform's dashboard.

#Allow and deny lists

Lists run before the score. An entry is an attribute, an operator and a value, and it decides outright.

Use them for what scoring cannot know: an office IP that is genuinely yours, a range a network has told you to exclude, a country you do not hold a licence for. See allow and deny lists.

New entries default to deny, deliberately — an allow rule written by accident silently narrows everything you accept, and that failure is invisible.

#Reading a routing rule against it

A routing rule can test is_bot, bot_score, bot_reason, is_proxy and proxy_kind, so a flow can send suspect traffic somewhere harmless rather than to the offer.

This is worth more than it sounds. A network that sees bot traffic on your click-outs may cut your payout or drop you; routing suspicion to a safe page costs you nothing and keeps their side clean.

#What it costs you

Bot clicks are counted in their own column, excluded from Clicks, and their cost excluded from Cost. See the figures, exactly.

So a bot wave inflates neither your traffic nor your spend here. Whether the platform charged you for it is between you and the platform — and the repeat addresses screen is what you take into that conversation.