This page explains the key concepts for mobile frontends in RUM. 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.
A view summary event aggregates the following data from a single view visit:
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.Early Access
User interactions represent activities performed by users on the mobile application's frontend. You can enable capturing of user interactions as described in Configure user interaction capturing for mobile frontends.
Currently, the following user interactions are supported for mobile:
Unlike RUM Classic, interactions in RUM can be captured independently of any request or user action.
For a complete list of user interactions, see Semantic Dictionary.
A user action represents a significant operation within the mobile frontend. It groups the requests, navigations, and errors that result from a single user interaction, giving you a complete picture of what happened and how long it took. For example, a user action starts when a user presses a button and ends when the resulting network call completes and a new screen is displayed.
A user action starts with one of the following events:
User interaction: A touch on a UI element that has a registered action handler (for example, a button or a list item), followed within 100 ms by a web request or a view navigation, triggers an automatic user action. If neither occurs within 100 ms, no user action is created, because a touch alone does not constitute a user action.
API call: Created manually using the Dynatrace API. This is useful for tracking custom workflows that are not captured automatically, such as multi-step processes or interactions that the agent cannot instrument. For details, see Customize mobile frontend monitoring using the RUM APIs.
While a user action is active, the agent links the events that result from the triggering interaction, so you can analyze them together and understand the full impact of a single interaction:
For API user actions, you can also attach event properties to capture additional business context. For details, see Customize mobile frontend monitoring using the RUM APIs.
The user action stays active as long as there is ongoing activity. The agent extends the user action while web requests are in flight or navigations occur, applying a 100 ms inactivity window after the last request or navigation completes.
A user action ends when one of the following conditions is met:
complete method. The user action ends at the time of the call.Each user action event captures the following information:
{interaction type} on {element name} on {view name}, for example, touch on Checkout on CartActivity. For API user actions, the name is the custom name you provide.same_view or navigation.api.Each related event (user interaction, navigation, error, or request) carries the user_action.instance_id of the user action, which links it to that user action.
The UI element name is derived from the accessible label or identifier of the UI element and may contain user-provided text, such as a button label. The same privacy masking rules that apply to the triggering user interaction event also apply to the element name in the user action. The screen name is derived from source-code class names and is not subject to masking.
For a complete list of captured data of a user action event, see Semantic Dictionary.
RUM 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 RUM. These events are sent only if the user restarts the mobile app within 10 minutes. 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.