Location in the Browser: What Does It Mean?

Not long ago, Google rolled out its “Geolocation API” (via Google Gears). Initially it was intended to enable third party publishers and developers to get location for their apps on mobile devices using a combination of the phone’s inherent location-awareness technologies (i.e., GPS) and Google’s cell-tower database (which has been expanded now to include WiFi locations). However it also works for destkop browsers, provided that Gears is installed on the computer.

Here’s the Google Code Blog discussing the impact:

When we originally proposed the Gears Geolocation API our goal was to make it easy for developers to deliver location enabled web sites on mobile phones. However we realized laptop users would benefit from location enabled web sites too. Today we are adding WiFi signals to the Geolocation API so that laptop users can benefit from location enabled web sites for the first time and mobile users from the increased accuracy. And because the Geolocation API is the same for developers in both desktop and mobile browsers you can even use the same code on both platforms!

In Chrome and Android, with Gears built in, you can deliver a location enabled web site without requiring your users to install a plug-in, but in other browsers they will need to go through a simple plug-in install process. We also submitted a simplified version of the Geolocation API as a WC3 specification and the upcoming Firefox 3.1 plans to support the W3C version directly. The Gears Geolocation API is completely free to developers and users through the default Google location provider.

So what does all this mean? We know about location-aware content and services and their potential in mobile. But what about on the desktop?

It essentially means that developers can tap into location and create more locally relevant versions of their sites or provide locally relevant information without requiring the user to enter location. There are some hoops here though: the user must have Google Gears installed in most cases. This is not true for Chrome users and will not be true for users of the next Firefox browser update 3.1.

If Gears is not installed, users at some point in the process are asked to install it. Then they are asked to opt-in and share their location. There’s essentially a double opt-in process. Google will ask if you want to share location and the app/publisher online will do the same. This is quite cumbersome right now, but as these technologies move directly into the browser, as with Firefox and Chrome, users will just need to allow sharing of their location. Ultimately it will be very much like location sharing on the iPhone.

Yahoo’s FireEagle does this already on a “manual” basis: users tell FireEagle where they are (much like updating one’s Facebook status) and third party sites can tap into the API and get access to that information. Sprint’s (Clearwire’s) new WiMax ISP Xohm provides location-specific content to users on a default homepage. And Skyhook Wireless’ Loki toolbar has been providing locally tailored content for a few years.

Let’s just say that within a year location awareness to within 200 meters (or less) will be available through most desktop browsers to publishers — and advertisers. The current IP targeting methodology used by Google and Yahoo for AdWords and Panama will be replaced with much greater location precision. It will make that customized location map in AdWords a real thing. Targeting will become available by neighborhood and not just DMA/City (Yahoo just added Zip-Level targeting).

This will be easiest for AdWords where end users are on Chrome or Firefox, but it will eventually come to IE as well. Users will need to enable location on the browser but then the ad platforms will be able to tap into that location, serving much more locally targeted ads (provided advertisers create them). This will also be possible for display advertising as well.

I’ve argued in the past that once location-awareness on the desktop gets to the neighborhood level, you get to tap into US Census and other public data (which could be incorporated into AdWords or Panama or adCenter) to allow for demographic targeting on a national scale. This represents — and I’m speculating about where all this will go — a potentially radical transformation of the current state of online and search geotargeting.

Imagine that an automaker like BMW wanted to target its demographic online — I’m guessing 25 to 50 year olds in upper income segments — it could now do that through a search campaign with a high degree of reliability. (Forget about the current AdSense demo targeting.) BMW could bid on all the same BMW brand and generic terms, but those ads could be restricted to users in specific geographic areas, tied to the neighborhood-level Census data (income, age, education, etc.). In other words, it would become possible for BMW to select the audiences to whom it wanted its ads exposed on a national scale (upon the right query triggers) and the system would use the coming improvements in location targeting, assuming the incorporation of Census and other related data, as a way to reach those audiences.

In other words, the same search term(s) list might trigger a BMW ad for one user in location A and no BMW ad in location B. Here’s another interesting scenario, this time with GM. It could show an ad for a car in a certain price range to a person in location A and a different ad for a high-end model in another location. These different ads could both be triggered by the same keywords, but the location/demographic data would determine whether to show the ad at all or which ad to show. You can obviously see the marketing power here.

It would operate largely as conventional direct mail does today (which uses Zip-level lists and neighborhood profiles). And all this would be enabled by more precise location targeting vis-a-vis the browser, as described above. Would such as system be foolproof? No, clearly not. For example, what about work locations where there’s no Census data about audience composition? It also requires better location awareness to be implemented in the browser first and then requires the search ad platforms to incorporate the Census and other data, tied to location.

Nonetheless, this is where I see these geolocation improvements taking the market. They open up a potential revolution for search (and brand advertisers’ use of search) — all tied to better location targeting.