Archive for November, 2010

I recently spent a whirlwind week in San Francisco, booked up with mobile conferences and related meetings. From Open Mobile Summit, Appcelerate to Under the Radar (not technically a mobile conference but really, what technology conference isn’t about mobile these days?), a few key themes emerged.

What everyone is talking and thinking about for mobile:

Android

This emerging mobile platform continues to be on everyone’s mind. Google’s Android presents massive opportunity, not just in sheer volume of devices on the platform ( for every iPhone today, there are about six new Android devices coming down the pipe) but with the monetization potential. A recent report from mobile ad company Millennial Media found that Android ad revenue has, for the first time ever, beaten iPhone ad revenue on the company’s ad network. So Android ads are generating more revenue. Why? According to Millennial, most Android users are first-time smartphone buyers, and advertisers are willing to pay a premium to reach those users early in their smartphone experience.

We are advising all our customers to build across platforms as they develop their mobile strategies. There is so much potential on Android (not to mention BlackBerry, Windows Phone 7, Nokia and others) and you can’t even do in-app purchase yet. Which leads me to my next theme…

Monetization

We strongly believe, and our data points to this, that in-app purchase will become the de facto strategy for monetization of mobile apps. This is the secret that I think a lot of people have been looking for in mobile.

Everyone is talking about the recent study from Flurry, which identifies in-app purchases as the leading source of revenue for social networking and social gaming applications. (There’s that social thing again…) As of September, in-app purchases accounted for 80% of revenues generated by mobile developers. Revenue from in-app purchase has already eclipsed that of advertising, and this functionality isn’t even available on Android yet. When that happens, stand back because the gold rush will officially be ON.  (and BTW, when it is available, Urban Airship will support it. You can count on that.)

Social

How can mobile get more social? We’ve seen some brilliant success in mobile apps that use social aspects to engage and monetize. Look at Tapulous, one of the very first companies to use push notifications in its popular gaming apps. The company boldly incorporated a social element to its messaging. When a user played a game, he or she could challenge a friend to beat that high score via messages sent directly to that friend’s device. The “it’s on” competitive mentality was a perfect match for the technology. Tapulous found success by marketing outside its client base, and this is a great blueprint we hope to see many apps follow on the road to success moving forward.

Data & Demographics

The ongoing discussion about who owns the customer rages on. By that we mean, who has access to the user behavioral data? Who should? The content provider / app maker? The platform? The carrier?

Most agree that today the platform owns that data, but that they will continue to feel pressure to share that data. One thing is clear: the data = value, insight and equity. There is definitely a need for vendors to help mobile publishers mediate the territory, establish insight across platforms so they can effectively engage and monetize the users of their apps.

These conversations are just getting going and many of them will continue into 2011 and beyond. As I always say, things are just getting interesting.

Today I’d like to announce a few improvements to our AirMail Push API for Android and BlackBerry devices. These APIs have already been in production for iOS apps for some time, and now they’re ready for use on all three platforms. Whether you’re developing an application for a single platform or using all three, aliases, tags, and the batch API might be just what you need.

Aliases

Since we first opened our push notification service, aliases have been used to ease integration requirements. By adding a developer-defined field to the registration payload, you can remove the need to store combinations of devices along side in your own database. Instead you can refer to the recipient by something convenient like the user ID or a hash of the email address. Now that aliases are available on all three platforms, you don’t even need to track what platforms the user is on.

As an example, say your end-user Bob has user id 42 in your database. When his iOS, Android, and BlackBerry apps start up, they add the string ’42′ as an alias in the JSON payload, like so:

PUT https://go.urbanairship.com/api/device_tokens/<iOS device token>
PUT https://go.urbanairship.com/api/device_pins/<BlackBerry PIN>
PUT https://go.urbanairship.com/api/apids/<Android APID>
Content-Type: application/json
body: {"alias": "42"}

To push, then, you can just use the alias as the recipient, and put the appropriate payload for each platform:

POST https://go.urbanairship.com/api/push/
Content-Type: application/json
body:
{
    "aliases": ["42"],

    # iOS
    "aps": {
        "alert": "Hello from Urban Airship!"
        "badge": 1
    },

    # Android
    "android": {
        "alert": "Hello from Urban Airship!"
    },
    "blackberry": {
        "content-type": "text/plain",
        "body": "Hello from Urban Airship!"
    }
}

No matter what the combination of devices registered with the alias “42″, all active recipients will then get the message, in the format appropriate for that device.

Tags

Like aliases, tags can be a great convenience and lessen the cost of tracking large numbers of ever-changing users. One common use case for tags is to track topics that the user is interested. Consider a news application: a user might select that they’re interested in breaking news about politics, entertainment, and technology. Your app code register each of those as a tag:

PUT https://go.urbanairship.com/api/device_tokens/<iOS device token>
PUT https://go.urbanairship.com/api/device_pins/<BlackBerry PIN>
PUT https://go.urbanairship.com/api/apids/<Android APID>
Content-Type: application/json
body: {"tags": ["politics", "entertainment", "technology"]}

If a news story comes along that your system determines is relevant to users that selected “technology” and “science”, then you could make a push request like this:

POST https://go.urbanairship.com/api/push/
Content-Type: application/json
body:
{
    "tags": ["technology", "science"],

    # iOS
    "aps": {
        "alert": "New Tech/Science Story",
    },
    "url": "http://example.com/news.html",

    # Android
    "android": {
        "alert": "New Tech/Science Story",
        "extra": "http://example.com/news.html",
    },
    "blackberry": {
        "content-type": "text/plain",
        "body": "New Tech/Science Story\nhttp://example.com/news.html",
    }
}

Every user tagged with science or technology will get this push, without needing any server-side database changes or keeping track of every user-initiated change.

Batch Push

Last but not least, we’ve expanded the batch API to support BlackBerry and Android. If you have to send a large number of distinct messages to multiple devices, you can group it into a single API call to minimize the number of round-trip HTTPS calls you make. This API now supports everything that the normal push API can do. Here’s an example:

POST https://go.urbanairship.com/api/push/batch/
Content-Type: application/json
body:
[
    {
        "apids": ["<my apid>"],
        "android": {
            "alert": "OMG you have to read this"
        },
    },
    {
        "device_pins": ["<my pin>"],
        "blackberry": {
            "content-type": "text/plain",
            "body": "Hello old chap, here's a note"
        }
    }
]

We hope these new additions help make your integration as painless as possible.

Before you can successfully send push notifications, you first have to convince your users to accept them. When they are asked, upon the install of your app, whether they wish to accept push notifications, you want them to say “yes.” For them to agree, users need to understand why they’d want to receive messages from your app. I’ve installed too many apps that ask if they can send me push notifications, but offer no glimpse into why I’d want them to, or what kind of notifications I would be receiving. If you want your users to opt-in (and you do), you need to make it very clear in the description of your app (inside the app store and upon install) how and when you’ll be engaging users via push notifications.

Then, you have to ensure they do not opt out of your notifications. To keep your users opted in, we highly recommend you make it easy for users to manage their push preferences within the app itself. Make it simple to turn notifications on and off, to set up quiet hours (times when no alerts will be received on the device), and let users decide for themselves which method of push-notification alert they wish to receive for which types of message. Some users will want audio and / or video alerts for more important information and badge updates for less crucial or less timely messages. Ideally, you’ll have a strategy for managing push methods yourself. There’s no reason to treat all push notifications equally.

Finally, analyze user behavior after you send your notifications. If you notice a decline in active users, or an increase in opt-outs, you are probably pushing too often, or without enough value.

In the end, you have to demonstrate value to the user or they’ll opt out of your push engagements——or worse, they’ll delete your app. By allowing your app to notify them, potentially interrupting them in the middle of something they are doing on their device, users are trusting you to communicate with them on their terms. Use push notifications successfully and you’ll have a priceless channel for user engagement; provide insufficient information, and they’ll turn you off.

This post is part of an ongoing series Push Notification Best Practices. We’ll look at different aspects of push and provide guidance on effective tactics. Up next, we’ll cover Measuring Push Notifications Effectiveness.

I came across an article this weekend titled “Android wins devs’ hearts and minds.” It takes a look at some of the statistics regarding developer plans for 2011 in terms of which platforms they will be supporting and developing for. They make a point that Android may have more attention from developers and may be poised to unseat Apple’s iOS as the top platform for developers.

They go on to say:

“When asked about their plans for 2011, however, developers said that 29 per cent of their new-platform efforts would be devoted to Android devices, versus only 8 per cent for the iPhone.

Of course, since the iPhone already holds a lead in developers, its developer growth would naturally be lower than that of Android. But still, such a large disparity indicates that next year may see Android overtaking iPhone in the battle to win the hearts and minds of the all-important developer cadre.”

This may be true, but ultimately it misses the point. The key for today’s app developer is that iOS and Android isn’t an either/or decision. Android has proven itself to be a popular platform that the public is adopting, and the iPhone obviously has a massive user-base, and all customers are expecting quality, feature-rich apps regardless of which phone they have. This leaves developers with little choice but to support at minimum two platforms, however, that comes with some specific challenges.

At Urban Airship, we work with app developers regularly. Typically we see three key objectives they have when it comes to cross platform support.

• Create a consistent experience – Ideally, app developers would like their mobile apps to have a consistent experience across all the mobile platforms they support. This is an issue we are continually helping our clients with. Whether it is consistent in-app purchases, enabling content subscriptions, or delivering push alerts and in-app messaging, developers want these things to be experienced the same across their different platforms. This is especially important when planning for new features and measuring app satisfaction.
• Reduce the porting burden – Mobile app developers have the same goal as other developers that support multiple operating systems. They want to reach as many people as possible while minimizing the headache of supporting apps in different environments. Ideally they would have one product, with one feature set, and one experience across all the platforms they support.
• Consolidate app evaluations – Ideally businesses would like to view the success of their applications not independently for a given mobile platform, but across all supported environments. For their key metrics, whether it is click throughs, engagement, uninstall rate, etc. they would like this to be something they could easily see as a whole and not in platform silos.

While iOS vs. Android certainly makes for interesting press and arguments, the real story is how they will support the top mobile platforms in a way that is most efficient and best for their business.

Newsweek makes it interesting this week with the release of its latest iPad app. The publisher has been on the cutting edge with its apps and is now the first major publisher to offer in-app subscriptions to its iPad users. This is a major differentiator… and where Urban Airship comes in.

As the New York Times article points out, the inability to offer subscriptions has been “a source of major frustration” for magazine and newspaper publishers. It is no easy feat to add in-app subscriptions that work within the Apple guidelines and practices. One of our engineering team members described the task as “Herculean,” which is apt, given the amount of code required to make it work.

As Richard Stephenson explains in his post, implementing subscriptions is difficult because Apple’s SDK for in-app purchase extends only to single-copy sales.

As publishers have raced to market with apps for the iPad, they have faced many unforeseen challenges in their attempt to transform a business model to fit the new paradigm. And the lessons they have learned will have broad impact across the industry. Conversations around subscriptions have mainly centered in the context of how magazines offer them – upfront money paid by a reader for access to content for a set period of time. But this subscriptions-monetization model translates to much much more than magazines and news. Any organization that provides information or content can succeed in monetizing their mobile strategies with Urban Airship.

Think of any content that users would pay for up-front: a 6-month magazine subscription, a one-year association membership, or an ongoing opt-in research database. In each use case with a mobile app, Urban Airship helps manage all aspects of the transaction, including identifying which devices (users) have paid for content, verifying the user account, and delivering the content to the device. Urban Airship tracks the entire lifecycle of a subscription. We see this as an important new monetization blueprint for all types of developers, and we are making it easy for them to integrate.

Further simplifying the process, if a user buys a new device, they still have rights to access back issues or other content they have paid for. Our subscriptions service manages this verification, associating a specific user with an account. Our service also enables “user entitlements.” In this process, content can be “unlocked” for designated users or those who have been authenticated. Publishers can put content behind a paywall, viewable only to subscribers. This is similar to what many information-providers have been doing on the web. An ID and password are used to unlock that content and make it viewable.

Publishers and content providers are wading in new waters and still in the early stages of identifying their mobile strategies. This is a dynamic market but one thing we know for certain: things are just starting to get interesting.