EUM Data

With the iOS 14 release (supported by iOS Agent 20.10.0), Apple introduced a new data collection policy. See iOS Data Collection Disclosure for details.

This page describes the types of EUM data, how data is collected, where data is stored, and where data is displayed in the Controller. For data retention and license consumption details, see License Entitlements and Restrictions.

Types of EUM Data

Metric Data

Metrics are data that reflect your application's performance. Browser RUM captures metrics from browser applications, such as timing and Ajax metrics. Mobile RUM captures metrics from mobile applications, such as crash metrics and network request metrics. You can view and analyze EUM metrics in the Metric Browser.

To learn more about EUM metrics, see:

• Browser RUM Metrics
• Browser Synthetic Metrics
• Mobile RUM Metrics
• Extensions and Custom Metrics

Custom Data

Browser RUM

You can add specific user information from a browser snapshot of your application. The information is expressed as key-value pairs, appears in the User Data section of the snapshot, and is available for page snapshots, Ajax requests, and virtual pages. To learn how to set custom user data, see Add Custom User Data to a Page Browser Snapshot.

Mobile RUM

Mobile RUM custom data such as Info Points, Custom Timers, and Custom Metrics are considered metrics and stored as mobile request event data. User data is another type of Mobile RUM custom data. Custom user data can be reported through network request events because user data is attached to each network request. 

To learn how to set user data, see User Data (iOS SDK) or User Data (Android SDK).

EUM Analytics Data 

You can view EUM data in Analytics if you have a Real User Monitoring Peak license. The EUM Analytics data consists of event data and is stored in the Events Service and visualized in widgets. EUM Analytics provides data for these event types:

• Browser Requests Event Data

• Browser Sessions Event Data

• Mobile Requests Event Data

• Mobile Sessions Event Data

• Mobile Crash Report Event Data

• Synthetic Sessions

• Connected Device Data

Cookies for Browser Applications

Browser RUM uses two different kinds of short-lived cookies for the JavaScript Agent to collect data and correlate events. Both types of cookies do not contain any personally identifiable information (PII) and are immediately deleted after being read.

• ADRUM cookie: Written by the JavaScript Agent, this cookie contains the referral page URL and some timing information to assist in gathering First Byte Time for some browser types. When the agent loads on the subsequent page, it reads the information and then deletes the cookie. If there is no agent on that page, the cookie is deleted when the browser is closed. For privacy purposes, the URL of the referral page is hashed.
• ADRUM_BT cookies: Written by the server-side agent when the page is served from an instrumented server. These cookies help correlate browser data with related server-side performance data (Business Transactions). 
  • ADRUM_BTa: Contains the backend transaction ID as well as timing info and is used to correlates end-user experience with the health of the backend app.
  • ADRUM_BTg: Contains the backend transaction ID and is used as an alternative method to correlate end-user experience with the health of the backend app.
  • ADRUM_BT[1-5]: Contains the business transaction numbers as well as timing and error info for the first five business transactions, such as ADRUM_BT1, ADRUM_BT2, etc.
  • ADRUM_BTs: Contains a link from a browser snapshot to a server snapshot. 

  • ADRUM_BTh: Written only if there was a server-side error.

    

    If Browser RUM detects that the page is HTTPS, the Security attribute is set for cookies. The Security attribute is a flag that forbids a cookie from being transmitted via an unencrypted HTTP connection.

• SameSite cookies: Provides the JavaScript Agent access to ADRUM_BT cookie to maintain Business Transaction correlation. When SameSite cookies are present, the agent has access to the ADRUM_BT cookie with Business Transaction data. Without SameSite cookies, the agent cannot parse Business Transaction data in the cookie sent from the application server. This is because the agent is loaded from a different domain than the browser website.

Web Storage

Browser RUM stores key-value pairs in web storage to associate page views with a particular session and browser. The value for each key is a randomly generated ID.

The following lists the keys and the expiration time for each key-value pair:

• ADRUM_AGENT_INFO (never)
• ADRUM_CLIENTINFO (never)
• ADRUM_XD_AGENT_ID (never)
• ADRUM_XD_AGENT_INFO (1 week)

Mobile Local Storage

Mobile agents use beacons to transmit metrics, app metadata, network requests, crashes, and custom data. When a beacon cannot be transmitted, the data is persisted in permanent storage within the container of the application and subject to the security configuration of the device and application. No encryption is currently being utilized. Once the network connection is restored, the beacons resume transmitting data. Because some of the data is provided by the developer's instrumentation of the app, such as breadcrumbs, user info, and the app (URLs, crash reports), some information is not explicitly collected by AppDynamics.  

Mobile agents also locally store a randomly generated ID for tracking sessions and license usage. The ID is stored in the Events Service.

Data Storage and Retrieval

AppDynamics uses four data storage components to store Browser RUM and Mobile RUM data: the EUM Server, the Events Service, the Metric Service, and the Controller. The Controller UI has no visibility into which storage component holds the data because it only interacts with the Controller API.

Browser RUM utilizes a JavaScript Agent and Mobile RUM utilizes Mobile agents to send raw data to the EUM Server. The EUM Server verifies, aggregates, and packages the data once every minute. The EUM Server sends the data to the Events Service and to the Controller. The Controller sends the data to the Metrics Service. The Controller API fetches the data from one of the four data stores and delivers it to the Controller UI when it receives data requests. 

Data Storage Details

Browser RUM

This table shows where different Browser RUM data is stored. To see how long the data is retained, see License Entitlements and Restrictions. Resource details are only available for those browser snapshots with resource timing.

Browser RUM Default Data Limits per App Key

• Metrics: 100k

• Pages: 500

• Ajax Requests: 500
• Max Event Size: 1 MB

Mobile RUM

This table shows where different Mobile RUM data is stored. To see how long the data is retained, see License Entitlements and Restrictions.

Mobile RUM Default Data Limits per Mobile App and App Key 

Controller Mapping of Data

Browser RUM

This table shows the relationship between the Controller UI components and their data sources.

Mobile RUM

This table shows the relationship between the Controller UI components and their data sources.

Access EUM Data

In addition to accessing EUM data through the Controller UI, you can also access event data through Analytics and the AppDynamics APIs. The AppDynamics APIs include the Analytics Events API and the Metric and Snapshot API that you can use to access EUM metric data. 

If you have enabled Analytics and Browser RUM, you can use Browser Analytics to view data for these event types:

• Browser Requests
• Browser Sessions

If you have enabled Analytics and Browser Synthetic Monitoring, you can use Synthetic Analytics to view data for this event type:

• Synthetic Sessions

If you have enabled Analytics and Mobile RUM, you can use Mobile Analytics to view data for these event types:

• Mobile Requests

• Mobile Sessions
• Mobile Crash Reports

If you have enabled IoT Monitoring, you can use Connected Devices Analytics to view data for the event types below. You do not need to enable Analytics to use IoT Analytics.

• Connected Device Data

Data and Deployment Models

AppDynamics offers SaaS and on-premises deployment models. You can access most Browser and Mobile RUM data from either deployment model.