topic USQL vs DQL: different session counts, contradictory docs on active sessions, and User Action Properties not available in Grail? in Dashboarding

USQL vs DQL: different session counts, contradictory docs on active sessions, and User Action Properties not available in Grail?

v_mayordomo — Tue, 30 Jun 2026 12:40:58 GMT

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.

1. Contradictory documentation: does USQL include active sessions?

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:

Only completed/finished sessions?
Both active and completed sessions?
Something else (e.g., depends on query type)?

This distinction is important because it directly impacts whether DQL and USQL are expected to return the same session counts.

2. DQL vs USQL return very different 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:

Are DQL user.events and USQL useraction expected to return the same session counts?
If not, what is the correct way to get equivalent counts from both?
Is there a recommended characteristics.classifier filter in DQL to match USQL results?

3. User Action Properties not available in Grail

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:

event_properties.myCustomProperty → undefined
event_properties.__myCustomProperty__ → undefined

The user.events data object does not seem to expose User Action Properties or Session Properties.

Questions:

Are User Action Properties available in Grail? If yes, what is the correct field path?
If not yet available, is there a roadmap for this?

4. Recommended approach for User Action data in new dashboards

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:

Is there a native DQL way to query User Action data (action names, properties) without using the classic USQL SDK import?
What is the recommended approach for building new dashboards that need User Action Property data?

Environment: Dynatrace SaaS, Grail active, web applications monitored with RUM (React SPA + JSF legacy).

Thank you in advance for any guidance.

Re: USQL vs DQL: different session counts, contradictory docs on active sessions, and User Action Properties not available in Grai

t_pawlak — Mon, 29 Jun 2026 12:36:37 GMT

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 desc

Then 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:

user.events in Grail contains multiple event types (request, navigation, user_action, view_summary, page_summary, error, etc.), so a simple countDistinct(dt.rum.session.id) is not equivalent to FROM useraction in USQL
To compare the two, first inspect the distribution of characteristics.classifier, then restrict the query to user_action events.
For User Action Properties, check events where characteristics.has_event_properties == true (or has_session_properties == true), as custom properties are represented through dedicated property events.
If the properties are still missing, it may indicate that the configured User Action Properties are currently available only in the classic RUM/USQL data model and are not yet exposed in Grail for that environment.

Re: USQL vs DQL: different session counts, contradictory docs on active sessions, and User Action Properties not available in Grai

v_mayordomo — Mon, 29 Jun 2026 14:22:21 GMT

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.