Table of Contents
Have you ever needed to find out where a site visitor physically was for something beyond analytics? I’m talking about things like finding your user on a map or locations of Store X within 50 miles of the user’s current location. Well, I have, and I’ve found there’s not really one solution that fits all users. Sometimes I find myself having to mix methods to provide the best overall user experience and/or changing up my execution depending on my needs.
For the most part you can break it down to three questions:
- Am I using this on mobile? (Go HTML5)
- Do I want to spend money? (If No: Go Google.load() with backup)
- Do I need to process this data at a later time (batch processing) or don’t want to rely on outside services? (Go Local Database)
One note about mobile: Most of the services below will look up the IP to the address of who’s registered it (the ISP) instead of where it is being served from. The best example is using a Local Database with my phone; it claims that I’m in Alabama when I’m really in Florida. It turns out the IP address is registered to some place in Alabama.
Local databases do have a lot to offer if you are willing to invest both time and money. I tend to use this type of service when I need to do back end processing on the IP addresses. It’s perfectly fine to use this for real time IP address geolocation lookups, but there are other options that are cheaper and easier if that is all you are using it for. If you are using this method for mobile, I would recommend that the finest resolution you can trust is Country.
This method requires you purchasing a database dump or CSV file and then importing it to your local database server. The company you are purchasing from will usually provide an API of how to pull the data from your database and or do special conversions. Every few months or so the company will email you to notify you there is an update. At this point you’ll need to go through and repeat the process to update your database. If this paragraph scares you, then please don’t go with this method.
Some providers will also provide you with binary files to avoid using a local database. I usually skip this method since having hundreds of thousands users hitting my server in a day all read from a series of files on my file system scares me.
HTML5 is now really a conglomerate of web based technologies that are supposed to make our lives easier. The geolocation API is one of those technologies.
GPS is the reason this method truly shines in mobile. Most phones will allow the geolocation API pull directly from GPS and then fall back to tower triangulation. Either way, you get a fairly accurate location. Do keep in mind, though, that this technology only provides latitude and longitude. You would have to use a separate service to find out what State/County/Country the user is located in.
The only big downside I see is on most phones/browsers it pops down a dialog that asks the user if they want to divulge their location. This sometimes runs into issues since users can just hit “no”. It’s also not a great user experience since now they have to hit yet another button just to use your site.
I enjoy using this method on desktop based websites since I already have to use a library like jQuery. I just tell it to load jQuery from google.load() and I happen to get the location data tacked on as part of an object. This provides a good user experience since they don’t have to click on anything and a good experience for my server since I don’t have to do yet another request to my server (or anybody’s server for that matter).
This method does have one huge drawback, you can’t trust it to work reliably. On cell phones if the object is empty (aka, it didn’t work), I use the HTML5 method to I cover my bases and provide a good all around user experience. On the desktop if the object is empty, I fall back to using a Local Database call.
Note: I have tested this method on multiple phones with mixed results. You can’t trust that this will work on ALL phones with ALL versions.
Please remember that Geographical Information Systems are just large databases of rather poor data created by humans. There will be errors, omissions and oddities no matter which method you use. Even if you somehow manage to use all the methods listed above I couldn’t guarantee 100% accuracy or even 100% results. Write your code to fail gracefully and give your users options to work around these issues when you can.