There are various reasons that APM CE (CEM) may not capture an authenticated user id in a monitored transaction. This can result in an unspecified user. Reasons
for this happening and what to do about it are discussed below
1. What is the Unspecified User Problem?
The unspecified user message typically looks like shown below:
<Please see attached file for image>
While displaying "login name" or "user group" in a defect list, an unspecified user(s) appears instead of the actual user name.
Having an unspecified user has the following disadvantages:
1) It hinders resolving an issue because the person who logged in is unknown.
2) Statistics for a particular user may be incomplete or misleading due to unspecified users.
An important note: There are various times when receiving an unspecified user message may be the expected result. An example is an e-commerce
website has no login process.
2. Guiding Principles
1) When working on unspecified user issues, start with the possible easier use case to find causes (such as those associated with authentication type and session identifier) and work towards the more complicated ones (such as network-related.)
2) Unless it is a case as listed above, most transactions will contain a login name and user group. So, unspecified users should be the exception rather than the rule.
3) There should only be one unidentified user per defect.
4) Only Unspecified Users and User Group Request Headers are the typical two user groups for e-commerce reports unless using certain types of user identifiers.
The following are typical causes of unspecified users:
How to Fix
Easy/Hard to Detect
Session Identifier Issues
Invalid or missing session identifier means APM cannot differentiate user sessions and identify users. This also impacts the binding of the various transaction hierarchy elements.
-Correct text/case in session identifier.
- Add or use another session identifier.
- If no session cookie is available, then add a port number. (Such as for NTLM Authentication.)
Application Type Issues
Incorrect application type impacts the type of session identifier used. See session identifier for reasons why this is happening
-Choose correct application type (such as Siebel instead of general)
Authentication Type Issues
Authentication type impacts the type of session identifier used. See session identifier for reasons why this is happening
- Choose correct authentication type. (such as NTLM instead of Basic)
If a defect happens in the login process, before the user is logged in, there will be no user identification
Turn off defect specifications before login or set expectations there will be no users for pre-login defects.
Session Timeout Issues
The user is at a remote location that needs a longer period of time for a session timeout.
Or session timeout is shorter than time needed to login/for a session.
Increase session timeout. (60 minutes by default).
Redirect to External URL
Users are authenticated are initially seen but an external redirect link is clicked.
Once clicked, you can see the transaction but lose the user to session information
Increase session timeout.
Use an internal link
This may be in the application/network realm and may not be possible to solve.