This topic describes the metrics and fields on the Real User Monitoring (RUM) dashboard and console in Application Real-Time Monitoring Service (ARMS). Use these definitions to interpret dashboard values, set performance baselines, and identify bottlenecks.
Dashboard metrics
Common metrics
| Metric | Description | Calculation |
|---|---|---|
| PV | Page views -- the total number of page view events. | Deduplicated by view.id across page, behavior, and resource loading events. |
| UV | User views -- the total number of distinct users. | Deduplicated by user.id. |
| Number of sessions | Total user sessions. A session spans from when a user enters a page until the page is closed. | Deduplicated by session.id. |
| Sessions per user | Average number of sessions per user. | Number of sessions / UV |
| Average session duration per user | Average time a user spends across all sessions. | Each session duration = max(session.end) - min(session.start). Average = total duration of all sessions / UV. |
Resource loading
Resources represent network requests defined by HTTP protocol and web performance standards. They fall into two categories: API requests and static resources.
| Metric | Description | Details |
|---|---|---|
| Number of resources | Total resource load count. | |
| Number of API loads | Total API request count. | Includes requests with resource type xhr, fetch, or api. Tracks server interaction such as response codes and response content. |
| Number of failed API loads | Total failed API request count. | |
| Number of static resource loads (CDN trend) | Total static resource load count. | Includes resource types such as css, javascript, image, and media. Tracks resource type, CDN usage, and network stability. |
| Number of failed static resource loads (CDN trend) | Total failed static resource load count. |
Resource loading performance
These metrics break down the time spent in each phase of a resource request. Use them to pinpoint bottlenecks in connection setup, DNS resolution, or data transfer.
| Metric | Description | Browser Performance API |
|---|---|---|
| Connect | Time to establish a connection to the server. | connectEnd - connectStart |
| DNS | Time to resolve the DNS name for the last request. | domainLookupEnd - domainLookupStart |
| SSL | Time to complete the TLS handshake. Not reported if the last request does not use HTTPS. | connectEnd - secureConnectionStart |
| Download | Time to download the response. | responseEnd - responseStart |
| Duration | Total end-to-end time to load the resource. | responseEnd - startTime |
Exceptions
An exception is an unexpected event during code execution. The available exception types depend on the platform:
| Platform | Exception types |
|---|---|
| Web, H5, Mini Program | JS errors, blank screens, custom exceptions |
| Android | Crashes, JS errors, Application Not Responding (ANR), custom exceptions |
| iOS | Crashes, JS errors, custom exceptions |
| Metric | Description | Calculation |
|---|---|---|
| Number of exceptions | Total exception count across all types. | |
| Affected users | Distinct users who encountered at least one exception. | Deduplicated by user.id where event type = abnormal. |
| Affected sessions | Distinct sessions in which at least one exception occurred. | Deduplicated by session.id where event type = abnormal. |
| Affected page views | Distinct page views in which at least one exception occurred. | Deduplicated by view.id where event type = abnormal. |
| Crash rate | Percentage of sessions affected by crashes. | Sessions with crashes / Total sessions |
| JS error rate | Percentage of page views affected by JS errors. | Page views with JS errors / Total page views |
Stuttering
Stuttering occurs when the main thread becomes unresponsive, degrading the user experience. Unlike exceptions, stuttering is not caused by unexpected runtime errors. It typically results from unoptimized code or device performance limitations.
On Android and iOS, a stuttering event is recorded when the main thread is unresponsive for 5 consecutive seconds.
| Metric | Description | Calculation |
|---|---|---|
| Number of stutters | Total stuttering event count. | |
| Affected users | Distinct users who experienced stuttering. | Deduplicated by user.id where event type = stuttering. |
| Stuttering rate | Percentage of page views affected by stuttering. | Page views with stuttering / PV |
Page performance
These metrics track browser rendering and loading milestones. Use them to identify where page load time is spent and which phases to optimize.
| Metric | Full name | Description |
|---|---|---|
| first_contentful_paint | First Contentful Paint (FCP) | Time until the browser first renders any DOM content -- text, images, SVGs, or canvas elements. Also referred to as blank screen time. |
| dom_interactive | Time to Interactive | Time until the page content becomes interactive. |
| dom_content_loaded | HTML complete load time (DOM Ready time) | Time until the initial HTML document is fully loaded and parsed. Does not wait for non-render-blocking resources such as stylesheets, images, or subframes. |
| dom_complete | DOM | Time until the page and all sub-resources are ready. At this point, the browser loading spinner has stopped. |
| load_event | Page full load time | Time until the page is fully loaded, including all sub-resources. Often used as a trigger for additional application logic. A page load time of less than 2 seconds is considered excellent, and up to 4 seconds is acceptable. A page load time greater than 5 seconds not only affects the website's search engine ranking but also severely impacts the user experience. |
| largest_contentful_paint | Largest Contentful Paint (LCP) | Time until the largest visible DOM element in the viewport is rendered. A time greater than 2.5s is marked as slow. |
| first_input_delay | First Input Delay (FID) | Delay between the user's first interaction with the page and the browser's response. |
| cumulative_layout_shift | Cumulative Layout Shift (CLS) | Quantifies unexpected layout shifts caused by dynamically loaded content such as third-party ads. A value of 0 means no shift occurred. |
Startup analysis
Startup metrics are collected only by mobile SDKs (iOS, Android, and HarmonyOS).
Startup metrics measure the time from when a user opens an application until it becomes responsive. Startups are categorized as cold starts and hot starts.
Cold start time
A cold start occurs when the application launches from scratch with no existing process in memory.
| Platform | Measurement |
|---|---|
| Android | From when ContentProvider completes its onCreate method to when onResume of the first Activity is called. |
| iOS | From when the first object is loaded into memory to the first successful run loop after UIApplicationDidBecomeActiveNotification. |
| HarmonyOS | Spans five stages: process creation and initialization, Application and Ability initialization, Ability/AbilityStage lifecycle, loading and drawing the home page, and secondary refresh of network data. |
Hot start time
A hot start occurs when an application process already exists in memory and is switched from the background to the foreground. Applies to all platforms.
First start time
The first start is the initial launch after installation, or the first launch after application data has been cleared. Applies to all platforms.
Console metrics
Common fields
| Field | Description | Example |
|---|---|---|
| Last reported | The most recent timestamp at which the event occurred. Calculated as max("timestamp") from collected data. | 2025-10-30 14:38:37 |