Developers that don't track mobile app health will get little insight into the user experience. Learn these effective strategies to track and understand mobile app performance metrics.
Imagine that new one-star reviews start appearing at an alarming rate on your Android application in the Google Play Store claiming it doesn't work after the latest update. It's not clear what the problem is because users don't care to include details.
One of the main challenges of mobile apps is that they are ... well, mobile. Users download these apps from an app store, and from that moment onward, applications become autonomous because, as a developer, you don't have access to users' devices. You can't even assume that these devices have a stable internet connection.
The autonomy of mobile apps makes it difficult to track their health -- but it's an important task nonetheless. You must assume that there will be bugs that can vary in severity. They might be so harmless and subtle that no one will ever notice them -- or so critical and fatal that they crash the application during the most important workflows.
Here are several strategies to track mobile app performance metrics.
How to track mobile app crashes
Crashes are among the most severe failures that users can experience with mobile apps. Luckily, it is simple to track crashes remotely.
Mobile apps strategy helps customers, employees to compete
Watch this webcast to learn of the many benefits mobile offers to businesses, and understand the approach of go mobile or get left behind.
Google and Apple automatically perform basic tracking of application
crashes
for Android and iOS and share crash reports with app developers. It takes very little effort to gain access to these capabilities through the Google Play Console for Android or Xcode for iOS.
In addition to native crash reporting capabilities, there is a wide selection of third-party crash reporting products, such as Crashlytics, HockeyApp, Firebase
and
Instabug. Most third-party products support both Android and iOS, and they add meta information to help developers debug. Some products even prompt users in real time for additional mobile app performance metrics related to crashes.
Track non-fatal errors
Crashes are fatal errors that cause the app to stop running. Not all errors are fatal, however. One example of a non-fatal error is when the app detects that the server violates a communication schema.
Let's say your app communicates with a server over HTTPS. In this case, both the app and the server should structure the data attached to the HTTP requests and responses in a specific way that the client and server teams chose. I call this structure a schema.
What happens if the server changes the schema without notifying the client? This change could have no effect -- or it could break part of an app's functionality, cause the app to crash or lead to some other invalid behavior that will be difficult to debug.
To protect the app from potentially destructive consequences of a schema violation, you can implement an anti-corruption layer that will process the data retrieved from the server and make sure that it is structured according to the expected schema. You can track these non-fatal errors using the same tools that report crashes. Although the app won't crash due to non-fatal errors, you should still report them as high-severity issues.
Track other mobile app performance metrics
There are a variety of other mobile app performance metrics that a developer should track. Here are a few examples:
Unpredictable errors. Errors that don't lead to app crashes are difficult to track. If you're lucky, users will describe their experience when they give your app feedback -- but don't count on it.
However, you can detect these errors using proxy metrics. Proxy metrics are measurable quantities that correlate with either user satisfaction or app performance. You probably already measure some of them for the purposes of business analytics and user experience optimization.
Errors that don't lead to app crashes are difficult to track.
Business metrics.
Conversion
rate is a great example of a business metric that you can use to identify quality issues. Imagine that you release a new version of the application and the conversion rate in one specific workflow drops significantly. There were no user interface changes that could explain this drop, and your error reports are empty. This drop in conversion could indicate an unexpected error that silently affects users.
Now, you can launch a full-blown investigation of a potential problem. You can track business metrics through various in-app analytics products, such as Firebase, Flurry Analytics
and
Mixpanel.
Performance metrics. A useful performance metric is the duration of server requests, which can give you important insights into how responsive the app is for users. However, it's important to not rely on averages to track performance.
Although the average duration of a server request is less than half a second, thousands of users can still experience unresponsiveness or even request timeouts. At the very least, track the total average and the average for the top and bottom users to see the difference in experiences between your average users and top/bottom users.
To track performance, you can use automated products, such as Firebase or New Relic, or do it semi-automatically by logging these metrics alongside business in-app analytics. Some developers even choose to roll out custom products using remote logging frameworks.
