How to use the Google Play Store to check your release

One of the great things about GPC and Play Store is all the centralized features that allow you to manage distribution, monetization, and performance in one place. 

Pre-launch reports are one of such features that Google provides to help developers ensure their initial distribution is successful via pre-release testing. When you publish an app to internal, closed, or open testing via the Play Store, Google will automatically generate a pre-launch report. This helps developers proactively identify issues before their app reaches real users, and includes tests for stability, performance, and privacy issues. 

Google does this testing by installing and running your app on a number of real Android devices (running Android 9 and above) in their test lab, crawling the app and performing basic actions like typing, tapping, and swiping. The findings from a pre-launch report can help you nip potential performance issues in the bud before you fully go to market with your app

Once you’ve fully released your app on the Google Play Store, you can start analyzing the wealth of data provided by GPC to understand how it’s performing. 

GPC captures data on technical, behavioral, and commercial metrics. The latter two are probably the ones you’ll want to start looking at right away to understand how viable your app really is, out in the market. 

Among these key behavioral and commercial metrics are total app installs, number of new users acquired, user loss, and conversion rate: the proportion of store visitors that download your app after viewing its page. 

Additionally, you’ll want to look at your app’s average rating once you’ve gotten some user feedback on board. User feedback can be particularly helpful in identifying performance issues that you may not have caught during pre-release testing, as it’s impossible to account for all the unique scenarios and risks that exist out in the real world. 

If any of your behavioral or commercial metrics are trending down — and especially if you start to notice your ranking on the Play Store drop — this can be an indicator of underlying performance issues. 

Let’s look at how the Google Play Store can help you address these issues by capturing technical performance metrics.

Crashes and Application Not Responding (ANR) errors are worst-case scenarios when it comes to your app’s performance as they create a lot of user frustration. This can lead to bad reviews, drops in usage, and even uninstalls. As such, these are the two most critical metrics that Android developers look out for when evaluating their app’s technical performance via GPC. 

GPC offers a few different metrics for both crashes and ANRs to help developers understand the true scope of the problem. 

Google considers the negative impact of these issues on users to be so severe that it’s  established “bad behavior thresholds” for both user-perceived crashes and user-perceived ANRs. If your app exceeds these thresholds, it’s likely to be less discoverable on the Play Store and, in some cases, a warning could be shown on your app’s listing in order to set user expectations.

In addition to crashes and ANRs, GPC gives you insight into other technical metrics that can be causing a slow or janky experience for your users. While not as frustrating as a full-on crash, these performance issues are definitely worth tracking and trying to optimize. They are as follows: 

• Start-up time: The duration of time from when a user launches your app to when the first frames appear on the screen. Also known as “time to initial display.” Google sets thresholds for cold (5s or more), warm (2s or more), and hot (1s or more) startup times so you can track how often your app’s times are considered unacceptable. 
• Slow rendering (non-gaming apps): Measures how often users are experiencing sessions where more than 50% of frames with a render time greater than 16ms. An excess of slow-rendering frames can lead to app jank. Extremely slow frames that take more than 700ms to render are called frozen frames.
• Slow session rate (gaming apps): Measures the sessions where users experience more than 25% of frames running slower than 30FPS or 20FPS, depending on your benchmark. A good frame-rate is especially critical for maintaining an immersive game experience.

Monitoring key metrics is one thing, but how do you resolve the issues in your app that the Google Play Store is warning you about? Luckily, GPC does offer some useful tooling (plus a wealth of documentation and guides) that can help early developers along. 

One of the first steps to troubleshooting performance issues in your app is to look at where, if at all, this issue seems to be spiking. Is it happening exclusively on older versions of Android that only a subset of customers are still using? Is it disproportionately affecting certain models of devices? 

Analyzing an issue across these common groupings, like device or geography, is often an intuitive first step. The following dimensions are captured by Google and reported in your dashboard: 

• Artifact: The version of your app on which the issue occurred.
• Android version (SDK): The Android OS version reported by the user’s device.
• Form factor: The type of device on which the app was run (for example, phone, tablet, TV, wearable, etc.).
• Device model: A high-level description of the device, consisting of a unique brand and device identifier, for example, “Google oriole.” A single device model may have variants with different Android versions, RAM, storage or system on chip (SoC).
• Country/region: The location reported by the user’s device at the time of the issue.

In the vast majority of cases, analyzing an issue across dimensions is simply not enough to understand what’s causing it. In these cases, you’ll have to start using more advanced analysis, some of which is available via GPC and other affiliated tools (like Android Studio) to get to the bottom of a problem. 

System tracing is one such method. It involves recording the activity on a device while your app is running for a short period of time, and then producing a trace file that profiles the levels of different system mechanics, like CPU or memory usage, as they changed over the duration of the program running. This lets you align problematic aspects of your program with the underlying system activity that’s doing the work under the hood to make those commands, functions, etc. actually run. 

There are numerous tools you can use to run a system trace, including Android Studio, which offers a CPU, memory, and energy profiling. Additional tools recommended by Google are the Perfetto command-line tool (Android 10 and higher) and Systrace

In GPC’s “Android Vitals” section, you can look through a list of crashes and ANRs that have associated reports and stack traces. The stack trace associated with a crash or ANR provides a snapshot of the sequence of nested functions called in your program up to the moment it crashed. This can be helpful in troubleshooting a crash, as it lets you trace back exactly what was going on in the stack frame leading up to it.

Adding logs to your app and displaying these either via a command-line tool or in a console, offers additional context to help debug crashes. Logcat is an Android-specific tool that can be used on both the CLI and in the Android Studio window. When an app throws an exception, Logcat shows a message followed by the associated stack trace containing links to the line of code.

When it comes to resolving ANRs, the Google Play Console offers some additional context vs. other types of errors. This is important, as the Play Store downgrades apps that consistently go above a certain ANR threshold, making them less discoverable to new users. 

The following information is displayed by GPC, and can be helpful in your initial troubleshooting steps: 

• ANR activity name: Fully qualified name of the activity class where the ANR occurred (if available).

• ANR type: What high-level event was going on when the ANR occurred. If this information is available for an ANR, it will help guide you in looking for the root cause. For example, Google may tell you that one type of ANR happened due to an input dispatching time-out, meaning that your app has not responded to an input event (such as key press or screen touch) within 5 seconds. Other ANR types that Google will call out include failure to execute a service, Service.startForeground() not called, Broadcast of intent, and JobScheduler interactions. 

While GPC labels ANRs based on the above conventions of when it happened, a major limitation of its usefulness is that it cannot tell you why it happened. 

We take a deeper look at this, plus other limitations of GPC in our next blog on this topic, Diagnostic Limitations of the Google Play Console. 

The Google Play Console is a great tool for flagging errors and other issues that might be hurting app performance and your user experience in the lead up to launch.

That said, as a diagnostic tool, GPC also has some pretty serious limitations. Among the gaps, GPC doesn’t offer any real session context, does very little to help engineers resolve network issues, and only provides closed, predictable testing environments.

Simply put, mobile teams need more complete tooling in order to push the most polished releases.

Embrace lets you tackle all the issues flagged by the Google Play Console, but with more granular data and the invaluable context of an entire user’s journey.

Check out our product to learn more, or get in touch to request a demo and see for yourself how Embrace can help you level up your app.