Please check if you have correctly mentioned where the attribute is stored, and steps are correctly configured.
Also, please share screenshot of the configuration for review.
Hello @Akshay M.
The configuration is done correctly and I can see the Users ID in the request attribute on the server-side.
Regards,
Babar
Hi Babar,
What version is your cluster?
As I can see on the Preview link, this hit GA only in v 1.175.
Best regards,
Radu
Babar, do you see this request attribute when you drill down to pure path from user action?
Sebastian
Hello @sebastian k.
After reviewing the below screenshot, please correct me if I misunderstood your question.
Regards,
Babar
Hi I was thinking about missing purepath for some of user Session because of dynatrace purepath limit per minute. But in such case only some of sessions should stay untagged.
Sebastian
Thank you for the reply.
On these PurePaths which have the User ID, can you do a backtrace all the way to the RUM Application?
Wrong path 
There has to be different issue.
Sebastian
Hello @Radu S.
Yes, tagged actions are reaching to the RUM application.
I can see the following information:
Regards,
Babar
Hi Babar,
That does not seem to go to a RUM-enabled application. Your backtrace has only one node (the service which you started the backtrace). Hence why you’re seeing “Requests to …” but not “Requests from …”. Also, the last node of the backtrace (which needs to be a RUM-enabled application) needs to show User Actions.
Only User Actions are mapped to a User Session. So the problem is that the PurePaths where you are collecting User ID are not actually directly associated with any User Action of a RUM-enabled application and so it’s impossible for us to use that attribute to tag sessions.
Here’s a visual example:
Hello @Radu S.
Is this related or our request attribute configuration on the Dynatrace or something related to application design?
Dynamic requests are tagged with the request attribute tag.
How to make it work?
Regards,
Babar
Hi @Babar Q.
The request attribute is configured correctly, because we are capturing it. However I am unsure your application is monitored correctly.
You need to ensure the following:
If any of these steps don’t work, you need to resolve it.
From what I can see, your backtrace didn’t lead to an Application. So that’s a good place to start understanding if you’re monitoring your application correctly.
Hello @Radu S.
No services detected.
I can see the request attributes (in the form of tag) in the dynamic requests.
One more thing to share that till now we did not instrument the Web Servers which will be instrumented soon.
Regards,
Babar
Then you’ve found your problem.
Unless Application is tied to Service which has Requests with the attribute, you cannot use that attribute to tag your sessions because we have no idea what sessions those requests belong to.
Possibly when you’re going to instrument the web servers, and the RUM injection will be done directly via OneAgent, then your attribute can be used for tagging sessions.
Hello @Radu S.
I wanted to share with you that after instrumenting the web servers, the request attribute is working perfectly fine for the user tagging.
Regards,
Babar
