Request Success Rate

Request success rate is the share of scraping requests that succeeded. It is the headline metric almost every vendor in this market quotes and almost none define the same way, which makes cross-vendor comparison of published figures close to meaningless unless the methodology travels with the number. Two providers can honestly report 99 percent and 92 percent on the same target while the second one is delivering more usable data, purely because of what each counted.

The numerator is where the ambiguity starts. The narrow definition is HTTP 200 and nothing more. A stricter one is a 200 whose body parsed into a non-empty result matching the expected schema. The strictest is a 200 that parsed and is not a soft block, meaning a challenge page, a consent interstitial, a generic "no results" page or a stripped variant served specifically to suspected bots. Soft blocks are the single most common way a headline number gets inflated, because the transport succeeded and only a content check can tell. The denominator matters just as much: attempts, unique URLs, or billed requests, and whether a URL that took four retries counts once or four times. Counting retries once and measuring at the URL level produces a much prettier number than counting every attempt.

This site publishes no first-party measurements of any vendor. We do not run block-rate or latency tests, and any figure you see here is either disclosed by the vendor or drawn from a named third-party benchmark with its methodology attached and dated. Treat undated success-rate claims as marketing copy regardless of source, including ours if we ever slip.

The practical move is to write your own success definition into the trial protocol before you contact anyone. Fix the URL list, the concurrency, the time window, and the content assertion that decides success, then run every candidate against the identical harness and compute the rate yourself from your own logs. Vendors with a real number will not object. The questions that expose a padded one are short: does your figure count retries, does it count soft blocks as failures, which targets and which dates produced it, and what percentile is it measured at. Tools such as ScrapeOps exist to monitor exactly this in production, and running that monitoring during the trial rather than after it is the cheapest way to avoid signing against a number that was never yours.