I measure proxy networks, browser engines and the anti-bot systems in front of scraping targets. Currently at NodeMaven.
In practice that means running controlled experiments and reporting what they show rather than what would be convenient:
- one variable per run, because the provider, the engine and the target are separate axes and moving two at once produces a number nobody can attribute
- an unmodified control in every comparison, since a pass rate without one is an observation rather than a claim
- every rate quoted with its denominator and its interval
- claims that did not survive replication kept next to the ones that did
Two results to show the shape of it. At Google the exit address is nearly the whole story: across five country settings the share of addresses Google would serve at all ran from 13% to 62%, while the share of served pages the browser then passed was 83 of 83 and did not move with the setting at all. At Amazon it inverts. Drawing from the same pool, interleaved, a distinct /24 per attempt, a Firefox-based engine was served 114 of 127 times where a patched Chromium was throttled on 113 of 131 - and the best engine at Google is the worst one here.
The two targets are usually discussed as one problem. They do not have the same bottleneck, so an engine picked for one of them is the wrong pick for the other, and a benchmark that reports a single pass rate hides exactly that. The Amazon split is an August 2026 reading from one machine; a later run on other hardware disagreed on the magnitude, and that re-check is currently running.
I am preparing the harness behind that for release. It runs browser automation frameworks against live targets through any proxy gateway a config file can describe, and the raw rows are published with the conclusions.
If you maintain a scraping or automation library and there is a claim about proxies or bot detection you would rather have measured than argued about, write to me. Measuring it is the cheaper half.