In one of our favorite Valentine’s Day posts of all time, Chris Dixon posted about the “geo stack” – a model for how to think about the various layers of the geolocation ecosystem.  According to Chris, the stack looks something like this: lat long detection > lat long translation (into venues, addresses, etc.) > user relationship (how to get consumers to share location) > recommendations (tips, reviews, etc.) > social graphs > monetization.  If you haven’t already, please click through and read the whole post – the comments are worth reading as well.

We’ve taken the liberty of trying to visualize this stack with a few tweaks and notes – for instance, we’ve included social graph in the “User Relationship” layer, and example companies who we see as competing at the various layers:

If you are working on something in the geolocation / social check-in space, you may find it helpful to think about where you fit into this stack, and what you need to do to stake and defend your claim in what is rapidly becoming a very competitive area.

The announcement yesterday of Google Buzz all but guarantees that Google has given up on its poorly thought out location experiment, Google Latitude. We’ve held off dropping Latitude into the deadpool in the hopes that Google would innovate around it and make it much more appealing. Turns outs, they decided to go down another path – instead of innovating around Latitude, they decided to trash it and go with something else. Whether it was Buzz, some other homegrown app, or an acquisition (if only they had bought Dodgeball back in the day…wait a minute…), Google obviously realized that they needed a better way to compete in the location space than Latitude. So what was so wrong with Latitude? Well, to state it as frankly as possible, Latitude crossed the creepy line. It was basically pitched as a way for Google to track all of a user’s movements, running all the time in the background (on phones that don’t start with the letter “i”) and then broadcast out that info to your GMail contacts. I.e. it was pitched as a creepy app (of course users have privacy controls, but people hear “always on” and they get creeped out).

On top of a bad product launch roll out, Latitude had (yes, we know it is still technically available, but we’re going to use the past tense nonetheless) major flaws as a social location app. First of all, using Latitude didn’t really add much of anything for the user. Why would a user use an app that just tracked them, where’s the value? Secondly, the app didn’t offer any benefit to anybody watching/following/tracking their contacts (we won’t go as far as “friends”), so why would anyone want to watch/follow/track? The answer is they didn’t – we’re pretty plugged-in guys here at LocationMeme and we can’t think of anybody that ever invited us, asked us or even talked about Latitude – it was a complete flop and Google needed to make a move, especially as other location apps are starting to gain strong traction.

So the logical question now is can Google Buzz establish itself as Google’s location service, and more to the point, can it compete with much smaller players such as Foursquare, Gowalla and Brightkite? And if it can’t beat these small players, how can Buzz hope to compete with Facebook (whenever they launch their location component), Twitter and Yelp? We’ll keep an eye on Buzz over the next few days and will get back to you with our thoughts on Buzz.

We want to throw one last thought out regarding Google and location. The one thing that Latitude did highlight is that Google’s greatest location asset is Google Maps/Earth. Google Maps continues to get better (free navigation in Android 2.1 for instance) and Google continues to build an enormous location database of businesses, restaurants, bars, schools – you name it. Integration with Google Maps was the correct strategy, and we hope that Google will make a way to integrate Buzz with Google Maps, preferably right in GMail. Maybe they could call it Longitude.

As millions of iPhone/iPod Touch and soon to be iPad users know, Apple’s SDK’s biggest drawback is single-tasking (i.e. no background processes). As the dominant mobile platform (we don’t want to debate “best” or “most used” – Apple’s SDK is the first mobile platform almost all developers develop their apps for first, so it is dominant), many social location services have built their apps to work in a single-tasking environment, first and foremost. To take this a step further, an argument could be made that the whole check-in craze is the bastard child of the limitations of Apple’s SDK. Would this space have evolved if Apple’s SDK supported multi-tasking? Well, we certainly have made the case for checking in as a concept that stands on its own merits, and Foursquare and Gowalla and others have made great progress in utilizing the focus of single-tasking to make relatively straightforward apps, but still, we would argue that the intrinsic value of check-ins aside, these apps are not all that they could be.

Back in September of last year, Loopt announced that they had hacked together a way to go around the background process limitation. Loopt made a complex agreement with “many partners” (including presumedly AT&T) to use cell tower triangulation to approximate a user’s location to update that user’s Loopt location (for a monthly fee). Here’s what I wrote at the time in the comment section of MG Siegler’s TechCrunch article covering this:

“Here’s my take. As far as a good way to create a revenue stream for themselves and AT&T, this is a smart move. However, as many commenters have already pointed out, cell tower triangulation really doesn’t make this all that special. Best case scenario is that I have some idea where my friends are in a city/area but I will have not have any idea what they are up to unless they check in somewhere (this is somewhat true even for GPS as street address doesn’t necessarily tell me what my friends are up to, but obviously it’s much more precise). When an app/phone can push and allow me to verify (or best case, do the verifying itself) where I am and what I’m up to, then we’ll see a breakthrough in this space.”

As I said then, I don’t think that this is very big news – cell tower triangulation has been around for awhile, and who wants to pay a monthly fee when their phone already has GPS and they’re paying a lot of money for 3G connectivity? Right, a very limited number of people. As I said in the comment, even if Apple allowed background processes that connected to the iPhone’s / iPad’s GPS (we still want GPS for the iPod Touch allow with that pesky camera), that still wouldn’t confirm to my friends what I’m up to – they could probably take a pretty good guess, but verification would still be needed in order to be sure – whether I, the user, do it myself or some other part of the app does it for me. This last part is what we see as the killer approach, and here is why…

Social location applications will truly come into their own when the apps themselves interact with the environment around the user’s physical location. What do we mean by this? Here’s an example – a user walks into a shopping mall and the app running in the background (again, running in a multi-tasking environment, i.e. not on Apple’s SDK right now, but Android, WebOS, whatever) and utilizing GPS pushes out a map of the mall with all of the user’s friends that are currently in the mall and shows them moving around the floorplan, and perhaps highlights what shops are having sales, and could even verify your correct location by cross-referencing it with other friends that have already checked into a location - all without the user having do initiate anything. Understand, this is separate from checking in – this is having the app push helpful info to the user without having them reveal their location to their friends or the world – the check-in would work as an endorsement (as we’ve mentioned before in this blog) but it wouldn’t be necessary to get something out of the app (i.e. you don’t get to be the mayor of anywhere on Foursquare unless you check-in). We could offer dozens of other examples, but we’ll let your imagination run wild instead.

So back to Apple. As the dominant mobile platform, Apple’s current SDK is severely stunting the growth of social location apps, both for developers and in how fast the average user adopts these kinds of apps (i.e. the average user needs to see more value come out of location apps). If the push for better and more useful location apps continues, developers will be faced with a very hard decision – to stay with Apple in the hope that they can gain more users and switch them over to better features if/when Apple finally decides to allow background processes, or opt to stay on the bleeding edge and build innovative features/apps on other platforms such as Android.