IP Reputation Scoring: How a Visitor Becomes a Number

Every filtering product eventually presents you with a number: this visitor scores 82, that one scores 14. The number is only useful if you understand what went into it, how it decays, and where you should draw your own lines. This is what happens between the request arriving and the score appearing.

What goes into a score

Reputation scoring aggregates evidence from several independent categories. The category matters as much as the individual fact, because evidence from different categories is worth more in combination than more evidence from the same one.

• Network classification. What kind of address is this? Datacenter and hosting ranges carry the heaviest weight, followed by known VPN and proxy infrastructure, then TOR exit nodes.
• Infrastructure context. The autonomous system, its historical behaviour, whether reverse DNS is present and plausible, and whether the whole ASN is dominated by automated traffic.
• Observed history. What this address has actually done—across your own traffic and, where a vendor offers it, across a shared pool. Volume, velocity, and outcomes such as chargebacks.
• Consistency. Whether geography, timezone, language, and device attributes agree with one another.
• Client integrity. Automation markers, rendering anomalies, and header irregularities gathered from the request and the browser environment.

Weighting and decay

Not all evidence deserves equal influence, and none of it should last forever.

Weighting reflects how often a signal is right. Datacenter origin is close to decisive for consumer-facing pages. A missing referrer is weak—privacy settings strip referrers routinely. Getting weights wrong in either direction is costly: overweight a weak signal and you block customers, underweight a strong one and you pay for bots.

Decay matters because addresses change hands. Consumer IPs are reassigned by ISPs constantly. A compromised machine gets cleaned. An address that hosted a botnet six months ago may today belong to an ordinary household. Evidence must lose weight over time or your system slowly accumulates unfair permanent verdicts.

Turning a score into a decision

A score is not a decision. You need bands, and the boundaries are a commercial choice.

Band	Interpretation	Typical action
Low	Consistent with an ordinary visitor	Serve normally
Elevated	Some anomalies, no strong evidence	Serve, log, watch for patterns
High	Multiple independent signals agree	Friction, restricted experience, or route away
Severe	Unambiguous automation or known-bad infrastructure	Block

Where you place these boundaries should differ by context. The threshold for showing a landing page can be aggressive: the downside of a wrong decision is one lost click. The threshold for blocking a checkout should be conservative: the downside is a lost order and an angry customer. Running one global threshold across both is a common and expensive mistake.

Shared intelligence and its limits

Vendors that pool observations across many customers can flag an address that has never touched your site. That network effect is real and useful.

It also has limits worth being clear-eyed about. Shared data reflects the aggregate population, which may not resemble yours—an address that is abusive against one vertical may be an ordinary customer in another. You inherit the pool’s labelling errors along with its coverage. And shared reputation says nothing about the signal that predicts your fraud best, which is usually your own conversion and chargeback history. Treat external intelligence as one weighted input, not as ground truth.

Auditing your scoring

Scoring that cannot be interrogated will eventually be switched off by someone who cannot explain a blocked customer. Insist on the ability to answer these questions:

• For any blocked request, which signals fired and what did each contribute?
• What share of traffic falls in each band, and how has that moved week over week?
• Which single rule is responsible for the most blocks—and is that justified?
• Of the traffic you allowed, what proportion later produced a chargeback or a fraudulent signup?

That last question is the only real measure of accuracy. Everything else tells you what the system did; only outcomes tell you whether it was right.

Watching for drift

Scores drift. Attack patterns change, proxy pools rotate, vendors adjust their models, and your own traffic mix shifts with each new campaign. A threshold that was correct in March can be badly wrong by July.

Review the band distribution on a fixed schedule. A sudden jump in the high band usually means an attack or a vendor model change—both worth knowing about immediately. A slow slide toward the low band may mean your adversaries have adapted and your signals have quietly stopped working.