---
title: Understanding the RUM Event Hierarchy
description: >-
  Learn about RUM event types and their hierarchical relationships including
  sessions, views, actions, resources, and errors.
breadcrumbs: >-
  Docs > RUM & Session Replay > Real User Monitoring & Session Replay Guides >
  Understanding the RUM Event Hierarchy
---

# Understanding the RUM Event Hierarchy

## Overview{% #overview %}

This guide walks through the different [types of data](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/data_collected) that RUM collects and describes the hierarchy of each event type.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/understanding-rum-event-hierarchy/rum-session-hierarchy-overview-3.1c773abd5bb92175ce83c91a2b23f3c0.png?auto=format"
   alt="Diagram of the RUM event hierarchy, displaying a single session containing multiple views." /%}

## Sessions{% #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](https://docs.datadoghq.com/account_management/billing/rum/#when-does-a-session-expire). Since a session encompasses the entire journey, all [attributes](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/data_collected/#event-specific-metrics-and-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](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/data_collected/#user-attributes).

#### Sample search: List all sessions from a user{% #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 type and user.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/understanding-rum-event-hierarchy/rum-sample-search-all-session-user-3.97eeabc0d662d12e6688b3949a8554c6.png?auto=format"
   alt="Sample search listing all sessions from user 'Chantal Loya'." /%}

Each session is automatically associated with a unique `session.id`.

## Views{% #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.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/understanding-rum-event-hierarchy/rum-switch-views-1.2045f059c43747689b69c34384391eae.png?auto=format"
   alt="RUM views." /%}

Similarly to the `session.id`, each view automatically has a unique `view.id` connected to it.

### Actions, errors, resources, and long tasks{% #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 %}

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](https://docs.datadoghq.com/real_user_monitoring/guide/send-rum-custom-actions/?tab=npm), such as form completion and business transactions.

#### Sample search: Top list of actions leading to an error{% #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.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/understanding-rum-event-hierarchy/rum-actions-all-add-to-cart-2.398ea8909ac78e2ffaf1049335f257a5.png?auto=format"
   alt="Sample search of all 'Add to Cart' actions that led to an error." /%}

### Errors{% #errors %}

You can use RUM to collect [frontend errors](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/collecting_browser_errors/?tab=npm) 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](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/browser/collecting_browser_errors/?tab=npm#collect-errors-manually) and [mobile](https://docs.datadoghq.com/real_user_monitoring/application_monitoring/ios/advanced_configuration/?tab=swift#custom-errors)). 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{% #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 "cart" page for a particular application.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/understanding-rum-event-hierarchy/rum-sample-search-errors.b2b912a20363be9951a5ea892f91e4a2.png?auto=format"
   alt="Sample search of all crashes that occurred on a page." /%}

### Resources{% #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 `/demo` view filtered by image size{% #sample-search-a-list-of-all-images-loaded-on-the-demo-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 `/demo` view and were larger or equal to 1000 kilobytes are listed.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/understanding-rum-event-hierarchy/rum-resources-1.c5fd1277a542149327a12600b85f9fc5.png?auto=format"
   alt="Sample search of all images loaded on the homepage view that were 1000 kilobytes or greater." /%}

### Long tasks{% #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{% #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.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/understanding-rum-event-hierarchy/rum-long-tasks-1.570220e9261aa0e1209d9b5b69e61452.png?auto=format"
   alt="Sample search of all frozen frame long tasks lasting longer than 500 milliseconds." /%}

### Vitals{% #vitals %}

Vitals are custom vitals you've created to measure the performance of your application at the component level. For example, you can measure how long it takes for part of your page to render or for a component to respond to a user interaction.

#### Sample search: A list of all sessions where the custom vital "checkout loading time" lasted more than 1000ms{% #sample-search-a-list-of-all-sessions-where-the-custom-vital-checkout-loading-time-lasted-more-than-1000ms %}

In this example, **Vitals** is selected from the event type dropdown and the checkout loading time is specified.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/understanding-rum-event-hierarchy/rum-events-vitals-1.ae0858100a57dd564c86805f8b4cb4be.png?auto=format"
   alt="Sample search of all sessions where the custom vital `checkout-loading-time` duration was more than 1000ms." /%}

## Troubleshooting{% #troubleshooting %}

### No data appears after writing a query{% #no-data-appears-after-writing-a-query %}

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/understanding-rum-event-hierarchy/rum-no-data-appears-4.ba10462f874643b9a49462dbe355ea72.png?auto=format"
   alt="Example of no data appearing 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 **sessions**, 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.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/understanding-rum-event-hierarchy/rum-data-now-appears-1.e3fd518ed22326a46eb79d3030a3c8e0.png?auto=format"
   alt="Example of updating a query by using the view and time frame selectors." /%}

### Querying an event type that is nested in a different event type{% #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 `/`{% #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.

{% image
   source="https://datadog-docs.imgix.net/images/real_user_monitoring/guide/understanding-rum-event-hierarchy/rum-top-ten-actions-1.f5e28cfbd703727146af6934d6835c3b.png?auto=format"
   alt="Sample search of the top ten actions that occurred on the homepage." /%}

## Further Reading{% #further-reading %}

- [Learn about the RUM Explorer](https://docs.datadoghq.com/real_user_monitoring/explorer/)
- [Learn how to visualize your RUM data](https://docs.datadoghq.com/real_user_monitoring/)