VPN detection is not click validation: compare the signals
A network label answers where traffic came from. Click validity is about the event, its eligibility and its outcome. Here is how the two signals compare.
Two questions get merged in most click-fraud discussions, and the merge is where the bad decisions come from. The first is where a request came from, which a network classification can answer approximately. The second is whether the event should count, which depends on eligibility rules, behavior and outcome. A VPN label is evidence for the first question and, on its own, says nothing about the second.
Two questions that look like one
The first question is descriptive: did this request arrive through a hosting provider, a privacy VPN or a residential connection? The second is normative: does this event satisfy the definition your business agreed on? Descriptive answers are cheap and statistical. Normative answers require a definition and an owner.
Confusing them produces a detector that is confident and wrong. You can classify every request correctly and still count invalid events, because classification never asked what an eligible event is.
What a network label can support
Address class is a population statement, not an individual one. A single IP can front a carrier-grade NAT with thousands of subscribers, a corporate egress with a whole office, or a privacy VPN with unrelated users. Calling that address suspicious assigns the behavior of a few to everyone behind it.
Google's invalid-traffic guidance is a useful concrete example of the definition problem. It covers intentional fraud and accidental clicks alike, which means the platform's own model treats the event and its context as the subject, not the delivery network alone.
A user agent string does not rescue this. It is self-reported by the client, trivially changed, and not an authenticated identity. Treat it as a hint that correlates with a device family, never as a statement of intent.
What an event-level review adds
Event-level review asks different questions: was this credit counted more than once for one interaction, did the flow look automated, was the session long enough to have read what it clicked, and did the downstream outcome match the claimed interest? Those are answerable with first-party data you already keep.
Notice that none of them require a universal threshold. A burst of activity is a reason to review a window, not proof of a click farm, and a single session that looks odd is not evidence of coordination. The threshold you invent will be wrong for some legitimate workflow, so state it as a review trigger rather than a verdict.
Where each approach fails
Put the three signals side by side and the blind spots become obvious.
| Signal | Question it answers | Characteristic failure |
|---|---|---|
| Address classification | Where did this arrive from | Rejects shared exits and privacy-conscious users |
| Automation signals | Does this look scripted | Misses paid human interaction entirely |
| Event and outcome review | Should this count | Needs a definition and an owner to be meaningful |
The table is the whole comparison. Each row is a real signal with a real blind spot, and none of them is a definition of fraud.
Measure the detector, not just the traffic
Keep three sets: events you know are legitimate, events confirmed invalid, and cases you could not resolve. Evaluate the detector against all three. A rule that rejects every shared exit looks decisive on the confirmed-invalid set and quietly harms ordinary users, which is exactly the trade nobody measures.
Record false positives as a first-class metric, alongside missing information. If the unresolved bucket keeps growing, the detector is not getting better; it is getting quieter.
Give the decision an owner
Coordinate with the measurement or advertising platform and the service's owner before changing a rule. Use the platform's supported reporting and correction process rather than testing live monetized ads with artificial clicks, which creates the very invalid traffic you are trying to prevent.
Limit collection to the purpose you can justify. Wanting to classify fraud does not make indefinite fingerprinting a requirement, and the AdSense invalid-traffic guidance is a reasonable reference for how a platform frames the categories.
Start by writing the eligible event in one sentence. If the sentence is about network origin, you have a proxy metric, not a definition.