Now, a new way to find and fix errors

When it comes to tracking app stability, you can always monitor the _crash-free_ indicator. The higher the percentage, the better. You don’t need to do anything extra to get the calculation — just make sure you’ve got the crash component activated in AppMetrica.

But a 100% crash-free value doesn’t mean the app works perfectly. Sometimes there’s no crash, but a button might not work, changes aren’t saved, experience awarded in a game isn’t counted — and your app loses favor among users.

Obviously, you want to find and fix these kinds of issues. You can rely on try and catch methods and the Errors report in AppMetrica for this purpose. Let’s look at what you can do in the new Errors report, now that it’s been completely overhauled.

What’s changed

We’ve updated the design. But that’s not all. We also added subsections for different operating systems and changed the error collection mechanism itself.

Android and iOS are now separate
The report is intended primarily for developers. Errors in the iOS version aren’t relevant to the Android developer. Besides that, on different platforms, the errors themselves look different. We took this into account and made a report for each OS:

Error dimensions
The report now automatically groups errors by event name, not by stack trace. A grouping identifier can be specified independently in order to group errors by it.

This puts the grouping of errors completely under your control. And inside an error, you now see helpful new fields like parameters, stack trace, text description, and nested errors:

How the new report helps you eliminate errors

Errors are now divided into subgroups for more precise classification:

Like crashes, errors can be closed, in the same way that cases are resolved in ticket systems. If an error occurs after it has been closed, the ticket now automatically reopens:

All this makes it easier to build processes and set priorities. It also helps you track the effectiveness of your work on errors and not lose sight of what only seemed to be fixed.

How error collection works

Unlike crashes, error messages are not sent automatically. The developer sets criteria for sending error notifications, typically by using exception handling methods. The _YandexMetrica.reportError_ method is used for transmitting them in the SDK. For detailed instructions on using the method, see the documentation for Android and iOS (Swift or ObjC).

Errors are stored on the device just like ordinary events, and are sent to the server according to the same rules.

How errors differ from crashes

If you use the crash report, you may have noticed that for errors there isn’t anything like a crash-free metric. This is normal, due to the very nature of the errors.

Crash-free is the proportion of sessions that did not end in failure. There can only be one crash per session, and for the user, all crashes look more or less the same. A crash is detected by the operating system as a crash. The system saves crash logs automatically. AppMetrica retrieves them, catalogs them, and makes them readable.

Knowing the percentage of sessions without errors isn’t much use in practice, since there may be multiple errors in a session. And what exactly should be considered an error is up to the developer to decide. If specific errors aren’t included when configuring error collection, they aren’t included in the report. But if the report is empty, it doesn’t mean there were no errors. Perhaps they simply weren’t caught. On the other hand, the percentage of crashes tells you a lot more about the stability of an app.

How to switch over to the new report

If you’ve been wanting to dig deeper into app stability, it’s time to update the SDK for iOS or Android and configure the new methods.

Already using the report? Share your thoughts in the Telegram chat!

–-

We focused on Errors to make it easier for you to focus on errors.

– The AppMetrica team