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.
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.
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
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 do not store user IP addresses. If you configure the Controller to store IP addresses, then the IP addresses are stored for up to 14 days.
Browser RUM Support for Sessions
Browser Requirements for Sessions
To use Browser RUM sessions, your browser is required to support for the following:
cross-origin resource sharing (CORS) for beacons
local storage for multiple-page sessions (single-page / multiple virtual page sessions don't need local storage)
Browser RUM sessions do not support beacons implemented with GIFs.
The table below lists the limits for session operations per account.
|Session Operations||Maximum Per Account|
|Stored session resource snapshots||10k per minute|
|Pending uploads of resource timing snapshots||100k|
|Published session beacons||10k per minute|
|Tracked sessions||5k per minute|
After the pending uploads of resource timing snapshots reach 100k, no further resource-timing snapshots are queued.
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.