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. Now, 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.
As it turns out this will be a fairly long post with quite a few details so I appreciate your interest and patience.
I have recently been iterating and testing on-boarding strategies for a new 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.
The result: About 40% more users kept coming back to 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: As covered before in an article about Gradual Engagement, 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.
The Pro’s And Con’s
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 and WhatsApp is as good as unknown, 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.
The biggest issue though, is what to communicate since you may not know what device a user is utilizing to open that email.
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.
Engage and growth
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.
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
Remote or Local
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.
What I have seen companies get wrong with in-apps or general notifications is the sheer amount. Users are not being catered to users’ actions and lastly the carelessness with which designers and developers treat them (e.g. local ones: asking for a confirmation every single time). The way to go is to determine - for the user - whether to confirm or acknowledge actions (Android Design has a very useful flow chart depicting when to confirm and when to acknowledge). It is very easy to fall victim to this very serious UX bug because it is technically so easy to do, e.g. whatever the user action just show an AlertView (iOS). The user experience will take a big hit if not executed by a user experience designer or UX-skilled developer who has the users’ perspective in mind. Furthermore, those do not need to show up as a pop-up. You can simply have them appear at the top or bottom end of the UI, smooth and non-interrupting.
The coolest thing about in-app notifications is the ability to track the initiation and the action immediately within the same environment with the same analytics tool.
The coolest thing about in-app notifications is the ability to track the initiation and the action immediately within the same environment with the same analytics tool. You do not need to go down complicated paths tying to connect both ends. This will be exceedingly useful because it is very hands-on and you do not need to move back and forth between analytics and other tools. To my experience, unfortunately, many app companies are ignoring in-app notifications. If they are integrated in clever ways, they work very well.
A huge benefit of push messages in general is their timeliness, though you can even further increase this effect by making them contextual in terms of copy and action. Users on-the-go have more free time on their hands which can lead to higher engagement. Imagine your metro or bus app with which you just checked a route. While you are taking the route the app tracks your location in the background and notifies you a couple of stops before you have to get off. I’d say “Pretty cool.” Anyone can remember that instance in which one was focused on their mobile and missed the moment to get off.
In terms of timeliness, take an educated guess mixed with data from your analytics tool to figure when notifications shall arrive on a users’ phone. For example, an event app will achieve higher engagement levels when sending timed notifications on Thursday and Friday evenings granted that you localize these efforts and don’t ping other users on the other side of the planet during their morning hours. Another example from an app that I personally use: Lumosity should recognize that I keep using the app during the evening, so why do they ping me at random times? The chance to engage me again is increased by sending a remote push around those evening hours.
The biggest issue with remote notifications is that deep linking isn’t working properly, so a click on a notification does not lead the user into the right place within the app.
Android puts even more power into your hands. You can append an action directly to the notification as shown in the pictures below where Duolingo integrates “Instant Follow”. In fact, Airbnb does a pretty good job too: Time, date and price directly included, all of the information that I really care about. However, appending a direct action like “Accept” could make the notification even more effective because it encourages people to get the reservation done sooner. The biggest issue with remote notifications is that deep linking isn’t working properly, so a click on a notification does not lead the user into the right place within the app. 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.
Many thanks to Alex Prushynskyy, Jordan Choo, Radek Grabarek, Andrew Thompson and Barry White for reading drafts of this post.
• • •I work at blended.io. We love to support innovative companies envision, conceptualize and realize competitive products & services that solve user problems and Jobs-to-be-done - especially in blockchain, fintech and investtech!
What their clients say:
“I really enjoyed the collaboration and appreciated their flexibility to adapt when requirements changed. The team does have the right blend of UX and engineering skills."
Deb Misra, Senior VP Engineering at fsinvestments.com