Posted on

Why Do Store Locator Plus Search Results Keep Changing?

This is a question that comes up fairly regularly.  In the past few weeks it seems to have become more prevalent and while I do not have empirical data to back up my theory, my guess it that Google Maps API has once again changed their geo-location algorithm.   That is the algorithm they use for Google Maps API requests looking for the latitude and longitude of a given address.

It is important to note that I said “Google Maps API” specifically.   While it is perfectly logical to think that the results you get from a product like Store Locator Plus, which uses the Google Maps API, would yield identical results to the Google Maps website, that is not the case.   In the past year alone I’ve seen at  least a dozen cases where I do an API lookup and get one set of latitude/longitude coordinates yet a visit to yields something similar but different.  Often the locations are within a few-hundred-yards of each other. However a few hundred yards can make a BIG difference when you are searching for specific locations within a city.

The app takes whatever is in the address input field and sends it to Google asking “hey, where is this?”.  Google sends back a lat/long that can be widely variant depending on the input.  Unfortunately a simple string of numbers that an American immediately thinks of as a “zip code” is more ambiguous to the Google server.  That makes for some interesting results.    Setting your default country to “United States” does seem to influence the Google Maps API algorithm, but only marginally.   Maybe there is a way to make that setting “more influential” to the geocoding algorithm.  That is something that is worthy of some extra research.

The way Store Locator Plus works is to take an address that is put into the zip/address field and send it away to Google for a latitude/longitude coordinate.   What happens after that is very dependent on what is returned from Google.      One thing I have learned from the experience is the more detailed the input the more consistent the results.

Here are specific results from extensive customer testing last week:

1508 7th Ave

This is fairly generic, so Google uses an algorithm (which they didn’t share with me) to determine the exact latitude & longitude using their “best guess” option.

The coordinates Google returned on subsequent identical searches:

47.60153687827675, -122.32470975000001
47.602484592904055, -122.32619270000004

It is not a BIG difference in lat/long but it is enough to skew the results on what is closest based on what Google thinks you meant by that address.

1508 7th Ave, Seattle WA

A more specific address begets more consistent results from Google:

47.605118409127265, -122.33055674999997
47.605692672148685, -122.33055674999997
47.605692672148685, -122.33055674999997

More specificity in what is sent to Google means less variance on the output.

1508 7th Ave, Seattle WA 98101

The very specific address yields identical results every time:

47.605692672148685, -122.33055674999997
47.605692672148685, -122.33055674999997
47.605692672148685, -122.33055674999997
47.605692672148685, -122.33055674999997
47.605692672148685, -122.33055674999997

Making Store Locator Plus Smarter

There may be ways to address this within the plugin, but with 30,000+ sites using the plugin I need to be careful on what I change and why.

Proposal 1: Auto-extend The Address

For example, it would be possible, with a good bit of work, to “figure out” what region of the world he map is showing via an algorithm.    For example, run a “behind the scenes” search of a single address and grab the city + state + zip from that whenever the address does not have a city + state + zip.  Then re-run the search with that info appended.  But there are issues:

  •  Not all users are in the USA.
  • What do you do for countries where the format is zip + province on the end?
  • What if a user types 1508 7th Seattle?  What is the street versus the city?

I could just take the initial center of the map and use that as the zip code, but that would mangle the location sensor results.

Proposal 2 : Add Separate Search Form Address, City, State, Zip Fields

I could create new input fields for city + state + zip, but again we have country specific issues.

I think entering separate fields is more of a pain for the user.

Have An Idea?  Share…

Have and idea on how to address the “moving target” issue, please share.