The Keys To Mobile Growth

Flurry has a useful new post by Toby Vogels on the keys to mobile growth. The article emphasises the importance of metrics, minimising churn and personalisation.

For further insights you might like to read my posts on metrics and retention.

One aspect I hadn’t previously come across is to not bombard the user with excessive onboarding:

“Activate first, educate later. This may seem obvious, however, John Egan from Pinterest explained that many apps focus too much on user education in the onboarding process.”

Mobile App Use

Flurry has an interesting new post on mobile app usage over the last year.

“overall app usage grew by 11% and time-spent in apps grew by 69%”

Most of the growth was in use of ‘messaging and social’ as well as other areas such as sports, news and shopping that demand that the user return to the app to discover new content.

Being Found and Discovered

Google has a useful new post on Tips to be better found and discovered on Google Play that is just as applicable to iOS as it is to Android.

The main themes are building for quality, requesting only permissions that are needed and listening to users. If you think about it, contrary to the title of the Google post, these have less to do about being found and discovered and more about retention. For all but the largest of companies, being found and discovered on the app stores usually only comes through marketing and PR activities.

From Mobile First to Mobile Native

benedictevansBenedict Evans has a post on From mobile first to mobile native where he says he is seeing an evolution beyond ‘mobile first’ to what he calls ‘mobile native’. This is where we forget desktops/laptops and low end phones and only provide a service to modern smartphones.

At first I didn’t think there was much in this idea until I suddenly realised the app I have been working on for a client for the last few months is just this. While I can’t yet say, for confidentially reasons, what the app is, it’s in a sector that’s currently very manually resource intensive and the current ‘state of the art’ innovation tends to be companies trying to take the service fully online via the browser. Conversely, the service I am helping create is fully mobile – skipping the ‘online’ part altogether. While I can’t talk about the service yet, here there some generic observations and insights.

Such strategies are implicitly suitable to target millennials who haven’t known a time without mobile and as Benedict says, the

“mobile-native generation that takes this for granted”.

Going fully and only mobile requires simplification of (business) process flow, simplification of the offering and generation of new value via the facilities offered by the phone.

Part of that added facility is the carry everywhere, always available capability that can make services immediately available. Tied to the immediacy is communication. If you want to engage and retain then the app will need to have in-built communication. The app I am working on uses Intercom.

Further ‘facility’ is the use of context, sensors and the camera to provide utility associated with the service. For example, in the app I am working on we use the camera to check the user’s id using microBlink. An id can be checked in seconds as opposed to relying on days or weeks of manual processing.

As benedict says, think about

“… how many different reasons there are that it would be impossible to build the same thing on the desktop”

If you can answer this question for your service than you might have something suitable for implementing mobile native.

On reflection Benedict coining the term ‘mobile native’ is confusing as, in mobile, ‘native’ means Java/c/c++ as opposed to web technologies. However, his ideas have value and provide opportunities for many sectors to circumvent or skip current ways of doing things and build services that fully depend on rather than just support mobile.

The Mobile Acquisition Funnel

I have been a long time advocate of analysis of the mobile acquisition funnel. I wrote about this as long ago as 2012 and my first encounter was in 2009. Things haven’t changed in some ways this area of retention has become more important.

Salesforce have a new useful article and infographics on Mobile Analytics Tools: Your Guide to What and How to Measure.

possible-metrics-for-your-app-based-funnel-stage-002

Onboarding and Help

smashingmagazineSome things seem to go into and out of vogue. At the moment onboarding seems to be making a comeback. Onboarding is the inclusion of one or more extra screens to introduce a new user to the app. Smashing magazine has a great discussion and tips on onboarding.

However, my tip is not to go over-board on this. My experience is that most users are impatient and don’t read what’s put in front of them. They try, then question. Hence, also think about how to serve customers when they start to wonder how to do particular things with your app – even if you have already told them in the onboarding. Your support starts with what’s behind a help icon or button.

Android Permission Complications

I previously wrote about the new Android M Permissions scheme and how, while more transparent permissions is good for everyone, they introduce a lot of complications. These complications are yet another example of something that developers usually know a lot about but their product managers and some designers won’t know how to resolve. This leads to lots of trouble agreeing/deciding how screens and messages should look and feel, especially when developers aren’t included in the pre-development stages of a project.

There’s discussion that even top apps might be avoiding the move to targeting Marshmallow so as to avoid the complications. I have one such client project where I did some small changes that involved fixing on M devices but I didn’t have the time budget to go through the new permissions implications with my client. Hence the app stayed targeting Lollipop. I have another client who isn’t interested in M at all until it is seeing a greater uptake on devices. I suspect these scenarios are typical at the moment. However, most apps will one day have to ‘bite the bullet’.

This week’s Android Dev summit, particularly day 1, has some great recommendations on to how to handle the new permissions scheme. However, the real problems are with edge cases that can seriously bazooka your app. The first was an Android Dev summit audience question and involves what happens if the user taps “Don’t ask again” and the user then has to go to App… Settings to fix the problem, The Android team said that if this happens, you have lost the trust of your user and that’s that. However, Manideep Polireddi has some thoughts on how you might recover from this situation. Another edge case is if the user does “Reset app preferences” as explained by the CommonsBlogs.

Stepping back, is all this worth it? What is this all about? There’s a very recent article on the Forrester blog where it says…

“Consumers are more willing than ever to walk away from your business if you fail to protect their data and privacy”

Some might say that this is something for older users and that younger millenials have a different attitude to privacy. However, the Forrester research shows this isn’t true…

forresterprivacy Forrester says that privacy concerns are very much alive and are set to be a competitive differentiator in years to come. For apps, this means that those that do it well will be rewarded with better user retention.

App Retention Linked to Contextual Content

mobileworldliveThere’s an article at Mobile World Live (by the GSMA) titled Personalisation Key to App Stickiness. We all know user retention is just, if not more, important as user acquisition so how do we achieve this?

The survey by Localytics found that mobile users will start a new app on average 4.5 times before potentially stop using it.

The key is…

“Personalied app content and marketing messages, tailored to their specific behaviour, location and intentions.”

Hence, it’s crucial we use the first app launches to discover context for displaying the appropriate content in those and future app launches. For example, if the app continues to show ’empty’ states then it’s unlikely to be used again. However, what if the app shows nothing because it’s driven by external events such as location, iBeacons or notifications? It’s important to allow the user to initially populate the data somehow, perhaps via browsing limited content or via injected dummy events. That way, the user will get to see how the app can provide value.