Use the User Experience item of the Edit system profile dialog box to configure UEM with AppMon. UEM is available for web and mobile native applications. Besides the Global settings (1 in the following graphic), you can configure UEM settings to apply to all applications using Default Application tab, or configure settings in an application-specific tab by adding a specific application, which creates a seperate tab for the application. This lets you customize UEM behavior for each application. For example, if you have two applications and only one of them is using
Angular.js, you can enable the
Angular.js sensor for this particular application only.
New system profiles contain a single configuration for the Default application (2). Click the Add specific application button (4) to copy the configuration for a specific application (3). Any application that does not have a specific configuration uses the Default application configuration.
|Monitor request name||Specifies the endpoint of the monitor request from dynaTraceMonitor. Usually there is no need to change it.|
Capturing settings determine the data that is captured: UEM and server-side data, just server-side data, or neither. Drag the slider to change the level of events to capture.
|UEM is turned off. Web server agents do not capture web requests. Shut down any manually injected agents. PurePaths are not captured for any incoming web requests.|
The General section includes settings that affect visit and user action creation.
|Capture the following percentage of visits.||Enter a percentage of visits to be captured. For example, if you enter 10% AppMon captures only each 10th visit to your web site. Typically there is no need to change from the default 100%.|
|Capture all server side||Select this check box to capture server-side PurePaths even when the corresponding visit is not captured.|
|Visit ends after user is inactive for X minutes||Lets you configure the time until a visit times out. Visit-based business transactions are calculated and stored in the performance warehouse only after a visit times out. A visit ends after 8 hours or if they contain 1000 user actions. New user actions then create a new visit.|
|Visit tag||Lets you use the value of a measure as a visit tag. For example, if the user name is stored in a session attribute, you can use a Web Requests - Session Attribute Value measure to tag visits with the username. All measures from the Business Transaction Evaluation/Filter/Grouping Values category can be used. You can configure any number of visit tags, but one tag must be configured to act as the primary visit tag search availability. Select the Is primary check box for the visit tag you want as primary. All other tags then act as additional tags and are not displayed in the visit details. The tag is set only once per visit, so once a valid tag value is determined, it does not change with the re-occurrence of the measure.|
Lets you define conversion goals used to count visits as converted. To define a conversion, use a URI web request matching pattern, a method occurrence, or any measure trigger.
Configuring conversion goals is especially useful with e-commerce business applications where the conversion rate (spectator or buyer ratio) should be calculated. For example, if your web-site calls an |
After you define at least one measure, you can use the Visits - Conversion Rate measure (which indicates the conversion rate of any of the conversion measures) and consequently, the conversion count of your visits. There is a separate conversion rate measure created for each measure that is assigned as a conversion measure that only indicates the conversion rate of this specific conversion measure. Default names of these measures are Conversion Rate for <conversion measure name>, but you can rename them as you want.
User Experience Index
Use this section to customize rules that calculate the user experience index of visits.
|Visit is tolerating if number of satisfied actions is less than||If the percentage of satisfied actions in the visit falls below this threshold, then the visit is marked as Tolerating. The default is 50%.|
|Visit is frustrated if number of frustrated actions exceeds||If the percentage of frustrated actions in the visit meets or exceeds this threshold, then the visit is marked as Frustrated. The default is 50%.|
Action groups are a good way to define individual performance baselines for different types of user actions. A new system profile contains six predefined action groups, one for every action type. You can also define custom action groups, such as one that groups all search actions into a custom group defined by a specific threshold. Every user action is assigned to one group by evaluating the action group list from top to bottom.
Action group configuration
- Based on their name.
- Starting or ending on a specific page by title or URL.
The baseline is the key performance metric used to determine Apdex rating to apply to each action in the each action group. You can set the performance metric for custom action group, or change the performance metric use3d for any predefined action group. To do this, select the action group to configure and click the Edit button in the Action Group button bar. Then in the Action group configuration dialog box, select the desired metric from the list. Only the performance metrics applicable to the action group type appear in the list.
The performance metric displays in user actions data in in both the client and AppMon Web. See
You can also optionally differentiate between web and mobile web. as shown in the following images, Actions for the Ajax action type can be grouped by XHR URL. Actions for the mobile ADK action type can only be grouped by name.
Action group advanced configuration
You can make additional configuration changes that apply across all of the selected profile’s defined action groups. See Action groups advanced configuration to learn how.
Using multiple performance baselines in action groups
Action groups and individual baselines appear in the User Action PurePath dashboard details.
On the User Actions dashboard, actions display by action group
Choose this setting to append the |
Ajax (XHR) detection and additional packs
Ajax (XHR) detection
XMLHttpRequest to perform requests.
Basic XHR Detection is a generic wrapper for all requests performed with
XMLHttpRequest. Selecting this module captures the Internet Explorer
ActiveXObject. Because it has more overhead than specific framework wrappers, using the specific wrappers whenever possible is recommended.
Some modules for specific frameworks require modifying the framework
js file. This is necessary to trigger framework instrumentation directly after the framework is loaded.
Manual XHR Framework Instrumentation contains a selection of the various code snippets to use.
This list contains settings for capturing additional information:
|Perceived render time||This module calculates the perceived render time. This is the time it takes for all visible images to completely load, depending on the browser window size. When activated, perceived render time is calculated for each user action. See Perceived Render Time for more information.|
|Streaming||Captures information about HTML5 video and audio tags embedded into a webpage. Manual instrumentation is required for videos in Flash or Silverlight.|
|Timed action support||XHRs are often sent via |
|User Timings||Captures timings measured by the browser’s |
|Visually Complete||Enables support for both the visually complete metric and the speed index metric. This setting is enabled by default in newly created system profiles. A page is “visually complete” when all the visual components have been rendered. It is the time when a user considers that the page is ready to interact with. It doesn’t consider, for example, any Ajax request that could be going on behind the page. Visually complete can be captured for page load and for Ajax actions. See Visually Complete metric for more information. The speed index is the average time at which visible parts of the page are displayed. It is useful for comparing the user experience of various pages. The lower the number, the better the user experience of the page. Speed index is only available for page load actions.|
W3C Resource Timings
Use the W3C Resource Timings section to enable detailed resource information capturing, and to capture all or a percentage of visits details to produce a resource waterfall chart for PurePaths using every page load action. Use waterfall and captured W3C resource timing data to help optimize the performance of your web application.Waterfall charting appears on the User Action PurePaths dashboard. See Web Performance Optimization for UEM and W3C Resource Timing Metrics for more information.
|Capture Resource Information||
|Domain Mapping||See CDN Content Analysis for more information on mapping domains.|
Capturing resource information may cause overhead, especially on browsers that do not support the Resource Timing API.
|Calculate Bandwidth and refresh every||Interval at which the bandwidth calculation repeats for a visit. The smaller the value the more accurate the bandwidth if it changes regularly. However, this also produces more overhead. For proper calculation, you also need to enable capture of web request/response sizes. See UEM FAQ for detailed info.|
|Enable bandwidth calculation on mobile browsers||Enables bandwidth calculation for mobile devices. Bandwidth calculation needs to download extra data. This overhead is often undesired on mobile devices. The option is only available if bandwidth calculation is enabled.|
With capturing enabled, you can grab any number of values for these types. The captured string truncates if longer than 100 characters.
Select the type and specify an ID. You can then use this ID for Measures and Business Transactions.
Finally, specify a capture expression (identifier) by which the value is retrieved:
- Meta Tag Names: Get the content attribute of the specified meta tag name.
- Meta Tag Names:
- Get the content attribute of the specified meta tag name.
- CSS Selectors:
- In addition to using a CSS selector to locate a particular element, you can also retrieve an element attribute value. To do so, add @ followed by the attribute name. The innerText or textContent of the element is retrieved if no attribute is specified.
- If the CSS selector query results in multiple elements, only the first element is captured.
- The variable must use dot notation for any Object property reference, for example
someObject[property]. Use brackets only when capturing Array values, such as ‘someArray’.
Captured values appear as Metadata Details when you hover over a user action PurePath root node or select Details from its context menu.
Capturing restrictions section
|Include/Exclude IPs (IP range)||You can configure ranges of IP addresses to exclude or include from User Experience Management. For example, if you want to exclude all visits of your web site from the local network you can add the network mask of your local network to the list of excluded addresses.|
|Include/Exclude Browsers (Browser range)||Include or exclude certain browsers and / or versions.|
|Monitor request path||
The Monitor Request Name defined in the Global Settings tab (by default
|Domain for AppMon cookies||
Overrides on which domain the AppMon cookies dtCookie, dtPC, and dtLatC should be set.
|Add the “Secure” attribute to the AppMon session cookie (dtCookie)||
Useful for web sites that employ the HTTPS protocol for secure communications, this setting marks the AppMon session cookie |
|Send AppMon monitoring request to foreign domain (CORS)||The Same Origin Policy only allows XHRs that are sent to the same server delivering the web page itself, but UEMaaS requires a Web Server Agent to send the monitor signal to a different server. To resolve this, modern browsers (IE 8 and later, Chrome 4 and later, FireFox 3.5 and later, Safari 4 and later, Opera 12 and later) support CORS, which lets the web server decide whether it allows content to be delivered to a 3rd party site. Enable this here.|
|Include the Anchor as part of the URI when determining an action name||Select this check box to include the Anchor as part of the URI when determining an action name.|
REST API - AppMon 6.5
Use the AppMon REST API to retrieve the snippet for your application and inject it as the first script into your page. The API is designed to be used during the build process of a web application and provides vital functionality the agent needs to instrument a website. Note that it is not recommended to request the snippet directly via a script tag, since this would unnecessarily decrease load times and require user privileges and direct access to the AppMon server. The API call looks like this:
Bootstrapper - AppMon 6.3
|Action reporting interval in seconds||Defines the delay until data captured with the mobile agent is sent to the AppMon Server. The delay is adjustable in 10-second steps between 10 seconds and nine minutes. The captured data is also sent when the mobile app is suspended or terminated, or if it is programmatically flushed via the corresponding mobile agent API.|
|Capture lifecycle events||Determines whether or not instrumented lifecycle actions generated by the mobile agent are sent. You can optionally select Only if device has WiFi connection for this setting.|
|Capture crashes||Determines whether or not to capture app crashes and send detailed crash reports to the AppMon Server. In order to prevent getting spammed with thousands of crash reports of different devices, in case of a defective crashing app, you can limit the number of handled crash reports per minute (five is the default). You can optionally select Only if device has WiFi connection for this setting.|
Determines whether or not the errors and exceptions reported via the |