Skip to main content
Version: NG-2.16

RUM - Real User Monitoring

Introduction​

In today’s digital ecosystem, user expectations are higher than ever. Whether accessing a platform through a mobile app or a browser, users demand fast, seamless, and error-free experiences. Real User Monitoring (RUM) is a performance monitoring approach that captures real-time data from actual users interacting with your applications. It provides deep visibility into the end-user experience across platforms, devices, and network conditions.

RUM helps organizations understand how users experience their applications under real-world scenarios—tracking everything from screen or page load times, API responsiveness, user journeys, to crashes and errors. By using RUM, teams can move beyond assumptions and synthetic tests to make data-driven decisions that improve performance, usability, and overall satisfaction.

vuSmartMaps RUM provides a unified solution to monitor and optimize both browser-based and mobile applications, empowering teams with full-stack insights and actionable intelligence.

Getting Started with RUM​

Understanding RUM Terminologies​

What is RUM?

  • RUM (Real User Monitoring) provides full visibility into how users experience every digital transaction across web, mobile, and custom applications. It helps quickly assess user satisfaction, measure the real-time business impact, and gain a comprehensive view of the user journey.

How Does Browser Real User Monitoring (RUM) Work?

  • RUM functions by embedding code into an application to capture real-time metrics during actual usage. Here's how it works for different types of applications:
    • Browser-Based Applications: JavaScript code is injected to track:
      • Page Loads: Monitors how long it takes for pages to load.
      • XHR Requests: Tracks asynchronous requests that modify the UI without triggering a full page reload.
  • This setup allows continuous monitoring of user interactions and application performance.

What is a User Session?

  • A user session—also referred to as a "visit," "journey," or "clickpath"—represents a series of actions performed by the same user within your application over a defined period.
  • A single session typically includes:
    • Multiple Page or View Loads
    • Third-Party Content Requests
    • Service Requests
    • User Actions (such as clicks or taps)
  • Each session includes at least one user action, providing valuable insights into the user's interactions within the application.

What is a User Action?

  • A user action is an interaction with the end-user interface that triggers a call to a web server, which may involve multiple nested calls. It typically represents a transition from one view to another, initiated by user input.
  • Example User Actions:
    • Page Load
    • Click
    • Touch

What is a Load Action?

  • A load action refers to the process of an actual page loading in the browser. For instance, when you type a URL and press Enter, a load action occurs. During this action, various resources are loaded, including images, HTML, and CSS files, to display the page.

What is XHR Action?

  • "XHR Action" measures the time taken to complete an XMLHttpRequest (XHR), which is a browser API used to send and receive data asynchronously without refreshing the page. This is particularly important for modern web applications that rely on API calls to fetch dynamic content or update the user interface without disrupting the user’s experience. Efficient XHR performance is critical for responsive and seamless applications.

What is Largest Contentful Paint (LCP)?

  • LCP measures the time it takes for the largest visible content element (such as a prominent image, video, or block of text) on a webpage to render fully in the user’s viewport. It is one of the Core Web Vitals defined by Google to evaluate page load performance. LCP is significant because it reflects the moment when the main content of the page becomes visible to users, which is crucial for user satisfaction.

What is First Input Delay (FID)?

  • FID measures the time between a user's first interaction with the webpage (e.g., clicking a link, tapping a button) and the time when the browser begins processing that interaction. It is a Core Web Vital that reflects the responsiveness of the webpage. A low FID ensures a smooth user experience, especially during the critical page loading phase when JavaScript execution might delay responsiveness.

What is Cumulative Layout Shift (CLS)?

  • CLS measures the sum of all unexpected layout shifts that occur on a webpage during its lifecycle. A layout shift happens when visible elements, such as images, buttons, or text, move unexpectedly while the page is still loading or being interacted with. A low CLS score ensures visual stability, preventing issues like accidentally clicking the wrong button due to sudden changes in the layout. CLS is also a Core Web Vital and an important factor for user experience.

Types of Real User Monitoring​

Browser Real User Monitoring (BRUM)​

Browser Real User Monitoring (BRUM) focuses on capturing real-time performance data directly from users interacting with your web applications. It monitors metrics such as page load times, user interactions, and JavaScript errors, providing deep visibility into frontend performance.

To explore how to configure and visualize browser-based metrics, navigate to:

RUM Features​

Real User Monitoring (RUM) is a performance monitoring technique that captures and analyzes the interactions of real users with your application—whether on web (browser-based) or mobile platforms. It provides end-to-end visibility into user journeys, helping teams understand how actual users experience the application under real conditions, including different browsers, devices, network speeds, and geographic locations

Key Benefits of RUM​

  • Improved User Experience: RUM provides real-time visibility into how users navigate through your application. It helps identify slow screens, high-latency APIs, long page loads, layout shifts, or rendering lags that may frustrate users. By resolving these, teams can enhance responsiveness and satisfaction across both mobile apps and web applications.
Page taking too long to load? RUM reveals which screen, API, or device is the bottleneck—so you can fix it fast.
  • Faster Issue Detection & Resolution: RUM captures actual performance data and errors as users experience them. This allows teams to:
    • Detect frontend/backend issues early (e.g., API failures, crashes, slow frames).
    • Access session-level trace data and flame graphs to analyze performance bottlenecks.
    • Reproduce issues with real session details, reducing resolution time.
  • Enhanced Conversions & Engagement: Slow load times and errors directly impact drop-off rates. By improving performance at critical touchpoints (e.g., login, checkout, key content pages/screens), RUM helps reduce user abandonment, leading to higher engagement and conversion rates.
  • Data-Driven Decision Making: RUM provides actionable performance metrics—such as screen/page load time, session duration, error rates, and slow render tasks. Product, development, and business teams can use this data to:
    • Prioritize high-impact performance fixes
    • Justify infrastructure or UI investments
    • Identify usage trends across versions, platforms, and regions
  • Proactive Optimization: By identifying trends in error frequency, slow screens, or network degradation, RUM allows teams to proactively optimize performance before widespread user impact. This supports a shift from reactive troubleshooting to strategic performance management.
  • Targeted Feature Improvements: RUM data highlights which screens, APIs, and user journeys are most and least used. This helps product teams focus enhancements where they matter most, while reducing friction in underperforming paths.
  • Resource and Cost Optimization: By identifying redundant or poorly performing requests, high resource consumption, or third-party delays, RUM helps reduce unnecessary load and improve server efficiency—leading to better performance and lower operational costs.

Use Cases of RUM​

  • Performance Tracking: RUM helps track the performance of web pages, user actions, network requests, and frontend code. It allows you to monitor how well your application is performing and identify areas that may need optimization.

  • Error Management: With RUM, you can monitor ongoing bugs and issues, tracking them over time and across different versions. This makes it easier to identify patterns and address problems before they impact a larger portion of users.

  • Analytics and Usage: RUM provides insights into who is using your application, including details like the user's country, device, and operating system. It also helps track individual user journeys and interactions, allowing you to understand how users engage with different features of the application.

  • Support: RUM allows you to retrieve all the relevant information from a user's session, such as the duration, pages visited, interactions, resources loaded, and any errors encountered. This detailed data helps support teams troubleshoot and resolve issues quickly.

RUM Real-world Applications​

Proactive Performance Monitoring for Retailers

A retailer utilizing RUM monitors their online catalog to detect any increases in page load times. RUM alerts trigger when load times exceed the acceptable threshold, allowing the retailer to quickly identify and address performance issues. This ensures a smooth shopping experience, reducing cart abandonment rates and improving customer satisfaction.

Optimizing Medical Record Systems for Clinicians

A healthcare provider using RUM analyzes a clinician’s clickstream in an electronic medical record (EMR) system to enhance data entry efficiency. By monitoring user interactions, the system identifies bottlenecks in the interface, allowing for targeted improvements that streamline the workflow and improve clinician productivity, ultimately leading to better patient care.

Improving Mobile Device Performance for Apps

An application development team leverages RUM to detect performance discrepancies when their app is accessed from different mobile devices. By monitoring real-time user interactions, the team can pinpoint device-specific issues such as slow load times or crashes, allowing for optimized performance across a wide range of devices and improving the user experience for all customers.

Enhancing Conversion Funnels in E-Commerce

An e-commerce platform employs RUM to track users' paths through the conversion funnel, providing valuable data on where users drop off and how they navigate the site. By analyzing these user journeys, the platform can attribute revenue more effectively and make data-driven decisions to improve conversion rates, ultimately boosting sales.

Identifying Service Latency to Optimize Code

A software development team uses RUM to gain insights into service latency and identify poorly performing code. By tracking user interactions in real-time, developers can quickly detect areas where latency affects the user experience and take immediate action to optimize code, improving the overall application performance and user satisfaction.

FAQs​

Will the Real User Monitoring JavaScript impact my application’s performance or cause slowness?

No, Real User Monitoring is designed to have minimal impact on your application’s performance. The JavaScript snippet uses only about 1–2% of the existing browser resources, ensuring it does not interfere with the user experience or slow down page load times. Data transmission is lightweight and optimized, occurring asynchronously to avoid blocking or delaying critical application processes.

If the Real User Monitoring (RUM) data collector/proxy is down or not reachable, will it increase the resource usage in the user's browser?

When the RUM receiver is unreachable, the monitoring script still collects data locally, but the collected trace/data is typically discarded if multiple attempts to transmit fail.

Does RUM collect any sensitive information?

No, RUM does not collect any sensitive or personally identifiable information (PII). It is strictly focused on capturing performance metrics and Web Vitals (such as page load time, interaction delay, and visual stability). All data collected is anonymized and used solely to monitor and optimize application performance.

Explain that the telemetry sending from instrumentation libraries to Observability Platform through proxy server is done in an asynchronous fashion and does not block or affect the regular functioning of the web application?

Telemetry is sent asynchronously from the instrumentation libraries to the Observability Platform via a proxy, ensuring it doesn’t block the main thread or impact web application performance. However, the initial Decide API call is synchronous and may briefly block the thread. This is avoided when using static configuration, as the Decide API is not invoked.

Can you give information on session id and its life cycle?

A session ID uniquely identifies a browsing session for a specific user. It helps in grouping together all page views, resource loads, errors, performance metrics, and interactions that occur during one continuous visit to a site.

Session Start

A session typically begins when a user lands on a web page and there is no valid session ID stored.
At this point, the RUM script generates a new session ID—a 128-bit HexString in lowercase—and stores it in a cookie named vunetRumSessionId.

When the function getCurrentSessionId() is triggered internally:

  • If no valid cookie exists (either never set or expired), a new session ID is generated and stored in a cookie.
  • If a valid cookie (vunetRumSessionId) exists:
    • It checks the time since the last recorded activity.
    • If the inactivity exceeds 5 minutes, the session is considered expired and a new session ID is created.
    • If the inactivity exceeds 30 seconds but is less than 5 minutes, the session remains active, and the last activity timestamp is refreshed with the latest user action.

Session Continuation

As the user navigates across the site (via clicks or SPA route changes), the same session ID continues to be used to track all actions.
The session remains active if:

  • The user performs any action within 30 seconds to 5 minutes of the last recorded activity.
  • In such cases, the system updates the last activity timestamp and refreshes the session cookie, keeping the session alive.

A session is considered active as long as the user interacts within this time window.

Session Timeout / End

A session is considered expired after 5 minutes of inactivity (no user events, page loads, or resource requests).
Once expired:

  • The next user interaction triggers the creation of a new session ID and starts a new session.

Session ID Scope Across Tabs and Windows

The same session ID is reused when:

  • The user opens a new tab or browser window in the same browser and profile, and the hostname remains unchanged.
  • The session cookie is still valid.

A different session ID is generated when:

  • The site is accessed in incognito or private mode.
  • The user switches to a different browser or a different profile in the same browser.
  • The session cookie is missing or expired.
  • A different application (instrumented using the vuSmartMaps BRUM SDK) is used—the session ID will be unique for each application.

Explain Client IP information is made available?

The browser does not expose the public IP address via JavaScript for privacy reasons.One way to get the client IP is through reverse proxy.When the traffic is routed through proxy, the client’s original IP is passed via headers "X-Forwarded-For" The RUM backend(otel collector) reads these headers to determine the real client IP.

What is Distributed Tracing and why is it important?

Distributed Tracing is a method used to track the complete journey of a request as it moves through different components of a distributed system—such as from a browser application to backend services. It helps identify where delays or errors occur, making it easier to debug issues and improve overall performance.

What is a Trace ID and how is it injected?

A Trace ID is a unique identifier assigned to each user request. It is injected into the request headers—often by the browser monitoring agent—when the request is first made. This ID is then passed along with the request to backend services, enabling consistent tracking across the entire transaction.

What is Context Propagation in Distributed Tracing?

Context Propagation is the process of forwarding trace-related metadata—like the Trace ID and Span ID—between services as the request flows through them. This ensures that every part of the request is linked together and can be viewed as a single trace.

How does Distributed Tracing help track performance across browser and backend applications?

By using Trace ID injection and context propagation, Distributed Tracing connects events from the browser (such as a user click) with backend processing. This end-to-end visibility allows teams to measure the time spent in each service, identify bottlenecks, and troubleshoot issues more effectively.

How is it decided if Session Replay should be sent for a session?

A normalized percentage function decides whether a session is selected for replay. The formula is based on:

percentage(base + replayPercentage * RandomJitter) < replayPercentage

  • base: A numeric value generated by hashing the session ID (which is originally a string).
  • RandomJitter: A randomness factor that can vary by ±25% to ensure better distribution across sessions.
  • percentage: This function ensures the output is always in the range of 0 to 100.
    • If the result exceeds 100 (e.g., 105), it will be capped at 100.
    • If the result is below 0 (e.g., -5), it will be set to 0.

If the normalized value is less than the configured replayPercentage, the session is selected for replay. This mechanism helps control the volume of session replay data while maintaining fair and balanced sampling.

Is Session Replay data recorded for every session? If not, how is it decided when to send it?

No, Session Replay data is not recorded for every session. It is controlled through sampling, similar to Traces. To decide whether to capture Session Replay, we:

  • Hash the session ID to get a consistent numeric value.
  • Use a formula with sampling percentage and random jitter to determine eligibility.

Only if the result meets the sampling condition, the session is selected for replay.

note
  • Traces follow a similar sampling method based on the hash of the session ID.
  • Logs are always sent and do not follow any sampling percentage.