How does programmatic geo targeting decide where a user is?
Part of US and Canada targeting
The short answer
Programmatic geo targeting compares the location in each bid request with the campaign's geography. That location comes from the device's IP address, from GPS and other location services when an app has permission, or from details a user supplied. Each source has a different precision, so border areas, VPNs and mobile networks need explicit handling.
Key takeaways
- OpenRTB names three location sources: GPS or location services, IP address, and user provided data such as registration details.
- Location under Device means where the device is now; location under User means a home base, not necessarily current location.
- IP derived location is coarse by design, and no published benchmark gives one accuracy figure for US and Canadian advertising.
- Privacy relays and VPNs present a different address, and a phone's carrier code stays the same when it roams across the border.
- A site list chooses where ads can run; the line item's geography decides who can see them, and an untargeted line bids everywhere.
How do buying platforms decide where a user is?
A buying platform does not locate anyone itself at bid time. It reads what the seller puts in the bid request and applies the campaign's geographic rules to it. IAB Tech Lab's AdCOM (opens in a new tab) lists the options "to indicate how the geographic information was determined" as three values: 1, GPS/Location Services; 2, IP Address; and 3, User Provided (e.g., registration data).
| Location type | Typical origin | Granularity a planner can expect | Main caveat |
|---|---|---|---|
| 1, GPS or location services | An app with location permission, or a page script allowed to use the browser's location interface | From a few meters to about 3 square kilometers, depending on the permission granted | Only present when the user allowed it and the app or page passes it on |
| 2, IP address | A lookup of the connection's address against a geolocation database | Country, then region and city with falling confidence | Reflects the network exit point, which may be a relay, VPN or carrier gateway |
| 3, User provided | Registration or account data, such as a postal code | Whatever the person typed | Describes a declared place, such as a home base, not where the device is now |
Definition
- Device geo and user geo
- In OpenRTB 2.6 a Geo object under Device gives "the location of the device which can also be interpreted as the user's current location," while a Geo object under User gives "the location of the user's home base (i.e., not necessarily their current location)."
A Canadian whose account lists a Toronto postal code may be on holiday in Florida, and one request can carry both facts. Ask the buying team which object its geography setting reads.
What does the bid request carry about location?
The OpenRTB 2.6 specification (opens in a new tab) defines the Geo object field by field. It also sets one rule worth quoting in full: "The lat/lon attributes should only be passed if they conform to the accuracy depicted in the type attribute. For example, the centroid of a geographic region such as postal code should not be passed." The Device object adds the raw inputs: ip, the "IPv4 address closest to device," and ipv6.
| Field | Specification meaning | What it tells a buyer |
|---|---|---|
| type | Source of location data; recommended when passing lat/lon | Which of the three AdCOM sources produced the location |
| lat, lon | Latitude and longitude | A point, valid only if it matches the source's accuracy |
| accuracy | Estimated location accuracy in meters, as reported from the device | How wide the circle around the point really is |
| lastfix | Number of seconds since this geolocation fix was established | How old the point is; the spec warns devices may cache location |
| ipservice | Service or provider used to determine geolocation from IP address | Which lookup produced an IP based location |
| country | Country code using ISO-3166-1-alpha-3 | CAN or USA, not the two letter CA or US |
| region | Region code using ISO-3166-2; 2-letter state code if USA | Province or state, when the seller sends it |
| metro, city, zip | Google metro code, UN/LOCODE city, ZIP or postal code | Finer areas, each only as good as its source |
The spec marks Device geo as recommended, not required, so a request can arrive with no location at all, or with country only.
How accurate is IP based geotargeting?
No published standard gives one accuracy figure for IP geolocation in North American advertising. What the standards do say is that IP location is coarse by design. RFC 8805 (opens in a new tab), the format network operators use to publish where their address blocks are, "intentionally only allows specifying coarse-level location," warns that "Errors and inaccuracies may occur at many levels," and tells consumers to "verify the accuracy of published locality."
The same document deprecates its postal code field, saying "new feeds SHOULD NOT include this field due to the granularity of this information." It also notes that when an operator moves an address block to a new place, services relying on the old location "may begin to suffer degraded performance." Read that as a ranking of confidence: country first, then region and city, with an IP derived postal code weakest.
| Source | What the documentation says | Fit for a border brief |
|---|---|---|
| Android precise location | Usually within about 50 meters, sometimes a few meters or better (Android (opens in a new tab)) | Can separate two sides of a river when fresh and permitted |
| Android approximate location | Accurate to within about 3 square kilometers | May straddle a border crossing or a narrow river |
| Browser location interface | Reports accuracy at a 95% confidence level in meters, with "no guarantee" of the actual location (W3C (opens in a new tab)) | Depends on the accuracy value sent with the point |
| IP geofeed | Coarse level location only; postal codes deprecated (RFC 8805) | Country level evidence; too coarse for a few kilometers |
| Privacy relay address | Represents coarse city level location by default (Apple (opens in a new tab)) | Region kept, exact position hidden |
How do VPNs and mobile networks affect location?
The ip field is the address "closest to device" that the seller sees, which may not be the device's own. A commercial VPN presents the address of its exit server, which can be in another city or another country, so an IP lookup locates the server. Apple's iCloud Private Relay works differently: Apple says its relay address "accurately represents the client's coarse city-level location by default" and that "Private Relay preserves the region the user is in."
Mobile networks add their own wrinkle. OpenRTB's Device object states that mccmnc values "represent the SIM installed on the device and do not change when a device is roaming," and that roaming "may be inferred by a combination of the MCC-MNC, geo, IP and other data signals." A Canadian SIM in Buffalo is still a Canadian carrier code, while its GPS fix is in New York.
Questions for the buying team about edge cases
- The team knows whether its platform reads Device geo, User geo or both for the campaign's geography.
- Requests with no location, or country only, have a stated treatment: excluded, or eligible only for country rules.
- The team knows how the platform treats known VPN, hosting and relay addresses.
- A GPS point is used only with its accuracy and lastfix values, not as a bare pin.
- Location reports show unresolved requests as their own row instead of dropping them.
Which geo settings are still needed after a site list is built?
A site list decides which pages can carry the ad; it says nothing about where the reader is. A Canadian site can have US readers, and the reverse, so every list needs location rules at the line item. Google's Display & Video 360 help on setting targeting (opens in a new tab) is explicit: "if you don't set any geography targeting, your line item will bid on impressions from all geographic locations." The same page says insertion order default targeting passes to new line items but not existing ones.
Five geo settings to confirm once the list is approved
- Set the country on every line item. Include lines created before the defaults changed.
- Add region or postal rules only where the brief needs them. Use province or state when the service area stops at a boundary, and expect coarse sources to blur the edge.
- Exclude what the business cannot serve. Add exclusions for areas just across a border or outside a delivery zone, rather than trusting inclusion alone.
- Match deal geography to line geography. Read the geography on the curated deal or PMP and make sure the line item does not widen or contradict it.
- Agree the location report before launch. Name the location dimension the client will see, and keep unresolved locations visible in it.
Language and country evidence for each site belong to the planning stage, explained in the CrUX popularity rank guide and the US and Canada hub. Location rules belong to delivery.
What does a border brief look like in practice?
Fictional example
Home heating oil delivery in Western New York
An unnamed heating oil supplier delivers to homes in Erie and Niagara counties, New York, and cannot serve Ontario addresses a few kilometers away across the Niagara River. Its agency builds a site list of home maintenance, energy saving and local news publishers, several of which are popular on both sides of the border.
The buyer sets the line items to New York State with the two counties as included regions, and adds an exclusion for Ontario. The supply partner confirms that most requests carry IP based location and some app requests carry GPS with accuracy values. The team agrees that requests with country only stay out of the county lines, and that GPS points without an accuracy value are treated as IP level.
The first location report shows a few impressions mapped to Fort Erie. The buyer traces them to IP lookups near the river and records that for the client. No delivery figures are implied.
How does PlacementGraph carry a brief's geography to the buy?
Frequently asked questions
Does a site list made of Canadian publishers keep ads in Canada?
No. The list limits which sites can carry the ad, and readers of those sites can be anywhere. Country delivery comes from the line item's geography setting, applied to the location in each bid request. A Canadian list with no location rule can serve impressions to US and international readers of those sites.
Is the postal code in a bid request the user's current location?
Not necessarily. Under Device it describes the device's location; under User it describes a home base, which OpenRTB says is not necessarily current location. The postal code may also be typed by the user or derived from an IP lookup, which RFC 8805 treats as too granular to publish.
Why do reports show impressions just across the border from the target area?
A likely cause is a location from a coarse source. An IP lookup or an approximate phone location covering a few square kilometers can place a device on the wrong side of a river or crossing. Check the location type behind those impressions before changing the campaign settings.
How small can a radius around a store usefully be?
Only as small as the signal behind it. Android documents approximate location at about 3 square kilometers and precise location at about 50 meters, and web requests without location permission rely on IP lookups, which are coarser. A radius tighter than the dominant source mostly selects requests that happen to carry GPS.
Sources
- OpenRTB 2.6: Device and Geo objects (opens in a new tab)IAB Tech Lab
- AdCOM 1.0: List of Location Types (opens in a new tab)IAB Tech Lab
- Geolocation (Candidate Recommendation Snapshot, March 2026) (opens in a new tab)W3C
- RFC 8805: A Format for Self-Published IP Geolocation Feeds (opens in a new tab)RFC Editor
- Request location permissions (opens in a new tab)Android Developers
- Prepare your network or web server for iCloud Private Relay (opens in a new tab)Apple Developer
- Set targeting (opens in a new tab)Display & Video 360 Help
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.