How to display user names in new RUM Experience using the UI (using CSS selectors and OpenPipeline)

[Aaron_Schultz]

• Summary
• Prerequisites
• Part 1: Capture the user name as an event property
• Part 2: Confirm the property is being captured
• Part 3: Create a pipeline to map the user name
• Part 4: Create a routing rule to direct data through the new pipeline
• Part 5: Verify user names appear in the User sessions view
• Troubleshooting
• What's next

 

Summary

By default, user sessions in the new RUM Experience (Experience Vitals) are identified by a generated ID rather than a meaningful user name. This article explains how to capture a user name from the page using a CSS selector, verify the capture, and then use OpenPipeline® processing rules to map that value to the user identifier field so it appears in the User and sessions view.

Note: This configuration applies only to newly ingested data. Existing sessions are not retroactively updated.

 

Prerequisites

• You have a Dynatrace SaaS environment with the new RUM Experience (Experience Vitals) turned on.
• You have the Modify RUM settings and Modify environment configuration permissions.
• You know the CSS selector that targets the DOM element containing the user name on your page.
• OpenPipeline is available in your environment.

 

Part 1: Capture the user name as an event property

In this part, you configure the application in Experience Vitals to read the user name from the page using a CSS selector and store it as an event property.

1. In Dynatrace, go to Experience Vitals > Overview > Web.
2. Select the application you want to configure.
3. Select the Settings tab.
4. Select Capture properties.
5. Select + New property. The Edit event property dialog opens.
6. Under Define event property key, set the Property key to a name you will reference later, for example username.
7. Under Define source, configure the two capture rows:
   1. In the first row, set Capture type to CSS Selector and enter your CSS selector in the Identifier field, for example #root > div > header > div > p. This tells Dynatrace which DOM element to read.
   2. Select + Add a processing step. A second row appears.
   3. In the second row, set Capture type to Access property and set the Identifier to innerText. This extracts the visible text content of the matched element.
8. Select Save.

Tip: To verify the selector before saving, open your browser's developer tools, go to the Console tab, and run document.querySelector('YOUR_SELECTOR').innerText. If the correct user name appears, the selector is valid.

 

Part 2: Confirm the property is being captured

Before setting up OpenPipeline, confirm that the event property arrives in Dynatrace by querying for it in a Notebook.

1. In Dynatrace, go to Notebooks and open a new notebook.

2. Add a DQL tile and run the following query, replacing username with the property key you configured in Part 1:

   fetch user.events
   | filter isNotNull(event_properties.username)
   | fieldsAdd event_properties.username

3. Confirm that the event_properties.username column is populated with the expected user names.Note: From the image, you can see that it also captured additional text, "Hi, " that you may not want. Do not worry, as we can create a clean up rule later.

If the column is empty, go back to Part 1 and verify the CSS selector and the innerText processing step are configured correctly. Generate new user actions in the monitored application (for example, load a page while signed in) and then re-run the query.

 

Part 3: Create a pipeline to map the user name

In this part, you create an OpenPipeline pipeline under User events and add a DQL processing rule to map the captured property to the user.identifier field.

1. In Dynatrace, go to Settings > Process and contextualize > OpenPipeline.
2. Under User events, select the Pipelines tab and select + Pipeline.
3. Give the pipeline a descriptive name, for example Map user name.
4. In the Processing stage, select Add rule and set the processor type to DQL.
5. Configure the rule:
   • Name: Enter a descriptive name, for example Set user identifier from username.
   • Matching condition: Enter the following to only process events where the property was captured:

     isNotNull(event_properties.username)

   • DQL processor definition: Enter the following expression:

     fieldsAdd user.identifier = event_properties.username

     

     Note: If your CSS selector captures additional text alongside the user name—for example, a greeting prefix such as "Hi, Priya", use replaceString to strip the unwanted text: fieldsAdd user.identifier = replaceString(event_properties.username, "Hi, ", "")

6. Select Save on the rule.

 

Part 4: Create a routing rule to direct data through the new pipeline

OpenPipeline uses the default pipeline unless a routing rule sends data to a specific pipeline. In this part, you create a routing rule that directs the relevant user events through the pipeline you created in Part 3.

1. In Dynatrace, go to Settings > Process and contextualize > OpenPipeline.
2. Under User events, select Dynamic Routing.
3. Select + Dynamic route. The Edit Dynamic route dialog opens.
4. Configure the route:
   • Name: Enter a descriptive name, for example Change user names.
   • Matching condition: Enter a condition that matches the application you want this pipeline to process:

     matchesValue(frontend.name, "Your App Name")

   • Pipeline: Select the pipeline you created in Part 3.
5. Select Save.
6. If multiple routing rules exist, drag the new rule above any others that might match the same data so it takes priority.

 

Part 5: Verify user names appear in the User sessions view

After completing Parts 1–4, generate new user sessions by interacting with the monitored application while signed in. Then confirm the user name appears in Experience Vitals.

1. In Dynatrace, go to Experience Vitals > Overview > Web.
2. Select the application.
3. Select Open with User & Sessions to open the session list.
4. Select a Recent sessions on from the top left of the page.
5. Confirm the User Identifier field shows the name captured from the page.

Note: Only sessions ingested after the pipeline and routing rule were published display the mapped user name. Earlier sessions retain the generated identifier.

You can also verify with DQL:

fetch user.sessions, from: now()-2h
| fields
user.identifier,
dt.rum.session.id,
frontend.name,
dt.rum.application.type
| filter isNotNull(user.identifier)
| limit 100

 

Troubleshooting

The event_properties.username column is empty/null in the Notebook query.

• Confirm the CSS selector resolves to a visible element at the time the page loads. Elements rendered asynchronously by a JavaScript framework may not be available when the RUM agent first runs. Try interacting with the page to trigger a user action after the element appears.
• Confirm the Access property step is set to innerText.
• Confirm the property key is spelled correctly in the query (keys are case-sensitive).

The event property is captured but user.identifier is still empty/Anonymous after setting up the pipeline.

• Confirm the routing rule is targeting the correct pipeline and is positioned above other matching rules.
• Confirm the pipeline has been published. Unpublished pipelines do not process data.
• Confirm the DQL expression in the processing rule uses the same property key as the one in Part 1.
• Confirm that you have the correct permission, as user.events and user.sessions are sensitive fields that required additional permission for viewing. 

Sessions show the user name in DQL but not in the Experience Vitals UI.

• Allow a few minutes for the UI to reflect newly ingested data.
• Confirm you are viewing a session that was ingested after the pipeline was published.

 

What's next

If this article did not resolve your issue, open a support case and include:

• The CSS selector you configured and a screenshot of the matching DOM element in browser developer tools.
• A screenshot of the Capture properties configuration for the application.
• A screenshot of the OpenPipeline pipeline and routing rule configuration.
• The output of the DQL query from Part 2 showing the current state of event_properties.username.
• The output of the DQL query from Part 5 showing the current state of user.identifier.

Additional resources:

• Event and session properties for web
• OpenPipeline processing rules
• Sensitive user.events and user.sessions fields
• Field Permissions

[AntonPineiro]

Thank you! 

[Julius_Loman]

@Aaron_Schultz I know this is more a question for the PM, but since the CSS capturing is there, why did they not keep the option to capture user tags in the same way as it was in RUM classic?

[Aaron_Schultz]

@Julius_Loman My apologies, but unfortunately, I do not have an answer to that. Someone else would have to answer that question.

[Puche]

Hi! Good review.

We would like to share a reflection, after the appropriate permissions were granted, we were able to verify that the information is stored and displayed correctly. As a result of this work, a question has arisen regarding the functional and architectural approach behind this capability, and we would appreciate understanding your perspective and the recommended best practices. From our point of view, the user information was already available within the events through the field: event_properties.username To transform this value into a User Identifier that can subsequently be used within the session experience, we needed to:

1. Create and maintain an additional configuration in OpenPipeline.
2. Define a specific dynamic route to process those events.
3. Enrich the standard user.identifier field.
4. Manage specific permissions on the corresponding sensitive fieldset.
5. Perform additional validation through DQL queries to verify both the behavior and visibility of the data.

We understand that user.identifier is a normalized attribute and is considered sensitive, which is why it requires specific data governance and access control mechanisms. However, we would like to better understand the functional motivation behind this separation between the Event Properties reported by the application and the standardized User Identifier used by Dynatrace. This question becomes particularly relevant when comparing this model with the previous approach based on User Tags. In our RUM Classic environment, user identification can be configured in a relatively straightforward manner using either a CSS selector or a JavaScript expression against the monitored application. By contrast, achieving an equivalent result under the new model has required incorporating several additional components related to property capture, OpenPipeline, routing, enrichment, and permissions. While we understand that this approach may provide advantages in terms of standardization, data governance, privacy, and future analytical capabilities, from an operational perspective it represents a significant increase in configuration and maintenance complexity. This consideration is especially important in our case, as we are planning the migration of several hundred RUM applications to Grail. Therefore, we would like to understand whether:

• This is the strategic model recommended by Dynatrace for user identification use cases in Grail.
• There are alternative implementation patterns that simplify the process.
• The separation between Event Properties and User Identifier is primarily driven by security requirements, data model normalization, or future correlation and analytical capabilities.

Our objective is to better understand the design philosophy behind this capability so that we can define a sustainable, efficient, and scalable migration strategy for the large number of applications that we need to adapt over the coming months.