One of the big problems we had at Citysearch was how to handle service areas. You see, in local search, everything had a location, was geocoded and was searched for geospatially based on that coordinate.

That worked well for restaurants, clubs, and other arts & entertainment-related categories. However, as we transitioned to yellow pages (again…how many of you remember http://yellowpages.citysearch.com from 5 years ago?), we recognized a growing issue. Many yellow page categories were services that would require the vendor to travel to the place they need to work (i.e. your house) rather than you visit their physical place of business. For example, do you really care where a plumber’s office is if he is willing to travel to your house?

Well, Gary Price came across a USPTO application about “electronic yellow pages.” I started to read it and found that MSN is trying to resolve the service area issue.

The problem:

One problem with these systems is that a merchant that services a particular area, but does not reside in that area, is not found in a bounded query directed to the area. In addition, the service merchant does not have a physical address in the area that can meet the criteria for returning a listing in response to a proximity query. For example, some mobile businesses (e.g., plumbers) service an area but do not have a physical office in the area. A bounded query directed to the area (e.g., directed to a particular ZIP code) does not return a listing for the mobile business. Likewise, a mobile business listing most likely is not returned in response to a proximity query, because there are likely other businesses that have a closer physical location than the business office for the mobile business. The listings for closer businesses are returned in response to the proximity query. In some circumstances, the closer businesses may not serve the location upon which the proximity query was based, but have their listings returned because their business offices or mailing addresses are closer than the business offices for some merchants that do serve the area.

Their solution is to add an additional lookup that ties a company to a list of zipcodes (zipcodes, it is assumed, are of a small enough geographic area and, in practice, this is in fact how many service providers “own” or purchase areas as with many of those lead-generation sites). Since this would all be in a database, you would then query in 1 SQL query, uniquing the list of merchants so you do not get duplicates (because of multiple service areas), and without any need to merge the data together because of the sort order.

There is additional information on how they will be doing queries in general:

  • they will use SQL Server
  • users will input a query term and geography
  • the query term will match against categories (some local searches/iYPs match against individual listings instead of categories but, for the most part, most iYPs match against categories and usually have an extra page between your search input and the listings where you must select a category…yuck!).
  • the geography input will match against a list of zipcodes which, if you remember, service providers have already been associated with a list of them (most local searches actually geocode your input and do a geospatial search against your input…but see above for the limitations on this)
  • additional info exists for service providers returned to designate/explain to users why they are seeing this merchant in the listing even though their place of business might be outside of their search boundary
  • they also bring up the possibility of access through mobile devices or desktop applications

well, we all knew MSN has been looking to build their own local search and iYP for a while now (and stop using other third parties to help power them)…I just wonder how much longer we’ll wait. We’ve already seen local search tied into Local live (was virtual earth) and it will be interesting to see how service areas will be presented on the map when/if they integrate that.

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
 
Loading ... Loading ...