Useraction in more than one application?

[AntonioSousa]

I'm quite aware that at the moment one user-action has to belong to one and only one application.

I have a situation where two applications intersect, and only one of them can get certain user-actions. Of course, it would be great if it could count in both applications.

Before requesting a RFE, I imagine there are several issues to this. Is this a fundamental limitation, or might it make sense that a certain useractions might be present in more than one application?

[Julius_Loman]

The concept is based on monitoring user interactions. The user interaction really belongs to a single application the user has opened and does an action within that app ("click"). Based on the action, the user might end up in a different application - for example, due to a redirect. Actions that follow in this user session are then attached to the second application. A more complex example might follow several different systems (many HTTP redirects). Still, this is a single user action attached to a single application.

Are you sure you don't want to distinguish between web requests in a user action? The web request in a user action can be for any web request service.

Sometimes Dynatrace users do not fully understand the concept behind real user monitoring and tend to mix the term application in Dynatrace (user perspective) with the term application they normally use (application is set of services on hosts). They do really mean different concepts and the second one does not exist in Dynatrace (you have to use tags).

To also cover your situation, you need to know the details. It's possible you need to split this one user action into two different actions depending on the input or other metadata. Setting up user action naming rules can be highly challenging, although it seems very easy at the first sight.

[AntonioSousa]

The situation I'm in is something like this: imagine an online business, with several verticals (eg. books, electronics, computers). I need to look at several metrics (eg. Apdex) for those verticals, but than would also like to look at cross-functionalities, like shopping carts. I can do it through USQL, but not in Applications, as I cannot define "sub-groups" inside Applications. This functionality comes close, but doesn't seem to work:

https://community.dynatrace.com/spaces/482/dynatrace-open-qa/questions/245272/tilde-operator-seems-t...

Of course, separating it into different applications is also not an option, as I would than not have the whole view. But having it in different applications could be interesting, despite other aspects (data volume & DEM licensing come to mind).

[Julius_Loman]

@Antonio S., that's a perfect fit for user action properties! In your example, I would define a user action property capturing the "vertical" - e.g book. Then you can either analyze the individual actions (add to card) by those properties in the multidimensional analysis and you can do it also via USQL (action properties are possible finally in USQL since 1.200).

Give user action properties a chance :-). They deserve it.

[AntonioSousa]

I took a deep look, and they are really interesting. Many thanks for pointing it out!

In my case I think it will now work, because I would have to get the "vertical" from the URL, and it's not a source for user action properties 😞

It's really strange that this issue has not been brought up, for what I can see in the forum. The tilde should work, or some other way to sub-group user actions in Applications should exist...

[Julius_Loman · Accepted solution]

If it's in the URL path, you should be able to define a request attribute (based on the URL) and use server-side request attribute as the property source. This will work if you have oneagent on the server installed.

If it's in the query string, you should use the query string parameter to capture that.

I believe the right way to define user action is to make them generic as much as possible and define additional dimension through request attributes. There is a limit on the number of Key User Actions. If you will defining action names based on some placeholder (such as "add to cart <dimension>") your number of action will explode and most likely you won't get much usable data from it.