Compare cost per kept result
Do not compare residential proxies only by dollars per GB. Compare the cost of a kept row, successful check, or completed account step.
| Pool | Good fit | Bad fit |
|---|---|---|
| Volume residential | Large public pages, broad geo checks, forgiving targets | Expensive targets with heavy blocks. |
| Premium residential | Sensitive targets, lower retry tolerance, stronger ASN needs | Cheap pages where volume already works. |
If volume residential needs four retries for one useful result, premium can be cheaper even at a higher sticker price.
Bandwidth is where cheap plans get expensive
Retry loops, images, blocked HTML, JavaScript bundles, redirects, and app probes all burn GB. The client app may credit only the final useful action. The proxy bill sees everything.
Measure total GB divided by kept results. That number decides the pool, not the sales page.
Run the same target on both pools
Use the same target, country, client, retry limit, and time window. Change only the pool. Stop after enough requests to see the block pattern. A tiny test beats a huge promise.
- Kept rows
- 403 or captcha rate
- Median response time
- GB used
- Retries per success
Default decision
Start with volume residential for public, forgiving targets. Move to premium only when the same test shows fewer blocks, fewer retries, or better kept-result cost.
A simple bakeoff worksheet
Run both pools through the same target. Keep request count, time window, country, headers, and retry policy identical. Then calculate cost per kept result.
cost_per_kept_result = gb_used * price_per_gb / kept_resultsIf premium halves the retry rate, it can win even with a higher per-GB price. If volume already keeps the data with low retries, premium is just a more expensive habit.
| Metric | Why it matters |
|---|---|
| Kept results | Measures useful output. |
| GB used | Measures real cost. |
| Retry rate | Shows hidden waste. |
| Block rate | Shows target fit. |
A common false win
Volume residential often looks cheaper in a short test because the first few requests work. The failure appears later when concurrency rises, retries start, and blocked pages get downloaded repeatedly. Premium often looks too expensive until you measure the same thing under load.
Run the bakeoff at the concurrency you plan to use. A pool that works at one worker can fail at twenty. Cost per kept result should include the load level, not just the first successful request.
Decision rule
Do not run the bakeoff on your easiest target. Use the target that decides the buying decision. A premium pool that only beats volume on a target you barely use is not worth changing the whole setup. The winning pool should win where the money actually gets spent. Recheck after target rules change. Old scrape results age badly. Re-run after major site changes. Keep both samples. Track failures separately.
Residential pool FAQ
When is premium worth it? When it lowers block rate or retry count enough to reduce cost per kept result.
When is volume enough? When the target is public, forgiving, and cheap to retry.
What metric wins? Cost per kept result. Not sticker price. Not pool size.