Geo.type
Where the location came from, as an integer from the AdCOM Location Types list: 1 GPS or OS location services, 2 IP address lookup, 3 provided by the user, such as registration data. Recommended whenever lat and lon are sent.
Field facts
- Path
device.geo.type,user.geo.type- Object
- Geo
- Type
- integer
- Requirement
- Optional
- Added
- OpenRTB 2.0
- Values
- AdCOM list Location Types
- Spec section
- 3.2.19
How it is used
Buyers price location by its source. A type 1 fix with good accuracy supports proximity targeting, while a type 2 location is usually reliable only to the city or region. OpenRTB 2.0 to 2.2 marked the field recommended outright.
Allowed values
| Value | Meaning |
|---|---|
1 | GPS/Location Services: The device reported its position through the operating system's location services, such as GPS, Wi-Fi or cell positioning. |
2 | IP Address: The location was estimated by looking up the request's IP address in a geolocation database. |
3 | User Provided (e.g., registration data): The user supplied the location, for example a postal code or city entered at registration. |
Example
Where the field sits in a payload, with everything else left out:
{
"id": "req-1",
"device": {
"geo": {
"type": 1
}
}
}Common mistakes
- Labeling IP-derived coordinates as 1 to make inventory look more valuable.
- Sending
latandlonwith notype, which leaves buyers unable to judge precision.
Version history
Added in OpenRTB 2.0, and present in the latest snapshot. The table shows how each version's spec text types the field.
| Versions | Type in the spec | Required | Deprecated |
|---|---|---|---|
| 2.0 to 2.1 | integer | Recommended | No |
| 2.2 | integer IP Lo Ty pr | Recommended | No |
| 2.3 to 2.3.1 | integer | No | No |
| 2.4 | integer | No | No |
| 2.5 | integer | No | No |
| 2.6-202210 to 2.6-202606 | integer | No | No |