I know you already know about the importance of retention. I bet you’ve had it with general retention articles. I know I have. So excuse me for not covering the basics of the need to take care of the app’s UI, bug fixes, and performance of communication channels. Instead, I want to talk about retention from a different angle – 3rd party SDKs. Almost everyone uses them. But did you know they may have dramatic impact on your retention, good or bad?
Most SDKs are there to help us, in the app business. And they do. Still, sometimes, 3rd party SDKs can actually damage your user retention. Hearing feedback from many app developers using SDKs, I have identified the three main weakness points of SDKs and user retention – Permission pitfalls, performance problems and UX issues. Fortunately, there are ways around each of these.
Permissions are always a bit of a nuisance for users. Some of them don’t even fully understand the mechanism. Yet the gods of smartphones chose to give them control for a reason – anyone deserves to have the right to say which app can access what on his device.
So it stands to reason that the key is to try and minimize the permissions your app requests. Why? Because many users are scared and suspicious. And the OS description of permissions can sometimes be intimidating (who doesn’t get Goosebumps seeing an app asking to “read phone status and identity”?). So it’s best to only ask for what you really need, and when the user gets to grant permissions at runtime, it’s even better to ask for permissions when it’s relevant, and at the right context.
Now some SDKs will tell you to add new permissions to your app for them to work. Complying automatically can hurt your retention.
How? In pre-Marshmallow Android, for instance, existing app users (your aftermarket) will not get an auto update to the new version, and they will need to manually approve the new permissions. We’re so used to apps that are automatically updated, that manually installing updates gets delayed, if it even happens at all. So we are left with: users who don’t enjoy the benefits of the new version and its’ new features; users who are left with bugs that can annoy them and therefore they will uninstall; users that finally do decide to update but then get an unpleasant reminder of the existence of permission requests.
So when an SDK wants you to add a permission, stop and think:
- Why is this SDK asking for those permissions? How will your users react? What are the chances of them installing and then not uninstalling you with this permission?
- Are you even allowed to add that permission to your app? If you’re developing a kids app, for instance, you can’t very well ask them for their location (you must comply with COPPA regulations: location request is a big no-no).
- Is this particular SDK worth the trouble? Maybe the same functionality can be maintained without adding permissions? Explore other SDKs, and you may find a better option.
- Can you implement the SDK you are after and have it work properly without granting extra permissions? Consult with the SDK company support team and ask them directly. Our In-app protection module allows app developers to turn off specific SDK permissions on the fly while still keeping it active. Could be handy in many situations, besides our focus here.
- Can you make a convincing case to your users of why you need this permission?
- How can you get your existing users to update, if there’s no way around adding permissions? You can send them update reminders via emails or through the app (push notification and in-app messages), but be careful not to badger them, or you might annoy them enough to uninstall.
- Can you benefit from our live data analytics? It’s one thing for your users to allow your app to access their location, it’s another thing to see it constantly reading the location. Learn how your SDKs actually use (or abuse) the permissions you and your users granted them.
Excellent performance indicators are critical for user retention. You kill yourself (quite rightfully) over upload time, minimal crashes, minimal battery waste and so forth. Yes, users have very little patience for poor performance. Imagine that the app you are using keeps crashing, is just too slow, or kills your battery in minutes. Will you keep using it? Well, I vote NO.
Now imagine that you jumped over hoops with your R&D and QA teams in order to have the best performance indicators you can have, just to have a foreign SDK crash your party (literally), dramatically slow your app by increasing the start time, or even greedily slurp up the user’s battery power. Uncool.
Unfortunately, some SDKs cause these exact performance issues, and it’s not as un-common as you might think. Actually, we ran a survey among app developers (variety of scales and app categories), and every single one of them reported that they experienced functionality issues that were SDK related. Most complains were on crashes caused by SDKs and on SDKs slowing the app and damaging its performance.
The key here is initial prevention – and it’s absolutely essential to run checks and investigations about SDKs before you implement them into your app. You should definitely go over SDKs reviews. For keeping up with SDK management and for protecting yourself in case of a critical performance issue, wrap your app with our in-app SDK protection, and get real time alerts for performance issues, data leakage or other SDK related risks that impact your app. Most importantly, you will also be able to turn off SDKs on the fly, with no need for a version update, so you can make sure the retention isn’t damaged.
Some SDKs might affect the app user experience or interface. Think of an app that integrates a monetization SDK. All is well, users use the app, the app makes money from ads.
Well, what happens if this particular SDK interferes with the app UI by serving a new ad (interstitial to be exact, as I am telling a true story) every time the user moves the device? Uninstall rate will skyrocket.
We’ve all experienced a ‘REAL annoying’ ad serving behavior. We usually close the app or uninstall it angrily. When we use an app we never bother to think “ho, it might be an SDK, poor app developer”. We blame the entire app for the bad experience, holding said app developer responsible.
It’s your role as an app developer to make sure your monetization operation (or any other) does not come at the expense of your retention.
SDKS are NOT the big bad wolf!
SDKs are there to help your app achieve the best possible results. In many cases, they help you keep users around. Some SDKs are designed to actively increase user retention.
You may think “why rely on SDKs? Why not develop everything in-house?” Well, you will lose precious development time, and let’s face it, you’ll probably never be as good as some SDKs that focus on a specific enrichment, that this functionality is its’ entire bread and butter. It’s just not possible to keep up with the pace.
It comes down to this: SDKs can be extremely beneficial for your app, but it’s always good to sleep with one eye open and stay vigilant.