A user action is an interaction with the web browser that involves a call to a web server, which can potentially have multiple nested calls.
User action types
A user action can be a load action, an XHR action, or a custom action. The key difference among these action types is the way action duration is calculated and that for each type there are different metrics available.
A load action is defined an actual page loading in your browser. If you type a URL in your browser and press enter, a load action occurs. During a load action, 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 begins with the W3C
onload handler has completed its task. The
XMLHttpRequests (see XHR actions below) are started by an
onload handler, the user action ends when the
XMLHttpRequest is complete.
User action timings
The following measures are used to chart the duration of specific steps in the load action process.
|Measure||Description||Definition in terms of W3C specification|
|DNS||Time spent resolving domain names.||
|TCP||Time spent establishing a socket connection from the browser to the web server.||
|SSL||Time spent establishing a secure socket connection from the browser to the web server.||
|Redirect||Time spent following HTTP redirects.||
|Request||Time spent waiting for the first byte of the document response.||
|Response||Time spent downloading the document response.||
|TTFB||Time at which the first byte of response from the server arrives at the client.||
|Network consumption||Time taken to redirect, resolve the DNS, and establish the TCP connection.||
|Server consumption||Time spent receiving a request and sending the response back to the client.||
|Processing time||Time between DOM loading and Load event start.||
|App cache||Time spent on checking relevant application caches.||
|OnDomContentLoaded||Time spent on executing OnDomContentLoaded handlers.||
|OnLoad||Time spent on executing OnLoad handlers.||
|Callback||Time spent on executing XHR callbacks.||
|Visually complete||Time at which all the content in the browsers visible area has been fully rendered.||
|Speed index||Time (in average) at which visible parts of the page are displayed. A lower Speed index means that most parts of the page are rendered very quickly.||
|User action duration||Time between initial user input and complete page load. Also includes load time of XHR requests initiated before
XmlHttpRequest or via
Dynatrace continuously tracks user interactions with each page. If user interaction leads to
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 were added in the callbacks. Dynatrace then waits until those resources have finished downloading before ending the action.
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.
The Fetch API provides an interface for fetching resources (including across the network). It is similar to
XMLHttpRequest, but the API provides a more flexible feature set. The generic definitions of
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 Dynatrace to automatically detect and capture Fetch API request information.
Custom user actions
User action naming rules
Many applications allow users to accomplish the same goal through different UI controls. When monitoring such applications, it can be difficult to differentiate between actions that have the same result and goal, but are executed by using different parts of the application UI. Likewise, if the UI of an application is translated into multiple languages, the same application function or control can appear under varying names. With user action naming rules, Dynatrace can detect such subtle variations and intelligently group related user actions (i.e., 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, the default
sessionid for PHP, 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:
<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 following caption:
click on "Firstname Text input"
Resolving captions for actions
- The attribute named
- The nodename, such as image, anchor, or input.
It stops when the
headtag, or the
documentelement is found.
- The innerText/textContent.
Key user actions
Most applications, both web and mobile, include user actions (for example, signups, checkouts, and product searches) that are particularly important to the success of your digital business. Such key user actions might take longer to execute than others or they might have the requirement to be of 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 sign-up user action. Alternatively, there could be a search action that is quite complex and requires longer than the allotted
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 historic trends.
Note: Dynatrace allows you to create a maximum of 500 key user actions per environment across all applications and a maximum of 100 key user actions per application. If a higher limit is required, please contact a Dynatrace ONE product specialist by clicking the chat button in the upper-right corner of the Dynatrace menu bar.
Mark a user action as a key user action
- On the Applications page, select the application, and scroll down to Top 3 user actions.
- Click View full details.
- Under Top 100 user actions, select a user action.
- On the top-right corner of the User action details page, select Mark as key user action. The selected user action will now be displayed under Key user actions on the User action analysis page.
- [Optional] To access a key user action from the dashboard, select an action from the Key user actions list and select Pin to dashboard.
- [Optional] To customize its Apdex rating, on the User action details page of the key user action, select Browse [...] > Edit > Key Performance Metric.