Mobile apps have come a long way in the past few years. We’ve gone from simple utility apps (calculators, reminders, flashlights, etc.) to social networks and enterprise level software, all served up from the phone in your pocket. These days it’s not uncommon for someone to record, edit, and publish a professional video all on their smart phone.
With the rising complexity of apps comes a need to keep track of user data, and with it, the birth of the login. Any app that holds data about users needs those users to authenticate themselves in some way or another.
That said – login is a point of tension for new users. No one wants to do it, and it can end up keeping a big chunk of potential users from using your app. Here’s one way to check and see if this problem is affecting your app:
Is Your App’s Login Affecting the App Adoption Rate?
- Go into iTunes Connect (or better yet, connect your iTunes Connect account to App Annie) and check how many downloads you had in the last month.
- Log into your analytics tool (Parse, Google Analytics, Flurry, etc) and see how many new users you had in the last month.
The ratio of #2 / #1 shows the amount of users who downloaded your app who actually ended up logging in. I’d bet this percentage is much lower than you’d expect.
The good news here is the lower your login rate is, the more room you have for optimization. There are two main factors that might hold someone who downloads your app from logging in:
- Your user got distracted and forgot to open your app after downloading it.
- Your user wasn’t sold on the benefits of logging in when they hit your login screen.
Let me share with you a case study of the login optimizations I have done in the last few months, and compare three different methods of attempting to get users to log in.
Real-World Login Case Study
When we shot our MVP out on the market, we had an optional login. We asked for the user’s phone number and first name. If the user went to use the app’s main feature, we would prompt the login again. Quick and easy. It got the product off the ground, and had a 75% conversion rate.
A few months down the line we decided we needed to introduce Facebook login to personalize the in-app experience and “make login easier.” After all, now the user only has to press one button: Login with Facebook.
We recognized we’d be losing out on a certain percentage of users who a) didn’t have Facebook or b) weren’t comfortable with giving their basic Facebook information to us, but decided it was worth the tradeoff of giving the best in-app user experience. This time around we made Facebook login required. All the login screen included was the name of the app, an animation, and the login button.
We had made the app better, but at the expense of acquiring a large chunk of new users.
So we decided to optimize. How can we communicate the benefit of logging in with Facebook?
We introduced a paginated table view, where the user could swipe through four pages to learn about the app (inspired by onboarding like Slack for iOS). We were upfront with users about what we would and would not do with their Facebook data. We showcased the media attention the app had received to build social proof, and even included a video. On the last page, we asked for users to log in with Facebook.
Since we added a paginated user onboarding, percentage of new users who logged in rose to 73%.
The big takeaway here is this:
- Think hard about whether you need users to log in or not.
- Consider the target market – and what kind of login they will be most receptive to.
- When requiring login, be sure to teach the users about why they should log in (“what’s in it for me?”).
- Optimize, optimize, optimize. Every release, try to test out at least a small tweak in your onboarding process and measure the results.
Have experience optimizing your app’s onboarding? Let’s chat in the comments.