Country, State, and City Targeting Explained

Geo-targeting is the ability to choose which location your request appears to come from. For a lot of work it is the entire point: a price, a search result or an ad slot can differ depending on where the visitor is, so you need an IP in the market you are checking.

The concept is simple. The execution has some rough edges worth knowing about before you build on it.

How targeting is expressed

With most providers, targeting happens through parameters in the proxy credential rather than through different hosts. A username might combine an account identifier with a country code and a session value:

lb-USERNAME-country-us-session-abc123

Country and session are the two common parameters. Region and city are usually additional qualifiers. The exact syntax is provider-specific, and the important property is that you can change the location per request without changing the endpoint.

This is also where session control lives, which we cover in Understanding Proxy Session IDs.

The accuracy gradient

Here is the honest part: accuracy is not uniform across granularities.

Country-level targeting is the most reliable. Any consumer ISP pool large enough to serve a country will have addresses that genuinely belong to that country, and verification is straightforward.

State or region-level is generally good in large markets with many providers, and less reliable in smaller ones. The pool may not contain enough addresses in a specific region to satisfy demand, and some providers substitute neighbours.

City-level is where expectations most often exceed reality. A pool needs a meaningful number of addresses physically located in a given city, and coverage thins quickly outside major metropolitan areas. A provider may return an address in the same region rather than the same city.

None of this is dishonest by itself. The issue is that a request asking for one city and receiving a neighbouring one fails quietly, and the data you collect is wrong in a way that is hard to notice.

Why IP location is fuzzy in the first place

IP geolocation is an inference, not a fact. Address databases map ranges to locations, but ranges get reassigned, addresses move between providers, and consumer connections are not always located where the registration says. Even the best databases are approximations, and they disagree with each other at the city level.

That is a reason to verify rather than assume, especially for city targeting, and it is why we ship IP lookup as a free tool: it tells you what an address resolves to, so you can inspect the reality rather than the label.

Verifying targeting before you scale

The workflow is short:

Request a sample of endpoints with the targeting you plan to use.
For each, fetch a page that echoes the exit IP.
Look up each exit IP to see its country and city.
Count how many landed in the expected place.

If city matches are inconsistent, either widen to state level or build tolerance into your analysis. Do not build a pipeline that treats a targeted address as authoritative without this check.

The proxy checker covers steps two and three in one call, reporting the exit IP and latency, and IP lookup gives the location detail.

What targeting does not do

Two limits are worth stating.

It does not change language or personalisation perfectly. A local IP gets you a local network identity. It does not set your browser's Accept-Language, change your timezone, or alter a logged-in profile. For a realistic local view you may need to align those too, which is the subject of Geo-Targeted SERP Testing.

It does not guarantee the content differs. Plenty of sites serve identical content everywhere. Confirm that location actually changes the answer before building a location-dependent pipeline, or you may be paying for targeting that adds nothing.

Use cases where targeting is essential

Regional price and availability checks, covered in Residential Proxies for Price Monitoring.
Rank tracking from a local vantage point, in SERP Tracking at Scale.
Ad verification by geography, in Ad Verification with Proxies.
Fare comparison by point of sale, in Residential Proxies for Travel Fare Aggregation.

The feature overview is at geo-targeting.

Getting it right

Treat targeting as a measurement problem before a configuration one. Decide the granularity your data actually requires, verify that the addresses you receive land there, and record the location you observed rather than the location you requested. That single habit prevents a lot of quietly incorrect analysis.

LightningBytes supports country, state and city targeting on the residential and mobile lines, with per-country coverage listed on each page.