In the recent article about the “Dos And Don’ts For On-Boarding Walkthroughs On Mobile,” I covered an important part of on-boarding, namely walkthroughs. Make sure to read it for the bigger on-boarding picture.
Today I will run through different communication channels like email, app notifications and SMS in order to keep up the momentum that your app has created throughout the sign-up and following walkthrough.
Nielsen data from 2012 demonstrates that today developers are competing with at least 41 apps that users keep or frequently use on their devices (probably more in 2014). Although app retention is growing constantly according to Localytics as 31% of apps are used more than 10x per month, 35% of apps are opened just 1-2x (in their entire lifetime on a phone) and the remaining 34% achieve 3-9 sessions.
I have recently been iterating and testing on-boarding strategies for a social product and hence got a fairly fresh perspective. We ran tests with email notifications within a 3-week timeframe where we compared 2 weekly cohorts. Cohort A only received a “Welcome” email whereas cohort B received 2 emails more within the 2 weeks that followed.
About 40% more users kept coming back from cohort B compared to those from cohort A (platform did not matter much.) For your perspective: neither of the apps, nor the walkthroughs or user acquisition endeavors changed. Convinced? Let’s get to the details.
What Are You Asking For on Sign-Up?
– Email address
– Phone number
– Consent to receive app notifications (remote or in-app)
(As a side-note: Do not go down the wrong path and ask users for every little detail during sign-up. Ask only for what you truly need during the sign-up process, with this you are providing value to the user and eventually you can start to ask for more.)
How do you use the channel you have indirectly chosen as best as possible to entice users to come back? Keep reading.
A Multi-Channel Approach
The status quo is that most apps require the user to register with their email, however, apps that primarily need the users’ phone number are quite plentiful as well.
Apart from the US where SMS is essentially free, one should examine whether the amount of additional users gained is worth the additional cost on top of all user acquisition and marketing efforts.
The limitation of 160 characters can be used to a developers benefit because it forces one to focus on the important and get rid of the extraneous.
The great benefit with SMS is that people who get invited will most likely use that number to sign up for your service (which is a big deal compared to email, see below) and you can even ping people no matter what even if some have uninstalled your app.
Engagement through SMS though is not void of obstacles. Although latency may not be a big deal, SMS delivery is far from guaranteed. It also depends on what you are willing to pay but you can expect a 2-5% non-delivery rate for western countries (the rate for more remote parts of the world is a great deal higher), so factor this in.
You can also change the sender name to make your SMS more personal (to get it in line with email and push messages) but you cannot track opening rates.
If you care about opening rates then email will be at your service. Email is a no-brainer because email is basically “free” to send (not considering the cost for email services). You can easily re-send emails once, twice or even more frequently to entice a user to come back (I have heard people saying 7 times is the magic number).
You will probably not try this with SMS, it will just get too expensive. The ability to track opening rates is undoubtedly a benefit that helps to test subject lines but otherwise could be considered more like a BS metric (Hello MailChimp;) because you cannot depict a users’ action thereafter, so it is not actionable.
Nowadays emails can be used in similar ways as push notifications because initially many users keep email notifications switched on and they appear as simple push messages (getting back in line also with SMS). The biggest issue though, is what to communicate since you may not know what device a user is utilizing to open that email.
Compared to SMS and push notifications, email gives you more flexibility in terms of content. It can seem tempting to include more content however because space is basically limitless. I see many companies going too far here including whatever “looks nice and seems important” but again less is more.
You just want to entice a user to open the app and get active there. The best result in my experience has been achieved by optimizing for mobile usage. Meaning; dedicate a clear action button that leads the user into the app if on a mobile device or to a dedicated website if the user interacts with email from within their desktop browser.
A very good example of this is Facebook’s email notification: You do not even see what a friend has done, the email just shows you the name of that friend and a clear action button.
Constant tracking of those email endeavors is fairly common but not as straight-forward as things could be because you always have to monitor more than one and then relate those metrics with one another. This may not sound too problematic right now but things get more complex down the road when you start tracking more and more “half-baked” metrics.
A side-note about email invitations: The issue with emails sent to non-users (compared to SMS) is that you cannot be sure whether the same addresses will be used to sign up for your service. A user may send an invitation to a friends’ work email address just because the user lacks the personal one. The invited person may use another email to register for your service resulting in a broken link between invitation and registration. Those add up and result in a constant perception that you cannot really trust those numbers. Not helpful.
Push notifications, in theory, seem to be the sure way to reach the 2+ billion proud owners of a capable smartphone and the many soon-to-be ones. They can prompt users at the right place, the right time while showing them the right piece of information in that moment.
In reality though ruthless requests made by almost every app developer have made users very sensitive to blindly accept push notifications (especially on iOS).
I find myself repeatedly refusing notification requests (on random apps) although I have a big professional incentive for allowance thereof (to discover new techniques and ways of doing things).
It is a different story on Android because users have to dig deep into the settings panel to shut them off explicitly. But what to do on iOS when users do not accept your notification request? Local reminders (in-apps) come in handy.
Remote or Local (Push Notifications)
Many people keep talking about push notifications without being very precise about their nature, remote or local aka in-app. It makes a big difference regarding ones technical setup and the user experience.
For example, content from in-app messages will come across as intrusive and out-of-context if sent to users that have not opened your app within the past few months.
Generally, you use remote notifications (that could even be email for that matter) in order to request or remind a user to open the app and engage (to do action X).
Once in the app in-app notifications are your way to provide support. Show a user where to start and lead them the way to provide the most complete end-to-end user experience possible.
The best general strategy is to reduce the complexity and to start with a bare minimum of actions that initiate notifications. Focus on one channel that notifies the user and then test copy, frequency and finally the action that the notification initiates combined with deep linking.
As you can see on–boarding and its engagement channels are a fairly broad playing field. The perspective: “Ok, we have notifications implemented, let’s use it for everything” will not get your business anywhere.
Testing and iterating at the on-boarding stage is the best playground to start off from, you will be able to use that knowledge for your user retention efforts down the road. It presents an almost sure way to users’ continuous engagement with your app.
You find the 1st part of the post here: The Dos and Don’ts for On-Boarding Walkthroughs on Mobile.
This post originally appeared on AndreeHuk.com.
Andree Huk is a co-founder at Mobilefirm.co. His experiences include:
- Growing UpTalk to 5M+ active users.
- Advising on product direction, growth, and user experience for mobile startups.
- Co-hosting Techdings.com, a podcast that interviews experienced technology leaders.
Call Andree today to talk about mobile app development, user engagement, and growth.
Photo Credit: Shutterstock/Dennis van de Water, Gemandacon, Ivan Kruk