Digital Experience Monitoring (DEM)

Dynatrace DEM provides availability and performance monitoring to help ensure that your applications and services are available, functional, fast, and efficient across all channels, including mobile, web, IoT, and APIs.

Real User Monitoring (RUM)

Dynatrace RUM is a performance monitoring process that collects detailed data about each user's interactions with your application, whether it be a browser-based application or a mobile app deployed on Android or iOS. Real User Monitoring collects data on a variety of metrics. For example, data collected on load actions can include navigation start, request start, and speed index metrics.

The unit of measure for calculating your organization's consumption of RUM (web and mobile) is sessions per application per hour, excluding replay capture. A user action is a mouse-click, finger tap, or app start that triggers a web request (for example, a page load or a page-view navigation). A user who interacts with more than one web application or app during the same session consumes one session per hour for each application. For sessions that last longer than one hour, one session is consumed per hour. For complete details on when RUM user sessions start and end, see User session timings. RUM session consumption is not capped.

Sessions that include only one user action are considered "bounced" and aren't counted. A user who interacts with more than one application at the same time consumes one session for each of those applications.

Interactions with hybrid mobile apps, that for technical reasons include a web application and a mobile app, will only be considered as a single session.

For details about the respective monitoring-consumption metrics, see Built-in Real User Monitoring metrics.

RUM with Session Replay

Session Replay helps capture and visually replay the complete digital experience of your end users. User interactions with your application are recorded and can be replayed in a movie-like experience. Session Replay makes it easy to reproduce production issues and errors, and to understand problems such as malformed pages and infinite spinners.

When Session Replay is activated for a given RUM session, the unit of measure is one session per application (web and mobile) per hour with Session Replay activated (also referred to as "Session Replay Capture" in your rate card). Depending on the session, you are billed for a RUM session or a RUM session with Session Replay, but not both. If a session is longer than one hour, the session is counted multiple times (once per hour).

For details about the respective monitoring-consumption metrics, see Built-in Real User Monitoring metrics.

RUM properties

Dynatrace captures a lot of information about the performance of applications. This information can be enriched with valuable metadata and converted into user action and user session properties. These properties are useful when creating powerful queries, segmentations, or aggregations on the captured metadata.

As of April 26, 2023, Dynatrace offers a free tier of 20 defined RUM properties per application. This amount is subtracted from the total number of properties you have defined for your applications. To calculate total consumption, the subsequent balance, after subtracting the free tier allocation, is multiplied by the total number of sessions across all your applications.

For details about the respective monitoring-consumption metrics, see Built-in Real User Monitoring metrics.

Browser monitors (clickpaths)

A browser monitor simulates a user visiting your application using a modern, updated web browser to monitor your application's business-critical workflows. Browser monitors can be configured to run from any Dynatrace public or private locations at frequencies of up to every five minutes and sends alerts when the application becomes inaccessible or when performance degrades significantly. In addition, they can be used to check the availability of internal resources that are inaccessible from outside your network.

The Dynatrace recorder is used to capture an exact sequence of clicks and user inputs, availability, and performance. Alternatively, a defined sequence can be scripted to accomplish the same goal.

The unit of measure for browser monitors is a synthetic action. A synthetic action is an interaction with a synthetic browser that triggers a web request that includes a page load, navigation event, or action that triggers an XHR or Fetch request performed during private and public executions of Synthetic Browser Monitors. Scroll downs, keystrokes, or clicks that don't trigger web requests aren't counted as actions.

# Synthetic actions/requests consumed per monitor = (# Synthetic actions included in monitor) × (# Executions per hour) × (# Locations) × # Hours

XHR or Fetch requests that are made by a synthetic browser as the result of a user action like a page load, which isn't directly triggered by user input, don't result in user actions and therefore aren't counted. Such XHR and Fetch calls are considered child requests of synthetic actions.

For details about the respective monitoring-consumption metrics, see Built-in Real User Monitoring metrics.

Third-Party Synthetic API Ingestion

The third-party endpoints of the Synthetic API enable the pushing of third-party synthetic data and events to Dynatrace. The API also facilitates adjustments of results which were previously pushed to Dynatrace.

The unit of measure is a third-party synthetic result where the number of test results ingested with Third-Party Synthetic API are added together.

For details about the respective monitoring-consumption metrics, see Built-in Real User Monitoring metrics.

HTTP Monitors

Synthetic HTTP monitors can be created to check the availability of resources—websites or API endpoints. In addition, they can be used to check the availability of internal resources that are inaccessible from outside your network.

The unit of measure for HTTP monitors is a synthetic request. An HTTP monitor consists of one or multiple HTTP(S) requests (for example, GET, POST, HEAD requests). Each request executed by an HTTP monitor equates to one synthetic request.

# Synthetic actions/requests consumed per monitor = (# Synthetic actions included in monitor) × (# Executions per hour) × (# Locations) × # Hours

For details about the respective monitoring-consumption metrics, see Built-in Real User Monitoring metrics.

Digital Experience Monitoring (DEM) (DPS)

How consumption of Synthetic NAM Monitoring affects billing

Unlike HTTP or browser monitors, NAM monitors don't have a separate line on the Dynatrace rate card (please contact your Dynatrace account manager for complete details). Instead, you're billed based on the number of metric data points generated during each execution of a NAM test.

The following details apply to metric data points: