Why Geofencing & Opt-in Notifications Could Save Foursquare

Source: Psiaki

Last week at CTIA, I moderated a panel on location-based advertising - it was a pleasure to have a conversation with Fred Boos of Rocketbux, Anne Bezancon of Placecast, Dan Gilmartin of Where, Rip Gerber of Loc-Aid and Lisa Petersen of Neustar.  

The panel got me thinking about the future of mobile advertising. For all the talk about location-based advertising and services (e.g. Foursquare, Facebook Places, Gowalla and the like), there are some core sustainability issues about these services.

Many mobile users, myself included, are still scratching their heads as to the utility of these apps, especially check-ins.  We are starting to see the developer community answer this criticism with some useful services, such as barcode scanning/price comparisons (e.g. from Zappli, eBay/Redlaser and Amazon), coupons (e.g. from Rocketbux and Cellfire), and local offers (e.g. from Where and xAd). 

From the perspective of advertisers, whether local or national, only a tiny percentage (my estimate is 2-3 5%) of mobile users' time is actually addressable with location-based advertising. Why?  Because when you multiple the 23% 30% that have smartphones by the 50% (my guesstimate) that have installed Facebook/Foursquare/Gowalla/etc by the 30% that open up these apps in specific locations to find information, you get a very small percentage.  

The solution, in my opinion:

• doesn't require users to open up specific apps all the time.  Perhaps it delivers information through notifications / text
• is opt-in / permission-based. Not only is spam an issue but privacy has to be maintained at all times
• knows the mobile users' location at anytime (even if they're not logged into an app) - I call this 'persistent locationing'
• intelligently understands the relevant area around the user from which to cull information/marketing messages. In other words, 'geofencing' around people, not locations. [Addendum: the key issue here is scale which I've been thinking a lot about especially as our portfolio companies INRIX, Where and Aha Mobile have all had to operate at large data scale.  When you have millions of location traces updating every few minutes or even every second, how do you multiplex this with millions of users and thousands of offers and create meaningful and accurate output streams. Not an easy computer science problem to solve.]
• is constantly running in the background (not on the phone but in the cloud) to search the users' surroundings for relevant information/marketing messages. In other words, 'persistent search'

For a location-based apps company like Foursquare, I think this is the only way they become truly universally usable, applicable across all 305M people in the US.  They also become appealing to brands/advertisers.  To achieve this, they need to do a big integration job across these APIs/web services. Here are the relevant vendors (not an exhaustive list):

• Notifications/text: SMS through aggregators such as Singlepoint, Sybase 365, etc. or smartphone notifications through Urban Airship, iLime etc.
• Persistent locationing: Location Labs, Loc-Aid - these vendors have integrated across multiple mobile operators and can expose any user's location, at all times
• Geofencing: Locomatix, Placecast, Location Labs, Simplegeo, [Adding: Xtify, based on Josh's comment]
• Persistent search: No one vendor here. Algorithms have to make sure not to ping database APIs (such as Yelp's API) too often or risk getting shut-off.

And finally, a couple of issues need to be addressed head-on for this solution to be successful: first, privacy, and second, business model.

Comments

[Account Deleted]

I've just put up a new post on local user-generate content here: http://www.nextwala.com/nextwala/2012/04/real-time-local-1-1.html

[Darrin Clement]

I like Joshua's last point (#4) related to privacy. It seems like a lot of the "check-in" platforms currently rely on specific points - locations - to check in. This presents a problem because doing so (if done in real time, and if done honestly) discloses your exact whereabouts. In contrast, companies like mine (Maponics) create predefined geofences like neighborhood boundaries so that users can check in to a local area, without disclosing exact location.

[twitter.com/mitensampat]

Ivan, Dev:

from my experience, the challenge is getting the operators to understand the value of building a platform that allows apps to leverage location as a context. they often get wrapped up in the value of different forms of data, and start to count the beans too early in the process.

for a persistent locationing model, the charging paradigm shouldnt be based on every dip (or push), but should rather be a CPA style revenue share. this allows some innovation to see the light of day and bring in some revenues, versus pricing it out of the park and getting nothing.

Advertising is often a good first application, and doing a hyperlocal ad network (pull only, not push ...from user p.o.v) is a good starting point to make the economics work for both sides. Keep in mind, the netbook and USB dongle sales are growing pretty rapidly and the ad inventory available there is significant to generate meaningful ARPU for the operator.

[Imitrovic]

While Groupon is not what you could consider mobile and location based in strict terms they still provide local services and from distribution perspective the affiliate move by Groupon (e.g. http://techcrunch.com/2010/10/21/ning-gets-its-groupon-on/ ) is an example how local services could be used to "infect" all other lifestyle apps and services. And in addition to distributing local services around, Groupon is also focusing on personalization (meaning relevance). Very smart in my opinion. Something that all local services, including mobile and hyperlocal should pay attention to.

[Imitrovic]

Depending on tier, volume, accuracy (GPS or cell), carrier, recency etc. it can go as low as below half a penny but around penny is more likely. Also, real-time network lookup (what is known as Control Plane) tends to be slow and you can't practically use it for real time display advertising; SMS with double opt in is obviously more applicable. I think tnat this approach today doesn't scale beyond individual marketing SMS campaigns and, what is more important, doesn't scale beyond big brands. So you are pretty much looking at individual marketing SMS campaign for a large brand (eg. Starbucks,
Dunkin Donuts etc.). While that is a valid model it is worth noting that large (actually the largest) portion of location services will revolve around small businesses (restaurants, spas etc.) and there is going to be a huge war to win local merchants (it has started already with Google Places, Facebook Places, Groupon, Yelp,
Foursquare, Where...). Network dip economy does not work there.

Network dip approach, while valid for some type of services, is not of lifestyle scale.

Background location on device in my view is tough at least from distribution perspective as it still needs binary distributed on consumer phones which obviously is a big issue.
You just can't make 20 million users to download and install your
binary. Also, managing background location across various device APIs has its challenges. Mostly people think of iPhone here
focusing less on other smartphones. Also, it doesn't work for feature phones which are still making the largest audience. It is going to be a while before we see a widely (tens of millions)
distributed location service that revolves around background location and (monetized) notifications.

So, one reality, at least for us in WHERE is to focus on a model where you have to "infect" other non-LBS apps with location services to extend their usage. We process about 100 million location requests per day from within non-LBS apps. In many cases we are able to extract location out of http request header (so it works even with feature phones) and in large number of cases we instruct non-LBS apps on how to pass location to us so we could deliver location services back to them and monetize in turn. The ultimate goal though would be to permanently embed highly monetizable location services into these apps and make them permanent part of any lifestyle application (stay tuned on this one).

Nevertheless, whichever method you use to obtain large amount of location data you will find out that relevancy is going to become your number one problem, not location really. Persistent locationing assumes that you will be able to deliver personalized (upper case p) location services to user constantly scanning for offers and places around user that particular user may like. Obtaining location is just a small part of all this and should be solved quickly so one could move onto solving the relevancy problem.

Personalization and taste profile is much larger issue with LBS especially when you deal with millions of users and millions of location impressions and places daily. I am sure that you noticed that Foursquare announced personal local recommendations as the top feature for their upcoming release. They are definitely on the right track here. It is going to be about connecting local
merchants to relevant audience. Foursuare is clearly thinking about relevance and especially how to pass that location and place relevance to other applications outside of Foursquare. I think that it is the right thing to focus on. Location on the other hand is always going to be there somehow.

[Account Deleted]

Josh,
Thanks for the math. Makes things more tangible. Couldn't one say that a penny per dip (if that is actually a market number) is covered by a $20 CPM ($0.01 x 1000 / 50% revenue share)? And while this is a high number, it is not completely out-of-whack with mobile ad CPMs... However this doesn't leave much if any margin for cover opex etc.

So if we use your previous comment at 7 notifications per week or 28 a month per user, this could lead to some interesting unit economics if you can tap into an ad network or directly sell ads at >>$20 CPMs.

[Joshua Rochlin]

Dev -
I think you are 100% correct there is currently no model that works for carrier dips that is not mission critical (ie. Tasso's people finder service). Even at a penny per dip, you would be looking at a $43 cost to have access to persistent location for a month. (My math: a dip every 10 minutes x 24 hours x 30 days x .01/dip). Even if you would only dip during the day or some other limited period you you would be looking at a cost of at least $10/month.
At Xtify we have built our business exclusively around device derived location. It is relatively free and allows for mass distribution of geo targeted notifications. What it does not allow us to do, is geo on feature phones. However, we have seen that brands are moving aggressively into smartphone apps and realize that the spending by smartphone owners is so much greater than feature phone users, that LBM efforts on smartphones is money well spent.

One day the carriers may price network dips more in line with real business models. . . . Maybe our grand-kids will be around to enjoy it.

[Account Deleted]

Ivan and Miten,
Thanks for your comments.

On a related note, can anybody talk about the pricing of network-based location dips? Just trying to gauge what sort of CPMs are necessary just to cover the cost of location dips... my initial guess is that the business model is still out-of-whack for ad-based models to cover basic location dip costs... which is why device-based locationing (which is essentially free on a variable basis) might have a chance to hang around as a solution...

[twitter.com/mitensampat]

Dev, thanks for writing a thoughtful article about the different slices of the pie.

Your call for persistent-locationing, in my view, can best be delivered by the conduit i.e. the network. The question that comes to mind is how you can distribute this context in an elegant fashion (while keeping consumer privacy at the forefront).

Operators have long spoken about developer API's but none have delivered an interesting platform to attract the bleeding edge entrepreneurs.

if every HTTP request had location in it, that would make life very interesting.

[Imitrovic]

Great post Dev, opens very important questions so it warrants a long comment.

It is true that people spend only small percentage of their mobile time using location based apps. So the problem is how to extend the time that users spend in contact with location based services so that location based startups would have more opportunities to deliver their services and offers to users (and actually make more money in the process).

Your thinking about continuous location awareness (persistent locationing) delivered in combination of background location, network based location and geofencing is a valid approach that relies on technology to become a reality - background location with dynamic geofencing around person (lot of patents have been granted in dynamic geofencing area, it is a bit scary to become successful by using this technology), notifications, integration with network based APIs, SMS gateways etc. Well, while the concept is valid it is however very technically complex - too many integration points, various device APIs, still you have to distribute binaries to phones in most cases, only supported in smartphones and if not it then becomes very expensive to scale beyond individual campaigns because of costs of network location dips and SMS. Where background location is used nativly on the device it affects usability through battery life and also unlikely to scale any time soon.

Moreover, delivering notifications out of the context without understanding whether user is in the appropriate situation to engage with her mobile phone at all makes this approach questionable - while you can have continuous locationing, user may just be annoyed by often notifications and actually not even ready to use her mobile phone at the moment of notification. That pretty much limits the number of notifications you can send to user throughout the day/week to avoid spamming.

It is extremly important to deliver location based services at the moment when user is actually using the phone as those are the best moments when user's full attention could be captured and location based offer "sold" to user.

So, how about turning this on the head a bit by not thinking about this as a technical problem to be solved by technology but rather looking at behavior and usage? While mobile users (not only smartphone users) spend small percentage of their time in location based apps they do obviously spend the rest of their mobile time in other, non-location based apps. So why not extend the "location time" by delivering location based services and offers while user is using those other apps? E.g. lot of users spend their time in music applications like Pandora so why not delivering relevant location based services and offers directly in Pandora? If you could reach large number of users across all kinds of apps at the moment when they are engaged with their mobile phones and use that opportunity to deliver relevant location based services (relevance is the key here, location being one part of it by default) then you really solved a big part of the original problem. The time that users spends receiving relevant location based offers and services is thus greatly extended out of their mothership consumer apps.

That is exactly the concept and approach that WHERE uses with WHEREAds (disclaimer here, I am CTO at WHERE). Via WHEREAds WHERE has delivered location based offers to 50 million users across 170 (and growing) applications, majority of them non-local and many of those apps users use for long periods of time (e.g. Pandora is one of the apps where we extend the reach of our location based services). So the time that users spend receiving location based services has been greatly extended without complex technology. Well, there is complex technology involved but of different nature and is more focused around solving the relevancy problem instead of solving complex technical integrations required by geofencing and constant location tracking.

So the two key issues here for location services to solve to be succesful and used for long periods of time - reach and relevancy. With reach you basically solve the large part of the original problem enabling location based services to extend beyond original location based apps - of course you have to find a way to get location of user in these other apps. With relevancy you make sure that users still treat your location services as services and not as spam. Relevance is fun problem to solve and it depends on Big Data. Capturing and processing Big Data is operationally complex but the answers you get out of the large amounts of data are crucial for relevancy.

We actually got 3 billion location points in a month without using background location and constant location tracking & polling at all! How's that for saving battery life and trees ;)

By having wide reach to users in non-location based apps (basically apps of all kind of categories) we in WHERE are able to calculate location taste graphs for users or what we call here calculate "Lifestyle Genome" for user making sure that we can segment users in such way to be able to deliver relevant location services outside of location based app. Once you solve relevance you actually solved what you call persistent search (we like to call it discovery) as persistent search is all about relevancy (what is relevant to me in this area at this moment).

Once you have relevant audience and in numbers (reach), audience that is using the phone at the moment when the location offer is delivered then you are able to introduce cool new loction services that have not been delivered before. How about flash mob local coupons? Restaurants being able to create Groupon like offers and push them to users of all apps in real time in certain geographic area? Isn't that exactly what geofencing approach would try to deliver anyway? Another disclaimer, WHERE has recently acquired daily deal company Local Ginger.

[TassoR]

Great blog post Dev. Like Josh I am keen to see this dynamic, continuous location space grow

[Account Deleted]

Josh,
Thanks for your comments. I agree with them. I wonder how many of these 'rules of engagement' with customers have already been hashed out by the direct marketing industry and can be applied here. For example, email marketeers have been around for a long time - best practices from there (such as optimum frequency of engagement) can probably be applied in mobile direct marketing. I wonder what Constant Contact or Eloqua have to say about this.
-dev

[Joshua Rochlin]

Dev-
You are anticipating the market exactly as we see it unfolding. Our partners are using Xtify in their mobile apps to send opt-in notifications based on geo-fence triggers (as well as other non-geo triggers).
See here about how DailyCandy is using geo-triggers to drive traffic to editorially relevant locations: http://nyti.ms/clUTXr

Also, you will shortly see other major brands and publishers roll out services that take advantage of "Persistent Locationing"

A few words of caution:
1. Create a service that does not require "GPS exact" location - this is battery consumptive to an extent unacceptable to the consumer. "Nearby" is good enough.

2. Pay attention to delivery cadence: just because you can send a message every time someone passes a relevant location does not mean you should. We have seen 3 notifications as the daily limit with no more than 7 in a week (except for travel apps that are showing relevant points of interest for a one-time visit).

3. Consider getting an app in market early, even if it's primary purpose is to create a channel to send geo-relevant push notifications to your mobile audience.

4. Consider keeping location and identity separate. Your customer will be more willing to share their persistent "where" if they do not have to also give up their identifiable "who".

Looking forward to watching this space grow.