With some types of mobile app, getting a user to download it is just the beginning of the problem. If the application is going to be personalised to a user’s preferences, or allow them to interact with others via some online service, then they’ll need to provide some data before they can start using it. Typically the more information a user provides about themselves, the better job an app or service can do of tailoring the experience to them. Unfortunately, the more steps a user has to go through before they can start using an app, the less likely they are to complete the signup process. Getting this wrong can catastrophically alter the economics of user acquisition.
Falling at the first hurdle
Vibhu Norby, co-founder of Everyme, recently shared some data about his experience of getting this wrong, along with his analysis of Path’s results in the same category. It’s a great warning to others to avoid friction in the signup process:
“Let me share with you some rough numbers from our mobile-first startup. Out of 300,000+ downloads and 250,000 unique website visitors, 200,000 people have signed up. So right away, chop off 60% of your audience whom are just window-shopping.”
Anecdotes from various apps with even larger audiences suggest this is a fairly typical drop-out rate if users need to sign-in/register for the app when they don’t already have an account. If it’s possible to let the user start using at least parts of the app (e.g. browse around some content) without signing in) then it’s a good idea to enable that option. Unfortunately, with something like a social network it’s not really possible to show relevant content before someone has signed in and identified some connections.
A sign-up step too far
“We used to have a screen where users could input their phone numbers and emails to help other users find them better. Out of 200,000, chop off 25% who don’t have the patience for that or are scared that we will sell their phone number. We also used to have a social network sign-in screen to automatically create groups for our users. Another 25% don’t want to sign-in to a social network, don’t see the skip button, or get bored by this time. We have since removed those two steps, but it took us a while to get there because we had to re-engineer how onboarding worked.”
A social network sign-in screen that lets the app trawl details from other networks you belong to should be contrasted with allowing users to sign-in to your app with an account they already have elsewhere via OAuth. The latter can actually reduce friction in onboarding significantly – without going overboard on permissions you can fetch lots of user info from their existing account. However, in this case a new social network is unlikely to want to be dependent on one of the major existing ones for user identity management and the social graph (get very successful and you can pretty much guarantee your access will be cut off unless you’re providing significant value back the other way).
I’ve signed up, now what?
“So that takes our original 550,000 eyeballs + people to 100,000 users. Now that the user is in our app and has an account, we want them to create a group and add their friends or family to the group. 25% of users won’t create a group and another 25% won’t add anybody to the group they created. Now we need them to share something to those people. Then the people they share with need to see the value, understand what is going on, and go through most of the steps above.
At best, we retain 5% of users through the entire onboarding process. Attempts to fix it have raised it only nominally. We are not alone on that count even amongst apps with much better onboarding and many more app versions than our own.”
A very similar figure is derived for Path, which should benefit from it’s CEO’s experience as an early Facebook employee.
“With 5-10 million downloads, Path has retained less than 200,000/users a day according to AppData.”
The economics of onboarding
On the one hand, this simply shows the difficulty of bootstrapping a new social network on mobile devices. However the lessons are more broadly applicable. Getting someone to try a new app could be seen as a battle between their curiosity and boredom threshold. By the time they’ve downloaded and installed the app, boredom is already close to winning with very little room for further friction. If we create some rules of thumb from the results of large well funded efforts like this we can use them to reason about user acquisition and monetization for apps that need a user login:
1) At least half of all downloads will never actually sign up and start using the app
2) Each and every step in your sign-in process is going to cut about 25% of your potential users
If you calculate a cost per download figure, you need to double it for a user acquisition cost. For every additional step beyond basic sign-up in your registration process, increase that cost again by 33%. It’s tempting to conclude that you should avoid sign-in and at least complex registration funnels at all costs, however, there is a trade-off. According to Flurry’s data, the types of app that typically need users to be logged in are also the ones with the highest levels of engagement. If the social components of an app cause it to be used twice as often then it might actually pay off to include an extra registration step, particularly for an ad-funded app that could use the data given by the user to improve the ad targeting. This only goes so far – at anything like 5% retention it’s unlikely to work for anyone, in Vibhu’s words:
“If you paid Google’s $1 CPC for people to enter your funnel, you’re really paying $20 per user and you will never recoup that cost.”
Make sure you can test and iterate
The conclusion that Everyme drew was that native mobile apps simply didn’t allow fast enough iteration to fix issues, nor the ability to test different versions so they’ve decided to try a web focussed product with companion apps instead. This is a fairly extreme conclusion and might be throwing the baby out with the bathwater. As we’ve discussed previously iteration speed is not all or nothing with web vs native and native A/B testing solutions do exist. Why not present the onboarding funnel in a webview until it’s been thoroughly tested and optimized, then replace with native later to improve the user experience if necessary? If you want to capture a lot of information from the user to fill out a profile then it’s never going to be the most pleasant experience on a small screen with touch input – it’s worth considering an incremental approach to gathering the information or giving the user the option to complete their profile on larger screened device at a later time. That said, downloading an app is always going to be a source of friction. Where it’s possible and economically feasible to deliver users the core experience via the (desktop and mobile) web, with an option to download native apps for an enhanced experience then perhaps you have the best of both worlds.
