Tag Archives: Application programming interface

How Blippy Can Help Foursquare Monetize Check-Ins

Foursquare‘s great for a number of reasons.  Like a lot of people, I use it to keep track of my friends when I’m going out, but it’s also a fun way to discover new restaurants and other spots based on friends’ check-ins.  Since I go to great lengths to find awesome Chinese, Indian, Thai, Vietnamese, Korean, etc. food, Foursquare makes it easy for me to share these gems with my close friends.  It’s also a good way to keep a running log of where I’ve been.

While the “check-in” is already becoming a commodity (Yelp recently released check-in functionality and Facebook will, too), Foursquare has focus and timing on its side.  Back in 2006 I might have friended someone on Yelp because I liked a bunch of their reviews, but since I don’t know these people beyond their food rants I don’t want to share my real-time location with them.  FB will have a similar problem since a lot of people have hundreds of “friends”.  Unless FB can make it easy to select what friends you want to share location information with, it’s going to be such a noisy mess that it won’t have any value (let’s all hope FB check-ins will be opt-in).  The point is that people are figuring out the best way to use social networks and Foursquare’s launch happened to coincide with the steeper end of this learning curve.  Most Foursquare users I know are far more selective about who they accept as friends (typically one’s “real” friends) vs. who they friend on “older”, non-native-mobile social networks.

Whether it be mayorships, scavenger hunts, coupons, or other marketing or promotional offers, there seem to be a number of ways that Foursquare can begin to experiment with monetization.  The problem with most of these monetization schemes is that they’re a little klugey and require too much work for either the user and/or the business.  Coupons would be a challenge for Foursquare, because traditionally coupons are distributed by the manufacturer to the consumer and then redeemed at the point of sale with the help of the merchant.  There are three entities in this transaction, all of whom benefit at specific parts of the coupon value chain.  The merchant honors the coupon and gives the customer the discount but then the merchant has to submit the redeemed coupon in order to get repaid.  This works because the consumer has an incentive to use the coupon (to get the discount), and once it’s used, the merchant has an incentive to get repaid.  The manufacturer is happy because it got a sale it might otherwise not have received.

Now, consider what happens when a hypothetical FS coupon is redeemed at a small business (not a Best Buy which has sophisticated POS systems).  You’re at a packed bar and you show the bartender your coupon for a free beer.  The bartender (who is usually not the owner and has less incentive to keep track of these things) will need to somehow process the coupon so that you can’t reuse it.  Let’s say there’s a simple code he types into your phone (that’s awkward and slow) or maybe he just swipes a finger across the screen to process it.  The problem actually isn’t the processing, it’s that unlike in the supermarket example, there is no third party that will repay the business owner for the coupon.  If the bar pays FS directly for each coupon redeemed, the bartender has little incentive to process the coupon.  If the bar is paying for each coupon that gets redeemed, a less-than-honest business is not going to process (and pay for) the coupon once it’s already acquired the customer.  A CPM-based coupon system isn’t a great alternative either since it’s difficult to tie the ad to a specific action and thus to charge much for the coupon.

The point is that check ins don’t necessarily translate into dollars, but sales obviously do.  The real value for businesses (and for FS) is to harness the social and loyalty aspects of Foursquare and tie them to sales.  One way that Foursquare might do this is by partnering with a company such as Blippy that publicly tracks users’ purchases.  Blippy is still early in its development (launched about a month ago) and doesn’t have an API yet, but consider how a Foursquare check-in could be tied to the bar bill you forgot you racked up at Clandestino?  Businesses could begin to tie their mobile advertising spend to specific customer check-ins and related purchases.  You could then begin looking at people’s networks to better understand who the influencers are – the people who by virtue of their check-ins attract high-spending, loyal friends to the business.  If you’re interested in digging deeper into network science, you may want to check out Professor Michael Kearns‘ posts about his incredible class, Networked Life (if you happen to be a student at Penn, I highly recommend it).

The other way to do this would be to integrate a mobile payment API into Foursquare.  A service such as Venmo or Square could be a neat addition and it would solve the problem of tying the check-in and social features to the customer’s purchase.

Reblog this post [with Zemanta]