In my last article, From idea to app store, one of the points I emphasised was that for your first version of an app, you should only release something that is a Minimum Viable Product. Essentially, don’t do too much up front because your users will likely have different thoughts on what works and what doesn’t.
Once your app is live, the next development stage is to analyse the usage data to see how users are using your app.
Firstly, you’ll need to ensure that you’ve built in some form of analytics into the app. There are dozens, if not more, pre-built and free to use frameworks to do this. There’s Google’s Firebase, Microsoft’s Mobile App Center, Flurry Analytics and lots more. They each offer their own features but at a minimum you should be looking to capture the following at a minimum:
There’s a lot more that’s worth capturing, but at a minimum you should ensure your analytics framework choice can capture the above in order to effectively inform your next steps
Analytics are only really valuable if you’re tracking the right things. Look at what your app does and what you want to be aware of when and how users use it.
Look at all the possible actions a user can take in the app and decide what data you want to capture for each.
It’s also important to note relevant privacy laws when deciding what information you track. At a minimum, users should be provided the opportunity to opt-out of being part of analytics.
I won’t go into any depth around crash reporting in this article, but it’s worth considering implementing a crash reporting solution as part of your overall analytics strategy so that you’re notified immediately of any issues as they arise in order to be in the best possible position to respond to problems if and when they occur.
As tempting as it is to stay glued to your screen watching your users in real time and seeing what they’re doing, it’s important to wait for enough users to take enough actions to get real useable intel.
How long users use the app and how many users there are is different for every app, but ensure you’ve got a fair size pool of real users: don’t just rely on friends and family who may have downloaded your app, get real data.
While the capture analytics data will guide you, it’s important not to forget the direct user feedback as well. If something is a hassle or not working for users, chances are someone is going to voice that directly to you.
Unfortunately, people are more likely to vent their grievances rather than tell you what you’re doing well. Reading what people are saying and looking at the analytics to see how people are using your app will provide valuable insights.
We’re only human, and it’s tempting to be guided by our emotions and “gut feels”, but this isn’t a good idea when making business decisions on the direction to take a product.
Take a step back and try to view the app and data objectively. Don’t think so much of it as “your app” but as a product that has a purpose and provides benefit. Based on how users are using your app see which areas require attention. If users are spending most of their time on one or two screens, focus on making them more stable and easier to use.
You’ll likely have ideas for the next big features, and while they may be good ideas, if users are getting frustrated by something on a heavily used area you need to focus on getting that right first. Fixing a frequent crash or irritation with the interface for example, is more worthwhile than adding new features that may have the same problem.
As I’ve mentioned before, always iterate. After releasing new versions of your app go through the steps above and capture, analyse and pivot your app direction accordingly. Look at how users have responded to new app versions as you make changes and see which directions are positive and negative.
As your app grows so will your analytics and it’s important to constantly base your decisions on the actual data coming in rather than feelings or your personal opinions.