Metrics Description
Download
Focus Mode
Font Size
Overview
RUM Pro currently supports metrics such as crashes, ANR, OOM/FOOM, error rates, FPS, suspension rate, memory peaks, app launch time, and more. These metrics vary in their statistical approaches and are primarily categorized into two types:
The metrics for calculating abnormality rates based on reported individual cases include crashes, ANR, and OOM/FOOM. For such metrics, the numerator typically represents the count of reported abnormal cases, while the denominator is the number of connected devices (deduplicated by device ID).
Metrics such as FPS, suspension rate, memory peak, and app launch time are based on independently collected data statistics and are not directly correlated with the number of reported issues.
After confirming that the configuration is properly enabled, you can view relevant metric data on the Data Overview, Abnormal Overview, Metrics Analysis, and Issue List pages.
Data Overview
Data Overview page primarily displays the core metrics related to RUM Pro, visualizing various monitoring metrics to facilitate monitoring and analysis, including Dashboard Metrics, Version metrics, and Business drill-down metrics.
Exception Overview
Crashes, errors, as well as ANR and OOM metrics on the Android platform, can all be viewed through their respective overview modules, as shown in the figure below.
Metric Analysis
iOS metrics such as ANR, FOOM, lag, memory peaks, and app launch time can be viewed on the Metrics Analysis page, as shown in the figure below.
Problem List
In addition to analyzing metric data through the Data Overview, Abnormal Overview, and Metrics Analysis pages, metrics such as crash, ANR, OOM/FOOM, and errors can also be flexibly analyzed in the Problem List.
Metrics Introduction
Crash
Crash refers to an application stopping normal operation and exiting. Crash metrics include Device crash rate; Crash rate; and User Crash rate.
Definition of Abnormality Rate:
Device Crash rate = Affected Device Count / Connected Device Count.
Frequency-based Crash rate = Occurrence Count / Launch Count.
User Crash rate = Affected User Count / Connected Device Count.
Definition of Statistical Fields:
Number of Affected Devices: The count of devices experiencing crashes, calculated as a distinct count by Device ID.
Number of Affected Users: The count of users experiencing crashes, calculated as a distinct count by User ID.
Connected Device Count: The count of internet-connected devices, calculated as a distinct count by Device ID.
ANR
ANR: When an application becomes unresponsive during operation and is force closed by the system, it is recorded as an ANR.
Definition of Abnormality Rate:
Device ANR Rate = Number of Affected Devices / Connected Device Count.
Frequency-based ANR Rate = Occurrence Count / Launch Count.
User ANR Rate = Number of Affected Users / Connected Device Count.
Definition of Statistical Fields:
Number of Affected Devices: The count of devices experiencing ANR, calculated as a distinct count by Device ID.
Number of Affected Users: The count of users experiencing ANR, calculated as a distinct count by User ID.
Connected Device Count: The count of internet-connected devices, calculated as a distinct count by Device ID.
Note:
Android ANR monitoring only requires the SDK to be properly initialized and the product to contain an active resource package to report normally. Android ANR monitoring currently does not support user toggle and is enabled by default.
iOS ANR monitoring supports user toggle. After SDK initialization and purchasing a resource package for the product, you need to create a configuration task to enable iOS ANR monitoring.
OOM
On the Android platform, the OOM rate includes the following three types:
Java OOM Rate: The probability of crashes caused by Java memory usage exceeding limits in the process.
Native OOM Rate: The probability of crashes caused by Native memory usage exceeding limits in the process.
FD OOM Rate: The probability of crashes caused by FD resource usage exceeding limits in the process.
Definition of Abnormality Rate:
Device OOM Rate = Number of Affected Devices / Connected Device Count.
Count-based OOM Rate = Occurrence Count / Launch Count.
User OOM Rate = Affected Users / Connected Devices.
Definition of Statistical Fields:
Affected Devices: The number of devices that experienced OOM, counted by deduplication based on Device ID.
Affected Users: The number of users affected by OOM, counted by deduplication based on User ID.
Connected Device Count: The count of internet-connected devices, calculated as a distinct count by Device ID.
Note:
Android OOM, similar to crashes, can be reported normally as long as the SDK is properly initialized and the product has an active resource package. Android OOM monitoring currently does not support user toggles and is enabled by default.
FOOM
FOOM (Foreground Out Of Memory) on the iOS platform refers to the system force-quitting an application due to excessive memory consumption while running in the foreground.
Definition of Abnormality Rate:
Device FOOM Rate = Affected Devices / Connected Devices.
FOOM Rate = Occurrences / Launches.
FOOM Rate = Affected Users / Connected Devices.
Definition of Statistical Fields:
Affected Devices: The number of devices affected by FOOM, counted by deduplication based on Device ID.
Affected Users: The number of users affected by FOOM, counted by deduplication based on User ID.
Connected Device Count: The count of internet-connected devices, calculated as a distinct count by Device ID.
Note:
FOOM on the iOS platform is not enabled by default. Users need to go to Settings / SDK Configuration to create a configuration task or modify an existing configuration task to enable FOOM monitoring.
Error
Errors refer to user-defined exceptions reported to the platform through the APIs provided by the RUM Pro SDK.
Definition of Abnormality Rate:
Device Error Rate = Affected Devices / Connected Devices.
Error Rate = Occurrence Count / Launch Count.
User Error Rate = Affected Users / Connected Devices.
Definition of Statistical Fields:
Affected Devices: The number of devices that reported errors, counted by deduplication based on Device ID.
Affected Users: users who reported errors, counted by deduplication based on User ID.
Connected Device Count: The count of internet-connected devices, calculated as a distinct count by Device ID.
Note:
Similar to crash, as long as the SDK is properly initialized and the product has an active resource package, errors can be reported normally.
Lag Metrics
Lag metrics include FPS and suspension rate, which are disabled by default (i.e., not collected). Users need to actively enable them by creating a configuration task.
FPS: Frame rate, the number of images the GPU and CPU can generate during application runtime, measured in frames/second (Frames Per Second, abbreviated as FPS). It is typically used as a metric to evaluate hardware performance and application smoothness.
Suspension rate: If the refresh delay between two application frames exceeds 200 ms, it is considered that the application has poor responsiveness to user interactions, and this delay is added to the suspension time. The suspension rate of a device is its total suspension time divided by the total foreground duration in a day, measured in seconds/hour.
Memory metrics
Memory peak: the maximum memory used by the application during a single run.
Physical memory peak: peak physical memory used by the application during a single run, also known as peak physical set size (PSS).
Virtual memory peak: peak virtual memory used by the application during a single run, also known as peak virtual set size (VSS).
Java heap memory peak: peak Java heap memory used by the application during a single run.
Foreground memory peak: peak memory used by the application in the foreground during a single run.
Background memory peak: peak memory used by the application in the background during a single run.
Launch time
The metrics for launch monitoring are launch time, which includes cold launch time and warm launch time.
Default cold launch: from process creation to the first frame drawn of the first Activity.
Cold launch: from the creation of the application process to the completion of the first rendering of the launch page. You can customize the launch completion point.
Warm launch: from the opening of an Activity to the completion of the first rendering of the page, when the process has already been created and there is no Active Activity.
Context switch: switching to the foreground after the application is in a suspended state in the background.
Note:
Android platform default cold launch. The Android platform provides the AppLaunchMonitor#ReportAppFullLaunch API, allowing users to customize the launch completion point. Since the definition of the launch completion point varies across applications, direct comparison between different apps is not feasible. However, the default cold launch uses the first frame rendering of the initial Activity as the statistical endpoint for launch completion, enabling direct comparison of launch time between applications.
Help and Support
Was this page helpful?
You can also Contact sales or Submit a Ticket for help.
Help us improve! Rate your documentation experience in 5 mins.
Feedback