Overview

RUM without Limits allows you to capture all session data while only retaining the sessions that are valuable to your organization. This tool enhances your data management by separating session data ingestion from indexing.

Key features

• Dynamic retention filters: Adjust what data to keep without changing any code
• Comprehensive metrics: Metrics reflect 100% of sessions, ensuring full visibility
• Targeted session retention: Prioritize crucial session data for cost optimization

This guide provides strategies for managing your RUM session volumes effectively within your observability budget.

Understanding retention filter sequencing

RUM retention filters let you choose which user sessions to keep. Here’s how they work:

Each session contains multiple events (like views that represent navigation, user actions, errors, resources that represent network requests) and each of them is full of attributes (like duration, context, etc.). The system evaluates each event individually against your retention filters:

1. Session kept: If at least one event in a session matches a retention filter AND is sampled in for retention, then the entire session is preserved.
2. Session discarded: If no events match any retention filters by the time the session ends, the entire session is removed.

How different event types work

Some events (like errors and actions) cannot be changed after they happen. Datadog calls these immutable events. Others (like sessions and views) can change as the user continues using your app. Datadog calls these mutable events.

• Immutable events (Action, Error, Resource, Long Task, and Vital events) are only checked once against your filters and cannot be changed once created:

  1. The event stops at the first filter that matches its tags and attributes.
  2. A random number is generated and compared to the filter’s sample rate to decide if the event should be kept or discarded.
  3. If the event is kept, the entire session (including all previous events) is preserved, and future events from the same session automatically skip the retention filters.
  4. If the event is discarded, it’s not evaluated by other filters, but other events from the same session continue to be processed independently.

• Mutable events (Session, View) are re-checked every time they update:

  • View and Session events are different from immutable events because they can change over time. These events receive updates whenever new events happen within them.
  • Unlike immutable events that are evaluated only once, View and Session events are re-evaluated against the retention filters every time they receive an update. This continues until they match a filter for the first time.

Best practices

Ordering retention filters

The order of your retention filters is important. Datadog recommends putting the most specific filters with the highest sample rates at the top of the list, and your most general filters with the lowest sample rates at the bottom.

For example, imagine you have a crash event (an Error event with the @error.is_crash:true attribute). This event could match more than one filter, but it is only evaluated against the first matching filter in your list.

• In the example below, the “Crashes” retention filter is placed above the more general “All errors” filter. This means that all crash sessions are kept, because they match the “Crashes” filter first.

  ✅ Recommended

• In the following example, the more general “All errors” filter comes before the “Crashes” filter. Because of this, crash sessions are only kept if they are selected by the “All errors” filter (for example, if it has a 50% sample rate). If they are not selected, they are not evaluated by the “Crashes” filter, and those sessions are lost.

  ❌ Not recommended

Fallback filters for capturing remaining sessions

A fallback filter at the bottom of your list captures a small percentage of sessions that weren’t matched by other filters. You should always include @session.is_active:false in your fallback filter query.

• With @session.is_active:false: The fallback filter only evaluates completed sessions, letting your other filters capture sessions first

  ✅ Recommended

• Without @session.is_active:false: The fallback filter captures all sessions immediately, potentially overriding your more specific filters

  ❌ Not recommended

Suggested retention filters and use cases

Below we describe the set of default filters, suggested filters, and their typical use cases.

Further reading

Additional helpful documentation, links, and articles:

Retention FiltersDOCUMENTATION RUM without LimitsDOCUMENTATION Analyze Performance with MetricsDOCUMENTATION