Country, State, City or ZIP? Test Residential Proxy Geo Granularity Before You Buy
More precise targeting is not automatically a better purchase. Country selection may be enough for language, currency and market-availability checks. State or region targeting can support jurisdiction-specific testing. City targeting may help metro-level quality assurance. Postal or ZIP targeting is the narrowest option, but it should be treated as an approximate network classification—not a street, household or person.

The right question is not “Does the provider offer city or ZIP targeting?” It is “For my authorized workload, how often does the requested granularity produce a usable exit, a credible location match, a stable session and the expected destination behavior at an acceptable cost?” This guide turns that question into a repeatable buying test.
Separate four measurements
A single “location matched” field is not enough. Record four distinct observations for every test request:
- Requested selector: the country, state or region, city, or postal value sent to the proxy service.
- Provider-reported result: the location, ASN and session metadata returned by the provider, when available.
- Independent classification: the country, subdivision, city, postal result, confidence and accuracy radius from independent IP geolocation data.
- Destination outcome: the language, currency, catalog, regional page, availability or other behavior actually observed at the authorized destination.
These measurements answer different questions. A provider can accept a city selector while independent data resolves only to the surrounding region. Two geolocation databases may disagree. A destination may use account history, cookies, DNS, device signals or commercial rules in addition to IP location. None of those results alone proves fraud or success.
Choose the minimum useful level
Start with the least granular level that can answer the business question.
| Level | Suitable authorized uses | Main limitation |
|---|---|---|
| Country | language, currency, national catalog and broad availability checks | hides regional differences |
| State or region | regional offers, tax display, state-level compliance QA | subdivision data may be missing or inconsistent |
| City | metro-level delivery, search-result and localization QA | city labels can be approximate and inventory may be thin |
| Postal or ZIP | tightly scoped local experience checks | not a household location; codes may be partial or inferred |
Do not buy postal targeting merely because it sounds more precise. If the destination changes only at country level, narrower inventory can increase cost and latency without improving the outcome.
Build a controlled acceptance matrix
Select a small set of markets that represent the production workload. Include one high-volume market, one market where regional accuracy matters and one market where granular inventory may be scarce. Then test country, region, city and postal selectors as separate cohorts.
Keep the provider, plan, protocol, destination, request payload, test window, session policy, concurrency and retry policy constant. For each target, sample multiple independent exits across several time windows. A single successful IP proves availability once; it does not prove dependable capacity.
Capture at least:
- selector accepted or rejected;
- connection success and time to first byte;
- provider-reported country, subdivision, city, postal code and ASN;
- independent country, subdivision, city and postal classifications;
- confidence value, accuracy radius and missing fields where supplied;
- destination-observed language, currency, catalog or eligibility result;
- unique exits, unique prefixes and ASN diversity;
- session stability and unexpected rotation;
- retry count, bytes transferred and cost per valid result.
Use the proxy location accuracy testing guide for the baseline measurement design and the ASN targeting test when network ownership is part of the requirement.
Treat confidence and radius as data
IP geolocation is an estimate. Country results are generally more dependable than state or city results, and granular fields may be absent. Some databases attach a confidence score and an accuracy radius to a location. Preserve those values rather than flattening the answer to a binary match.
For example, a city label with a wide accuracy radius is different from a high-confidence city result with a narrow radius. A blank city or postal field is not automatically a defect: it can be a more honest result than false precision. Define in advance whether a missing granular field is acceptable, requires fallback or invalidates the sample.
Never reinterpret map coordinates as a precise endpoint. They normally represent an area associated with the network, not the street or household using the IP.
Test fallback behavior explicitly
Scarce city or postal inventory creates an important failure-mode question: what happens when the requested target is unavailable?
Require one of two safe behaviors:
- return a clear “no matching exit” result; or
- broaden the target only when the application explicitly authorizes a documented fallback.
Silent broadening is dangerous. A request for one city that quietly receives an exit elsewhere in the country can pass connectivity checks while corrupting market-research or verification results. A direct connection that bypasses the proxy is never a valid fallback.
Test unavailable and deliberately invalid selectors. Confirm that errors are bounded, retries stop and logs retain the requested and delivered levels. The retry amplification guide helps prevent thin inventory from becoming a retry storm.
Evaluate capacity, sessions and cost together
Granular targeting often reduces the eligible pool. That can increase exit reuse, ASN concentration, queue time and rotation pressure. Measure quality under the intended concurrency rather than only with one serial request.
For sticky workflows, test whether the selected area remains consistent for the full required session. An IP change within the same city may be acceptable for one workload and invalid for another. Use the session stickiness test to separate location consistency from exact-IP persistence.
Calculate cost per valid business result, not cost per request:
effective cost = proxy cost + retry traffic + failed-work cost + validation cost
cost per valid result = effective cost / accepted destination outcomes
Compare the incremental cost of each targeting level with the improvement it produces. The bandwidth cost estimation guide provides a reusable model for traffic-based plans.
Define pass criteria before the trial
Set thresholds from the workload, not from a vendor claim. A useful scorecard includes:
- minimum connection-success rate;
- minimum country and subdivision match rates;
- required city or postal match rate, including the allowed confidence or radius;
- minimum rate of correct destination outcomes;
- maximum p95 latency and retry rate;
- minimum pool diversity at production concurrency;
- maximum session-location drift;
- maximum cost per valid result;
- zero silent geographic or direct fallback.
Report a confidence interval or at least the sample size beside every percentage. Small samples make rare inventory look more reliable than it is.
Pre-purchase checklist
- Write the destination behavior that the location must change or verify.
- Choose the least granular selector that can test that behavior.
- Test representative markets, including a scarce-inventory case.
- Keep workload and network variables constant across cohorts.
- Store requested, reported, independently classified and observed results separately.
- Preserve confidence, radius and missing-field information.
- Test invalid targets, exhaustion, retries and explicit fallback.
- Measure diversity, concurrency, sticky-session behavior and effective cost.
- Reject silent broadening and direct bypass.
- Re-test periodically because IP allocations and geolocation data change.
FAQ
Does ZIP targeting mean the exit is inside that exact ZIP code?
Not necessarily. Postal results can be partial, approximate or inferred from network data. Treat them as a testable classification with known uncertainty, never as proof of a physical address.
Which database should be the source of truth?
No single database is universal. If granular location is important, compare at least two independent views where practical and give the destination outcome its own field. Document disagreements instead of choosing the most favorable answer after the test.
How many exits should I sample?
Enough to cover multiple independent exits, time windows and expected concurrency for every target. Record sample size and uncertainty. Increase the sample when a decision carries more cost or operational risk.
Can I broaden from city to country when inventory runs out?
Only if the application explicitly permits that fallback and labels the result. Otherwise fail clearly. Silent broadening makes location-sensitive datasets unreliable.
Compliance and privacy
Run tests only against systems you own or are authorized to access. Respect terms, robots guidance, rate limits, privacy obligations and regional law. Minimize collected data and never use IP geolocation to infer a household, street address, sensitive trait or individual identity. Geo targeting is a routing and quality-assurance control, not a tool for evading access rules or misrepresenting a person.
Related Recommendations
- How to Audit ASN and Prefix Concentration Before Buying a Proxy Pool
- How to Test Proxy Keep-Alive Without Breaking IP Rotation
- How to Decompose Proxy Latency Before You Buy a Faster Plan
- How to Test NO_PROXY Rules Before Traffic Bypasses Your Proxy
- Residential Proxy Session Stickiness Test: Measure Stability Before You Buy
- How to Design Proxy Timeout Budgets for Reliable Automation
- How to Test a Proxy for DNS Leaks Before You Buy
- Sticky vs Rotating Proxy Sessions: A Practical Selection and Testing Guide
- How to Switch Proxy Providers Without Breaking Production
- Is the Proxy Failing—or Is the Target Throttling You? A Control-Route Test Plan