29 Jun 2026
10:47 AM
- last edited on
30 Jun 2026
01:40 PM
by
MaciejNeumann
Hi Team,
We are building new Grail-based dashboards (Document app) for our RUM-monitored web applications. To add business context to sessions, we configured User Action Properties that capture JavaScript variables from the page. These properties work in USQL but we cannot find them in DQL.
Additionally, we found significant differences between USQL and DQL session counts for the same application and time range, and contradictory documentation about what sessions USQL includes.
We would appreciate help understanding these differences and the recommended approach going forward.
We found two official Dynatrace documentation pages that contradict each other:
"User sessions and actions USQL reference" states:
"Dynatrace captures user activity in real-time but requires a session to end before data is queryable via USQL."
"USQL - User session query language" states:
"queries always work on the raw user session data that includes both active and already finished user sessions"
Which one is correct? Does USQL return:
This distinction is important because it directly impacts whether DQL and USQL are expected to return the same session counts.
For the same application and time range, we get significantly different results.
DQL query (user.events in Grail):
fetch user.events, from:now()-24h | filter frontend.name == 'My_Application' | filter view.name == '/my-app/some-page' | summarize sessions = countDistinct(dt.rum.session.id)
Result: 83 sessions
USQL query (classic):
SELECT COUNT(DISTINCT usersession.userSessionId) FROM useraction WHERE useraction.application = 'My Application' AND useraction.name LIKE '%some-page%'
Result: 35 sessions
The DQL count is 2.4x higher. We noticed that user.events contains multiple characteristics.classifier types per view (request, error, navigation, user_action, page_summary, view_summary, visibility_change, other), so countDistinct(dt.rum.session.id) may be counting sessions across ALL event types.
Questions:
We configured User Action Properties that capture JavaScript variables from the page to enrich our RUM data with business context. They work correctly in USQL:
SELECT useraction.stringProperties.myCustomProperty, useraction.name FROM useraction WHERE useraction.application = 'My Application'
However, we cannot find these properties anywhere in Grail DQL. We tried:
The user.events data object does not seem to expose User Action Properties or Session Properties.
Questions:
Currently, the only way we found to use User Action data (action names with naming rules, properties) in new Grail-based dashboards is by importing the classic SDK in code tiles:
import { rumUserSessionsClient } from "@dynatrace-sdk/client-classic-environment-v1"; const response = await rumUserSessionsClient.getUsqlResultAsTable({ query: usqlQuery });
This works, but it mixes classic and Grail data models and we are unsure about long-term support.
Questions:
Environment: Dynatrace SaaS, Grail active, web applications monitored with RUM (React SPA + JSF legacy).
Thank you in advance for any guidance.
29 Jun 2026 01:36 PM
Hi,
I would not expect these two queries to return the same number out of the box.
In Grail, user.events is an event-based RUM data model. It contains many event types for the same journey/session, for example navigation, request, error, page/view summary, visibility changes, user actions, and property events. Therefore:
fetch user.events
| filter frontend.name == "My_Application"
| filter view.name == "/my-app/some-page"
| summarize sessions = countDistinct(dt.rum.session.id)counts all sessions that produced any matching user event for that view, not only sessions with a classic useraction row.
To get closer to the USQL FROM useraction query, I would first inspect the classifiers:
fetch user.events, from: now()-24h | filter frontend.name == "My_Application" | filter contains(view.name, "/my-app/some-page") | summarize events = count(), sessions = countDistinct(dt.rum.session.id), by: { characteristics.classifier } | sort events descThen restrict the DQL query to the user-action-like events only, for example:
fetch user.events, from: now()-24h
| filter frontend.name == "My_Application"
| filter contains(view.name, "/my-app/some-page")
| filter characteristics.classifier == "user_action"
| summarize sessions = countDistinct(dt.rum.session.id)Depending on how the application is instrumented, especially for SPA navigation, you may also need to compare view.name, view.detected_name, page.detected_name, and user_action.name rather than assuming that USQL useraction.name LIKE ... maps directly to view.name.
My recommendation would be:
29 Jun 2026 03:22 PM
Hi, thank you for the detailed response.
We followed your suggestion and checked for property events in our environment. Unfortunately, none exist:
fetch user.events, from:now()-24h
| filter frontend.name == "My_Application"
| filter contains(view.name, "/my-app")
| summarize events = count(), sessions = countDistinct(dt.rum.session.id),
by: {characteristics.classifier}
| sort events desc
This returns 8 classifiers (request, error, other, user_action, view_summary, navigation, visibility_change, page_summary) but no property classifier.
We also tested directly:
- characteristics.has_event_properties == true → 0 results
- characteristics.has_session_properties == true → 0 results
- characteristics.classifier == "property" → 0 results
Additionally, when inspecting individual user_action events, the characteristics.has_event_properties field is not present at all — not even as false. It simply doesn't exist in the event schema for our
tenant.
The User Action Property (a JavaScript variable configured as a string property) is correctly captured and queryable in USQL (useraction.stringProperties.<key>) and visible in the UI session filter
(properties.<key>), so the classic data model works fine.
It seems that property events are not being ingested into Grail for our environment. We are opening a support case to investigate further.
Thanks again for your help — your suggestions were very useful to narrow down the issue.
Featured Posts