Create custom names for user actions

To support applications that have dynamic elements and require a different approach, we've introduced a new and improved version of user action naming. If you already have existing naming rules defined for your application, you must migrate to the new, improved version, recreate all existing naming rules, and click Switch to new user action naming.

User action names are generated automatically based on triggered load or XHR URLs and are often difficult to read and remember. When your application handles a lot of user requests and interactions per day, tracking user actions becomes difficult when you don't have the means to group them logically.

User action naming rules give you the option to generate consistent and readable user actions that can be easily grouped and tracked throughout the application.

These action naming rules can be created and customized for each application individually and then used throughout Dynatrace in:

  • user experience charts
  • graphs
  • conversion goals (for example, add-to-shopping-cart and newsletter-sign-up)
  • key user actions
  • top consumers list

To easily create and maintain user action naming rules, you can make use of placeholders, input parameters, and even different rules for Load and XHR actions.

Add and use placeholders

Placeholders allow you to add dynamic elements to custom naming rules.

Placeholders are useful in cases where you want to have dynamic input values (for example, the URLs of blog posts visited by your users) included in user action names or when you want to remove or replace certain parts of an input value (for example, dynamic user session IDs) and group them under a common user action name.

Placeholders consist of the following three elements:

  • An input value, such as a page URL
  • A processing step that extracts or replaces parts of the input (optional)
  • The placeholder name, which is used in the user action naming rule

To make placeholders easier to use, Dynatrace provides a set of pre-defined placeholders, such as pageUrl, sourceUrl, xhrUrl, Top XHR URL, and pageTitle. To understand placeholders better, consider the following example: an XHR action triggers the selection of the confirmation button on a checkout page. Clicking the confirmation button (the source action in this case) is followed by one of these target actions:

  • multiple chained XHR requests are triggered by the first web request, such as xhrUrl or Top XHR URL.
  • a new load action is triggered, redirecting you to a confirmation page. In this case, you have a sourceUrl, which is the URL where you finished the checkout process, and the pageUrl, which is the URL where you see the confirmation of the checkout process.

Such chains and correlations of actions are best seen in a waterfall chart. You can use sourceURL and pageURL, or the XHR equivalents XHRUrl and Top XHR URL, to properly name your actions in cases where such correlations occur.

The provided set of placeholders is non-customizable but can be immediately used for creating your own naming rules. You can also create your own placeholders.

To create a placeholder

  1. From the left-hand menu, select Applications.
  2. Select the application, and then select the Browse [...] button.
  3. Under Application settings, select User actions > User action naming.
  4. Select Add placeholder and select your input data type. Note: For the CSS selector, JavaScript variable, Meta tag, and Cookie value data types, you must also specify a value. add a placeholder
  5. Optional Add processing steps and conditions, and preview your placeholder to see if it works as intended.
  6. Name your placeholder and select Save.

Processing steps

To help you make the most of placeholders, we’ve introduced the following processing steps:

  • extract: Requires the delimiter from which the extraction must begin and the delimiter at which the extraction must end. The delimiters are not part of the extraction. If the leading delimiter isn't present, the extraction starts from the beginning of the input. If the trailing delimiter isn't present, the extraction stops at the end of the input.
  • replace: Requires the delimiter from which the replacement must begin and the delimiter at which the replacement must end. Optionally, you can also provide the replacement text. When replacement text isn't provided, the matched characters are discarded.
  • replace text: Requires the text that needs to be identified and matched. Optionally, you can provide the replacement text. When replacement text isn't provided, the matched text is discarded.
  • replace IDs: Requires the ID that needs to be identified and matched. Optionally, you can provide the replacement IDs. When a replacement ID isn't provided, the matched ID is discarded.
  • extract with regular expression: Requires a regular expression to identify and extract.
  • replace with regular expression: Requires a regular expression to identify the string to be replaced. Optionally, you can provide the replacement regular expression. When not provided, the matched regular expression is discarded.
    Note: Currently, only the (.*) capture group is supported.

Create action names

Dynatrace provides you with the option of creating custom load as well as XHR actions. You can use new placeholders or the existing placeholders that are available in the Placeholders list to create your new naming rules.

In this example, we use CampaignID to create a new custom naming rule that identifies a page load as a campaign view with the CampaignID added to the action name.

  1. From the navigation menu, select Applications.
  2. Select the application, and then select the Browse [...] button.
  3. From the Application settings menu, select User actions.
  4. Select the Naming rules for load actions or Naming rules for XHR actions tab.
  5. Under User action naming, select Add naming rule.
  6. Type a naming pattern using a placeholder. Ensure that the placeholder is within braces (example: {CampaignID}).
  7. Optional Define the conditions under which you can also use placeholders to further refine the applicability of the rules.
    In our example, to create a custom action naming rule that only applies to a special promotional campaign, where CampaignID is 3, you can use conditions and placeholders to only match the desired actions that should be named accordingly. creating custom user actions
  8. Optional Use the Preview your rule section to check if your new naming rule works as expected.
  9. Click Save.
  10. Use the Move up/down controls to change the priority of the rules.
    The first matching rule in the table is applied first. user action naming rules

Use cases and examples

In the following sections, we look at examples of user action naming rules that were created in the earlier version and show how equivalent rules can be created using the new, enhanced version of user action naming rules.

Extract valuable information out of your data inputs

Examples from the earlier version of user action naming rules:

  • Extract /some-path-before/(.*).some-defined-text-after from path from path
  • Extract Loading of page /sales/(.*) from action name
  • Extract (.*) from page title
  • Extract (.*) from XHR URL

You can now achieve the same result using placeholders and a processing step.
With the extract processing step, you can define leading and trailing delimiters that define exactly where extracted values are to be pulled from. In this way, it’s possible to replace many naming rules that previously required regular expressions.

example for extract

Name actions based on their URL or path

Examples from the earlier version of user action naming:

  • Design step: if action name contains design
  • Config data call: action name matches regular expression */config/*
  • Product: path begins with /product/
  • Search: XHR URL begins with /api/search/dynamic

In the earlier version of user action naming rules, the action name was typically used as an input value for the renaming of action names that were automatically detected by Dynatrace. This often led to confusion, since users didn’t understand that action names were being used as input values as they were defined.

What had to be differentiated here is the auto-detected action name by Dynatrace (a possible input) and the final action name defined by the user through the naming rule. In all these cases, a user could have simply used the page path or URL or the XHR URL instead. Now you can simply use a default placeholder in your naming rule, such as pageUrlPath or pageUrl, to get the same information, followed by the begins with or contains conditions to do the same.

With the new version, you can use a default placeholder, such as pageUrlPath or pageUrl, to get the same information, followed by the begins with or contains condition to do the same.

example for renaming

Conversely, you can use a match regular expression condition for more flexibility.

For example, former rules in the earlier version of user action naming:

  • Customer Contact Request for UFO: XHR url matches regex match .*/api/request/.*/contact?category=UFO

example for regex

Remove or mask parts of your data inputs

Examples from the earlier version of user action naming:

  • Remove ID: (\\?|&)_id=:*?(?=&|$)
  • Remove conversation: (\\?|&)conversation=:*?(?=&|$)
  • Remove params: \?.*
  • Remove searched car: (?<=search-results\/cars\/)[a-zA-Z0-9]*

Removing and masking parts of data can now be achieved more easily with the "remove in-between" approach. If you want to remove the value of a certain query string parameter, which could be the ID of your user, define the key as a trailing delimiter and & as a following character that introduces other parameters. If your matching input doesn’t have a trailing delimiter, you'll be notified.

example for renaming

For more flexibility or, for example, to remove all parameters of your URL, use replace by regular expression.

example for replacing with regex

Consolidate naming rules by leveraging placeholders

Let’s consider an e-commerce checkout in this example. To name your load actions for each step in the earlier version, you had to first define one action naming rule for each individual step.

In this case, one rule is assigned per checkout step:

  • Loading of Enter personal details: action name begins with /checkout/index.php?step=details
  • Loading of Select payment method: action name begins with /checkout/index.php?step=payment
  • Loading of Order summary: action name begins with /checkout/index.php?step=summary
  • Loading of Order confirmation: action name begins with /checkout/index.php?step=confirmation

With the new version, you can create a placeholder that uses a JavaScript variable called adobePageName as input, which may already be available in an existing data layer of an analytics tool, for example Adobe Analytics.

example for JS variable

Leveraging the power of your previously defined placeholder, you can then create a single action naming rule that covers all the naming rules you created with the earlier version and result in the same action names.

load action example