Enrich RUM telemetry with primary Grail fields and tags
- Latest Dynatrace
- How-to guide
- 6-min read
- Published Aug 26, 2026
RUM data from web frontends (RUM JavaScript) and mobile apps (OneAgent for Mobile) enters Dynatrace through the rumagent ingest source, which offers no at-source tag configuration. To add primary Grail fields and tags, configure DQL processors in OpenPipeline at ingest time.
Use frontend.name as the source field for tag derivation. This primary field is present on every user event and user session; its value comes from the frontend nodes defined in Dynatrace. A single frontend name, or a group representing the same product or team, anchors team ownership and application context, enabling consistent segments, pipeline routing, bucket assignment, and alerting across RUM and other signal types.
For general guidance on primary Grail fields and tags, see Primary tags.
Defining primary tags for Real User Monitoring will be expanded in the future. Currently, configuring primary tags via OpenPipeline DQL processors is the recommended enrichment path.
| Platform capability | How primary tags help |
|---|---|
Data routing | Route data to specific pipelines based on |
Bucket assignment | Assign a target retention bucket based on |
Segments | Define segments based on |
Alerting | Create targeted alerts and notifications scoped to specific |
To configure security context (dt.security_context) for RUM data, use DQL processors in the relevant OpenPipeline configuration scopes. See RUM permissions for access control.
Enrichment guide
OpenPipeline organizes data processing into configuration scopes—one per signal type (User events, User sessions, Smartscape events, Events, Davis events, Business events, Timeseries). Within each configuration scope in OpenPipeline, you create one or more pipelines that process the data. Each scope is independent. We recommend configuring the primary tag derivation rule in each scope relevant for RUM data.
In all configuration scopes (except User sessions), frontend.name is a scalar string, so the exact same DQL rule applies everywhere. User sessions is the exception because a web session can span multiple web frontends, frontend.name is an array there and requires a different DQL pattern.
In practice, each team typically owns one or more dedicated pipelines within a configuration scope for their custom processing and metric extraction. Use pipeline groups to create a base pipeline within each configuration scope. All incoming data passes through the base pipeline first. Add the primary tag DQL processor there so that primary_tags.* is set before data reaches any team-specific pipeline. Teams can then rely on primary_tags.* already being present in their pipelines for routing, extraction conditions, or further enrichment.
1. All configuration scopes (except User sessions)
Apply the following steps in each of these configuration scopes:
Settings > Process and contextualize > OpenPipeline > Smartscape events- Settings > Process and contextualize > OpenPipeline > User events
- Settings > Process and contextualize > OpenPipeline > Events
- Settings > Process and contextualize > OpenPipeline > Davis events
- Settings > Process and contextualize > OpenPipeline > Business events
- Settings > Process and contextualize > OpenPipeline > Timeseries
Steps:
- Open the configuration scope and select the base pipeline (or create one using pipeline groups).
- Go to Processing and select Add processor > DQL processor.
- Enter a processor name, for example,
Derive primary tags from frontend name. - Set the matching condition to
isNotNull(frontend.name) and isNull(primary_tags.team). Note theisNull(primary_tags.team)expression in the example. It makes sure an existing team tag is not overridden if one was already set earlier (e.g. at source). - Add a DQL statement that maps frontend names to a primary tag value:
fieldsAdd primary_tags.team = if(in(frontend.name, {"Astroshop", "Astroshop Mobile"}), "shop-team")
- Select Save.
To map multiple frontend groups to different tags, chain additional fieldsAdd statements. Each statement sets the field only if no earlier statement has already set it:
fieldsAdd primary_tags.team = if(in(frontend.name, {"Astroshop", "Astroshop Mobile"}), "shop-team")| fieldsAdd primary_tags.team = if(isNull(primary_tags.team) and in(frontend.name, {"Checkout", "Checkout Beta"}), "checkout-team", else: primary_tags.team)
matchesValue supports wildcards, so you can match frontend name patterns without listing every variant:
fieldsAdd primary_tags.team = if(matchesValue(frontend.name, "Astroshop*"), "shop-team")| fieldsAdd primary_tags.team = if(isNull(primary_tags.team) and matchesValue(frontend.name, "Checkout*"), "checkout-team", else: primary_tags.team)
2. User sessions
User sessions are the exception. A web session can span multiple web frontends. For example, a user may navigate through several web applications, each mapped to a different frontend. As a result, frontend.name in user.sessions is an array.
Unlike other configuration scopes (where primary_tags.team holds a single string value), a session record carries all team values from every frontend the session touched. For example, a session that spanned both Astroshop and Checkout frontends produces primary_tags.team = ["shop-team", "checkout-team"].
Build an array of candidate team values (one per team), then remove nulls to produce the final tag array:
fieldsAdd primary_tags.team = arrayRemoveNulls(array(if(in(frontend.name, {"Astroshop", "Astroshop Mobile"}), "shop-team"),if(in(frontend.name, {"Checkout", "Checkout Beta"}), "checkout-team")))
Coverage by signal type
| Signal type | Configure in |
|---|---|
Smartscape FRONTEND entities | Smartscape events configuration scope |
User events ( | User events configuration scope |
User sessions ( | User sessions configuration scope |
Events | Events configuration scope |
Davis events (problems) | Davis events configuration scope |
Business events | Business events configuration scope |
Timeseries | Timeseries configuration scope |
Query enriched data in Grail
Primary Grail tags appear as top-level fields and can be queried with DQL.
Filter user events by primary tag
fetch user.events| filter matchesValue(primary_tags.team, "shop-team")| summarize count(), by: {frontend.name, primary_tags.team}
Aggregate user sessions by team
fetch user.sessions| filter matchesValue(primary_tags.team, "shop-team")| summarize avg(duration), by: {primary_tags.team, frontend.name}
Limitations
-
Because each configuration scope requires its own DQL processor configuration, you must apply tag-mapping changes separately in each affected configuration scope.
-
The maximum number of primary tag keys per record is subject to the general OpenPipeline limits.