Skip to end of metadata
Go to start of metadata

On this page:

This section provides both an overview as well as pertinent details of Browser RUM sessions. We also describe the Session UI that you'll use to view session data.

What is a Browser RUM Session?

A Browser RUM session is a collection of chronological events for a particular end user from the start of a session to a configurable period of inactivity. An event represents an activity occurring at the moment in time that can be recorded, aggregated, and correlated at certain levels. In Browser RUM, events are limited to page loads, virtual page loads, iFrames, and Ajax requests. 

Only Ajax requests configured to be published to the Events Service are included in sessions.

For example, when a user purchases product from an e-commerce site, the session might capture the page/virtual page loads, iFrames, or Ajax requests for the user logging in (start), selecting and paying for products, and logging out (end).

The figure below describes how the user's actions cause events that are tracked in the session.

Why RUM Sessions Are Important

You can think of sessions as a time-based context to analyze a user's experience interacting with an application. By examining RUM sessions, you can understand how your applications are performing and how users are interacting with them. This enables you to better manage and improve your application, whether that means modifying the UI or optimizing performance.

Use Cases

In some use cases, you can use RUM sessions to analyze a user's or a group's behavior. You analyze a user's behavior based on the user's unique ID across multiple sessions in what is called sniping. In addition, you can query for a segment of users with similar behavior, such as visiting a certain specific page or using a particular device. This technique of grouping users with similar behavior is called bucketing. Browser RUM sessions allow you to query users on a wide array of criteria such as the type of browser, device, location, landing page, IP address, and more. 

How EUM Captures RUM Sessions

The JavaScript Agent loads a temporary GUID into the browser local storage and then transmits beacons to the EUM Cloud or EUM Server that include this GUID. We can then use the GUID to track the user's device over the duration of one or more sessions. The EUM Cloud then publishes these events into a session record stored in the Events Service. 

Session Persistence

Sessions persist until a period of user inactivity that you configure in the controller. Sessions can also end when the GUID is removed from local storage, which can happen for a number of reasons. For example, the user could clear local storage or the browser is configured to clear the local storage when the browser is closed.

Maximum Session Time

We don't technically limit the time of a session. Instead, we restrict the maximum number of events to 1000. You can, however, configure the maximum time for each event by configuring session monitoring timeouts and then derive the maximum time for a session by multiplying the configured session inactivity timeout by 1000. For example, if you configure the session inactivity timeout for each event to be five minutes, the maximum session time would be 5000 minutes. Of course, in this case, most sessions would not last 5000 minutes because end users would trigger events well before the maximum time of five minutes. 

Single Page / Multiple Page Sessions

When the browser cannot write the GUID to local storage, Browser RUM cannot track the user's device over one or more sessions. Instead, Browser RUM uses the temporary GUID in memory to create one-page or multiple virtual page sessions. Virtual pages are simply those sections of the DOM that are dynamically created and loaded into the current page.

Privacy/Security of Session Data

We do not perform browser or device fingerprinting. By default, we only store the end user's IP address for the maximum time of two weeks, but you can configure session monitoring to stop storing IP addresses. You can also get user data in sessions with the permission of end users. 

Browser RUM Support

Browser Compatibility

  • IE6/7/8/9/10/11/Edge
  • Chrome, including Mobile
  • Firefox, including Mobile 
  • Safari, including Mobile
  • Opera

Browsers are rapidly evolving, and not all versions have been individually tested with Browser RUM. You can view the browser versions likely to support the Resource Timing API.

Browser Requirements for Sessions

To use Browser RUM sessions, your browser is required to support for the following:

Browser RUM sessions do not support beacons implemented with GIFs.

Injection Types for Browser RUM in Java Environments

Listed below are the injection types with their supported frameworks/technologies:

  • Automatic Injection: JavaServer Pages (JSP) compiled using the Jasper compiler. Jasper is the default JSP compiler in Tomcat, Glassfish, and JBoss.
  • Assisted Injection: All Servlet frameworks.
  • Manual Injection: All technologies that generate HTML pages.

See Configure the JavaScript Agent for details.

Injection Types for Browser RUM in .NET Environments

AppDynamics certifies Browser RUM instrumentation forthefollowing.NET frameworks:

Web Application/ AJAX Frameworks


Additional Supported Script Injection Methods

ASP.NET Web Forms (.aspx)

3, 4

Automatic, Using Attribute Injection

ASP.NET MVC Web Forms (.aspx)

3, 4, 5

Automatic, Using Attribute Injection 


3, 4, 5

Automatic, Using Attribute Injection

ASP.NET Core on the full .NET Framework4.0+Using Attribute Injection

Microsoft SharePoint

2007, 2010


AppDynamics does not support Browser RUM instrumentation of legacy ASP (.asp) pages.

Supported Runtime Environments for .NET Browser RUM

  • Microsoft IIS versions 6.0, 7.0, 7.5, 8.0, 8.5

Session Limits 

The table below lists the limits for session operations per account.  

Session OperationsMaximum Per Account
Stored session resource snapshots10k per minute
Pending uploads of resource timing snapshots100k
Published session beacons10k per minute
Tracked sessions5k per minute

After the pending uploads of resource timing snapshots reach 100k, no further resource-timing snapshots are queued.

Sessions UI

As in Browser RUM Analyze, the main Sessions page is made up of two tabs:


The Records tab lets you scan individual sessions and allows you to filter and sort to get exactly the data in which you are interested.

Click View Details or double-click an item to see the information for a specific session. The sequence of page views for the session is shown on the left side of the screen. Select a specific page view to see detailed information, including a page load waterfall, tabular details for resources, and, if your backend is instrumented with AppDynamics, correlated server-side business transactions.  


The Charts tab provides you with a set of predefined widgets of the data set you have created plus a custom widget builder. As with the Charts tab of the Analyze UI, you can delete, re-add, resize, and drag-and-drop to move the widgets.


  • No labels