Overview

There are various ways you can modify the data and context collected by RUM, to support your needs for:

• Protecting sensitive data like personally identifiable information.
• Connecting a user session with your internal identification of that user, to help with support.
• Reducing how much RUM data you’re collecting, through sampling the data.
• Providing more context than what the default attributes provide about where the data is coming from.

Override default RUM view names

The RUM Browser SDK automatically generates a view event for each new page visited by your users, or when the page URL is changed (for single-page applications). A view name is computed from the current page URL, where variable alphanumeric IDs are removed automatically. For example, /dashboard/1234 becomes /dashboard/? .

Starting with version 2.17.0 , you can add view names and assign them to a dedicated service owned by a team by tracking view events manually with the trackViewsManually option:

1. Set trackViewsManually to true when initializing the RUM Browser SDK.

   import { datadogRum } from '@datadog/browser-rum';
   datadogRum.init({
       trackViewsManually: true,
   

   window.DD_RUM.onReady(function() {
       window.DD_RUM.init({
           trackViewsManually: true,
   

   window.DD_RUM &&
       window.DD_RUM.init({
           trackViewsManually: true,
   

2. You must start views for each new page or route change (for single-page applications). RUM data is collected when the view starts. Starting with version 4.13.0 , you can also optionally define the associated service name and version.

   • View Name: Defaults to the page URL path.
   • Service: Defaults to the default service specified when creating your RUM application.
   • Version: Defaults to the default version specified when creating your RUM application.
   • Context: Starting with version 5.28.0 , you can add context to views and the child events of views.

   For more information, see Setup Browser Monitoring .

   Latest version

   The following example manually tracks the pageviews on the checkout page in a RUM application. Use checkout for the view name and associate the purchase service with version 1.2.3 .

   datadogRum.startView({
        name: 'checkout',
        service: 'purchase',
        version: '1.2.3',
        context: {
            payment: 'Done'
   

   window.DD_RUM.onReady(function() {
      window.DD_RUM.startView({
            name: 'checkout',
            service: 'purchase',
            version: '1.2.3',
            context: {
                payment: 'Done'
   

   window.DD_RUM && window.DD_RUM.startView({
        name: 'checkout',
        service: 'purchase',
        version: '1.2.3',
        context: {
            payment: 'Done'
   

before v5.28.0

The following example manually tracks the pageviews on the checkout page in a RUM application. It uses checkout for the view name and associates the purchase service with version 1.2.3 .

datadogRum.startView({
  name: 'checkout',
  service: 'purchase',
  version: '1.2.3'

window.DD_RUM.onReady(function() {
  window.DD_RUM.startView({
    name: 'checkout',
    service: 'purchase',
    version: '1.2.3'

window.DD_RUM && window.DD_RUM.startView({
  name: 'checkout',
  service: 'purchase',
  version: '1.2.3'

before v4.13.0

The following example manually tracks the pageviews on the checkout page in a RUM application. No service or version can be specified.

datadogRum.startView('checkout')

window.DD_RUM.onReady(function() {
    window.DD_RUM.startView('checkout')

window.DD_RUM && window.DD_RUM.startView('checkout')

If you are using React, Angular, Vue, or any other frontend framework, Datadog recommends implementing the startView logic at the framework router level.

React router instrumentation

To override default RUM view names so that they are aligned with how you’ve defined them in your React application, you need to follow the below steps.

Note : These instructions are specific to the React Router v6 library.

1. Set trackViewsManually to true when initializing the RUM browser SDK as described above .

2. Start views for each route change.

      import { matchRoutes, useLocation } from 'react-router-dom';
      import { routes } from 'path/to/routes';
      import { datadogRum } from "@datadog/browser-rum";
      export default function App() {
        // Track every route change with useLocation API
       let location = useLocation();
       useEffect(() => {
         const routeMatches = matchRoutes(routes, location.pathname);
         const viewName = routeMatches && computeViewName(routeMatches);
         if (viewName) {
           datadogRum.startView({name: viewName});
       }, [location.pathname]);
      // Compute view name out of routeMatches
      function computeViewName(routeMatches) {
       let viewName = "";
       for (let index = 0; index < routeMatches.length; index++) {
         const routeMatch = routeMatches[index];
         const path = routeMatch.route.path;
         // Skip pathless routes
         if (!path) {
           continue;
         if (path.startsWith("/")) {
          // Handle absolute child route paths
           viewName = path;
         } else {
          // Handle route paths ending with "/"
           viewName += viewName.endsWith("/") ? path : `/${path}`;
       return viewName || '/';
   

      import { matchRoutes, useLocation } from 'react-router-dom';
      import { routes } from 'path/to/routes';
      export default function App() {
        // Track every route change with useLocation API
       let location = useLocation();
       useEffect(() => {
         const routeMatches = matchRoutes(routes, location.pathname);
         const viewName = routeMatches && computeViewName(routeMatches);
         if (viewName) {
           DD_RUM.onReady(function() {
             DD_RUM.startView({name: viewName});
       }, [location.pathname]);
      // Compute view name out of routeMatches
      function computeViewName(routeMatches) {
       let viewName = "";
       for (let index = 0; index < routeMatches.length; index++) {
         const routeMatch = routeMatches[index];
         const path = routeMatch.route.path;
         // Skip pathless routes
         if (!path) {
           continue;
         if (path.startsWith("/")) {
          // Handle absolute child route paths
           viewName = path;
         } else {
          // Handle route paths ending with "/"
           viewName += viewName.endsWith("/") ? path : `/${path}`;
       return viewName || '/';
   

      import { matchRoutes, useLocation } from 'react-router-dom';
      import { routes } from 'path/to/routes';
      export default function App() {
        // Track every route change with useLocation API
       let location = useLocation();
       useEffect(() => {
         const routeMatches = matchRoutes(routes, location.pathname);
         const viewName = routeMatches && computeViewName(routeMatches);
         if (viewName) {
           window.DD_RUM &&
             window.DD_RUM.startView({name: viewName});
       }, [location.pathname]);
      // Compute view name out of routeMatches
      function computeViewName(routeMatches) {
       let viewName = "";
       for (let index = 0; index < routeMatches.length; index++) {
         const routeMatch = routeMatches[index];
         const path = routeMatch.route.path;
         // Skip pathless routes
         if (!path) {
           continue;
         if (path.startsWith("/")) {
          // Handle absolute child route paths
           viewName = path;
         } else {
          // Handle route paths ending with "/"
           viewName += viewName.endsWith("/") ? path : `/${path}`;
       return viewName || '/';
   

Enrich and control RUM data

The RUM Browser SDK captures RUM events and populates their main attributes. The beforeSend callback function gives you access to every event collected by the RUM Browser SDK before it is sent to Datadog.

Intercepting the RUM events allows you to:

• Enrich your RUM events with additional context attributes
• Modify your RUM events to alter their content or redact sensitive sequences (see list of editable properties )
• Discard selected RUM events

Starting with version 2.13.0 , beforeSend takes two arguments: the event generated by the RUM Browser SDK, and the context that triggered the creation of the RUM event.

The potential context values are:

For more information, see the Enrich and control RUM data guide .

Enrich RUM events

Along with attributes added with the Global Context API or the Feature Flag data collection , you can add additional context attributes to the event. For example, tag your RUM resource events with data extracted from a fetch response object:

If a user belongs to multiple teams, add additional key-value pairs in your calls to the Global Context API.

The RUM Browser SDK ignores:

• Attributes added outside of event.context
• Modifications made to a RUM view event context

Enrich RUM events with feature flags

You can enrich your RUM event data with feature flags to get additional context and visibility into performance monitoring. This lets you determine which users are shown a specific user experience and if it is negatively affecting the user’s performance.

Modify the content of a RUM event

For example, to redact email addresses from your web application URLs:

You can update the following event properties:

The RUM Browser SDK ignores modifications made to event properties not listed above. For more information about event properties, see the RUM Browser SDK GitHub repository .

Discard a RUM event

With the beforeSend API, discard a RUM event by returning false :

Note : View events cannot be discarded.

User session

Adding user information to your RUM sessions can help you:

• Follow the journey of a given user
• Know which users are the most impacted by errors
• Monitor performance for your most important users

The following attributes are optional but Datadog recommends providing at least one of them:

Increase your filtering capabilities by adding extra attributes on top of the recommended ones. For instance, add information about the user plan, or which user group they belong to.

When making changes to the user session object, all RUM events collected after the change contain the updated information.

Note : Deleting the user session information, as in a logout, retains the user information on the last view before the logout, but not on later views or the session level as the session data uses the last view’s values.

Identify user session

datadogRum.setUser(<USER_CONFIG_OBJECT>)

Access user session

datadogRum.getUser()

Add/Override user session property

datadogRum.setUserProperty('<USER_KEY>', <USER_VALUE>)

Remove user session property

datadogRum.removeUserProperty('<USER_KEY>')

Clear user session property

datadogRum.clearUser()

Sampling

By default, no sampling is applied on the number of collected sessions. To apply a relative sampling (in percent) to the number of sessions collected, use the sessionSampleRate parameter when initializing RUM.

The following example collects only 90% of all sessions on a given RUM application:

For a sampled out session, all pageviews and associated telemetry for that session are not collected.

User tracking consent

To be compliant with GDPR, CCPA, and similar regulations, the RUM Browser SDK lets you provide the tracking consent value at initialization. For more information on tracking consent, see Data Security .

The trackingConsent initialization parameter can be one of the following values:

1. "granted" : The RUM Browser SDK starts collecting data and sends it to Datadog.
2. "not-granted" : The RUM Browser SDK does not collect any data.

To change the tracking consent value after the RUM Browser SDK is initialized, use the setTrackingConsent() API call. The RUM Browser SDK changes its behavior according to the new value:

• when changed from "granted" to "not-granted" , the RUM session is stopped, data is no longer sent to Datadog.
• when changed from "not-granted" to "granted" , a new RUM session is created if no previous session is active, and data collection resumes.

This state is not synchronized between tabs nor persisted between navigation. It is your responsibility to provide the user decision during RUM Browser SDK initialization or by using setTrackingConsent() .

When setTrackingConsent() is used before init() , the provided value takes precedence over the initialization parameter.

View context

Starting with version 5.28.0 , the context of view events is modifiable. Context can be added to the current view only, and populates its child events (such as action , error , and timing ) with startView , setViewContext , and setViewContextProperty functions.

Start view with context

Optionally define the context while starting a view with startView options .

Add view context

Enrich or modify the context of RUM view events and corresponding child events with the setViewContextProperty(key: string, value: any) API.

Replace view context

Replace the context of your RUM view events and corresponding child events with setViewContext(context: Context) API.

Global context

Add global context property

After RUM is initialized, add extra context to all RUM events collected from your application with the setGlobalContextProperty(key: string, value: any) API:

Remove global context property

You can remove a previously defined global context property.

Replace global context

Replace the default context for all your RUM events with the setGlobalContext(context: Context) API.

Clear global context

You can clear the global context by using clearGlobalContext .

Read global context

Once RUM is initialized, read the global context with the getGlobalContext() API.

Contexts life cycle

By default, global context and user context are stored in the current page memory, which means they are not:

• kept after a full reload of the page
• shared across different tabs or windows of the same session

To add them to all events of the session, they must be attached to every page.

With the introduction of the storeContextsAcrossPages configuration option in the v4.49.0 of the browser SDK, those contexts can be stored in localStorage , allowing the following behaviors:

• Contexts are preserved after a full reload
• Contexts are synchronized between tabs opened on the same origin

However, this feature comes with some limitations :

• Setting Personable Identifiable Information (PII) in those contexts is not recommended, as data stored in localStorage outlives the user session
• The feature is incompatible with the trackSessionAcrossSubdomains options because localStorage data is only shared among the same origin (login.site.com ≠ app.site.com)
• localStorage is limited to 5 MiB by origin, so the application-specific data, Datadog contexts, and other third-party data stored in local storage must be within this limit to avoid any issues

Micro frontend

Starting with version 5.22, the RUM Browser SDK supports micro frontend architectures. The mechanism is based on stacktrace. To use it, you must be able to extract service and version properties from your application’s file paths and filenames.

How to use it

In the beforeSend property, you can override the service and version properties. To help you identify where the event originated, use the context.handlingStack property.

Any query done in the RUM Explorer can use the service attribute to filter events.

Limitations

Some events cannot be attributed to an origin, therefore they do not have an associated handling stack. This includes:

• Action events collected automatically
• Resource events other than XHR and Fetch.
• View events (but you can override default RUM view names instead)
• CORS and CSP violations

Further Reading