Success rate
The share of requests that return a usable response. Meaningless without a sample size and a named target.
Success rate is the proportion of requests that produce the response you wanted. It is the headline metric in proxy marketing and the one most often quoted without the context needed to interpret it.
#What a rate needs to mean anything
- A sample size. “98%” from 100 requests and from 100,000 are very different claims.
- A definition of success. A 200 response containing a block page is not a success, though naive measurement counts it as one.
- A named target. Rates against an echo service and against a heavily defended retailer are not comparable.
- A date. Pools and defences both change continuously.
#The most common measurement error
Counting HTTP status alone. Many anti-bot systems return 200 with a challenge page or an empty result set, because doing so wastes the scraper’s time. Validate that the response actually contains what you asked for, not merely that the request completed.
#Reading provider claims
A rate published without sample size, target and date is marketing. Treat it as a claim about the vendor’s confidence, not as a measurement.
#What a rate must state to be meaningful
A percentage on its own is not a measurement. Five facts turn it into one, and a claim missing any of them cannot be compared with another claim.
| Fact | Why it changes the number |
|---|---|
| Sample size | A rate over a handful of requests is noise |
| Target | Sites differ enormously in how hard they are |
| Date | Defences change, so results expire |
| Definition of success | A 200 with a challenge page is not a success |
| Concurrency | Rates fall as parallelism rises |
#The error that inflates every number
Counting HTTP 200 as success is the most common measurement mistake, and it always flatters the result. A challenge page, a consent wall and an empty result set all return 200. So does a page served to a suspected bot with the data removed.
Validate the content instead. Assert that a field you actually need is present and plausible, and count anything else as a failure however the status code reads. A rate measured this way is lower and useful; a rate measured on status codes is higher and meaningless.
#Why we publish no provider rates here
We do not print a success rate unless we ran the test and can state all five facts above. A number without them tells a reader nothing they can act on, and repeating a vendor’s figure as though it were a measurement would be worse than printing nothing.