How to Measure Proxy Cost per Successful Request

Proxy pricing is easy to compare and surprisingly easy to misread. A plan with the lowest price per GB or per IP can become the most expensive option once retries, invalid responses, slow requests, and operator time are counted. The useful business metric is cost per validated successful request.

Define success before measuring cost

A transport-level success is not always a business success. A request should count only when it meets the conditions required by the workload. Define these conditions before a test begins:

• the connection completes without a proxy or network error;
• the response status is acceptable for the task;
• the returned page or API payload contains the expected fields;
• the data is fresh, complete, and passes validation;
• latency stays within the operational limit;
• the request follows the target site's terms, access controls, and applicable law.

For example, an HTTP 200 response containing a block page should not be counted as a usable result. Likewise, a fast response with missing product data is not a successful collection event.

Use the complete formula

Start with this operating formula:

Cost per successful request = total workload cost / validated successful requests

Total workload cost should include more than the proxy invoice:

1. proxy traffic, IP, port, or subscription fees;
2. bandwidth consumed by retries and failed sessions;
3. compute time for requests, parsing, and validation;
4. storage and observability costs;
5. engineering or operator time spent handling failures;
6. wasted sessions that cannot complete the intended workflow.

If a test costs $120 in proxy usage, $30 in compute, and $50 in operations, and produces 8,000 validated results, the real cost is $0.025 per successful request. A cheaper plan that produces only 5,000 valid results from the same workload would cost $0.040 per success.

Track the request funnel

Record the workload as a funnel instead of a single success percentage:

• attempted requests: every request sent;
• transport successes: connections that returned a response;
• accepted responses: responses with an expected status and content type;
• validated results: records that passed content and freshness checks;
• usable outcomes: results delivered to the downstream system without manual repair.

This separation exposes where money is lost. A low transport success rate may point to connectivity or capacity. A large gap between accepted responses and validated results may indicate block pages, inconsistent content, or poor targeting. A gap at the final stage often reveals parsing or data-quality problems unrelated to the proxy itself.

Run a fair comparison

Test competing plans with the same target set, geography, concurrency, timeout, retry policy, session behavior, and validation rules. Use a representative sample that includes normal and peak periods. Randomize the order of requests so one provider does not receive only the easiest targets.

Measure at least:

• validated success rate;
• median and 95th-percentile latency;
• bytes transferred per usable result;
• retry count per usable result;
• error and block-page categories;
• time spent on manual investigation;
• cost per successful request by country and target type.

Do not let aggressive retries hide a weak first-attempt success rate. Report both first-attempt performance and final performance after permitted retries.

Segment before drawing conclusions

An overall average can conceal expensive failure pockets. Break results down by:

• destination country or region;
• target domain and request type;
• static versus rotating sessions;
• authenticated versus public endpoints;
• time of day and concurrency band;
• page size and response format.

A provider may be efficient for lightweight API requests but costly for large pages. Another may perform well in North America and poorly in a specific APAC market. Route workloads according to measured strengths rather than choosing one universal winner.

Control retries and session waste

Retries are necessary for transient failures, but unlimited retries distort both cost and reliability. Set a small retry budget, use backoff, and retry only errors that are genuinely temporary. Preserve a session when the workflow depends on continuity; rotate only when the use case and target rules permit it.

Never treat CAPTCHA challenges as something to bypass. Record them as a separate outcome, reduce unnecessary request pressure, and review whether the workflow is appropriate and authorized.

Practical evaluation checklist

• Write the definition of a validated success.
• Fix the same test conditions for every plan.
• Tag every attempt with provider, route, region, target, and outcome.
• Separate first-attempt results from retried results.
• Include compute, bandwidth, and human handling costs.
• Review performance by segment, not only the global average.
• Repeat the test at different times before committing volume.
• Keep logs free of credentials and unnecessary personal data.

Frequently asked questions

Is price per GB still useful?

Yes, but only as an input. It helps forecast the invoice, while cost per successful request shows whether the purchased traffic produces usable business outcomes.

How large should a test be?

Use enough requests to represent the real mix of countries, targets, page sizes, and peak periods. A small uniform sample can rank providers incorrectly.

Should latency be included in cost?

Yes. Slow responses consume compute capacity and can reduce throughput. Track latency directly and convert additional runtime into compute cost when comparing plans.

Can the cheapest provider still win?

Absolutely. The point is not to prefer a higher list price. The winning option is the one that delivers the lowest compliant cost for a validated outcome at the required quality and scale.

Make the metric operational

Add cost per successful request to weekly proxy reporting beside success rate and latency. Set alerts when the metric rises by country, target, or route. Re-test after major workload changes because page size, validation rules, and concurrency can alter the economics.

Teams evaluating residential proxy capacity can review 98IP's residential proxy options and apply the same controlled benchmark before scaling. Use proxies only for authorized, lawful workflows and minimize the data retained in logs.