When an app crashes, it disrupts the user experience, may cause data loss, and worst of all, might even cause users to uninstall the app altogether. As developers, we do our best to minimize crashes, but no app is ever perfectly stable.
A crash can actually represent a great opportunity to improve an app and one of the best things we can do as developers is to measure our crashes and exceptions.
 |
| The crashes and exceptions report in Google Mobile App Analytics. |
Measuring crashes in your app can help you make better a product, make more money (if that’s your thing), and use your development resources more efficiently (especially if you are the only developer).
Google Mobile App Analytics offers easy-to-implement automated crash and exception measurement for Android and iOS as part of the V2 SDKs, as well as a host of reporting options to slice the data in context with all of the user engagement, goal completion, and in-app payments data you already know and love.
To help new developers get started, and to give existing developers some pointers, here are four things app developers should be doing today with Google Analytics crash and exception measurement:
1. Automate your crash measurement.
Want to measure app crashes but don’t want to deal with a complicated implementation? Fully automated crash measurement with Google Mobile App Analytics takes just one line of code to
implement for Android or
iOS:
<!-- Enable automatic crash measurement (Android) -->
<bool name=”ga_reportUncaughtExceptions”>true</bool>
// Enable automatic crash measurement (iOS).
[GAI sharedInstance].trackUncaughtExceptions = YES;
Implement automated crash measurement with just one line of code on Android or iOS.
Now each time your app crashes, the crash will be measured and sent to Google Analytics automatically. Try automated crash measurement now
for Android or
iOS.
2. Find out how stability is trending.
Are new releases increasing or reducing app crashes? Monitor the stability of your app from version to version by looking at crashes and exceptions by app version in the Crashes & Exceptions report.
If you are measuring the same app on two different platforms, like Android or iOS, you can break this view down further by selecting Platform as the secondary dimension.
 |
| View crashes and exceptions by app version number in the Crashes & Exceptions report. In this example, version 1.1.7 has crashed 7,285 times, while the latest version 2.0.0 has only crashed 91 times in the same period. Nice work dev team! |
To graph crashes for two or more versions over time, you can create advanced segments for each version number, and apply them both to the Crashes and Exceptions report.
 |
| See crashes by app version over time using advanced segments and the crash and exception report In this example, a bug fix pushed around January 24 caused significant reduction in crashes across both versions, but crashes persist for v1.1.7 that might warrant some additional investigation. |
3. Find out what crashes are costing you.
Do you know what app crashes are costing you? Find out what crashes cost in terms of both user engagement and dollars by using a custom segment.
By using a particular crash or exception as a custom segment, you can see how user engagement and in-app revenue may be impacted by a particular issue or set of issues.
 |
| Use custom segments to segment user experience and outcome data by crashes. This gives you some idea of what they might be costing you in users and in dollars. |
To set this up, you’ll want to create two custom segments: one that contains all the sessions in which the exception(s) occurred, and another baseline segment that contains all other sessions unaffected by the exception(s).
Once created, try applying both segments to your Goals or Ecommerce Overview reports to get a sense of how the exception(s) might affect user outcomes. Or, apply the segments to your Engagement overview report to see how the exception(s) might impact user engagement metrics.
4. Gain visibility into crashes at the device model level.
Do you know which device models are the most and least stable for your app? Developers can’t always test their app on all devices before launch. However, by using Custom Reports in Google Mobile App Analytics, you can monitor crashes and exception per device to find out where additional testing and bug fixes may be needed.
To see crashes and exceptions by device, create a custom report and use a dimension like Mobile Device Marketing Name, with Crashes and Exceptions as the metric.
 |
| See crashes by device by using a custom report. To get even more detail, add the Exception Description dimension as a secondary dimension. In this example, the high level view shows the Galaxy Note and Desire HD as device that might need additional testing before the next launch. |
5. (Advanced) What about caught exceptions? You should measure those too.
While caught exceptions won’t crash your app, they still may be valuable events to measure, especially when they might have an impact on user experience and outcomes.
For instance, if your app normally catches a server timeout exception when requesting user data, it might be useful to measure that caught exception to know how often a user’s request is not being fulfilled.
 |
| A caught exception is measured in Google Analytics using a custom description. In this example, a number of failed connections may indicate a backend problem and could be causing a poor user experience. Reducing the number of these caught exceptions could be a goal for the dev team in the next release. |
As always, please keep in mind that you should never send personally identifiable data (PII) to Google Analytics. Raw exception descriptions may contain PII and we don’t recommend sending them to Google Analytics for that reason.
Also note that there’s a 100 character limit on exception descriptions, so if you send your own descriptions, be sure to keep them concise.
Lastly, here are some links to resources you might find helpful when implementing crash and exception measurement in your app:
And for brand new users:
Posted by Andrew Wales, Google Analytics Developer Relations
