RUM(auto-instrumentation only): Is it possible to perform complicated user session analytics query?

[lbgtolentino]

We have the following analytics requirement using RUM for mobile (iOS and Android) where we only implemented the auto-instrumentation feature of the SDK.

Find out how many users perform an action where api/service call failed, then users retry (tap again the button) and was successfully able to continue. 
Another scenario is the same as above, but user was not able to successfully continue.

It is not possible to query this way it seems because there is no obvious way to relate events, actions, page names and service urls in one session
Is this something possible by custom query or by manual custom naming/action?

[Julius_Loman]

For DEM classic (not upcoming DEM on Grail) the user session analytics depends on USQL limitations. USQL works on user sessions and user actions. 

For successful business analytics output, you need proper user action names for user interactions that are critical for your business process. You can't query by API requests from your application from USQL. In most cases, you can't do much with user action naming rules since they lack application context (e.g., "Touch on OK" itself is not enough if it happens in different scenarios).

Implementing Dynatrace SDK in a mobile application for business analytics purposes definitely requires design and proper implementation. Just placing auto instrumentation without any further customization can be enough only for general metrics and some (general) user experience data, not for any kind of business analytics.

[Patrick_H]

Not in current offering, but in theory this would be possible with RUM on Grail, but this will be quite some complex queries including merging of subquery results, so this probably will get time/data intense/expensive if performed for larger timeframes and not on single sessions.
I would rather suggest to evaluate that on mobile app side ad report session properties based on the scenarios - then the sessions can be easily grouped by that and also such queries will then be much more easy to define and will be faster too.
The session properties bases approach should also work in current offering.

[lbgtolentino]

Thank you Julius and Patrick. One of the possible solution in general we are looking at is to manually name each page, each user action so that it is easier for the BA to query what they want, but as our developers pointed out this is quite convoluted and overkill to perform on hundreds of pages and buttons and actionable items.
Another solution is to only rename user actions that is really needed(the need is not yet fully defined).
Is this solution the only way to when it comes to using dynatrace as a source of business analytics?

[Julius_Loman]

@lbgtolentino if you really need business analytics (and not much user experience), I suggest you look at Dynatrace business analytics offering (SaaS only) which uses business events. It's much more tailored for business analytics and you are not that much limited. You can leverage the SDK as the transport of your business events and you will still have the context of user session and (generic) metadata such as device or application version. Also - depends on your architecture, you might want to capture the bizevents by OneAgent on your perimeter (API gateway) - if you can map rest calls to important interactions. Really depends on what you are trying to achieve and how your mobile app and the rest of your application landscape looks like

In general, setting user action names (please do not consider user action as page name, it is conceptually different) is not that difficult as it seems at first sight (you have semantic attributes and two options how to set it from the code). And most importantly - you need to do that for the most important interactions only. 


Anyway - if you are on SaaS, explore bizevents in the business analytics offering. If you are on Managed, consider moving to SaaS 😀 Bizevents is a gamechanger here. If you are left with Dynatrace Managed, I'd recommend combining what @Patrick_H suggested (session/action properties) with action naming for your business critical user interactions with the app.