RUM (Real User Monitoring)

Real User Monitoring captures performance and interaction data from your real users’ browsers. Unlike browser checks (synthetic runs from the cloud locations you pick), RUM measures the actual experience: every user, every device, every network condition.

When to use RUM

Track user-perceived performance (web vitals: LCP, FCP, CLS, INP, TTFB).
Catch JS errors your test suite missed.
Understand real user flows (which pages, which buttons, in what order).
Identify slow regions, slow devices, slow ISPs.

When NOT to use RUM

Answering “is the site up?” is a job for a browser check or an HTTP check.
Backend performance belongs in traces.
A single canary value won’t come from RUM, which is statistical (millions of points), not deterministic.

How it works

You install the @siteqwality/rum SDK in your front-end. It:

Starts a session shared by the visitor’s tabs.
Records page views and Web Vitals with PerformanceObserver.
Listens for errors (error, unhandledrejection).
Tracks clicks, requests and other activity.
Sends batched events to https://in.siteqwality.com.

The SDK has two layers:

Observe, sent for every sampled session: page views, Web Vitals, errors (with their stacks), failed requests, frustration signals and custom events.
Analyze, activated only when a recording rule matches the session: every click and form action, successful requests, resource timings, console entries and long animation frames.

Session replay is the third tier: pixel playback, activated only by Replay recording rules.

RUM application

Each install of the SDK targets a RUM application, typically one per domain or one per major build. Each app has:

A unique application_id and a public client_token.
A domain, linked from the application’s dashboard header.
Privacy settings: a privacy level and selectors.
Recording rules that activate detail and replay capture.
Excluded resources: resource URLs it never records.

Create one under Observe → RUM.

Install

Install the SDK from npm or paste the CDN snippet into your pages; the RUM quickstart has both. If your site sets a Content Security Policy, see CSP and intake endpoints.

Tracking custom data

// Identify a user (call after login); the session then shows it
SiteQwalityRUM.setUser({ id: 'usr_abc', email: 'alice@example.com', name: 'Alice' });

// Label every later batch
SiteQwalityRUM.setGlobalAttribute('plan', 'pro');

// Custom error
SiteQwalityRUM.addError(new Error('Payment dialog refused'), { feature: 'checkout' });

// Custom event
SiteQwalityRUM.addAction('checkout_step_2', { variant: 'A' });

What gets captured

Observe (every sampled session)	Analyze (rule-activated)	Replay (Replay rule)
Page views, load timing, time spent and scroll depth	Clicks, taps, field changes and form submits	Full DOM snapshots and mutations
Web Vitals (LCP, FCP, CLS, TTFB, INP) with attribution	Successful fetch and XHR requests	Mouse, scroll and input events
Errors with message and stack (known browser noise filtered)	Resource timings	Privacy: masking and blocking from the application’s privacy level
Failed requests and frustration signals	Console entries
Custom events from `addAction`	Long animation frames

See what is collected when for the details.

Privacy

The SDK follows the application’s privacy settings, delivered with its config:

A privacy level, strict, balanced or relaxed, sets how replays mask inputs, text and media, and which personal data patterns are scrubbed.
hide_action_text: drop element text from click names. See hiding element text in click names.
Consent, Global Privacy Control, cookieless sessions and user email capture. See consent and browser signals.

Set these conservatively if you handle PII or financial data, and check what each application stores: one created before privacy levels may store mask_inputs: false. See replay privacy.

Session dimensions

Every session carries browser, os, device_type and country, so you can segment vitals and errors without instrumenting anything. Country is looked up from the client IP address at ingest; the IP itself is never stored or logged. See segmenting by dimension.

IP geolocation by DB-IP, CC BY 4.0.

In the dashboard

Overview opens with six key figures, each compared with the previous period: sessions, page views, visitors, sessions with errors, bounce rate and median active time. Core Web Vitals follows, with all five vitals at the 75th percentile (p75), each colored by Google’s thresholds, and the share of page views rated good, needs improvement and poor.

Vital	Good	Poor
LCP	≤ 2,500 ms	> 4,000 ms
INP	≤ 200 ms	> 500 ms
CLS	≤ 0.1	> 0.25
FCP	≤ 1,800 ms	> 3,000 ms
TTFB	≤ 800 ms	> 1,800 ms

Anything between the two is “needs improvement”.

Breakdowns rank routes, entry and exit pages, referrers, channels, UTM campaigns, countries, devices, browsers, operating systems, releases and frustrating elements. The Pages tab lists each route or path with views, sessions, p75 LCP, INP and CLS, and the share of sessions with an error.

Vitals charts plot p50, p75 and p95 in your local time zone. Buckets with fewer than 10 samples are drawn faded.

Sessions lists sessions active in the range that have at least one page view. Search matches any user ID or email the session carried, a session ID prefix, any visited URL or any error message in the session, ignoring case. Filters, sort and range live in the URL, so a copied link reopens the same view.

Errors groups errors with events, sessions and identified users per group for the selected range. An error’s page lists the affected sessions, and Replay opens the session’s replay at the error.