AI answers are local. “best dentist near me”, “coffee shop open now”, or “plumber prices” return a different answer in Buffalo than in Brooklyn — because the surface localizes to where the request appears to come from. This guide covers the three independent layers you can stack to control that geography, and how to use them for local rank tracking.

Three layers, from broad to precise

Each layer targets a different mechanism, and they compose. You can use one, two, or all three on the same region object.
1

Country exit — the residential IP's country

country places the capture behind a residential exit IP in that country. This is the only required field in a region object and the coarsest layer.
2

State / city exit — a city-level residential IP

state and city narrow the residential exit to a sub-national region and a city, so the request egresses from an IP that actually resolves to that locality. This applies to every browser-captured surface.
3

Locality — a Google geotarget via uule

location is a Google Ads geotarget canonical name applied as a uule parameter on the four Google surfaces (google_search, google_news, google_ai_overview, google_ai_mode). It pins the answer to one of ~100,000 named localities — cities, ZIPs, boroughs — independent of the exit IP. Names come from Google’s public geotargets list.
These layers are independent. The residential exit (country/state/city) works on every browser-captured surface; the location geotarget only affects the Google surfaces, where it stacks on top of the exit IP. On a non-Google surface, location is simply ignored.

A local rank-tracking request

Combine all three to capture what a searcher in a specific locality sees across the Google surfaces. Because every surface × region pair is a separate child, one request captures the same query across as many localities as you list (up to 10 regions per request).
Each surface × region pair is billed separately. Two surfaces across two localities is four captures. See Credits & billing before fanning out across many localities.

Verifying what was localized

Every Envelope reports what geo was actually applied under provenance.region, so you can trust the result rather than assume it. Alongside the residential requested/effective region keys, two fields cover the location geotarget:
provenance.region.requestedLocation
string | null
The Google geotarget canonical name you asked for (or null when you sent no location).
provenance.region.effectiveLocation
string | null
The name a uule was actually applied for. It is null — paired with a location_not_applied warning — whenever the name could not be encoded, so a wrong locality is never claimed.
Always read effectiveLocation, not your request, when you attribute a result to a locality. If it differs from requestedLocation (or is null), the precise locality was not applied — check for a location_not_applied warning.

Choosing the right layer

Use country (optionally state/city) alone. The residential exit is enough when you care about country- or region-level differences, and it works across every browser-captured surface, not just Google.
Add location with the Google geotarget canonical name for the exact locality. This is the layer that gives you ZIP- and borough-level precision on the Google surfaces, independent of which residential IP the capture egressed from.
Set the residential state/city and the location geotarget together. The IP resolves to the city while the uule pins the Google answer to the named locality — the closest match to what a local searcher actually sees.

Next steps

Regional availability

The full regions array reference — every field, country coverage, and requested-vs-effective semantics.

Output formats

Where provenance.region and the location_not_applied warning live in the Envelope.