Mixing targets in one sheet is how bad decisions start
This run was supposed to settle a simple question before buying more residential traffic. Instead I put eleven different targets in the same sheet. That is already a bad start, but it is also how these decisions usually happen in practice.
The batch had: one supplier API, two public directories, three retail product pages, a travel page, a jobs board, two SERP checks, and one account-adjacent flow that should not have been there. That last one needed a stable exit, so it belonged in a Static ISP test. It skewed the residential numbers and made the residential pool look bad when the real problem was session choice.
The useful comparison is not type against type. It is route behavior against the page that pays the bill: status codes, retries, accepted rows, and billed bytes.
What each proxy type actually is
A datacenter proxy comes from hosting infrastructure. The ASN is a cloud or datacenter provider, so any target that checks ASN will identify it as non-residential immediately. A residential proxy comes from consumer ISP space, so the IP class looks like an ordinary home connection.
That is the entire structural difference. Residential credibility only fixes the IP-class part of a block. It does not fix reused cookies, too many concurrent workers, bad browser state, wrong country settings, or a fingerprint that is already suspicious. Upgrading the pool type without diagnosing the reject reason is how budget disappears.
The columns that matter in a comparison log
| Column | Why it matters |
|---|---|
| Status mix | Separates proxy failures (407) from target blocks (403, 429) from success (200) |
| Challenge rate | CAPTCHA or JS challenge responses count as traffic even when they waste a request |
| Accepted rows | What your parser actually kept — the output the job was for |
| Median latency | Datacenter is typically faster; residential adds ISP hop latency |
| Provider bytes | What the proxy billed — includes redirects, retries, and blocked assets your app never saw |
| Reject reason | If this column is empty, the comparison is incomplete |
mixed-pool test — columns kept per target slice:
status mix, challenge rate, accepted rows, median latency,
provider bytes, reject reason, manual review note
annoying row:
account-adjacent flow was in the batch; should have been Static ISPWhere datacenter held up and where it did not
Datacenter did fine on the supplier API. Faster, cheaper, and no ASN complaint. One public directory blocked hosting IPs immediately — 403 on the first request, consistent across workers. One retail slice returned HTML on the first hit, then gave stale availability data on the next request; the problem was session, not IP class, but it read like a block.
Volume Residential fixed most of the retail failures. Premium Residential improved the accept rate slightly but not enough to justify moving the whole job at $5.00/GB versus $0.89/GB.
retail-slice-7 results:
datacenter: 318 accepted / 510 requests / 0.21 GB provider bytes
volume residential: 462 accepted / 530 requests / 0.29 GB provider bytes
premium residential: 481 accepted / 525 requests / 0.31 GB provider bytes
manual review note:
premium won, but not by enough for this target
rerun with images blocked before changing the pool againThe pricing difference makes this math visible. Volume Residential is $0.89/GB. Premium Residential is $5.00/GB. Datacenter is $0.65/GB. All three are billed per transferred byte, so cost-per-accepted-row uses the same denominator across pools — what changes is how many bytes each pool burns on blocks and retries before a usable row lands. Static ISP is the exception: it is pay-per-IP with unlimited bandwidth, so keep it out of any per-GB comparison.
The provider meter sees more than the app counter
On retail-slice-7, the scraper reported 0.18 GB. The provider log showed 0.29 GB. The gap was redirects, blocked assets, consent pages, and retry loops — traffic that the proxy forwarded but the parser never accepted. That is a normal gap on retail targets. The app counter counts the nice path. The provider meter counts everything.
The Proxynade dashboard network logs show host, outcome, latency, and byte totals per request. Usage logs export as CSV. Running the comparison against provider bytes, not app bytes, is what makes the numbers honest.
How to assign targets to proxy types without overspending
The decision after this run: start with datacenter, move only the failing target slice to Volume Residential, and move only the stubborn slice to Premium Residential. Do not upgrade the entire queue because one target is hard.
| Target type | Starting point | Move when |
|---|---|---|
| Public APIs, news, simple directories | Datacenter | ASN-level deny appears in reject log |
| Retail product pages, travel, marketplaces | Volume Residential | Challenge rate stays high after session fix |
| Geo-sensitive, ad checks, local SERPs | Volume Residential | Accept rate still low after country targeting |
| Stubborn retail, highest-friction targets | Premium Residential | Only after Volume fails on that specific slice |
| Account-adjacent, long-session flows | Static ISP | Do not run these in a rotating pool at all |
If the log cannot say why a row failed, do not upgrade the pool. Fix the log first.
Proxy type comparison FAQ
When should I use datacenter proxies instead of residential? Use datacenter for targets that do not check ASN: public APIs, simple directories, news pages, light price checks, and first-pass parser tests. If the reject reason is 403 or ASN-level deny, move that target slice to residential. Do not move the whole queue.
Why does the provider byte count differ from my app counter? Your app counter records the rows your parser accepted. The provider meter records everything the proxy forwarded: redirects, blocked assets, consent pages, and retry loops. The gap is normal and usually larger than expected on retail targets.
When is Premium Residential worth the price over Volume Residential? Only when Volume Residential still wastes enough rows on a specific target to justify the per-GB difference. At $0.89/GB for Volume and $5.00/GB for Premium, the break-even depends on how many extra retries you are paying for at the lower tier.
Is datacenter billed per GB like residential? Yes. Datacenter is $0.65/GB, billed per transferred byte — the same model as Volume Residential ($0.89/GB) and Premium Residential ($5.00/GB). Static ISP is the one that differs: pay-per-IP with unlimited bandwidth.
What columns matter most when comparing proxy types? Status mix, challenge rate, accepted rows, median latency, provider bytes, and reject reason. If a column is missing, the comparison is incomplete.
Decision checklist
- Record reject reason for every failed row before changing pool type.
- Compare provider bytes, not app bytes.
- Keep account-adjacent flows out of rotating pools.
- Move only the failing target slice, not the whole queue.
- Block images and fonts before concluding that Premium is needed.