IP location services
IP location services name the vendor or database that turned an IP address into a location. OpenRTB 2.x sends the value in Geo.ipservice on device.geo and user.geo, and it is meaningful only when Geo.type is 2 (IP address). Buyers use it to judge how far to trust city and postal-level data, since providers differ in accuracy.
Values
| Value | Name | What it means |
|---|---|---|
1 | ip2location | The IP2Location database. |
2 | Neustar (Quova) | Neustar's IP geolocation service, which grew out of the Quova product. |
3 | MaxMind | MaxMind's GeoIP databases and web services. |
4 | NetAcuity (Digital Element) | Digital Element's NetAcuity service. |
511 | 51Degrees (High Confidence) | A 51Degrees lookup that reported a high confidence level for the result. |
512 | 51Degrees (Medium Confidence) | A 51Degrees lookup that reported a medium confidence level, so city and postal data deserve less weight. |
Fields that use this list
How to use it
Send ipservice together with Geo.type 2 whenever the location came from an IP lookup, and name the service your own pipeline actually used, not the one the publisher once mentioned. Values 1 to 4 have been in OpenRTB since 2.4. The two 51Degrees values, 511 and 512, were added later and also tell the buyer how confident that lookup was. The list declares no vendor range, so numbers such as 513 are simply undefined. Some contracts fix the provider: rtblint's Vungle Exchange profile requires ipservice 3 when type is 2.
Common mistakes
- Sending
ipservicewithGeo.type1 or 3. The service only applies to IP-derived locations. - Treating 511 and 512 as vendor-specific codes. They are defined values for one vendor at two confidence levels.
- Sending a provider name as a string, such as "maxmind". The field is an integer.
Validation
On OpenRTB 2.6 snapshots, RTBlint reports a value outside this list as openrtb.value.invalid. Paste a request into the tester to check the values you send.
Related lists
All lists are on the enumerated lists index.