Using MaxMind’s accuracy radius
As more of the world takes a privacy-focused approach to web use, IP geolocation fills an essential niche in customer analytics. It’s fast, it’s non-invasive and doesn’t require the customer to opt-in, and it works for most IP addresses. If you want to get the most value out of IP geolocation, however, you have to understand how to use the data effectively.
The mappable geolocation area data included in MaxMind’s geolocation products and services is composed of geolocation coordinates (latitude and longitude), and an accuracy radius (in kilometers). This mappable area is our most precise geolocation data because, as discussed in our previous post on accuracy, IP geolocation isn’t precise enough to put a pin on a map . Some geolocation technology (for example, GPS) may return a point, or a point with such a small accuracy radius that it can easily be treated as a point, but IP geolocation is different.
When doing data analysis and building applications, working with geolocation area data is different than working with a geolocation point. If we assume we are locating IP addresses down to a narrow, fixed location, when in fact we are locating them down to a probable area of 80 square kilometers or more, we may build applications that don’t perform their intended task.
This post will look at how to use MaxMind’s mappable IP geolocation area alongside other tools by looking at an example use case. Below, you will find:
- an overview of our example use case,
- a discussion of other tools that should be used alongside IP geolocation lookups,
- and how to work with MaxMind’s mappable IP geolocation area (accuracy radius) instead of a geolocation point.
This guide will cover how data may be used, but will not cover a technical integration in any specific programming language. For help with integration, see the resources on our developer portal.
For our example, we’ll consider a simple localization use case.
Example use case
We would like to make an application for a chain store with many retail branches across the country. The store wants to provide its customers with in-store shopping, curbside pickup, and delivery options. The customer is likely to constrain their choices based on their location, perhaps considering curbside pickup or in-store shopping for nearby locations. Other customers may prefer delivery in all cases. To make matters more complicated, different products are only available in certain locations, or are only available to ship. You want to build an application that will make it easy for customers to select the best localization options as quickly as possible, ensuring that they don’t search for products that aren’t available to them.
One part of this application will use a customer’s geolocation to suggest the best local branch(es) to a customer, and automatically filter their search results based on that assumption.
Our application should leverage available customer preference and geolocation data to give the prospective customer the best possible experience in the least intrusive way.
IP geolocation is one among many tools
When we say “in the least intrusive way,” that’s because IP geolocation may be only one of many sources of information we could use to deliver localized content to our prospective customer.
Before doing an IP geolocation look up, for example, we might see if we have any kind of record of dealing with this customer, for example, a cookie from a previous session in which the customer identified their localization preferences. If you can tie the browser or IP address to a previous record in your own database, you may not need to do IP geolocation at all.
If you try IP geolocation and it doesn’t yield the best results, you might try opt-in HTML5 geolocation, or prompting customers to identify their localization preferences manually.
Among these different options, IP geolocation fills a valuable niche. It’s non-intrusive, it’s fast, it works for many IP addresses, and it doesn’t require the customer to opt-in. This means you don’t have to interrupt the user experience.
Using mappable areas
One of the most important things to understand about MaxMind’s geolocation data when building applications is that it returns a mappable area, not a point. It’s true that MaxMind products return a point, defined by latitude and longitude, for IP addresses, but the point is only half of the data. We also return an accuracy radius. Together, these three data points define a mappable circle in which we think the IP address is likely to be located.
Why does this matter? Let’s look at our use case to see how we would solve the problem of localizing a customer’s content using a mappable point, versus the mappable areas in MaxMind products and services.
Treating geolocation like a point
MaxMind data returns a mappable area, but if we forget about that or treat the data as if it’s a point anyway, we may not always get the best results.
When a new prospective customer visits our website, we check their IP geolocation. The GeoIP City Plus web service returns the geolocation coordinates 42.1293, -72.7522.
It also returns an accuracy radius of 50 kilometers, but we may not pay too much attention to that if we are thinking about the data as a point. We might assume that the customer is in a population center near the geographical coordinates, probably Springfield. We don’t really know where the customer is, but maybe this is what we expect:
Using these assumptions, we build our application to select the closest store to the geolocation coordinates, which in this case is obviously the Chicopee store.
Working with mappable areas instead of points
As was discussed above, GeoIP location data is not a point, but a mappable area, a circle on the globe. We believe that the IP address is more likely than not to be inside of this mappable area. However, it is no more likely to be at the center of the mappable area (the point on the map), than it is to be anywhere else within the circle.
If we build our application with the accuracy radius in mind from the beginning, we’ll have something that looks like this:
Using the latitude, longitude, and accuracy radius, we now have a better sense of where this prospective customer might be. Instead of one specific store, we may need to recommend several. We could build our application to give prospective customers a choice between a select number of stores, cutting down the time it takes to get the right localization.
We might be tempted to simply include all stores that are within the circle, offering the options of Hartford and Chicopee. In most cases, this would work out well:
However, we should remember that the mappable area represents the area in which we believe the IP address is likely to be located. We don’t know that the IP address is more likely to be at the center of this circle than any other place inside of it. For example:
The customer may be located near the perimeter of the circle. The circle is also only the area in which we believe the IP address is likely to be, so the customer may be outside of the circle as well. Understanding this, we probably want to build our application to include stores that are within an area similar to the one provided by GeoIP, but with a larger radius to account for the possibility that an IP address is near the perimeter or outside of the mappable area.
Learn more about IP geolocation
This guide has been provided as a basic overview of how and why to use mappable geolocation areas rather than geolocation points in your applications. We discussed a simple use case of localizing the online storefront for a brick and mortar chain based on the prospective customer’s geolocation, but treating IP geolocation as an area rather than a point has implications for many other applications.
You can learn more about IP geolocation by reading: