Export the user session data for managed customers for Power Bi reporting

[lovleen]

Hi team,
What would be the best method to export the user session data for managed customers for Power Bi reporting?
My understanding - User session export feature is best for Splunk and elastic but for Power BI API call is best if we want scheduling.?
Also, creating Python or any script here is not preferred as API call simply works here?
Could you please confirm my understanding?

•There are some concerns regarding usersession.endReason, as the column shows either TimeOut or USER_ACTION_LIMIT.
Question - When user session ends due to mentioned reasons like user inactivity or user closed browser or others mentioned in doco, and user immediately starts the session, can we stitch these together?
Question - USER_ACTION_LIMIT refers to the number of RUM user actions Dynatrace processes per minute. Can we increase it for our tenant?
When this limit is exceeded, Dynatrace throttles session capture to protect the license and prevent system overload. We need to confirm how this works in our environment. I assume there is a configuration in place, but this will also depend on how our license usage is calculated given our fixed license allocation.

[t_pawlak · Accepted solution]

Hi,
For Power BI reporting, the User Sessions API / USQL approach is usually the better fit when you need scheduled, repeatable data extraction. The API is designed for querying user session data and returning it in a structured format, which fits reporting tools well. By contrast, User session export is primarily intended for continuous export to an HTTPS endpoint/webhook, which is typically more natural for downstream systems such as Splunk, Elastic, or a custom ingestion pipeline
Export user sessions 
So you have 2 options:

• Power BI / scheduled reporting → API call (USQL) is usually the cleaner option.
• Continuous near-real-time forwarding of session data → User session export is usually the better option.

On the usersession.endReason topic:
user session can end because of timeout/inactivity, browser close, a 6-hour duration cap, or because Dynatrace technically splits sessions after about 200 user actions. The session structure also includes endReason values such as TIMEOUT and USER_ACTION_LIMIT, and there is also a partNumber field because sessions can be split into multiple parts for technical reasons

USER_ACTION_LIMIT: if a user session reaches about 200 user actions, a new session is created and subsequent actions are placed into that new session.

licensing:
Dynatrace explicitly says that when sessions are split for technical reasons, there is no extra charge for those additional session parts. 

[lovleen]

Is there any way we can stitch these sessions together?

[t_pawlak · Accepted solution]

Hi,
not natively in Dynatrace, at least not as a single rebuilt session object. I mean in Dynatrace if a session ends because of TIMEOUT, browser close, duration cap, or a technical split such as USER_ACTION_LIMIT, the next one is stored as a new session record. partNumber can help indicate that one user journey was technically split into multiple parts. And here you can or USER_ACTION_LIMIT, you can usually stitch such parts together on your reporting side, for example in Power BI, if you want to treat them as one business journey. And for TIMEOUT or a genuine new visit after inactivity / browser close, I would usually treat that as a new session, because that is how Dynatrace handles it.
so yes and no 😉
yes, you can stitch them together on your reporting side, but Dynatrace does not natively merge them back into one session record. partNumber helps with technical splits, while timeout-ended sessions should usually remain separate.

[lovleen]

Thanks, appreciate your input.