• Home
  • How to use Dynatrace
  • RUM
  • Basic concepts
  • User actions

User actions

A user action is an interaction with an end-user interface that involves a call to a web server, which can potentially have multiple nested calls. It is a transformation from one view to another view that is triggered by a user input, for example, a page load, click, or touch.

User action types

The following types of user actions are available in Dynatrace:

  • Load action
  • XHR action
  • Custom action

The key difference among these action types is the way action duration is calculated and the list of available metrics.

Load action

A load action is defined as an actual page loading in your browser. If you type a URL in your browser and press Enter, a load action occurs. During this action type, many resources are loaded, including images, HTML, and CSS.

The action duration in this case is the time required for the complete load action. More specifically, the start time of the user action equals the W3C navigationStart time. If this attribute is not available, the start time equals the time when the RUM JavaScript is initialized in the browser. The end time is when the last onload handler has completed its task. The onload handler is an event handler in JavaScript that's used to call the execution of JavaScript after a page, frame, or image has completely loaded. If any XMLHttpRequests are started by an onload handler, the user action ends when the XMLHttpRequest is complete.

Page load cycle

User action timings

The following measures are used to chart the duration of specific steps in the load action process.

MeasureDescriptionDefinition in terms of W3C specification
DNSTime spent resolving domain names.window.performance.timing.domainLookupEnd - window.performance.timing.domainLookupStart
TCPTime spent establishing a socket connection from the browser to the web server.window.performance.timing.connectEnd - window.performance.timing.connectStart
SSLTime spent establishing a secure socket connection from the browser to the web server.window.performance.timing.connectEnd - window.performance.timing.secureConnectionStart
RedirectTime spent following HTTP redirects.window.performance.timing.redirectEnd - window.performance.timing.redirectStart
RequestTime spent waiting for the first byte of the document response.window.performance.timing.responseStart - window.performance.timing.requestStart
ResponseTime spent downloading the document response.window.performance.timing.responseEnd - window.performance.timing.responseStart
TTFBTime at which the first byte of response from the server arrives at the client.window.performance.timing.responseStart
Network timeTime taken to redirect, resolve the DNS, and establish the TCP connection.window.performance.timing.responseEnd - window.performance.timing.fetchStart - (window.performance.timing.responseStart - window.performance.timing.requestStart)
Server timeTime spent receiving a request and sending the response back to the client.window.performance.timing.responseStart - window.performance.timing.requestStart
Processing timeTime between DOM loading and Load event start.window.performance.timing.loadEventEnd - window.performance.timing.domLoading
App cacheTime spent on checking relevant application caches.window.performance.timing.domainLookupStart - window.performance.timing.fetchStart
Frontend timeTime spent in the browser on executing JavaScript and rendering the page.User Action Duration - Server Time - Network Time
OnDomContentLoadedTime spent on executing OnDomContentLoaded handlers.window.performance.timing.domContentLoaded - window.performance.timing.domLoading
OnLoadTime spent on executing OnLoad handlers.window.performance.timing.loadEventEnd - window.performance.timing.loadEventStart
CallbackTime spent on executing XHR callbacks.-
First paintTime spent from navigation to when the browser renders the first non-default background element.-
First input startTime when the user first interacts with the page, for example, clicks an end-user interface element.-
First input delayTime spent from the first input start to when the browser is able to respond to that interaction.-
First contentful paintTime spent from navigation to when the browser renders the first bit of content, such as text or images.-
Largest contentful paintTime spent from navigation until the largest content element in the viewport is completely rendered.-
Cumulative layout shiftSum of all individual layout shift scores for every "unexpected" layout shift occurring during a load action.-
Visually completeTime at which all the content in the browser visible area has been fully rendered.-
Speed indexTime in average at which the visible parts of the page are displayed. A lower speed index means that most parts of the page are rendered very quickly.-
User action durationTime between the initial user input and complete page load. Also includes load time of XHR requests initiated before loadEventEnd and load time of dynamic resources and script executions triggered by DOM modifications.-

XHR action

Most modern applications, including single-page applications, rely on a single load action that downloads the framework and initializes the page. After that, the DOM of the page is changed via JavaScript, and all communication with the web server is done via XmlHttpRequest.

Dynatrace continuously tracks user interactions with each page. If user interaction leads to XmlHttpRequests or fetch() calls, an XHR action is created. Dynatrace also detects if there are additional XHRs triggered in the callback of the initial XHR and so on. In this case, Dynatrace waits until all requests are finished. By monitoring the DOM, Dynatrace can also identify resources that have been added in the callbacks. Dynatrace then waits until those resources have finished downloading before ending the action.

XHR actions

An XHR action starts with the user's click on a control on a web page. All metrics are calculated in relation to this point in time and are based on the initial XHR that triggers the user action.

Detected interaction types

Real User Monitoring detects the following interaction types in your application:

  • Click
  • Double click
  • Mouse down
  • Mouse up
  • Scroll
  • Key down
  • Key up
  • Touch start
  • Touch end
  • Change

For web apps To select which interaction types should be captured automatically

  1. In the Dynatrace menu, go to Web.
  2. Select the application that you want to configure.
  3. In the upper-right corner of the application overview page, select More (…) > Edit.
  1. From the application settings, go to Capturing > Advanced setup.
  1. Scroll down to the Wrappers for addEventListener and attachEvent section, and use the toggles to include or exclude the interaction types from being captured.

    Global event capture

Fetch API

The Fetch API provides an interface for fetching resources, including resources across the network. It is similar to XMLHttpRequest, but the API provides a more flexible feature set. The generic definitions of Request, Response, and other network request objects in Fetch allow them to be used at any time they are needed, whether it's for service workers, Cache API, or anything that handles or modifies requests and responses. Fetch also supports the Cross Origin Resource Sharing (CORS).

User actions based on the Fetch API appear in Dynatrace as XHR actions. You can configure RUM to automatically detect and capture Fetch API request information.

Custom user action

Rather than relying on default user action generation, you may want to fine-tune your Real User Monitoring by adding additional user actions directly into your application's HTML. This can be useful if our automated user-action generation doesn't catch specific actions or you want to introduce specific fine-grained timings into your application monitoring. For example, you can measure how long it takes to open a JavaScript-only dropdown menu, or you can measure the duration time of some JavaScript code. To define custom actions, use the RUM JavaScript API.

User action duration

The duration of a user action can be broken down into three components:

  • Server time: The time consumed on the server side.
  • Network time: The time required for data transfer.
  • Frontend time: The time required for the browser to render the page.

These components contribute to the overall duration of a user action.

The user action duration is calculated as follows:

  • User action duration = (loadEventEnd or endTimeOfLastXHR) - actionStart

where:

  • actionStart: navigationStart for page loads or "click time" for XHR actions and user navigations, such as a click on a button or a link
  • endTimeOfLastXHR: When XHR calls are triggered during the process and aren't finished before loadEventEnd, then the end time of the last XHR call is used instead of the loadEventEnd time

The user action contributors are calculated as follows:

  • Server time = responseStart - requestStart
  • Network time = (requestStart - actionStart) + (responseEnd - responseStart)
  • Frontend time = User action duration - Server time - Network time

Below you can view examples of user action contributors:

User action contributors for a single instance of a user action within a user session

User session view

User action contributors aggregated for one user action, in other words, across all user action instances

User action view

User action contributors aggregated for the entire application

Application overview

User action naming rules

Many applications allow users to accomplish the same goal using different UI controls and following different paths. When monitoring such applications, it can be difficult to differentiate between actions that have the same result and goal but are executed using different parts of the application UI. Likewise, if the application is translated into multiple languages, the same application function or UI element can appear under varying names. With user action naming rules, Dynatrace can detect such subtle variations and intelligently group user actions that achieve the same goal into logical groups for monitoring.

Dynatrace automatically removes certain common sessionid tokens from user action names, for example, jsessionid for Java containers, default sessionid for PHP, and CFID and CFTOKEN for ColdFusion. Nonetheless, there are numerous session ID variations that may be present in your environment. If Dynatrace doesn't automatically recognize and remove session IDs from certain user action names you encounter, you'll need to configure custom naming rules for those user actions.

Action name detection

Dynatrace tries to assign meaningful names for actions. To do this, it checks several action properties, such as inner HTML, caption, and hint of the HTML element that triggers the action. This element can either be a button or an anchor. It also tries to get the caption if there's a more complex HTML structure with multiple nested tags.

Set action name with data-dtname custom attribute

If the standard action name detection doesn't serve your purpose, you can set the data-dtname custom attribute within the HTML tags and use it as a caption. For instance, the following action:

html
<label for="txtFirstname">Firstname</label> <input data-dtname="Firstname Text Input" type="text" value="firstname" name="firstname" title="Firstname" id="txtFirstname" />

can be assigned the click on "Firstname Text Input" caption.

For a custom attribute to appear as a user action name, you also need to configure a naming rule that includes the {elementIdentifier (default)} placeholder.

If you're using different attribute names for different tools, you can choose to set an alternative to data-dtname that Dynatrace can use for user action naming purposes.

Resolving captions for actions

The RUM JavaScript uses several techniques to choose the name that best fits an action. It starts with the innermost HTML node that is clicked, such as a button, an image tag, or a link, and checks the following in the order of precedence:

  1. data-dtname attribute
  2. nodeName, such as an image, anchor, or input
    It stops when the html tag, body tag, head tag, or document element is found.
  3. innerText or textContent

If none of these return a reasonable result, the RUM JavaScript starts applying a recursive algorithm that checks different things depending on nodeName of the currently checked HTML node. If nothing is found, the parent node is checked.

Key user actions

Most applications, both web and mobile, include user actions that are particularly important to the success of your digital business. Examples of these actions are signups, checkouts, and product searches. Such key user actions might take longer to execute than others, or they might have the requirement to be of a shorter-than-average duration.

For instance, consider that you've set your global Apdex threshold to 3 seconds. While this threshold might be acceptable for the majority of user actions, it might not be acceptable for a signup user action. Alternatively, there could be a search action that is quite complex and requires more time than the allotted 3 seconds.

With the key user action feature, you can customize the Apdex thresholds for each of these user actions. You can use this feature to monitor key actions with a dedicated dashboard tile and track historical trends.

You can define up to 500 key user actions per environment across all your applications and up to 100 key user actions per application.

When you reach the maximum key user action limit, consider using calculated metrics for Real User Monitoring, which offer similar capabilities.

Mark a user action as a key user action

Web applications
  1. In the Dynatrace menu, go to Web.
  2. Select the application, and scroll down to Top 3 user actions.
  3. Select View full details.
  4. Go to the Top 100 user actions tab, and select a user action.
    The user action detail page opens.
  5. In the upper-right corner of the user action detail page, select Mark as key user action.

Pin a key user action to dashboard

Web applications
  1. In the Dynatrace menu, go to Web.
  2. Select the application, and scroll down to Top 3 user actions.
  3. Select View full details.
  4. Go to the Key user actions tab, and select the required key user action.
    The user action detail page opens.
  5. In the upper-right corner of the user action detail page, select Pin to dashboard.

Customize Apdex rating for a key user action

Web applications
  1. In the Dynatrace menu, go to Web.
  2. Select the application, and scroll down to Top 3 user actions.
  3. Select View full details.
  4. Go to the Key user actions tab, and select the required key user action.
    The user action detail page opens.
  5. In the upper-right corner of the user action detail page, select More (…) > Edit > Key performance metric.
  6. Use the slider to adjust the Apdex thresholds.