Browser Data Models in RUM

Real User Monitoring (RUM) emits a small set of event types that describe what the browser did and what the user experienced:

• Session: A container that groups all events belonging to a user visit.
• View: A page view or SPA route change; the anchor for page‑level metrics and Core Web Vitals.
• Resource: Any networked resource fetched by the page (XHR/Fetch, images, CSS/JS, fonts, etc.).
• Error: Uncaught JS errors and handled errors you report.
• Long Task: Main‑thread blocks (>50 ms) that degrade responsiveness.
• Action: User interactions such as clicks (and custom actions where applicable).

Each event carries common attributes (e.g., service.name, env, device/OS) and type‑specific attributes (e.g., view.url, resource.status_code). Use the View as your primary pivot: most investigations start at the view, then drill into resources, long tasks, and errors for that view.

How to read these tables

• Naming: Dot‑notation (e.g., view.url) groups related attributes. Keys are case‑sensitive.
• Units:
  • Durations are in milliseconds unless noted.
  • Sizes are in bytes.
  • Booleans are true|false.
• Timestamps: Epoch milliseconds (browser local clock) unless noted.
• Cardinality:
  • Low → good for grouping and faceting (e.g., env, service.name).
  • High → good for filtering only (e.g., session.id, view.id, URLs).
• Consistency: A session can contain multiple views; each view can emit resources, actions, long tasks, and errors.

Tip: Start every query by narrowing to a specific env and service.name, then filter a time window, then add conditions on view.url or resource.status_code.

Sessions

A session represents a contiguous user visit. It starts when the SDK loads and ends after 15 minutes of inactivity (idle timeout) or after a maximum of ~4 hours, whichever comes first. A session stitches together all views, resources, errors, and actions.

Use sessions to:

• Correlate multiple views performed by the same user in one visit.
• Analyse the full journey behind a crash or a slow page.
• Review the replay (if recording is enabled) alongside metrics.

Event Types

Example (filters): env = "prod" AND session.id = "..." → Inspect all views/resources/errors for that visit.

Views (Page loads & SPA route changes)

A view is emitted for traditional navigations and soft navigations (SPA route changes via History API/hash). Views are the anchor for page‑level performance and UX metrics:

• Loading time: Tuntil the page becomes idle after navigation.
• Core Web Vitals: LCP, CLS, INP attributed to the active view.
• Time spent: Active time on the view (until route change or tab close).

View Metric

View Attributes

Example (slow views): view.loading_time > 2500 AND env = "prod" → Show slow views; facet by view.url and device.model.name.

Core Web Vitals (attached to Views)

Core Web Vitals reflect real UX on key dimensions:

• LCP (Largest Contentful Paint): Loading smoothness of primary content.
• CLS (Cumulative Layout Shift): Visual stability; layout shifts without input.
• INP (Interaction to Next Paint): Overall interaction latency, replacing FID.

Interpretation:

• Good (typical targets): LCP ≤ 2.5 s, CLS ≤ 0.1, INP ≤ 200 ms.
• Track distributions by view.url and app.version to catch regressions early.

This page does not define additional CWV table fields. Use the View section for CWV‑related metrics surfaced alongside views (LCP/CLS/INP are attached to views in dashboards).

Example: INP > 200 AND view.url CONTAINS "/checkout" → Investigate interactions on Checkout; open related Session Replay for context.

Resources (Network requests & assets)

Resources capture the work your page asks the network to do: XHR/Fetch calls, images, fonts, CSS, JS, and more. For each resource we record method, URL, status, timing breakdowns, and sizes (when available).

Use resources to:

• Spot slow or failing API calls (group by resource.name or endpoint).
• Find oversized assets (large images, CSS/JS bundles) hurting LCP.
• See which third‑party hosts dominate time on page.

Resource Timing Metrics

Resource Attributes

Example (failures): resource.type = "xhr" AND resource.status_code >= 500 → List failing backend calls; facet by trace.id (if propagation is enabled) and service.name.

Errors (Runtime & reported)

Errors include uncaught JS exceptions plus errors you report manually (e.g., handled promise rejections). Each error links back to the view and session and carries message, type, stack trace, and (where possible) source file + line.

Use errors to:

• Triage noisy client exceptions by release and environment.
• Validate sourcemaps (minified stack traces indicate a mapping issue).
• Link to Session Replay to see exactly what preceded the error.

Error Metrics

Error Attributes

Example (release regression): error.type = "TypeError" AND app.version = "1.4.2" → Compare error volume vs previous version.

Long Tasks (Main‑thread blocks)

A long task is any main‑thread activity > 50 ms. Long tasks delay input processing and harm interactivity (and often inflate INP). They commonly originate from heavy JS execution, layout thrashing, or synchronous XHR.

Use long tasks to:

• Identify scripts causing jank (facet by long_task.name or resource.name).
• Correlate spikes with views, replays, and releases.

Long Task Timing Metrics

Long Task Attributes

Example: long_task.duration > 120 → Investigate outliers; check which view.url and script path they align with.

Actions (User interactions)

Actions represent key interactions (e.g., click/tap) and optionally custom actions your code emits. They provide the glue between user intent and technical signals (resources, long tasks, errors) that follow.

Use actions to:

• Attribute slowness to specific clicks (e.g., “Place order” triggers heavy work).
• Inspect interaction targets and selectors to find fragile UI.

Action Metrics

Action Attributes

Example: action.type = "click" AND action.target.name = "Add to cart" → Trace the resulting resources and errors.

Common attributes (applies to most events)

These are attached broadly so you can slice and compare across dimensions:

• service.name, project.name, env: Logical ownership & environment.
• app.version: Release tag used for rollouts and regression analysis.
• session.id, view.id: For precise scoping.
• Device & OS: device.model.*, os.*, browser.* for platform variance.

Core

Operating System

Geo-Location

Tip: Keep service.name stable over time; use app.version for release grouping rather than encoding versions into service names.

Trace correlation (RUM ↔ APM)

If you enabled trace propagation in the browser, RUM adds trace headers to matching hosts. When your backend accepts these headers, Middleware correlates resource events to backend traces, enabling a full path from click → request → service span → database.

Use correlation to:

• Jump from a failing XHR in RUM to the exact backend trace.
• Understand which services affect a slow view.

Trace identifiers are shown alongside resources in the UI when trace propagation is enabled; no additional fields are defined on this page.

Example: Filter a failing resource and select Open in Trace from the event panel.

Privacy & PII (reminder)

• Client‑side masking: Inputs and selected DOM nodes can be masked/excluded before data leaves the browser (see Session Recording Privacy).
• Headers & URLs: Use ignoreHeaders and ignoreUrls to avoid capturing sensitive values.
• Data minimisation: Prefer IDs over raw user data; use hashing if a join key is required.

These controls do not change the data model—only what values are allowed to populate each field.

Practical queries (copy ideas)

• Find slowest pages: view.loading_time > 2500 → group by view.url.
• Track CLS regressions: CLS > 0.1 → group by app.version and view.url.
• Investigate 5xx backends: resource.type = "xhr" AND resource.status_code >= 500 → open traces.
• Jank hotspots: long_task.duration > 50 → facet by resource.name (script).
• Error spikes after deploy: app.version = "X.Y.Z" AND event.type = "error" → compare to previous.

Glossary

• Idle time / Loading time: Time from navigation/route change until no network or long tasks occur for a short window.
• Soft navigation: Route changes without full page reload (SPA via History API/hash).
• Largest Contentful Paint (LCP): Render time of the largest above‑the‑fold content block.
• Cumulative Layout Shift (CLS): Sum of unexpected layout shifts.
• Interaction to Next Paint (INP): End‑to‑end latency for user interactions.
• Long Task: Any main‑thread task > 50 ms.

Frustration Data

Frustration signals help you identify your application’s highest points of user friction by surfacing moments when users exhibit frustration.

Frustration Metric

Frustration Attributes