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 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 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 configured in Part 1. 

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

[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?