Datadog Real User Monitoring
Datadog Real User Monitoring (RUM) is an observability product that captures performance timings, errors, resource loads, and user-session data from real browsers and mobile apps. It is oriented toward front-end performance and reliability rather than marketing analytics. This page describes its data model and privacy posture even-handedly.
What this means
RUM instruments the browser (or app) to report what real users experience: page and route load timings, Core Web Vitals, resource and network performance, JavaScript errors, and session-level activity. Its purpose is performance and reliability observability, distinct from web or product analytics.
Within Datadog, RUM data can correlate with backend traces and logs, letting teams follow a slow or failing user interaction from the browser down through services.
Data model and posture
RUM records views, actions, errors, resources, and long tasks, grouped into sessions. Sampling controls how many sessions are captured, and the SDK offers privacy options such as masking and limiting what session data is recorded.
Because RUM observes user sessions, the privacy surface depends on those capture settings and your consent handling — sampling and masking reduce it, fuller session capture increases it.
- Captures timings, Core Web Vitals, errors, resources
- Session model groups views and actions
- Correlates with backend traces and logs in Datadog
- Sampling and masking govern the privacy surface
How it appears in analytics and logs
Datadog RUM in a page means a browser SDK is recording timings, errors, and session activity. Slow Core Web Vitals or error spikes here point to front-end or delivery issues, not marketing measurement.
Diagnostic use case
Use Datadog RUM to diagnose front-end performance and errors as real users experience them, correlating browser timings with backend traces in one observability platform.
What WebmasterID can help detect
WebmasterID's website observability focuses on traffic and bot intelligence; RUM is the complementary front-end performance lens on the same real users.
Common mistakes
- Treating RUM session counts as marketing visitor metrics.
- Capturing full sessions without masking sensitive content.
- Ignoring sampling when interpreting absolute counts.
Privacy and accuracy notes
RUM can record session activity and views, so privacy settings — sampling, masking, and what is captured — govern the surface. This is educational, not legal advice.
Related pages
- Sentry performance monitoring
Sentry is an error-monitoring and performance platform that captures exceptions and, through tracing, transaction timings across front-end and backend. Its browser SDK reports errors and performance from real sessions. This page describes its observability data model and privacy posture even-handedly, distinct from web analytics, with no ranking.
- New Relic Browser monitoring
New Relic Browser is the front-end monitoring component of the New Relic observability platform, capturing real-user page timings, errors, and AJAX/resource performance, and correlating them with backend telemetry. This page describes its observability data model and privacy posture even-handedly, distinct from web analytics, with no ranking.
- Pageviews: what the metric counts
A pageview is recorded when a page is loaded (or a virtual page is rendered in a single-page app). It is the oldest web-analytics metric and the easiest to misread: pageviews count loads, not people, and modern apps and prefetching can inflate or hide them. This page defines the metric and its caveats.
- Website observability
Traffic and bot lens alongside front-end RUM.
Sources and verification notes
- Datadog — Real User Monitoring documentationVendor docs for RUM browser and mobile monitoring.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.