Recently, doing one of the software service configuration in NAM, I had troubles recognizing the real-user operations context by HTTP request/response template. In this particular application front-end design, this context appeared near the end of 20...30kB request POST body - too far to detect it with NAM staying within the reasonable capacity demand.
We have this application instrumented with Dynatrace RUM as well. Occasionally, I have noticed that after instrumentation every client machine started adding "dtSa" and other useful cookies, where I could easily read the operation context. Something like this:
Fourth parameter ("Search" in this case) is exactly what I need for NAM configuration.
Apparently, Dynatrace doesn't use this information in its reporting. The only documentation I could find regarding this cookie refers to "Application Monitoring & UEM" solution. It seems like this is an idle inherited option. Maybe I miss something.
I have few questions regarding this finding:
Can I build a long-term NAM operation context detection strategy relying on this cookie parameter?
Is there plans to enable operation context recognition in Dynatrace with this cookie?
RUM and NAM have some point of overlapping functionality but they are far not identical. NAM (if configured in a right way) still has much wider, accurate and more focused view at real-users perception. In includes network component. In my practice of using these two solutions together we already had cases when real-users were suffering from noticeable server-side performance degradation and NAM fairly triggered an alert in those cases, but it was missed in Dynatrace RUM statistics.
In our case NAM is helping us to recognize what is bothering real users the most, while Dynatrace shows the root cause where it can (it is far not 100% of cases).
This cookie is very helpful to discover what actually end-user hits at the particular form of the application and what is the response time.