AppMon User Experience Management (UEM) captures transactions triggered within browsers (desktop or mobile) or mobile apps from end to end: browser or app, over web server and application server, into the database.
UEM for Web Applications
UEM for mobile apps
UEM only vs. Full-stack
|Feature||UEM only||Full stack|
|Automatic JS Agent injection||1|
|HTML Error codes capture|
|Frontend data capture|
|Backend data capture|
What is a User Action?
onload handler, which in turn might perform XHR requests, or other actions.
A user action's duration is called response time. It represents the time the user waits until it is possible to continue with the use case. A low response time indicates better performance than a high one.
The web has the following different user actions:
Initial page load
Web 2.0 action or XHR call
New page navigation
Streaming media playback
You can track HTML 5 video and audio stream playbacks, which is a user action. See Monitor Streaming Media Activity for more information.
What is a visit?
A visit is a group of user actions performed by the same user within a certain time period. It is created with the first user action and ends after the user is inactive for a specified period of time. See System Profile > User Experience for more information. This user inactivity time setting defaults to 30 minutes. You can define it on an application-level (System Profile - Applications). A visit represents the user's click-path and helps to analyze problems. A visit duration is calculated from the start of the first user action to the end of the last user action.
What is Apdex?
Apdex (Application Performance Index as defined by the Apdex Alliance) is an open, standard way to depict the performance of User Actions. Apdex is a ratio of slow and fast requests. It is application independent and represents performance as a single value between 0 and 1. Everything lower than .5 is unacceptable everything higher than .93 is excellent. Use this value to compare the performance of different applications and to understand long-term performance trends.
The Apdex is calculated by categorizing user actions by their response times into Apdex Performance Zones:
- Satisfied — Comprised of a chosen threshold (T), and the following formula:
Everything faster than T is considered satisfied.
- Tolerating — slower than T, but faster than 4T.
- Frustrated — slower than 4T
For example, assume you have an application-wide satisfied-threshold called page load baseline.
To set this, click Client - System Profile > User Experience vertical tab > Default or Application Specific Settings horizontal tab > General > Action groups.
The threshold for page load baseline is defined as two seconds. User actions map to the following zones based on their response time:
If there are 10 satisfied actions, five tolerating actions and two frustrated actions, the result is an Apdex of (10+5/2)/17=0.73.
Additional Bandwidth Factor in the Apdex Calculation
AppMon UEM assumes that users with a slow network connection (such as from a mobile phone) accept slower user actions.
Click System Profile > User Experience > Default or Application Specific Settings horizontal tab > Web Applications sub-tree to switch the bandwidth calculation to on. This evaluates the performance of a user action, where 1,500 Kbits/sec is the norm (factor 1 for the Apdex performance zone thresholds) and 56 Kbits/sec is slow (factor 2).
For example, a bandwidth of 630 Kbits/sec results in a factor of ~1.6. The satisfied-tolerating threshold for the previous example changes to 2.0 x 1.6 = 3.2s. The tolerating-frustrated threshold changes to 4 x 2.0 x 1.6 = 12.6s.
What is the User Experience Index?
AppMon uses the term User Experience rather than Apdex. User experience analyzes how the performance is perceived by the application's users, and categorizes visits into satisfying, tolerating and frustrating, depending on the performance of user actions and errors.
Users have a frustrating experience if:
- Their last action failed (The Web site does not work - I'm leaving.).
- Their last action was frustrated (The Web site is too slow - I'm leaving.).
- More than 50% of all actions were frustrating.
Users have a satisfying experience if:
- No action failed.
- More than 50% of all actions were satisfying.
Users have a tolerating experience if their experience is neither frustrating or satisfying, which means that:
- Their last action was not frustrating or failed.
- Less than 50% of all actions were satisfying.
- More than 50% of all actions were at least tolerating.
The percentages in the previous calculations can be adjusted. Click System Profile > User Experience > Default or Application Specific Settings horizontal tab > General > Visit Experience Zone to modify these thresholds.
A visit's user experience zone is determined by a well-ordered series of calculations, each representing a possible reason for a particular experience zone. The reason with the highest precedence is recorded in the visit, and determines the visit's experience zone. The ordered list of reasons is given in the following table:
|Precedence||Visit Experience Zone Reason|
|Evaluated first||Frustrated: There was an error in the last action of this visit.|
|↓||Frustrated: There was a crash in the last action of this visit.|
|↓||Frustrated: The last action of this visit was Frustrated.|
|↓||Frustrated: Too many actions in this visit were Frustrated.|
|↓||Tolerating: There are failed actions in this visit.|
|↓||Tolerating: Too many actions in this visit were Tolerating or Frustrated.|
AppMon captures the client IP address. To do this, it watches for appropriate HTTP headers and converts this address to a geographical location with a built-in database. See Configure Geographic Location for more information.
Specific concepts for Web Applications
Bandwidth Calculation Example
|size of requested image||download time||bandwidth|
|3 kbyte||23 ms||-|
|10 kbyte||87 ms||-|
|30 kbyte||123 ms||2 Mbit/sec|
The bandwidth displays in several UEM dashlets (for example, Visits Dashlet) and are used as a measure for charting and alerting. Since this measuring might cause significant network overhead, the bandwidth calculation is disabled by default. You can enable it globally or per application, and separately for mobile. See System Profile - User Experience for more information. You can configure the calculation interval. It defaults to five minutes.
Third party content
W3C resource timing metrics
Perceived render time
Auto detection of XHR (Ajax) calls
|dojo||1.6.1 ‐ 1.12.21||Supported|
|extjs||3.4.0 ‐ 6.2.01 2||Supported|
|icefaces||2 & 31||Supported|
|jquery||1.3 ‐ 1.12.4, 2.0 - 2.4 & 3.0-3.21||Supported|
|prototype||1.6.0 ‐ 1.7.31||Supported|
|angular||1.0 ‐ 1.5.8, 2.0.01||Supported|
|mootools||1.4.5 ‐ 1.6.01||Supported|
2 In certain cases the JS agent does not capture the correct end time for extjs 6 user actions if the promise API is used.
The following frameworks are covered with the basic XHR detection:
The following frameworks are covered with the jQuery sensor:
Since Dojo 1.7, modules are loaded using require(). This is not fully supported and can lead to some user action loss depending on the loaded module. This may affect the capture of event listeners added by the dojo/on module and the capture of XHR requests executed by the dojo/request/xhr module.
Also, manual bootstrapping is not supported in this release. AppMon only captures AngularJs requests if the web app is automatically initialized with Angular using ng-app directives.
See Monitor Streaming Media Activity for more information.
Specific concepts for mobile apps
See System Profile - User Experience for more information.