As you might know user retention is king; you’ve built a great product that solves a real problem and you’ve spend thousands of dollars and thousands of man hours to acquire new customers through various mediums but at the end of the day, you have some customers who stop using your product.
On mobile this indicates they’ve deleted / uninstall your app, some might be for gracious reasons and others might be disastrous. How do you know which segment you fall into ?
In this post I’ll highlight the steps I took to get insights on customers who stopped using our service(uninstalled) and how we tried to get them back.
Why traditional analytics didn’t work
We needed a way to find out who uninstalled our app, as far as I know, most analytics services can’t track this information since iOS doesn’t provide a way to do this and because there’s no concrete way to track this type of information.
We use Mixpanel peoples analytics in-house to track a bunch of stuffs which works great and you can also set up notifications for users who have been inactive for a certain period of time to re-engage them, among others.
Since our app is strictly used for calling, we’ve noticed people are not as engaged, compared to say, a social app etc. I personally use our app only a handful of times a month to keep in touch with family and friends overseas. This makes tracking in-active users ineffective for us.
Looking for a better way: Epiphany.
The idea to actually dig deeper and track this information occurred to me when I decided to cancel my TV subscription since it was setting me back about $99 a month. I decided to purchase a Roku and Chrome Cast because I figured a Netflix subscription was good enough for me, so I called in and requested for a cancellation, a day after the cable guy came over for the disconnection and everything was done.
All well and good right ? Nope, I got a call the next day from the same cable company offering a 1 year offer I couldn’t refuse, talk about saving 80%. As you can see, they had a very effective and solid retention strategy in place.
So fast forward a couple weeks, the solution I came up it was pretty simple and straightforward but highly effective. Let’s get started,
Background Updates
First off, I needed a way for the app to stay in communicating with our server by sending heartbeats at certain intervals, so we know it’s still alive even when not in use.
Background updates provides you a way to wake your app in the background to perform short-lived tasks. This was introduced in iOS 7 so it seemed like a perfect candidate. Since this feature was not meant to be used as a way to track users but to improve the overall iOS apps user experience. I decided to keep things healthy by opting-in to have it wake the app only once or twice a day.
When your app is woken up in the background, you have 30 seconds to perform any updates you like, this was more than enough since all I had to do was ping the server to tell it the app was alive on the user’s device.
Limitations
Although background updates is highly effective; there was one fatal flaw you have to keep in mind, if a user decides to kill/close your app from the app switcher; this will effectively stop future background updates until the user manually opens your app again, which totally makes sense. That’s where push notifications comes in:
Push Notifications
Initially I wanted to use silent notifications, but I came to the realization that it had the same characteristics as background updates meaning if a user decides to kill/close your app, they’ll stop receiving silent notifications until it’s manually re-opened. So I ended up using user notifications.
When we stop receiving heartbeats from our app after a couple days, this indicates a couple of things as happened, either:
- The user has been offline for a few days.
- The user disabled background updates for our app (less likely).
- The user as killed the app from the app switcher.
- The app has been deleted.
To get a better hypothesis of what actually happened, we send out push notifications a few times to the devices that stopped sending us heartbeats. This is useful because we can then query something called, “Feedback Service” to get more information of what’s happening.
APNs Feedback Service
The Feedback Service gives you an overview of devices were your push notification could not be delivered because the app is no longer on the user’s device. As you can see, this immediately eliminates the first few hypothesis we had above because:
A device will not be listed in the feedback service if the user’s device is offline because when they’re come back online they’d get the push notification or if the user happened to disable push notification for the app it would be ignored.
Similarly, they’d still get the user notification weather or not they killed the app from the switcher or disabled background updates.
Now you might ask, using only push notifications could have been effective enough to find out who uninstalled your app. The reason is simply, UX. You don’t want to keep buzzing your entire user-base every couple days with notifications asking them to come back or re-engage them. I personally delete an app that behaves this way.
Since you have to send notifications a couple of times before they get listed in the feedback service, it’s a good idea to limit those notifications to a specific set of users who stopped sending heartbeats.
Got it?
Time to re-engage
Now we’ve collected a list of users who have stopped sending updates and have also been listed in the feedback service, so now we know they’ve decided to stop using our service. Since a lot of effort went into having them use our service in the first place, we need to know why they abandoned us.
Reaching out: Email
Our primary method for re-engagement is email, which is great because we can track who read our emails and those who didn’t.
You can see the email below, we’ve also experimented with others using polls and such: Key take away, make sure you make it as personal as possible.
Subject: How was your Cardup experience !Body: Hello {Name},Hope you’re having a great day. Richard from Cardup here, I noticed you recently stopped using our service and I was hoping to get some insights into why you made that decision.I’d like for you to understand, I'll make it my personal mission to find a solution to your problem if you do happen to have one.Please do reach out anytime.Sincerely,Richard Aberefa, Founder.
With this we were able to get a bunch of unbelievable feedback into why they deleted our app. Also, their response was pretty proactive as if they’ve been waiting for someone to rant to, but overall they felt grateful for reaching out promptly. We then made it our mission to address the problems as soon as possible.
Some of the issues were similar to other feedbacks we’ve gotten, some were feature requests we had in the pipeline, pricing etc.
By only tracking inactive users, we wouldn’t have gotten the amazing feedbacks we did because we could have mistaken a user who wasn’t using our app at that point with someone who was experiencing a problem then deciding to delete it and such.
In the end we are averaging about several hundred users who come back to use our service every month using this method. We’ve then decided to build a more robust implementation since our previous implementation was a trial run.
Hope this helps other adventurous folks, Have fun.
