Google provides geolocation information via the
Geo object, common to both
the OpenRTB and Google protocols. This document describes higher-level details
of how Google populates geolocation in bid requests and suggests best practices
for its use.
How the Geo object is populated
Google only sources device locations from IP geolocation, never from GPS
or other sources. While the OpenRTB specification supports separate
geolocations for the user (e.g. home address) and the device (where the device
is when the ad is being placed), Google only supports the latter. Consequently,
the Google protocol contains only one
Geo object, in
BidRequest.geo; and for
OpenRTB, Google will only populate the
Geo object fields are populated identically for both protocols. The following
fields exist only in the OpenRTB variant of the
Geo object, they are never
populated by Google in either protocol:
ipservice. Most of the unsupported fields above are related to alternative
In order to protect user privacy, Google only provides a coarse geolocation that is shared by a sufficiently large number of users, generalizing detected location as necessary.
Geo object supports two separate representations of location – civil
location and geographical coordinates.
Civil locations are represented by the following fields:
Geographical coordinates are represented by the following fields:
In both Google and OpenRTB protocols, both representations contain the same
location and accuracy. For example, if a bid request populates the
city-level precision, then the
lon fields will contain the latitude
and longitude of the centerpoint of the identified city, and
accuracy will be
the radius of a circle with the same area as that city. Google also limits the
precision of the
lon fields to 0.01 degrees.
Best practices for geolocation targeting
For bidders that need custom geolocation data we recommend using the approximate
accuracy fields for performing spatial geolocation lookups.
We don't recommend the use of the
ip field for geolocation, since Google only
shares the IP address in truncated form; the use of truncated IP addresses for
geolocation can result in somewhat inaccurate results.
The Geo Table
geo_criteria_id field represents geolocation as a numeric identifier,
which is mapped to a geolocation in geo-table.csv available for download at
Reference tables section of the Protos & Reference Data page. This field and
the corresponding table are now deprecated–you can use the
Geo field described
above to get similar geolocation information. As an example, if a bid request
Geo populated with city-level precision, then the
contain the code for the corresponding city. You can use that ID to locate a
record in the geo table.
- Criteria ID
- Unique and persistent assigned ID. In the API, these criteria are of type
- Best available English name of the geo target.
- Canonical Name
- The constructed fully qualified English name consisting of the target's own name, and that of its parent and country. This field is meant only for disambiguating similar target names--it's not supported in LocationCriterionService (use location names or criteria IDs instead).
- Parent ID
- The criteria ID of a parent. This field is included for legacy support, and the IDs may not be consistent across datasets. Canonical names is the preferred method of constructing hierarchies.
- Region Code
- The ISO 3166-2 region code for the state or province target, if one exists.
- Country Code
- The ISO-3166-1 alpha-2 country code that is associated with the target.
- Target Type
- Autonomous Community
- City Region
- Congressional District
- DMA region
- National Park
- Postal Code
- TV Region
- Union Territory
Due to advertising regulations and laws of the People's Republic of China, you may be asked to provide certificates and licenses if you are advertising certain categories of products in China. You do not need to submit certificates until after your account has been activated. Once your account is active, you will be provided with information on how to submit certificates to Google.