Technical deep dive · AuditJet vs Datadog RUM

Event ingestion, session replay, and observability at scale — a technical deep dive into Datadog RUM.

Before you choose a monitoring tool, you need to understand what the tools actually do. This page explains how Datadog RUM works — event ingestion, session replay, cardinality, APM correlation, billing — and where AuditJet fits for teams focused on Core Web Vitals and business impact.

Run Free Audit Start Monitoring

Section 01

What is Datadog RUM?

Datadog is a cloud monitoring and observability platform founded in New York in 2010 by Olivier Pomel and Alexis Lê-Quôc, two engineers who met while working at Wireless Generation. The company went public on Nasdaq in September 2019 and has since grown into one of the dominant players in the cloud infrastructure monitoring market, with a product surface that spans infrastructure monitoring, application performance monitoring (APM), log management, security, continuous testing, and real user monitoring.

Datadog RUM — Real User Monitoring — is the frontend layer of this observability stack. It is a JavaScript-based telemetry product that instruments your web application to capture what real users experience: page load times, JavaScript errors, network requests, user interactions, and full session replays. Datadog RUM is not a standalone product; it is one node in a platform designed so that each product amplifies the value of the others.

The target users of Datadog RUM are engineering teams at mid-to-large companies who are already using Datadog for infrastructure and APM. For these teams, adding RUM to an existing Datadog deployment is a natural extension — the same dashboards, the same alerting system, the same tag taxonomy, the same on-call workflows. The incremental investment is relatively low when the platform is already in place.

This is the Datadog flywheel. Every product Datadog adds compounds the value of the products that came before it. Frontend performance data — a slow LCP on the checkout page — becomes dramatically more actionable when you can click through to the backend trace that caused the delay, see the log lines emitted during that request, and correlate the spike with an infrastructure event on the upstream service. Individually, each data source is useful. Together, they create a debugging capability that no single-purpose tool can replicate. This compounding effect is the genuine case for Datadog RUM — and it is important to understand it clearly, because it also explains why Datadog RUM makes less sense in isolation.

Datadog is known for strong enterprise sales motion, deep integration with AWS, GCP, and Azure, and a compliance posture that satisfies SOC 2 Type II, HIPAA, PCI DSS, and GDPR requirements. For regulated industries — financial services, healthcare, e-commerce at scale — the Datadog platform is often the default choice precisely because it consolidates observability and compliance tooling into a single vendor relationship.

Section 02

How Datadog RUM works

Understanding Datadog RUM requires understanding a handful of core architectural concepts. These are not Datadog-specific inventions — they are the vocabulary of modern observability engineering — but Datadog's implementation of them is what shapes the product's capabilities and its cost structure.

Event ingestion

The central architectural concept in Datadog RUM is event ingestion. Rather than storing raw session recordings as the primary data model (as a tool like FullStory does), Datadog ingests discrete, structured events — page views, user actions, errors, long tasks, resource loads — each as a JSON record with a defined schema. A page view event carries metadata: URL, viewport, referrer, load timing, LCP, INP, CLS. A user action event carries the element clicked, the latency of any resulting network request, and a trace ID linking it to the backend.

This event-centric model has important implications. It means Datadog can run arbitrary queries over your frontend telemetry — "show me all sessions where LCP exceeded 4 seconds on Chrome Mobile in Germany, sorted by the user's revenue tier" — with the same query engine used across the rest of the Datadog platform. The tradeoff is that the per-session billing model is tied to this event volume: more sessions mean more events mean higher cost.

The RUM agent

Datadog instruments your application by injecting a JavaScript SDK — approximately 25–40KB gzipped — either via an npm package or a CDN snippet. The SDK instruments browser APIs automatically. It uses the PerformanceObserver API to capture Core Web Vitals (LCP, INP, CLS) and navigation timing. It wraps native fetch and XMLHttpRequest to capture network request timing and propagate trace context headers. It hooks into React (or other frameworks') error boundaries to capture unhandled exceptions with source-mapped stack traces. User interactions — clicks, form submissions, route changes in SPAs — are captured as action events.

The SDK batches events locally and flushes them to Datadog's intake endpoints at intervals or on page visibility change, minimising the impact on the user's connection. This is a well-solved engineering problem across the RUM category; Datadog's implementation is mature and handles edge cases like bfcache navigation, service workers, and cross-origin resource timing.

Session sampling and session replay

Datadog RUM's session replay feature can capture a full DOM replay of user sessions — every mouse movement, click, scroll, and DOM mutation — using a MutationObserver-based serialiser. The replay is reconstructed client-side, giving you a pixel-accurate video-like recording of what the user experienced.

Because storing full session replays at 100% of traffic is expensive, Datadog's SDK supports configurable session sampling. You set a sessionReplaySampleRate — typically 5–20% for production traffic — meaning only that fraction of sessions get full replay recording. You can also configure conditional sampling: record 100% of sessions that contain a JavaScript error, but only 5% of sessions overall. This keeps costs manageable while ensuring you capture the sessions most likely to be useful for debugging.

Cardinality

In observability, cardinality is the number of unique values a given tag or dimension can take. Browser name (Chrome, Firefox, Safari, Edge) is low-cardinality — four values. Country is medium-cardinality — around 200 values. User ID, session ID, and URL path for sites with millions of product pages are high-cardinality — potentially billions of unique values. High-cardinality data is expensive to index because the index itself grows proportionally to the number of unique values.

Datadog manages cardinality through its Indexed Spans model. When events are ingested, Datadog makes a retention decision: some events are retained in full detail for querying (indexed); others are summarised into aggregate metrics. You configure retention filters that determine which events to keep. This is a powerful but non-trivial configuration task — getting it wrong means either paying too much (retaining everything) or losing debugging fidelity (retaining too little).

APM correlation

One of Datadog RUM's most distinctive features is its ability to correlate frontend events with backend distributed traces. When the RUM SDK makes an instrumented network request, it injects Datadog's trace propagation headers (W3C traceparent or Datadog's own format) into the HTTP request. If your backend is also instrumented with Datadog APM, the same trace ID flows from browser to web server to microservice to database query. A slow LCP caused by a slow API call surfaces in Datadog RUM as a clickable link to the complete distributed trace — showing every service, every database call, every log line emitted during that request.

Billing model

Datadog RUM charges per session. A session is a 4-hour window of continuous user activity — a user who visits your site, leaves for two hours, and returns starts a new session. For SaaS products where users spend long periods in-app, this window mitigates billing inflation. For high-traffic content sites where users make many short visits, session counts accumulate quickly. At 100,000 sessions per month, costs run approximately $200–$400/month depending on features enabled. At 1 million sessions per month, costs can reach $2,000–$5,000+ before session replay storage. This makes Datadog RUM cost-predictable per user but potentially expensive at scale, especially for consumer-facing sites with high-frequency casual visitors.

Section 03

Key features of Datadog RUM

Datadog RUM is a broad product. These are the capabilities that matter most to engineering and product teams evaluating it.

Core Web Vitals tracking

Datadog RUM captures LCP, INP, CLS, FCP, and TTFB from real user sessions using the PerformanceObserver API. These metrics can be segmented by browser, device type, operating system, geographic region, and application version — letting you answer questions like "is our LCP regression specific to Safari on iOS 17?" The data reflects actual user experience rather than simulated lab conditions, which matters for understanding how Google's ranking algorithms perceive your site.

Session replay with DVR-like controls

Datadog's session replay lets you watch exactly what a user experienced — mouse movements, clicks, scrolls, form interactions, and DOM state changes — with a scrubber interface similar to a video player. When a user reports "the checkout button didn't work," you can find their session and watch the exact moment of failure. Sensitive inputs (passwords, credit card fields) are masked by default. The replay is reconstructed from DOM mutations rather than video capture, keeping storage costs manageable.

Error tracking

JavaScript errors are captured with full stack traces, automatically deobfuscated using source maps uploaded during your CI/CD build. Datadog groups errors by fingerprint, tracks the count of affected users, and shows the error rate over time. You can set alerts when an error rate exceeds a threshold or when a new error type appears in production. The integration between error tracking and session replay means you can immediately view the session of a user who hit a specific error.

Funnel analysis

Datadog RUM includes a funnel analysis feature that tracks conversion paths through your application. You define a sequence of views or user actions — landing page → product page → add to cart → checkout → confirmation — and Datadog calculates the drop-off rate at each step. This adds a product analytics dimension to what is otherwise a performance monitoring tool, making Datadog RUM useful for both engineering and growth teams.

User journey mapping

Beyond conversion funnels, Datadog RUM can visualise the actual navigation paths users take through your application — a Sankey-style diagram showing how many users move from each page to the next. This is useful for discovering unexpected navigation patterns (users navigating to a settings page from a place you didn't expect), identifying dead-end pages, and understanding how users explore your application organically.

Feature flag integration and mobile RUM

Datadog RUM integrates with feature flag providers (LaunchDarkly, Statsig, and others) so you can correlate performance metrics with flag states — answering whether the new checkout component caused an LCP regression in the variant group. Datadog also extends RUM to native iOS and Android applications, using SDKs that capture mobile-specific metrics alongside web RUM data, valuable for organisations operating across web and mobile surfaces.

Section 04

Strengths and limitations of Datadog RUM

Every tool has genuine strengths and genuine limitations. Understanding both is the foundation of choosing correctly.

Genuine strengths

Enterprise-grade session replay: Datadog's session replay is among the best in class, alongside FullStory. The DOM serialisation is mature, privacy masking is robust, and the replay UI is genuinely useful for debugging user-reported issues.
APM correlation: The ability to click from a slow frontend event directly to a distributed backend trace is a capability that only platforms can offer. If you're running microservices instrumented with Datadog APM, this is uniquely valuable.
Funnel and journey analysis: Adding product analytics on top of performance monitoring — conversion funnels, user journey maps — extends Datadog RUM's value from engineering to product teams.
Mobile RUM: If you operate both web and native mobile applications, Datadog's unified RUM coverage across iOS, Android, and web is a significant operational simplification.
Compliance and data residency: SOC 2 Type II, HIPAA, GDPR tooling, PCI compliance, and data residency options in the EU. For regulated industries, this compliance posture is a meaningful differentiator.
Deep ecosystem integration: The Datadog platform — infrastructure, APM, logs, security, synthetics — is one of the most complete observability stacks available. The compounding value of the full platform is difficult for any single-purpose tool to match.

Honest limitations

Per-session pricing is unpredictable at scale: Viral content, seasonal traffic spikes, or a successful marketing campaign can multiply session counts in hours. There is no billing cap on per-session plans, meaning unexpected bills are a real risk for fast-growing or content-heavy sites.
No AI fix blueprints or remediation guidance: Datadog RUM tells you that LCP is slow. It doesn't generate code-level fix suggestions or prioritise improvements by estimated revenue impact. The diagnostic step is left to the engineering team.
Synthetics is a separate product: Synthetic monitoring — scripted browser tests that run on a schedule regardless of real traffic — is Datadog Synthetics, a separately priced product. A complete monitoring stack (RUM + Synthetics) requires budget for two product lines.
No competitor benchmarking: Datadog RUM has no feature for comparing your CWV scores against competitors' public performance data. Understanding whether you're faster or slower than direct competitors requires external tooling.
No revenue impact modeling: Datadog does not connect CWV score degradations to estimated conversion or revenue loss. The business case for a performance investment must be made by the team separately.
Complex to configure correctly: Retention filters, session sampling rates, cardinality management, source map upload pipelines, and tag taxonomies all require engineering investment to configure well. Under-configured, Datadog RUM produces noisy, expensive data. It is not a tool you can deploy in an afternoon and trust immediately.

Section 05

The observability platform vs. the focused tool — a key architectural tradeoff

Datadog RUM's value is multiplicative. It compounds when you are also using Datadog APM, logs, and infrastructure monitoring. The APM correlation feature — arguably Datadog RUM's most powerful capability — is only meaningful if your backend is instrumented with Datadog APM. The funnel analysis becomes more powerful when you can correlate funnel drop-offs with backend errors surfaced in Datadog Logs. The infrastructure monitoring view tells you whether a CWV regression correlates with a deployment, a database failover, or a CDN configuration change. Each product in the Datadog platform amplifies the others.

Using Datadog RUM in isolation — without APM, without infrastructure monitoring, without logs — leaves most of its value on the table. You get session replay, Core Web Vitals from real users, and error tracking. These are useful capabilities. But you are paying for a per-session billing model designed for a product that does much more than you are using it for.

The billing model reflects this design intent. Per-session pricing makes economic sense when session data powers funnels, replays, APM correlation, and error tracking simultaneously — the session is the unit that unlocks all of these insights. If you only need CWV metrics, you are still paying for the session record, the session replay infrastructure, the event ingestion pipeline, and the query capacity that supports the features you are not using.

This is the concept of tool fit: the right tool is the one that solves your actual problem at the right altitude. If your problem is "our LCP is slow and we need to catch regressions before they hit users," Datadog RUM is architected for a larger problem — full-stack observability, distributed trace correlation, and multi-surface telemetry. That larger solution is correct for teams who need it. For teams whose problem is specifically Core Web Vitals and their business impact, it is solving a $4,000/month problem when the actual problem costs $49/month to solve.

Cost calculus

At 100,000 sessions/month, Datadog RUM costs approximately $200–$400/month depending on plan tier, before session replay storage. At 1 million sessions/month, costs reach $2,000–$5,000+. Consumer-facing sites with high-traffic content — blog posts, marketing pages, product listings — can accumulate millions of sessions from casual visitors who will never convert, each one billing as a full session. AuditJet uses flat-rate pricing starting at $49/month regardless of traffic volume.

Section 06

AuditJet vs Datadog RUM — an honest comparison

Both tools do real work. The question is whether you need the full platform or the focused instrument. Here is where each genuinely wins.

Capability	AuditJet	Datadog RUM
Core Web Vitals monitoring	Synthetic Lighthouse scans (hourly) + real-user CWV tracking with regression alerts and historical trend data.	Real-user CWV capture (LCP, INP, CLS, FCP, TTFB) segmented by browser, device, and geography.
Session replay	Not included. AuditJet is metric-level monitoring, not session recording.	Core feature. Enterprise-grade DOM replay with configurable sampling, privacy masking, and DVR controls.
APM and backend trace correlation	Not included.	Full distributed trace correlation — from slow frontend event to database query. Requires Datadog APM on the backend.
Revenue impact modeling	Connects CWV score changes to estimated conversion rate and revenue impact using industry research coefficients.	Not available. Business impact analysis is left to the team.
AI Fix Blueprints	Code-level remediation guidance per performance issue, generated by AI and prioritised by impact (Watchdog+ plan).	Not available. Diagnosis is the tool's job; remediation is the team's.
Competitor benchmarking	Compare your CWV scores against named competitors using public CrUX and Lighthouse data.	Not available.
White-label agency reporting	Branded PDF reports and multi-client dashboards for digital agencies (Agency plan).	Not available. Datadog is a direct-to-engineering-team product.
Synthetic monitoring	Included in all plans. Hourly Lighthouse scans from multiple locations.	Not included in Datadog RUM. Requires Datadog Synthetics — a separately priced product.
Error tracking	Not included. AuditJet focuses on performance metrics, not JavaScript error monitoring.	Full JavaScript error tracking with source-map deobfuscation, error rates, and affected user counts.
Mobile RUM	Not included.	Available for iOS and Android native apps.
Pricing model	Flat-rate $49–$499/month regardless of traffic volume.	Per-session billing. Scales with traffic — can be unpredictable at high volumes or during traffic spikes.
Setup complexity	URL-based setup in under five minutes. No SDK installation required for synthetic monitoring.	Requires SDK installation, source map upload pipeline, retention filter configuration, and sampling rate tuning.

Where Datadog RUM wins

Datadog RUM wins clearly in session replay quality — it is enterprise-grade, comparable to FullStory, with excellent privacy controls and a polished debugging experience. APM correlation is genuinely unique: no focused monitoring tool can show you the full trace from browser to database on a slow page load. Funnel and journey analysis, mobile RUM coverage, and compliance posture are meaningful differentiators for enterprise teams. If you are already on the Datadog platform — if your engineers live in Datadog dashboards, your on-call runbooks reference Datadog monitors, and your backend is already instrumented with Datadog APM — then adding Datadog RUM is a logical extension with compounding value.

Where AuditJet wins

AuditJet wins at the intersection of performance monitoring and business impact. The revenue impact modeling — connecting a CWV regression to an estimated conversion and revenue loss — is a feature Datadog does not offer and that fundamentally changes how engineering teams communicate with product and commercial stakeholders. AI Fix Blueprints give engineers actionable, code-level remediation guidance directly from the monitoring tool, closing the gap between diagnosis and fix. Competitor benchmarking — seeing how your LCP compares to named competitors — is an insight category that observability platforms have no architectural reason to build. Synthetic + RUM combined in a single flat-rate plan removes the need to budget for two separate Datadog products.

The key question for any team evaluating both tools is: are you trying to solve observability, or are you trying to solve performance quality and business impact? These are related but distinct problems. Datadog is an observability platform — it is excellent at giving engineering teams visibility into complex system behaviour across multiple layers. AuditJet is a performance quality tool — it is built around the question of how site speed affects user experience and revenue, and what to do about it.

Section 07

Who should use each tool?

Use Datadog RUM if

Your engineering team is already running Datadog for infrastructure monitoring, APM, or log management — you will get multiplicative value from adding RUM to an existing platform investment.
You need session replay for debugging user-reported issues and your team makes frequent use of individual user session recordings.
You need APM correlation — clicking from a slow frontend event directly to the backend distributed trace that caused it.
You operate native iOS or Android apps alongside your web application and want unified telemetry in one platform.
You are in a regulated industry (healthcare, financial services) and need a compliance posture with SOC 2 Type II, HIPAA, and data residency options from a single vendor.
Your primary problem is full-stack debugging — understanding complex failures that span frontend, backend, infrastructure, and external dependencies.

Use AuditJet if

Your primary goal is improving Core Web Vitals — LCP, INP, CLS — and you need continuous monitoring with regression alerts and historical trend data.
You want to quantify the revenue impact of performance regressions and communicate business value to stakeholders outside the engineering team.
You need AI-generated, code-level fix guidance that tells you not just that LCP is slow but exactly what to change in your codebase to fix it.
You want competitor benchmarking — seeing how your CWV scores compare to named direct competitors using real-world data.
You are a digital agency managing performance for multiple clients and need white-label PDF reports and a multi-client dashboard.
You want synthetic and real-user monitoring combined in a single flat-rate plan, without per-session billing that scales unpredictably with traffic.

Section 08

Frequently asked questions

What is Real User Monitoring (RUM)?

Real User Monitoring (RUM) is a category of web performance tooling that collects timing and interaction data from actual users visiting your application, running in their browsers on their devices and networks. Unlike synthetic monitoring — which simulates visits from a controlled lab environment — RUM captures the distribution of real-world performance across the full diversity of user devices, browser versions, network conditions, and geographies. Common RUM metrics include Core Web Vitals (LCP, INP, CLS), Time to First Byte (TTFB), JavaScript error rates, and network request timing. Datadog RUM, Google's CrUX dataset, and tools like SpeedCurve and Sentry all implement RUM, each with different architectural choices about what to capture, how to aggregate it, and what billing model to use.

How does Datadog RUM billing work?

Datadog RUM bills per session. A session is a 4-hour window of continuous user activity — a user who has been idle for more than 4 hours and returns starts a new session. Each session is a single billable unit regardless of how many page views, actions, or errors occur within it. Pricing is tiered by plan and session volume. At 100,000 sessions/month, costs typically run $200–$400/month; at 1 million sessions/month, $2,000–$5,000+ before session replay storage. Session replay storage is priced separately. Per-session billing is predictable in terms of cost per user, but unpredictable during traffic spikes from viral content, seasonal campaigns, or product launches.

What is session replay and how does Datadog implement it?

Session replay captures a reconstruction of what a user saw and did during their visit — mouse movements, clicks, scrolls, form interactions, and DOM changes — playable like a video. Datadog implements session replay using a MutationObserver-based DOM serialiser: rather than capturing video frames, it records DOM snapshots and the incremental mutations applied over time, then reconstructs the page state client-side at replay time. This approach is storage-efficient compared to video capture and allows scrubbing to any point in the session. Sensitive data (passwords, payment fields) is masked by default. Because full replay storage for 100% of sessions is expensive, Datadog provides sampling controls — teams typically record 5–20% of sessions, with the option to always record sessions that contain errors.

What is cardinality in observability?

Cardinality is the number of unique values a dimension or tag can take. Browser name (Chrome, Firefox, Safari, Edge) is low-cardinality — four values. Country is medium-cardinality — ~200 values. User ID is high-cardinality — one unique value per user. In observability systems, cardinality determines the cost and feasibility of indexing. A time-series database can maintain a counter per unique combination of tag values (metric series). If you tag a metric with user_id, the number of series explodes to the number of users, making queries prohibitively expensive. Datadog manages cardinality through Indexed Spans — when raw events are ingested, you configure retention filters that determine which events are kept in queryable detail versus summarised into aggregate metrics. This allows you to maintain high-fidelity data for important dimensions while controlling storage costs for high-cardinality ones.

Can Datadog RUM track Core Web Vitals?

Yes. Datadog RUM captures Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS), First Contentful Paint (FCP), and Time to First Byte (TTFB) from real user sessions using the PerformanceObserver API — the same browser API that Chrome uses to report CWV data to Google's CrUX dataset. These metrics can be filtered and segmented by browser, device type, operating system, geographic region, application version, and any custom tags you add. The data reflects actual user experience distribution rather than a single lab measurement, which is important for understanding how Google's Core Web Vitals ranking signals perceive your site across its full user base.

What is APM correlation and why does it matter?

APM (Application Performance Monitoring) correlation links a slow frontend event — a slow page load, a slow user action — to the specific backend distributed trace that caused the delay. When Datadog's RUM SDK makes an instrumented fetch or XHR request, it injects distributed trace propagation headers (W3C traceparent or Datadog's own format) into the HTTP request. If the backend service is instrumented with Datadog APM, the same trace ID flows through the entire request path — web server, microservice, database query — and Datadog can display the complete trace alongside the frontend event. For debugging slow LCP caused by a slow API: you see the frontend event, click through to the trace, and see whether the bottleneck was the application server, a slow database query, a downstream microservice, or an external API call. This capability is architecturally impossible for tools that only instrument the browser.

Can AuditJet replace Datadog RUM?

No — and AuditJet doesn't try to. Datadog RUM is an enterprise observability platform with session replay, distributed trace correlation, mobile RUM, funnel analysis, and error tracking. AuditJet is a focused performance quality tool for teams whose primary problem is Core Web Vitals monitoring and business impact. AuditJet adds things Datadog RUM doesn't: revenue impact modeling, AI fix blueprints, competitor benchmarking, synthetic monitoring included in all plans, and white-label agency reporting. Datadog RUM adds things AuditJet doesn't: session replay, APM correlation, mobile RUM, and JavaScript error tracking. The right choice depends on what problem you are actually trying to solve.

What is the difference between Datadog RUM and Datadog Synthetics?

Datadog RUM captures telemetry from real users visiting your site — it reflects actual user experience but only generates data when users are present. A site with low overnight traffic produces little RUM data between midnight and 6am. Datadog Synthetics is a separate product that runs scripted browser and API tests from Datadog's global infrastructure on a schedule — simulating user journeys whether or not real traffic exists. Synthetics gives you consistent baselines, uptime monitoring, regression detection on deploy, and performance data from specific geographic nodes. The two complement each other: Synthetics for consistent, comparable lab measurements; RUM for real-world distribution data. They are priced and purchased separately on the Datadog platform. AuditJet includes synthetic monitoring (hourly Lighthouse scans) and real-user CWV tracking in a single flat-rate plan.

Start monitoring

CWV monitoring that scales with your revenue, not your session count.

AuditJet gives you synthetic and real-user Core Web Vitals monitoring, revenue impact modeling, AI fix blueprints, and competitor benchmarking — at a flat rate that doesn't change when your traffic spikes.

Run Free Audit Start Monitoring