RUM

Counting experiences with the session as the unit of record

RUM data is built with the session at the top. A session is one continuous usage experience of a single user, and within it, screen transitions (Views), interactions (Actions), network requests (Resources), and errors (Errors) are bundled. A session lasts at most 4 hours and expires after 15 minutes of inactivity. If there is an interaction after that, a new session starts automatically (as of August 2026, source: RUM & Session Replay). The practical meaning of this structure is that you can speak in terms of people: not "100 errors" but "23 users hit errors, 20 of them on the checkout screen." Whereas backend logs and metrics count the number of events, RUM counts the number of experiences. Being able to decide the priority of failures by "the number of people affected" is the biggest change before and after adopting RUM.

The 3 ways to add the SDK

There are 3 installation methods for browsers (as of August 2026, source: Browser Monitoring Setup). First, the manual method of embedding the SDK in the front end via npm or a script tag and initializing it with an application ID and client token. Second, Agentic Onboarding, which delegates the embedding to an LLM coding agent. Third, Auto-Instrumentation, which automatically injects the SDK into the HTML returned by the web server or proxy. Among the manual methods, npm bundling is the standard for modern apps and has no impact on page load performance, but it may miss errors that occurred before SDK initialization. Async loading from the CDN is for sites with strict performance targets. With any method, installation itself is complete once you write the initialization code. What is difficult is not the code but the design decision of "what to record and how far," covered from the next section on. For mobile, SDKs for Android and iOS native apps are available.

Session Replay - reproduction power and the masking default

Session Replay is a feature that plays back the user's browser experience like a recording, and it is built on the open source rrweb (as of August 2026, source: Session Replay). For "a bug report with no known reproduction steps," the value of seeing the actual screen exactly as it happened is rated more highly the more one has experienced it, because the sequence of interactions at the time of the error, the screen state, and the preceding transitions all remain. Replay data retention is 30 days by default. On the privacy side, a setting called defaultPrivacyLevel controls the granularity of recording, with a choice of mask (mask everything), mask-user-input (mask input values only), and allow (no masking). When the setting is not specified, the default is mask, and masked data is never collected in its original form by the SDK in the first place and is not sent to Datadog. In other words, masking is permanent and cannot be removed later to view the data (as of August 2026, source: Session Replay Privacy Options). Understanding this design of "removed before sending, irreversible" lets you carry the discussion of personal information described later forward on solid ground.

Protecting per-session billing with a 2-tier structure and sampling

RUM's billing unit is the number of sessions. On the official pricing page as of August 2026, it is divided into 2 tiers with different features.

The pattern of accidents is clear: while the low-priced Measure covers all traffic, if you apply Investigate or Session Replay, meant for detailed investigation, to the full volume without designing which sessions they apply to, the unit price difference (20 times and over 16 times Measure) shows up directly on the bill. Traffic surges from bots or viral attention also hit the session count directly. The center of the defense is sampling: at SDK initialization you can specify sessionSampleRate (the share of sessions collected as RUM) and sessionReplaySampleRate (the share of those recorded through to replay) (source: Client-Side Browser Monitoring Setup). "Collect broadly, narrow the expensive recording" is the standard initial design. The overall pricing structure is covered in the pricing guide. Note that prices in this article are examples at each point in time and do not reflect price revisions after writing.

Connect to APM traces and follow screen slowness all the way to the back end

RUM alone only tells you as far as "this request on this screen is slow." When connected to APM, the front-end request is tied to the corresponding backend trace, and you can follow "is the cause of the slowness front-end rendering, the API, or the DB beyond it" along a single line (as of August 2026, source: Correlate RUM Events with Other Telemetry). The configuration, assuming APM instrumentation is already done on the target service side, takes the form of listing your own API origins in the Browser SDK's allowedTracingUrls. With this, a trace ID is injected into requests to the targets, and you can jump directly from the RUM screen to the corresponding trace. Being able to reconstruct the event "it took 8 seconds on the customer's screen" from real trace data rather than hearsay via sales is all the more effective in organizations where front-end and back-end responsibilities are separated, because finger-pointing turns into reading data together. Note that the official documentation has a remark that this connection may affect APM billing, because the RUM side uses APM's paid data.

Personal information and consent - being able to say "what we collect"

Since RUM is a mechanism that collects behavioral data from real users, you cannot escape privacy design. The practical starting point is to create a state in which "if asked what our RUM collects, we can answer accurately." What is collected is screen transitions, interactions, requests, errors, and their attributes, and if Session Replay is enabled, the appearance of the screen is added. The first technical defense is the aforementioned masking (default mask, applied before sending, irreversible), and we recommend keeping a one-page table, shareable with legal and privacy staff, of the granularity at which input forms and elements displaying personal information are masked. Beyond that, how to obtain consent for behavioral collection via cookies and similar technologies is a matter that depends on the laws and regulations of the countries and regions the service targets and on the site's privacy policy, and is not something completed by Datadog settings alone. Not "we leave it to the tool's defaults" but "we can explain why we chose this setting" is the only posture that passes with both auditors and users. Put "updating the privacy policy text" into the pre-adoption checklist from the start, alongside the technical settings.

Who needs observation of real customers

RUM is effective first for services where the front-end experience is directly tied to business metrics: e-commerce checkout flows, SaaS onboarding, the reading experience on media sites. These are the places where "slow or broken" translates into revenue or churn, and the case for investing in observation per real user stands. Conversely, for internal tools with a small, specific set of users, or static sites with almost no dynamic interaction, the significance of paying per-session billing to observe real customers becomes thin. Another axis is "who covers monitoring during hours and on paths where there are no real customers." Because RUM is a passive mechanism in which data is generated only when there is actual access, it cannot detect a late-night outage or a failure on a path nobody has stepped on yet. That is the role of Synthetics, which actively sends simulated access, and the two are complementary rather than competing. If you first add RUM thinly to the main flows only and run for 1 month an operation of prioritizing bugs by the number of people affected, you can judge its value in your own organization from real measurements.