Every bot-defence product is sold on what it stops. Requests blocked, attacks mitigated, percentage of automated traffic identified. Those numbers are easy to produce and easy to compare, and they describe one half of the system's behaviour.
The other half is what it does to people who were not doing anything, and it is almost never measured — because it is almost never visible.
One error announces itself and the other does not
When a bot gets through, something happens. An account is taken over, inventory is bought out, a form is filled with garbage, a bill arrives larger than expected. There is an incident, and the incident has an owner, and someone goes looking for why the defence did not catch it.
When a real customer is blocked, nothing happens. They see a challenge that will not pass, or a page that will not load, or a checkout that refuses without saying why. Then they leave. There is no alert, no ticket, no incident review. In the analytics it is indistinguishable from someone who changed their mind.
This asymmetry does not reflect the actual costs. It reflects which failure generates a notification.
What the second error is worth
A blocked customer is not a near-miss. It is the whole relationship, usually permanently, and often quietly.
They cannot appeal a decision nobody told them about. Most will not contact support, because from where they are standing the site is broken rather than suspicious of them. If they are on a corporate VPN, a mobile carrier that routes traffic through another country, a small ISP that buys transit from a network with a poor reputation, or simply a shared address behind carrier-grade NAT, they will hit the same wall next time, and they will not try a third time.
The people most likely to be caught this way are also not a random sample. They skew toward mobile users, toward countries with less consumer broadband and more shared addressing, and toward anyone whose connection does not look like a home in a wealthy country. A defence tuned only on catch rate systematically works worst for exactly those users, and the operator cannot see it happening.
Why tuning drifts one way
Left alone, most deployments get stricter over time, and the mechanism is structural rather than anyone's fault.
Every missed bot produces evidence: an incident, a complaint, a demand that the rules be tightened. Every blocked customer produces silence. Feed both into the same review meeting and the strictness only ever ratchets in one direction, because only one side of the ledger ever sends anyone a message.
Breaking that requires deliberately generating the missing signal. Sampling what was blocked and looking at it. Tracking the challenge-abandonment rate as a first-class metric rather than an operational detail. Treating a sudden drop in traffic from one network as a possible false-positive cluster rather than a successful mitigation. None of that is difficult; it is just work that nobody is currently being asked for.
The question to ask about any detection
Before acting on a signal, it is worth asking what it would take for the signal to be wrong, and what happens to the person if it is.
Some findings are close to certain — an address published by its operator as an exit node, a range a registry has disowned. Others are inferences, and remain inferences however good the engineering is. Both can be useful. They should not both trigger the same response, because the cost of being wrong is not the same and the likelihood of being wrong is not the same.
A defence that treats every signal as equally certain has not eliminated that judgement. It has just made it once, in advance, on behalf of every user it will ever see — and, given how the feedback works, almost certainly in the stricter direction.