App Health Insights Dashboard
With the App Health Insights dashboard, you can track key app performance and stability metrics across all live versions of an app. These metrics can help you monitor any ongoing issues, track potential regressions across newer app versions, and continuously improve your app's user experience.
- Requirements
- Access the App Health Insights dashboard
- Dashboard overview
- Understand your app's performance and stability
- Trend graphs
- Managing filters
- App Health Insights dashboard FAQ
- Feedback
Requirements
To use the App Health Insights dashboard, make sure you have:
- An administrator, developer, or analyst role. You can find your role in the Developer Console, under Settings > My Account.
- A live app in your developer account.
Access the App Health Insights dashboard
To access the App Health Insights dashboard, navigate to the Developer Console, select Apps & Services > My Apps and choose a live app. Select the menu icon under Actions, and then select App Health Insights, as shown in the following image.
Dashboard overview
The App Health Insights dashboard contains data for in-field key performance indicators (KPIs) across all live versions of your app. The dashboard aggregates data from user devices associated with your app over a chosen time period. The dashboard displays each KPI as an average over the time period, and includes trend graphs for the same period. In the sidebar, select Performance or Stability to see the associated data. Customize your view by using the available filters. For details about filters, see Managing filters.
Performance dashboard
When you access the App Health Insights screen, the performance dashboard shows by default.
Here you can choose between App Latency, Foreground Low Memory Killer Event (LME), or Fluidity. The App Latency tab is selected by default, which shows the following four KPIs:
- App Launch Time - Warm Start
- App Launch Time - Cold Start
- Ready To Use - Warm Start (coming soon)
- Ready To Use - Cold Start (coming soon)
The Foreground Low Memory Killer Event (LME) tab displays LME event metrics and the Fluidity tab displays frame drop rate metrics. For details about the performance KPIs, see App latency, Memory use, and Fluidity.
Stability dashboard
To display the stability dashboard and review your app's stability KPIs, select Stability from the sidebar.
The stability dashboard has the following four KPIs:
- Crash Rate
- ANR Rate
- Crash Count
- ANR Count
For details about the stability KPIs, see Stability.
Understand your app's performance and stability
On the dashboard, you can select Performance or Stability from the sidebar to access the performance or stability data for your app. The performance dashboard has separate tabs for app latency, foreground low memory events, and fluidity.
The following sections define the available KPIs on the App Health Insights dashboard.
App latency
The App Latency tab is on the performance dashboard. On this tab, you can view data relating to app launch time. Use the available drop-down menus to filter the results displayed by devices, app version, and time period. For details on the filters, see Managing filters.
| KPI | Description | Additional information |
|---|---|---|
| App Launch Time - Warm Start | The average time it takes for the first activity to appear on screen (even if the screen is blank), when the app process is already running on the device.
A warm app means that the app process is already running when a user launches the app. |
app launch time (warm start) = time to create the activity (if not already running from the previous app launch) + time to render the activity (even if the screen is blank)
The App Launch Time KPI card displays the average warm start time across all warm start app launch events. |
| App Launch Time - Cold Start | The average time it takes for the first activity to appear on screen (even if the screen is blank), when the app process is not running on the device and needs to be created.
A cold app means that its process is not running on the device when a user launches the app. |
app launch time (cold start) = time to start app process + time to create the app activity + time to render the activity (even if the screen is blank)
The App Launch Time KPI card displays the average cold start time across all cold start app launch events. |
| Ready To Use - Warm Start
(coming soon) |
The average time it takes to fully draw the desired app activity, when the app process is already running on the device.
A warm app means that the app process is already running when a user launches the app. |
report fully drawn (warm start) = time to create the predefined activity (if not already running from the previous app launch) + time to render the predefined activity
Fully drawn means that the app has called Activity.reportFullyDrawn(). For more information, see the Android documentation on the reportFullyDrawn() method.
Note: If you haven't implemented the RTU metric, it will be unavailable on the dashboard, and shows "This KPI requires you to implement the Ready To Use (RTU) marker in your app." For help with implementation, see How to measure and improve app startup times in Fire OS. |
| Ready To Use - Cold Start
(coming soon) |
The average time it takes to fully draw the desired app activity, when the app process is not running on the device.
A cold app means that its process is not running on the device when a user launches the app. |
report fully drawn (cold start) = time to start the app process + time to create the predefined activity + time to render the predefined activity
Fully drawn means that the app has called Activity.reportFullyDrawn(). For more information, see the Android documentation on the reportFullyDrawn() method.
Note: If you haven't implemented the RTU metric, it will be unavailable on the dashboard, and shows "This KPI requires you to implement the Ready To Use (RTU) marker in your app." For help with implementation, see How to measure and improve app startup times in Fire OS. |
Memory use
The Foreground Low Memory Killer Events (LME) tab is on the performance dashboard. Select this tab to view the KPIs for memory use. Use the available drop-down menus to filter the results displayed by devices, app version, and time period. For details on the filters, see Managing filters.
| KPI | Description | Additional information |
|---|---|---|
| Foreground Low Memory Killer Events (LME) | The average daily instances of foreground low memory events that led to the app being killed on the device. | A foreground LME occurs if the system is short on memory after killing all non-persistent background apps or services. The dashboard shows a trend of total daily foreground LMEs for the selected time period. |
Fluidity
The Fluidity tab is on the performance dashboard. Select this tab to view the KPIs for the drop rate of UI frames in the app. Use the available drop-down menus to filter the results displayed by devices, app version, and time period. For details on the filters, see Managing filters.
| KPI | Description | Additional information |
|---|---|---|
| Frame Drop Rate | The percentage of UI frames that were dropped, out of the total UI frames generated by the app. | percentage of dropped frames = (total frames dropped for the app ÷ total frames for the app) * 100 |
Stability
To view the KPIs for app stability, select Stability in the sidebar of the dashboard. Use the available drop-down menus to filter the results displayed by devices, app version, and time period. For details on the filters, see Managing filters.
| KPI | Description | Additional information |
|---|---|---|
| Crash Rate | Percentage of total unique devices with at least one recorded crash event, across total unique active devices for the app in the defined time period. | The total unique devices with one or more recorded crash or ANR events is aggregated daily. Total unique active devices includes each device where an app launch was recorded at least once in the defined time period, and is aggregated daily.
For example, if a user launches the app on their device X times in a single day, it would count as a single active device for the week. However, if the same user launches the app on their device Y times on the next day as well, then it would count as two active devices for the week. Note: Certain use-cases, such as opt-outs and Kids, aren't included in the definition of active users for the crash rate metrics. For more details, see FAQ. |
| App Not Responding (ANR) Rate | Percentage of total unique devices with at least one recorded ANR event, across total unique active devices for the app in the defined time period. | |
| Crash Count | Total crash events recorded across all active devices for the defined time period. | The crash count and ANR count are the sum of all crash or ANR events, emitted by a user's device and attributed to a specific app running on the device. The total includes both foreground and background events by default. |
| ANR Count | Total ANR events recorded across all active devices for the defined time period. |
Crash and ANR event tables
Below the trend graph on the stability dashboard are tables for crash events and ANR events. These tables show details about the stability events recorded for the given app. The tables include the following data:
- Event Information: provides the beginning of the stack trace log that was generated as part of the crash or ANR event
- Last Occurred: provides the timestamp for the last crash or ANR event associated with the event
- Devices Impacted: provides the daily aggregated count of unique customer devices that generated the given crash or ANR event
- Occurrences: provides the total of all events generated for the given crash or ANR event
- Last Log: opens a new window, which contains the detailed stack trace for the crash or ANR event
By default, the dashboard sorts the table by Devices Impacted, but you can choose to sort by the other columns, such as Last Occurred or Occurrences. If there is enough data, the table becomes scrollable and paginated. To export the table as a CSV or Excel spreadsheet, hover over the top right corner of the table and use the three-dot menu.
Trend graphs
Each KPI has an associated trend graph on the dashboard. The graph provides an overview of the app's stability or performance over the defined time period. The x-axis represents the dates within the selected time period, and the y-axis represents the numerical value of the selected KPI.
You can hover your mouse over the trend graph to view information associated with an individual data point. For example, with app launch time, hovering over an individual data point displays the daily average value for app launch time and the total number of events used to compute the value. To see graphs for a specific data set, use the available filters. When you change the values in the filters, the trend graphs refresh automatically to reflect the selected data. On the stability dashboard, choose the trend graph you want to view by using the drop-down menu.
Managing filters
The App Health Insights dashboard provides multiple filters to refine your view of the KPIs across time periods, devices, and app versions. Any changes to these filters automatically refreshes the visible KPI values and associated graphs on the dashboard.
The Appstore ignores data that has a statistically negligible impact on the selected KPI, and therefore might not have a sizeable impact on the performance and stability monitoring of an app. For example, the Appstore wouldn't include the data generated by a test version of the app used by few hundred testers that triggers app launch time events. This ensures that the dashboard represents real-world, user-impacting app events as closely as possible.
The following sections describe the available filter types.
Time period
You can set the Time Period filter to either Last 1 Week, Last 2 weeks, or Last 4 weeks to display the data aggregation across that time period. By default, the dashboard shows the four-week period for your app. The graph's x-axis represents the dates. Hover your mouse over a particular date on the graph to view the associated KPI value.
App version and published date
The App version, Published Date (GMT) filter contains a list of all app versions which are currently live (in-use) for your app. The items listed in the app version filter use the format <serial number> <app version> <version code> <publish date>. The list is sorted by publish date from most recent (the latest app version) to least recent (the oldest app version). The app version filter shows the app version in two formats: the app version value from the app's manifest file, and the friendly version code. You can search for a particular version by using the search bar at the top of the drop-down menu and entering the version code or publish date. After you select one or more values within the app version list, you can view all selected values by clicking SHOW SELECTED VALUES at the bottom of the drop-down menu. To reset your selection, click the three-dot menu next to the App version, Published Date (GMT) filter text and select Reset.
Device type
The Device Type filter contains the list of device families—Fire TV or Fire tablet devices—that are currently in-use for the app. You can manually select a specific device type from the list, or use the search bar to look for a particular device type. A selection here impacts the list of devices available under the Devices Only filter.
Devices only
When you change your selection in the Device Type filter, the Devices Only filter automatically refreshes the list of available devices. The updated list includes only those devices that match the selected device types. The Devices Only list is sorted alphabetically and the unfiltered list contains all devices that are in-use by users of your app. The Appstore strictly restricts this list to those devices that you targeted during app submission and ignores side-loaded device names from this list. Search for specific devices using the search bar or manually select devices by scrolling through the list.
Foreground events only
The stability dashboard includes a filter for Show Foreground Events Only. Set this option to ON to filter out any crash and ANR events that occurred while the app was running in the background. By default, this filter is set to OFF and the dashboard displays both foreground and background crash and ANR events.
App Health Insights dashboard FAQ
The following are frequently asked questions (FAQ) about the App Health Insights dashboard.
- Q: How often is the data on the dashboard refreshed?
-
- For most KPIs, the dashboard data has a delay of 24 hours. If you view the dashboard data on a particular day, the latest data available is from the previous day.
- For crash rate and ANR rate KPIs, the dashboard data has a delay of 72 hours. If you view the dashboard data on a particular day, the latest data available is from three days prior.
- Q: For a few app versions, the crash rate and ANR rate appear unusually high. Is this expected?
-
Crash rate is defined as the percentage of total unique devices with at least one recorded crash event, across total unique active devices for the defined time period. To calculate active users for an app, the Appstore relies on users' permission to be able to collect app usage data. Also, there are legal and policy restrictions to collect some types of user data, such as app usage by children. For these reasons, the active user count for an app might be under-reported in a few instances, leading to slightly higher crash and ANR rate reported for specific apps and versions.
- Q: Why can't I see any data for a particular KPI or set of filters?
-
There might be instances where the dashboard displays "No data found". This could be due to one of the following reasons:
- The KPI isn't supported for your app. As an example, in app latency, Ready To Use depends on a developer defining the interaction point in the app. If the associated details aren't found, the KPI data will be unavailable for the app.
- The set of applied filters didn't return any data for the KPI. This might be due to missing historical data for app versions or device types, for the given time period.
If you believe there is an issue with data availability, use the feedback button on the bottom left of the dashboard screen to share your concerns, or contact developer support.
- Q: Can I use this dashboard for my Live App Testing (LAT) app versions?
-
Currently, the App Health Insights dashboard is available for live apps only. If you upgrade a LAT app to a live version, it becomes available as one of the versions under the app version filter. The dashboard filters out LAT apps that are used by testers only.
Feedback
To help provide you with a better experience, share your feedback using the feedback widget located on the bottom left of the dashboard screen.
Last updated: Mar 26, 2024