Last week was my first opportunity ever to visit the famous Mobile World Congress, the largest show of the year for the mobile phone industry. First impressions: the show is HUGE. It’s hard to overstate the enormity, so I’ll give some stats:
- More than 72,000 attendees and 1,700 exhibiting companies
- Walking the venue from end to end, without even touring the halls, is over 1 kilometer
- Attendees made use of more than 94 square kilometers of exhibit and meeting space
- The show brings over €320M to the Barcelona economy
With a show this big, it’s very easy to get lost in the noise and activity, which is exactly what happened to me for the first day and a half on site. During that time I wandered the halls looking for vendors, presentations, companies with whom Mojo Lingo shared some commonality. I ended up finding the most connection to the App Planet and developer sessions that occupied Hall 8.
There were two main themes being trumpeted by exhibitors and speakers in the App Planet: the utility of carrier APIs, including location and payment services; and the evolution of the mobile app. With the proliferation of devices, platforms, and mobile operating systems it is no surprise to me that the much-anticipated “third platform” for mobile is increasingly looking to be HTML5. FirefoxOS, announced at the show, is betting big on it, with their entire OS being based on HTML5.
Even as I seemed to find my home among the app developers, I also began to notice an interesting disconnect. Lots and lots of attention was being paid to the mobile app industry, and rightly so. But what is interesting is seeing how carriers are attempting to position themselves in this new world where they find themselves less and less exclusively in the driver’s seat. As networks become increasingly seen by consumers as simply the delivery mechanism for minutes, messages and megabytes, carriers are beginning to scramble a bit to find ways to remain relevant to their customers. Their ideas for /how/ to do this seem to center on APIs: They want to sell you, the application developer, access to information about their subscribers or services delivered on behalf of their subscribers. On the surface, these look like a good idea, and they do have some merit. But I find myself skeptical that this strategy of selling APIs will deliver the deep, long-term value the carriers so desperately want. Let’s look at each of these APIs in turn:
Location is all the rage right now. The ability to market to consumers based on where they are has a lot of appeal. But even beyond marketing there are some very interesting and useful-to-consumer applications of location services. These include routing calls to the nearest brick-and-mortar store based on the current location of the caller; finding the nearest taxi right at the moment the caller needs to hail one; “geofencing”, the ability to draw a box on a map and get updates when a specific person goes into or out of the area, has applications in health & safety as well as fleet management. The carrier’s pitch around location services is that it works with any phone, from the smartest Android or iOS device to the dumbest candy-bar feature phone.
But there are a number of factors that limit the utility of these APIs:
- It is slow. Low resolution fixes can be done in a few seconds but high resolution fixes may require minutes to achieve. In the world of the internet where page loads are measured in milliseconds, even a low resolution fix is an eternity
- It is imprecise. Next to the GPS-driven accuracy in smartphones, the location information from via the carrier API is not much better than an educated guess
- It is awkward. The mechanisms for gaining consent are much more awkward. Consent is a crucial part of the experience, as privacy concerns are very real. On a smartphone this can be as easy as a quick pop-up window that asks for permission to access the GPS. But to gain consumer consent within the network, the consumer currently has to visit the carrier’s website ahead of time and authorize the application, all out of the control of the application developer
- It isn’t exclusive. Most damning of all, the carriers are not holding a monopoly on the information. They do enjoy a very temporary corner on the market for location information on “feature phones”, the industry term for basic telephones, the opposite of a smartphone. But the world is changing and it will not be long before everyone has a smartphone. This is the exact goal of both the Ubuntu for Mobile and FirefoxOS projects, and is underscored by the $50 smartphone offered by ZTE, all three of which were popular displays on the MWC show floor.
Why pay the carrier for the privilege of getting location information when you, the application developer, can get better information for free directly from the device with a better user experience?
This is a particularly juicy opportunity for carriers, and they are pulling out the stops to generate interest in these APIs. The pitch again has some merit: make it easy for mobile subscribers to pay for things using just their phone, and have the charges appear on their phone bill. There are two primary mechanisms here: the backend API, suitable for in-app purchases, and near-field communications hardware, or NFC. NFC promises to turn your mobile phone into a physical payment device, much like a contact-less credit card. Backend APIs are useful for online payments, such as in-game purchases or content subscriptions. In both cases the appeal to the carrier is obvious: getting a small percentage of each transaction can add up to significant cash.
But again there are reasons why these APIs seem unlikely to take off:
- It is confusing. As a consumer, do I really need another payment option? Changing behavior is hard to do, to pull it off those wanting to make the change have to be able to offer something that is significantly better than what already exists. Payment with credit card is pretty easy and it’s very familiar. On Android and iOS, with payment information already saved, there’s no great hurdle to clear for consumers wanting to make a payment
- It can’t be justified. As an app developer, what is my incentive to invest in the effort to implement a new payment mechanism? Without users who want to use it, and without a significant advantage in clearing rates (lowering my costs), why bother?
This left me feeling disillusioned and disconnected with the carriers’ efforts to remain relevant. But it got me thinking…there has to be a better way. So I started thinking about the problem, the goals of carriers, the goals of developers, and what appeals to consumers. The ideas I came up with were so big, I felt they needed their own post, which will be posted soon and linked here.