Real user monitoring tools: interactions, replay and backend traces

If a team already runs backend APM, I would first check whether browser requests can join its existing traces. Another frontend dashboard may be useful, but it may leave engineers matching releases and finding requests across separate systems. A team mainly fixing page-load and interaction regressions may have less reason to consolidate infrastructure first.

The practical differences between real user monitoring tools lie in the evidence they retain. An INP distribution, a session timeline, a DOM replay and a backend trace answer different questions. Each has its own collection and retention path. A “RUM supported” label does little to explain where an investigation can go.

When user-side waits need to lead into services and logs, I would consider a connected platform such as Guance, especially if nobody is assigned to maintain those links. Teams with a mature toolchain should use what already works. For a narrow web-performance requirement, a specialist product or a small set of self-collected metrics may be a better fit.

Guance Editorial Team · 28 October 2026. This article compares documented behavior, and Guance is one of the services discussed. The sampling example uses explicit assumptions. We have not run an equivalent-workload performance test or established a conversion uplift or cost saving.

What does one INP value on a chart represent?

INP replaced FID as a Core Web Vital on 12 March 2024. It observes eligible click, tap and keyboard interactions during a page visit, including input delay, processing and the wait for presentation, with rules for outliers. It is neither first-input delay nor a measure of every action, such as scrolling. A visit without an eligible interaction may have no INP value. INP definition, transition date

Keep historical FID when it helps interpret older releases, but its observation scope differs from INP; do not splice the two into one continuous trend.

The field assessment uses the 75th percentile of page-visit INP, with mobile and desktop assessed separately; 200 ms or less is good. Taking p75 across all individual clicks, or averaging the p75 values of several pages, produces a different statistic. That distinction matters on pages kept open for many interactions. A single-page application's virtual routes also need not share the browser document's lifecycle, so understand how the deployed SDK assigns metrics to its Views.

LCP concerns the appearance of major content, INP concerns responsiveness, and CLS concerns visual stability. A home page appearing quickly says little about a filter used after login. Segmenting by device, page template and release makes the work more specific. A site-wide average can hide a serious regression affecting a smaller group on slower devices.

CrUX is a useful public baseline, with eligibility rules for users, browsers and pages. PageSpeed Insights can show page- or origin-level field data only when qualifying samples are sufficient. The CrUX API normally covers a rolling 28-day period, rather than an individual's live visit. Yesterday's fix does not immediately replace all that history. Missing URL data is not proof that nobody visited. CrUX methodology, API collection period

Synthetic checks still have a role. They repeat a selected journey from controlled locations and devices, including when no users are visiting. RUM describes successfully instrumented, permitted and delivered traffic. The populations differ: a healthy synthetic check cannot dismiss a problem limited to a device, signed-in state or long session.

A browser request needs more than matching tags

An API duration in the browser waterfall is the client's view of the whole wait. Connection setup, network travel, gateways and service processing can all contribute. A long request alone does not establish a slow database. To explain the server-side portion, the request must carry context the backend can continue, and the relevant spans must actually be collected and retained.

Guance's current Web SDK uses allowedTracingUrls to restrict trace-header injection to selected XHR/Fetch requests, and traceType to select propagation. This fragment belongs in the CDN integration's initialization options; it targets the example API path and uses W3C propagation. NPM/TypeScript integrations use the documented TraceType enum instead. Web integration and options

const tracingOptions = {
  allowedTracingUrls: [/^https:\/\/api\.example\.com\/v1\//],
  traceType: "w3c_traceparent"
};

These options do not instrument the server. Nor should the allowlist expand to arbitrary third-party domains. For cross-origin requests, the API and gateway must allow the actual injected headers; at least check traceparent for this example. Adding a non-safelisted header can introduce a CORS preflight. If it is rejected, the browser may block the business request itself. Once the request arrives, backend instrumentation must read and propagate the context. CORS preflights and headers

service, env and version help locate the right release, but matching tags cannot create a distributed trace. A sampled browser visit can point to a backend trace that was sampled out, or whose retention has expired. Guance's allowTraceHeaderWithoutSession can inject headers into eligible requests even when the RUM session is not sampled. It does not create that Session or report its missing View, Error, Resource or Action records.

With the connection in place, Guance's RUM request detail can lead into the associated trace and the existing APM path through services, logs and resources. Request details, trace details Teams already running Datadog, Dynatrace or New Relic should first consider their browser-to-backend paths as well. Frontend instrumentation need not trigger a backend migration. Sentry also supports distributed tracing across frontend and backend services; its origins in error investigation do not make it a frontend-only tool. Sentry propagation

A session, a replay and a metric have different histories

A session timeline organizes captured views, errors, actions and requests. Session Replay adds records from which an experience can be reconstructed. Guance's Web replay uses DOM snapshots and changes, rather than a screen video. Resource URLs and access to fonts and images, supported cross-origin or Canvas content, and the completeness of recording all affect what remains visible. Web replay integration, data integrity

Guance Web also needs an SDK build containing replay and a call to startSessionReplayRecording() to begin recording. Receiving View or Session data confirms those RUM records arrived; it does not establish that a replay is being recorded.

Replay sampling can be conditional on RUM session sampling. Datadog's Browser SDK documentation applies sessionReplaySampleRate to sessions already selected by sessionSampleRate. Assume one million sessions eligible for collection, 20% RUM sampling and 10% replay selection within that sample, without additional retention or error-triggered policies:

Expected RUM sessions = 1,000,000 × 20% = 200,000
Expected replay candidates = 200,000 × 10% = 20,000

These are expectations for two-stage random sampling, not delivery guarantees or a bill forecast. Permission, SDK loading, recording startup, network delivery and the product's billing rules also affect the actual count. The percentages are not added together, and one vendor's defaults do not describe another's. Error-triggered recording can introduce another path. Datadog sampling

Long-lived metrics also do not imply long-lived visit detail. Datadog's current RUM Measure provides aggregate metrics across sessions sent to it, while RUM Investigate controls which detailed sessions are retained. Its public offer retains the relevant out-of-the-box metrics for 15 months, and sessions and replays for 30 days. Check the SKU and agreement: a point on a three-month trend does not mean every underlying visitor can still be opened. Datadog plans and retention

Guance links Web replay retention to RUM retention, so changing the latter also changes replay availability. Backend traces and logs still follow their own policies. Keeping sessions for a seven-day support window but traces for three days removes some server-side evidence from the fourth day onward. Replay access and retention

Privacy rules shape what engineers can see later

An empty area in a replay is not necessarily packet loss. Guance Web currently defaults to mask-user-input; certain inputs and marked regions are masked. Check the actual handling of passwords, email, phone, payment-related fields and custom elements. If a name also appears in a URL, button label, custom attribute or manually supplied event, masking the input does not automatically sanitize those other paths. Privacy and expected omissions

Action names illustrate the distinction. The SDK's current enablePrivacyForActionName defaults to off; enabling it applies DOM privacy rules to automatically inferred Action names. Names deliberately supplied through business attributes or addAction() still need application-level care. Replay masking is not a universal redaction switch for the complete RUM payload. Actions and privacy

The SDK also does work on the device. Download size is only the start: DOM observation, long-task collection, network tracing, serialization, compression and recording consume runtime resources. Guance's standard and slim builds have different capabilities; the slim build does not provide Session Replay. Its bundle size cannot describe the overhead of a configuration with replay enabled. Compare loading, interaction and long-running use on the intended lower-end devices with the actual feature set. SDK builds and scope

Web, native Android/iOS and Mini Apps have separate SDKs and event semantics too. Browser support does not automatically cover a Mini App, and a native performance event does not establish browser-style DOM replay. Follow collection, upload domains, storage, support access, external calls and deletion through the intended deployment. A vendor's home country or a private-deployment label cannot settle all those details.

Choose around work the team already does

These paths help narrow the choice without assigning every product to a fixed camp.

SpeedCurve and DebugBear document real-user and lab views. Interpret each according to its source; one laboratory score does not describe every visitor. SpeedCurve CWV, DebugBear field data

web-vitals is a measurement library, rather than a complete session platform. Sending beacons to an endpoint and storing results in ClickHouse or BigQuery can support custom metrics and correlation. Somebody must still operate delivery handling, route/release dimensions, access, retention, queries and alerts. Grafana can visualize backend results; it does not create that pipeline. Existing infrastructure can make this a modest addition. Starting from scratch and adding replay is a different project. web-vitals measurement and reporting

Price the evidence that will remain available

One million visits produce different bills when metered as visits, sessions, retained sessions, events or data volume. A long session can generate many resources and actions; replay has its own payload and recording conditions. “Visits times a unit price” cannot price every service. Nor does a stored-file compression ratio determine another SDK's upload volume.

For Datadog, distinguish current Measure, Investigate and replay items. Dynatrace's current documentation lists RUM, optional Session Replay and RUM properties as separate consumption items. For New Relic, use the applicable data, user or compute model; an older per-GB figure cannot price the whole Browser service. Dynatrace consumption, New Relic pricing

Guance Enterprise Plan also needs its full boundary: ingestion uses compressed reported bytes, storage includes retained RUM data and replay files, and applicable processing, connected backend signals and dedicated compute must be included. A session-based offer needs its own rate card rather than a mixture with Enterprise Plan meters. Customers still maintain the SDK, business fields and privacy configuration. Enterprise billing scope

Where backend observability already exists, I would first connect the browser and align propagation and retention, then consider the repeated request-finding work that can go away. A frontend team concentrating on CWV should fund actionable interaction and release evidence. A team with an established data backend and narrow requirements can reasonably collect its own metrics. When users, services and logs need to form one investigation path, and nobody intends to maintain those links and query backends, compare Guance on that complete delivery scope.

Performance and conversion can be analyzed together, but device, acquisition source and user intent also affect both. Estimate the business effect of a fix with a controlled experiment or carefully designed analysis of the team's own journeys. RUM helps identify who experienced a change and retains evidence explaining it. It does not turn a simple before-and-after release comparison into causal proof.