The pricing list of a proxy provider is structured in such a way that comparing suppliers seems straightforward: one gigabyte costs $1, while another costs $8 — that's an eightfold difference. In practice, the team that bought a gigabyte for a dollar often ends up paying more for the collected data than the one that paid eight. The reason is not marketing or hidden fees: the price per gigabyte simply is not the unit in which your task is measured. You are not buying traffic — you are buying successfully extracted records, and between these two quantities lies a chain of multipliers that differ for each project.
The bill comes not for what you calculated
A typical scenario: you planned to collect a million product cards, estimated 200 KB per page, calculated 200 GB, and a budget of around $1,500. A month later, your personal account shows 900 GB and a bill three times higher than the estimate. No one deceived you: three things changed that were not included in the calculation.
The gap between the price and the bill always breaks down into the same components. It’s worth analyzing them separately — the formula will come together on its own.
Three multipliers between the price and the bill
1. What the actual page weight is
The estimate of "200 KB" is pulled from thin air and refers to bare HTML. The actual weight depends on how you retrieve the page. The raw HTML response from a modern store is usually hundreds of kilobytes. However, a fully rendered page in a headless browser, with all scripts, fonts, images, and analytics, weighs 2–5 MB. The difference between the two ways of obtaining the same data is an order of magnitude, and it entirely affects your traffic.
Industry calculations typically operate with a range of 1–3 MB for unoptimized scraping and 100–300 KB for optimized scraping. The difference between these two modes is not "a little savings," but a tenfold difference on the same project.
2. What portion of responses is actually usable
The second multiplier is the success rate, the share of requests that returned usable content. A captcha instead of a page, a 403 error, an empty frame without data, a redirect to a placeholder — all of this is paid traffic that yielded no records.
The arithmetic is simple and ruthless: number of requests = needed records ÷ success rate. With a 95% success rate, it takes 1.05 million requests to get a million records. With a 70% success rate, it’s already 1.43 million. With a 60% success rate, it’s 1.67 million. Thus, a drop in success from 95% to 60% adds nearly 60% to the bill, with the price per gigabyte remaining unchanged.
3. Retries, timeouts, and overhead traffic
On top of this, there is the overhead traffic from the wrapper itself. The difference between a mature and a hastily assembled stack is enormous: for well-tuned managed platforms, retries consume about 0.1–3% extra, while for a custom Scrapy pipeline, it’s 5–15%, and this share grows with scale. Aggressive retry logic that hits a blocked domain five times in a row can easily turn these percentages into tens.
A metric that doesn’t lie
Let’s consolidate everything into one figure. You should not count dollars per gigabyte, but rather the cost per thousand successfully extracted records:
- Cost per 1000 records = (average response weight in GB ÷ success rate) × (1 + retry share) × price per GB × 1000
The value of this formula is that it makes incomparable offers comparable. A cheap pool with a ban rate of 40% and an expensive one with a ban rate of 5% finally end up on the same axis. Notably, this metric has also been adopted by providers over the past year: industry materials increasingly refer to "price divided by success rate," rather than just the bare price per gigabyte.
How this looks in dollars
Let’s take a million records, an average page size of 500 KB, and residential traffic at $8/GB — a typical mid-market scenario. We only change the success rate:
- 95% success — 1.05 million requests, about 525 GB, approximately $4,200
- 70% success — 1.43 million requests, about 715 GB, approximately $5,720
- 60% success — 1.67 million requests, about 835 GB, approximately $6,680
The spread is nearly $2,500 at the same price. Now, let’s compare two offers that look like night and day in the pricing list. Provider A: $2/GB, but has a 55% success rate on your target. Provider B: $6/GB with a 92% success rate. With the same 500 KB and a million records, A results in about 910 GB and $1,820, while B results in about 545 GB and $3,270. Here, A is indeed cheaper, and this is an honest result: with a large price gap, low success does not always eat away at the benefit.
But add to A a 15% retry rate against 3% for B, and include headless rendering, which is necessary precisely because the cheap pool often returns a placeholder instead of content — and the page weight for A goes up to 1.5 MB compared to 500 KB for B. Recalculating: A — about 3.1 TB and $6,200, B — about 560 GB and $3,370. The positioning has flipped. This is why the question "who has the cheaper gigabyte" makes no independent sense: the answer depends on your goal, your stack, and your ban rate.
Why scraping APIs are considered differently — and how to compare them
A separate complexity is that part of the market does not sell gigabytes at all. Scraping APIs and web unblockers charge per request, and they price them based on complexity. The price range for 2026 for 1000 pages looks like this:
- Simple HTML: ScrapeOps around $0.19, ScraperAPI around $0.49, Scrape.do around $0.58, ScrapingBee around $0.66, Bright Data around $1.00
- With JS rendering (usually 5 credits instead of one): ScrapeOps around $0.95, Scrape.do around $2.90, ScrapingBee around $3.30, ScraperAPI around $4.90, Bright Data around $5.00
- Sites under anti-bot protection (10–25 credits): ScrapeOps around $1.90, Scrape.do around $4.45, ScraperAPI around $5.96, ScrapingBee around $6.60, Bright Data in the range of $8–15
Note the gap within a single provider: for ScraperAPI, a simple page and a protected page differ by twelve times. The "per request" pricing seems more predictable than gigabytes until the target shifts from the first category to the third — and this happens without your involvement, at the decision of the website owner.
This can be brought to a common axis with the same formula: cost per request ÷ success rate × 1000. After that, the offer of "$3.30 for 1000 JS pages" and the offer of "$6 per gigabyte of residential traffic" can finally be placed side by side. A broader analysis of the approaches themselves — official API, ready dataset, or your own parser — has been discussed separately; here, only their comparability in terms of cost is important.
Measurement in one evening
The formula is useless without your own numbers, and the good news is that obtaining them is a task for a couple of hours. A pilot of 1000 requests to your actual URLs provides everything you need.
- Take a representative sample of targets — not the main page, but those specific cards, categories, and results that you will be collecting in production. Success on the main page predicts nothing.
- Record four counters separately: valid responses with data, HTTP errors, captchas and challenges, "empty two-hundreds" — code 200 without the needed content. The last category is the most treacherous: formally, this is a success, but in fact, it’s paid junk.
- Capture the actual traffic volume from the provider's statistics, not from your estimates. The discrepancy between the estimated and actual page weight is usually the first finding of such a pilot.
- Count retries as a separate line, rather than blending them into the total number of requests.
- Repeat with a second provider on the same day. Success rates fluctuate with the mood of anti-bot systems, and measurements spread over a week cannot be compared.
If the pilot shows a low success rate, don’t rush to change providers: first, it’s worth understanding the reason. An analysis of typical sources of the problem is compiled in the material on how to diagnose a low success rate with proxies, and regular monitoring of the same metrics should be established. Often, the issue lies in headers, timing, or the client's TLS fingerprint, rather than the quality of the IP.
Four levers that move the numbers more than discounts
Once the metric is calculated, it becomes clear where it is most sensitive. A 10% discount on the price is the weakest of the available levers.
Response weight. The quickest win. Collecting only what you need reduces traffic by 2–10 times. If a headless browser is necessary, block images, fonts, media, and third-party scripts at the request interception level — content is not affected, but the volume drops significantly. Enable compression and conditional requests via ETag: a page that hasn’t changed since the last crawl should cost you a 304 response, not a megabyte.
Success rate. Every ten percentage points of success in the range of 60–95% translates to tens of percentage points on the bill. Here, it’s not about money, but engineering: a correct client fingerprint, a reasonable pace, the right type of IP for a specific target.
Mix of proxy types. Routing all traffic through a residential pool is the most common and most expensive mistake. A significant portion of targets can be easily served by data center proxies, which are an order of magnitude cheaper; residential addresses should only be spent on what truly requires them. Routing by target, not by habit, cuts proxy expenses by 60–70%.
Retry discipline. Exponential backoff, a cap on attempts, and avoiding retries on codes that don’t respond to retries. The difference between 3% and 15% overhead traffic is the difference between a neat wrapper and its absence. The practical side of this issue is discussed in the material on optimizing traffic consumption through proxies.
What remains beyond traffic
The complete picture of expenses is broader than the proxy bill, and this should be kept in mind when choosing between "collecting it yourself" and "buying ready-made." For a project of the scale of a million pages per month, industry estimates for a self-hosted solution look like this: residential traffic $500–1500, engineering time $1000–2000, infrastructure $300–500. In total, $2000–4400 per month — and that’s before writing the actual business logic. With an engineer's rate of about $100 per hour, a few days spent fixing broken selectors can cost more than a monthly proxy bill.
This is not an argument against self-collection — it’s an argument for considering engineering hours as a line item in the budget, just like gigabytes. The pricing model should also be chosen consciously: for stable long sessions, payment for a dedicated IP is often more cost-effective than per megabyte.
In short
The price per gigabyte is not the price of data, but the price of one of four multiplicands. Comparing providers based on it is like choosing a car based on the price of a liter of gasoline without asking about fuel consumption. The working unit of comparison is one: how much does it cost to extract a thousand successfully retrieved records on your targets, with your response weight, your success rate, and your retries.
Calculate it in a pilot of a thousand requests before committing to an annual plan. Quite often, it turns out that the cheapest offer in the pricing list costs you more than all the others — and that the largest potential for savings lies not in negotiating discounts, but in a couple of dozen lines of code that disable image loading.
```