Understanding the RUM Event Hierarchy
Overview
This guide walks through the different types of data that RUM collects and describes the hierarchy of each event type.
Sessions
All RUM data refers to user or synthetics sessions, which are at the top of the event hierarchy. A session is a unique user journey and encompasses everything (for example, pages viewed, views, clicks, scrolls, and errors) the user triggered. A session can last up to four hours of continuous activity, or it can expire after 15 minutes of inactivity. Since a session encompasses the entire journey, all attributes tied to that user are also tied to that session. For example, you may want to query on a default attribute, like action count, then add something more custom, like user attributes.
Sample search: List all sessions from a user
To list all sessions from a specific user, select Sessions from the event type dropdown, then make a search query for the session status and user.
Each session is automatically associated with a unique session.id.
Views
Within a session, a view event is created each time a user navigates to a page (Browser RUM) or to a screen or screen segment (Mobile RUM) of an application.
Each view automatically collects multiple view-specific attributes and data, such as text in the URL and timing metrics, such as the load time of a given page. When querying for specific views, you can add any default level attributes, like device, operating system, or user information, for example. However, event-specific attributes must be view-specific. To view events only, you can adjust the event selector as shown in the image below.
Similarly to the session.id, each view automatically has a unique view.id connected to it.
Actions, errors, resources, and long tasks
Within views, the SDK creates more granular events that all fall along the same hierarchy level. However, each event is unique and carries its own attributes and properties.
Actions
Actions represent user activity on a page. In browsers, all click actions are automatically collected. On mobile, all taps, swipes, and scrolls are collected. Beyond these default actions, you can also send custom actions, such as form completion and business transactions.
Sample search: Top list of actions leading to an error
This example displays a query that searches for all actions from users clicking on the “Add to cart” button that resulted in an error.
Errors
You can use RUM to collect frontend errors that occur during the user session. By default, the browser SDK creates error events for unhandled exceptions and console errors. Additionally, you can collect custom errors through the RUM addError API (on browser and mobile). On mobile apps, you can also see if the error led to a session termination, also known as a crash.
Errors can be viewed in both RUM and Error Tracking. Source and custom errors are processed by Error Tracking, while console errors are solely in RUM.
Sample search: List of all crashes that occurred on a page in the application
This example displays a query that searches within the errors event to view all crashes that occurred on the “HomeViewController” page for a particular application.
Resources
Resources are collected from views and include external requests from your application to a network provider, things like XHR, JS loading, images, or fonts, for example. Since it is collected from a view, you can query for all resources loaded on an application, or scope it down to just resources that occurred in a single view.
Sample search: A list of all images loaded on the /cart view filtered by image size
In this example, Resources is selected from the event type dropdown, then a query for images that loaded on the cart view and were larger or equal to 1000 kilobytes are listed.
Long tasks
Long tasks are any task that blocks the UI thread for a specified period of time. On mobile for example, a long task may be a frozen frame if the screen is blocked for longer than 300 milliseconds.
Sample search: All frozen frame long tasks that lasted more than 500 ms
In this example, Long tasks is selected from the event type dropdown and then duration is specified.
Troubleshooting
No data appears after writing a query
If you aren’t seeing data after writing a query, confirm that the event selector matches what you have in the search bar. In the example above, the event selector is set to search within views, but the search bar only contains action attributes. To view action-related data, switch the view selector to actions. If you still don’t see any data, check the time frame selector to ensure you are in a time window where data should be appearing.
Querying an event type that is nested in a different event type
When querying for specific actions, you can use the parent event type, but not one at equal or lower level. For example, actions are nested underneath views, and actions and errors are at the same level in the hierarchical chain. This means you can query for all actions and errors that happened on a given page, but not for all actions that had a specific error type.
Sample search: The top 10 actions that occurred on /
This example searches within the actions event type for all view names using the Top List view to see the top 10 actions that occurred on /, which represents the homepage.
Further Reading
Additional helpful documentation, links, and articles:
