Set Up Datadog RUM to Track Real User Experience (2026)

Datadog RUM is not just about tracking page loads; it’s about understanding the quality of the experience from the user’s perspective, in real-time, across all their devices and browsers.

Let’s see it in action. Imagine a user browsing your e-commerce site. They click on a product, then add it to their cart. We’re not just recording these events; we’re linking them into a user session.

Here’s a snippet of what that session might look like in Datadog:

{
  "session_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
  "user_id": "user_12345",
  "view": {
    "name": "Product Page",
    "url": "/products/widget-pro",
    "start": 1678886400000,
    "end": 1678886415000,
    "dom_complete": 1678886410000,
    "load_event_end": 1678886412000
  },
  "action": {
    "type": "click",
    "name": "Add to Cart",
    "target": {
      "selector": ".add-to-cart-button",
      "text": "Add to Cart"
    },
    "start": 1678886416000,
    "end": 1678886417000
  },
  "resource": [
    {
      "type": "xhr",
      "url": "/api/cart/add",
      "status": 201,
      "duration": 150,
      "start": 1678886416100
    }
  ],
  "error": []
}

This single JSON represents a slice of a user’s journey: they loaded the "Product Page," and then they clicked the "Add to Cart" button, which triggered an XHR request to /api/cart/add. If an error occurred anywhere in this flow (JavaScript error, network failure, slow resource load), it would appear in the error array.

The core problem RUM solves is the disconnect between what developers see in their staging environments and what users actually experience in the wild. Synthetics can tell you if your site is up, but RUM tells you if it’s usable and performant for real people. It bridges the gap by collecting client-side metrics directly from the user’s browser: page load times, JavaScript errors, slow network requests, frontend performance indicators like First Contentful Paint (FCP) and Largest Contentful Paint (LCP), and user interactions.

Setting up RUM involves a few key steps:

Install the RUM Browser SDK: This is a JavaScript snippet you add to your web application. You can integrate it via a <script> tag, a module bundler (like Webpack or Rollup), or a tag manager (like Google Tag Manager). The most common approach for a single-page application (SPA) using React, Vue, or Angular is to initialize the SDK early in your application’s lifecycle.

<!-- Via script tag -->
<script async src="https://www.datadoghq.com/rum-v2.min.js"></script>
<script>
  window.DD_RUM && window.DD_RUM.init({
    applicationId: 'YOUR_APPLICATION_ID',
    clientToken: 'YOUR_CLIENT_TOKEN',
    site: 'datadoghq.com', // or 'datadoghq.eu', etc.
    service: 'your-web-service-name',
    env: 'production',
    version: '1.2.3',
    sampleRate: 100, // Track 100% of sessions
    trackInteractions: true // Track user clicks, scrolls, etc.
  });
</script>

Configure Initialization Options: The init object is where you define your application’s identity and RUM’s behavior.
- applicationId and clientToken: These are your unique identifiers for Datadog. Get them from your Datadog account’s API keys section.
- site: Crucial for ensuring data goes to the correct Datadog region. Use datadoghq.com for US, datadoghq.eu for EU, etc.
- service, env, version: These tags are fundamental for correlating RUM data with your backend traces and logs. They should align with your existing tagging strategy.
- sampleRate: This determines the percentage of user sessions that will be monitored. For initial setup and debugging, 100 is common. For high-traffic sites, you might reduce this to manage data volume and cost.
- trackInteractions: Setting this to true enables the SDK to automatically capture user actions like clicks and form submissions, providing valuable context for performance issues.

Track User Views and Actions: The SDK automatically tracks page loads and navigations (for SPAs). For custom actions or more granular tracking, you can use the SDK’s API:

// Example of manually tracking a view change in an SPA
window.DD_RUM.startView('Dashboard Page', { 'page_type': 'dashboard' });

// Example of manually tracking a custom action
window.DD_RUM.addAction('click', { 'element_type': 'button', 'element_name': 'Save Settings' });

Monitor Errors: The SDK automatically captures unhandled JavaScript errors. For specific application errors you want to report, you can use:

try {
  // ... code that might throw an error ...
} catch (error) {
  window.DD_RUM.addError(error, { 'context': 'Error during user profile update' });
}

The mental model for RUM is a continuous loop: collect data from real users -> analyze performance and errors -> identify bottlenecks -> deploy fixes -> repeat. It’s about shifting from reactive debugging to proactive user experience management.

What most people miss is that RUM’s real power comes from correlating frontend issues with backend traces and logs. When a user reports a slow checkout, you can jump from a RUM session showing a long-running XHR request to the corresponding backend trace in Datadog APM, and then to the logs generated by that trace. This end-to-end visibility is what truly allows you to pinpoint and resolve complex, distributed issues.

The next step after setting up RUM is often integrating it with Datadog Synthetics to establish a baseline of performance and availability.