Bot Score Thresholds: The Number You Set Is a Business Decision
The two errors cost different things
A false negative, a bot waved through, costs whatever that automation does: scraped prices, hoarded inventory, card testing volume, fake accounts that support has to clean up. A false positive, a human challenged or blocked, costs conversion on that session and sometimes the customer permanently, because a person blocked at a sneaker drop or a checkout does not file a bug report. They leave and tell people.
The costs are asymmetric by endpoint. A false positive on a blog page is a rounding error. A false positive at payment is a lost order at the most expensive moment in the funnel. One global threshold across a whole property guarantees the number is wrong in both directions somewhere.
Set thresholds per endpoint, by purpose
Public content can tolerate permissive settings, with rate limits doing most of the work. Login and account creation deserve stricter thresholds, because account takeover and fake account creation concentrate there and the legitimate user has more patience for a challenge when protecting an account. Checkout and limited inventory endpoints get the strictest settings during the events that attract automation, and can relax between them.
Seasonality matters too. The threshold that was right in a quiet month is wrong during a drop, a sale, or a credential stuffing wave, and mature teams schedule threshold profiles the way they schedule infrastructure scaling: in advance, from the commercial calendar.
Measure the false positives directly
You cannot tune what you do not count. Sample challenged and blocked sessions, replay them against subsequent behaviour, and track how many later converted through another route, contacted support, or simply never returned. Challenge solve rates by score band tell you where humans start failing: the band where solve rates collapse is usually where your threshold should not be without a step up option like a stronger proof instead of a hard block.
Give blocked users a visible remedy: a support path, an alternate verification, anything that is not a wall. The remedy traffic is also your best labelled dataset of real humans the system misjudged.
Retune in small moves, with a rollback
Move thresholds in small increments on one endpoint at a time, watch both error measures for a full business cycle, and keep the previous setting one click away. Large sudden tightening during an attack feels decisive and routinely blocks a slice of real customers nobody counts until the revenue meeting.
Document every change with its reason and its measured effect. Six months later, when a new engineer asks why search pages run a looser threshold than checkout, the answer should be in the record, not in the memory of whoever set it during an incident.
Keep reading
Related guides on this site: Velocity Checks: Catching Card Testing Before It Becomes a Chargeback Pile Chargeback Alerts: Buying 24 Hours to Refund Before the Dispute Lands https://riskrampart.com/blog/index.md.
Frequently asked questions
What is a bot score threshold?
A cutoff applied to a risk score assigned to each session or request. Traffic scoring above the threshold is challenged or blocked. The setting trades automation let through against real customers refused.
Should one threshold cover a whole site?
No. Error costs differ sharply by endpoint. Checkout and limited drops warrant strict thresholds, login sits in the middle, and public content can run permissively with rate limits doing most of the work.
How do you know if a threshold is too strict?
Sample blocked and challenged sessions, track challenge solve rates by score band, and follow how many blocked users later converted or contacted support. Collapsing solve rates mark the band where humans are being refused.