A low proxy rate can still produce an expensive page. Retries and large responses add traffic, and some HTTP-successful requests fail the validator that determines whether the result is usable. Compare the billed traffic with the number of validated jobs.
Define the unit and accounting boundary
A successful page is a logical job that passed a validator you declared before the run. The validator might require the expected record set, a complete document, or another bounded application-level assertion. It should describe the result you can use.
RFC 9110 (opens in a new tab) says a 200 response means the request succeeded at the HTTP layer, but that status cannot validate the returned application content. A successful CONNECT has a narrower meaning: it establishes a tunnel rather than returning representation content. A 200 that fails the workload validator still contributes traffic and cost, but it does not increase the validated-job count. That is also why proxy success-rate numbers often disagree.
Calculate one observed run
The worksheet starts empty. Enter aggregate values from one isolated run, or load the fabricated example to check the arithmetic. It makes no requests, and every value stays in the current browser tab.
Cost per validated job
Enter values from one observed run to compare provider-metered traffic with the results your validator accepted.
Values stay in this tab and are not stored or transmitted. Use aggregate counts only. Keep credentials, proxy URLs, target names, raw IPs, and customer data out of the worksheet.
EMPTY WORKSHEETEnter one run or load the example to inspect the arithmetic.
Worksheet is empty.
Start with one observed run. Enter aggregate values above or load the fabricated example.
proxy cost per validated job = (price per GB × metered MB ÷ 1000) ÷ validated jobsUses decimal GB. Confirm the provider's billing convention.
| Input | Definition | Boundary |
|---|---|---|
| p | Effective dollars per decimal GB | Same product and billing period |
| J | Eligible logical page jobs | Count before the first attempt |
| A | Physical attempts | First attempts and retry attempts |
| S | Jobs whose validator passed | Within the fixed retry budget |
| T | Provider-metered MB | All attempts in the isolated window |
| R | Provider-metered retry MB, optional | Only attempt_index greater than 1 |
| O | Other attributable cost, optional | Compute or another assigned run cost |
- Input
- p
- Definition
- Effective dollars per decimal GB
- Boundary
- Same product and billing period
- Input
- J
- Definition
- Eligible logical page jobs
- Boundary
- Count before the first attempt
- Input
- A
- Definition
- Physical attempts
- Boundary
- First attempts and retry attempts
- Input
- S
- Definition
- Jobs whose validator passed
- Boundary
- Within the fixed retry budget
- Input
- T
- Definition
- Provider-metered MB
- Boundary
- All attempts in the isolated window
- Input
- R
- Definition
- Provider-metered retry MB, optional
- Boundary
- Only attempt_index greater than 1
- Input
- O
- Definition
- Other attributable cost, optional
- Boundary
- Compute or another assigned run cost
This worksheet uses decimal 1 GB = 1000 MB. Confirm the provider's billing convention before using the result as an invoice estimate. The effective price p should come from money and traffic that belong together: divide actual product spend by provider-metered GB for the same period. If several workloads share the plan, allocate spend using this workload's share of period traffic and document that allocation.
Retry traffic R includes traffic from physical attempts after the first attempt for each job. A failed first attempt with no retry is still a failure, but it is not retry traffic. Retry traffic is a subset already included in total traffic T, and retry cost is a subset already included in proxy cost, so neither should be added again. R must use the same accounting basis as T. If provider records do not attribute traffic to attempts, label R as allocated or estimated and document the method.
The fabricated example contains 10 jobs, 13 physical attempts, 8 validated jobs, 250 MB of metered traffic, 60 MB assigned to retries, a $4 effective rate, and $1 of other attributable cost. It produces an 80% validated-job rate, 1.625 attempts per validated job, 31.25 MB per validated job, $0.125 of proxy cost per validated job, and $0.25 included cost per validated job.
Use the billing meter in a matched run
Browser and command-line counters are useful diagnostics. Chrome DevTools Protocol reports encodedDataLength as the total bytes received for a request in its Network.loadingFinished event (opens in a new tab). cURL exposes separate size_download and size_header fields through --write-out (opens in a new tab). Those counters help explain the client run.
For T, use the usage record your contract treats as billable. As one concrete example, Bright Data documents a residential-zone Statistics view (opens in a new tab) that reports current bandwidth in GB and bills that network by bandwidth. Your provider and product may expose a different meter. Do not quietly substitute browser bytes for provider-metered bytes and call the result an invoice estimate.
- Use the same runner, browser build, proxy protocol, and controlled or explicitly authorized workload.
- Hold region, concurrency, session policy, timeout, retry budget, and stop condition constant.
- Control cache and service-worker state so one run does not inherit a warmer client than the other.
- Isolate provider usage with a zone, sub-user, or clean time window so unrelated account traffic does not enter T.
- Keep credentials, proxy URLs, raw IPs, customer identifiers, and sensitive request data local.
If you need a runnable protocol, start with the 30-minute workload benchmark. It defines the frozen workload before you spend a full trial budget. Use the latency decomposition guide when duration is the result that changed.
If product architecture or session behavior is part of the purchase decision, compare the exact SKUs with the residential-versus-ISP browser automation guide.
Compare the results without double counting
| Field | Run A | Run B | Why it stays |
|---|---|---|---|
| Effective $/GB | Your value | Your value | Billing input |
| Validated-job rate, S / J | Your value | Your value | Validator-defined outcome |
| Attempts / validated job, A / S | Your value | Your value | Attempt load per validated job |
| Metered MB / validated job, T / S | Your value | Your value | Traffic efficiency |
| Included cost / validated job | Your value | Your value | Declared included-cost boundary |
- Field
- Effective $/GB
- Run A
- Your value
- Run B
- Your value
- Why it stays
- Billing input
- Field
- Validated-job rate, S / J
- Run A
- Your value
- Run B
- Your value
- Why it stays
- Validator-defined outcome
- Field
- Attempts / validated job, A / S
- Run A
- Your value
- Run B
- Your value
- Why it stays
- Attempt load per validated job
- Field
- Metered MB / validated job, T / S
- Run A
- Your value
- Run B
- Your value
- Why it stays
- Traffic efficiency
- Field
- Included cost / validated job
- Run A
- Your value
- Run B
- Your value
- Why it stays
- Declared included-cost boundary
This sheet describes only the products, routes, validator, workload, and conditions you tested. If any of those boundaries change, you have a new comparison. Optional other attributable cost does not establish a complete cost boundary, so call the result included cost per validated job rather than all-in cost.
What this number can and can't tell you
- A permissive validator can inflate S. Review failed and accepted samples before trusting the unit cost.
- The calculation cannot identify why a job failed. Preserve a separate outcome taxonomy for proxy, HTTP, timeout, and validation failures.
- A short run cannot prove long-term capacity, stability, geography, or performance at another concurrency level.
- Shared fixed fees and tiered commitments need an explicit allocation rule before an included-cost comparison is fair.
Treat the result as one measurement from a single run. Compare it with the current rankings, inspect the underlying reports, and read the methodology before carrying a local result beyond its scope.
Before the next purchase, take one authorized workload, declare its validator, run a fixed number of jobs, and pull the matching provider-metered traffic. Record the declared cost boundary with the result, keep sensitive details local, and follow the responsible-use policy throughout the test.