This page explains the key concepts for mobile frontends in the New RUM Experience. Understanding these concepts helps you analyze user behavior and application performance in mobile environments.
Application starts represent the initialization of a mobile application, measuring the time it takes for the app to load and the first view to become visible after being launched by the user.
There are three types of app starts, each with different performance characteristics:
Cold start—occurs when the app is launched from a non-running state. This happens, for example, when the app is launched for the first time since the device booted. A cold start involves the complete initialization process, including loading resources, setting up the runtime environment, and initializing the app.
Warm start—encompasses a subset of the operations that take place during a cold start. This can happen if the user backs out of the app but then re-launches it shortly after. The behavior may differ significantly depending on the platform.
Hot start—has lower overhead than a cold or warm start. If the app state still resides in memory, operations such as object initialization, layout inflation, and rendering may be avoided. This occurs when the app is fully running in the background and is brought to the foreground again.
For a complete list of captured data of an app start event, see Semantic Dictionary.
In mobile applications, a view represents a screen the user is interacting with. Views are distinct screens or layouts within a mobile app that display specific content or functionality, such as a shopping cart, or settings view. The visit of a user to a specific view is aggregated into a view summary event.
In mobile applications, a view represents a screen the user is interacting with. Views are distinct screens or layouts within a mobile app that display specific content or functionality, such as a shopping cart, or settings view. The visit of a user to a specific view is aggregated into a view summary event.
View instances are identified by a unique view.identifier, while all instances of the same screen share the same view.name for aggregated analysis. This allows you to analyze both individual view visits and overall performance patterns across all visits to the same view.
For a complete list of captured data of a view summary event, see Semantic Dictionary.
A navigation represents the transition between views in a mobile application. These events provide insights into how users move through the app:
Mobile navigations can be triggered in different ways:
startView to signal a new view which implicitly creates a navigation event.User interactions represent activities performed by users on the mobile application's frontend. These are captured when "User Interactions" option is enabled in the section "Session Replay" in settings in Experience Vitals. During the Early Access period, there’s no cost associated with this feature.
Currently user interactions that are triggered via touch are supported for mobile.
Unlike RUM Classic, interactions in the New RUM Experience can be captured independently of any request or user action.
For a complete list of user interactions, see Semantic Dictionary.
The New RUM Experience captures various error types that can occur in mobile applications.
A crash is a fatal issue that terminates the application. When your mobile application crashes, Dynatrace automatically reports a crash event. The crash report includes:
Crashes are grouped by similarity of the stack trace and occurrence in the source code, making it easier to track issues across different versions of your application.
For a complete list of captured data of a crash event, see Semantic Dictionary.
ANR events are critical errors specific to mobile applications where the app's main thread becomes unresponsive and cannot process user input events or update the UI. This forces the app to be closed, causing frustration for users.
ANR events are automatically captured by the New RUM Experience. These events are sent only if the mobile app is restarted within a timeframe of 10 minutes by the user. ANR errors are always fatal (error.is_fatal = true) because the non-responsive app resulted in a fatal exit.
For a complete list of captured data of an application not responding event, see Semantic Dictionary.