AppMon UEM's mobile app support lets you track visitors, actions, and PurePaths triggered by your iOS and Android application. See Supported platforms for information on which mobile platforms can use AppMon's mobile UEM support.
To trace UEM activity, you must integrate the Mobile Agent into your mobile app by adding mobile agent method calls to the app's source code. When integrated into the mobile app, user experience data can be collected and analyzed in the same way as for users browsing your UEM enabled web application. The following shows the steps needed to generate and analyze mobile app UEM data.
Steps to integrate AppMon UEM's mobile app support into your mobile app include the following:
- Configure AppMon for Mobile UEM
- Integrate with the application
- Link web requests
- Configure mobile data collection
- Define measures
Configure AppMon for Mobile UEM
The setup is similar to the setup for UEM:
- Perform basic AppMon setup. Follow the procedure in Installation overview.
- Apply the UEM license, including Visits Volume. See Licensing.
- Install an Agent on the application server or web server. See User Experience Management Administration.
Integrate with the application
See the relevant page in the following links for detailed information on integrating the Mobile Agent into your mobile app.
- iOS Agent Setup and Instrumentation
- Auto-Instrumentation for iOS
- Android Agent Setup and Instrumentation
- Auto-Instrumentation for Android
See How to instrument a hybrid app for information on integrating with hybrid apps.
Link web requests
If a web request is tagged and the server side is instrumented, the server side web request PurePath links to the mobile User Action PurePath.
- If the web request is tagged on the same thread where a currently open action was started, it is always linked to this action.
- If the web request is tagged in a different thread, it is only assigned to an action if the web request occurs during the time frame of the action and the action is left in the same thread. Because AppMon currently does not capture the latency between the web request started on the mobile side and received on the server side, linking by thread ID and time frame is not guaranteed to work as expected for higher-latency scenarios.
Configure mobile data collection
Configure how mobile data is collected in the system preferences. In the AppMon Client, click Settings > Edit System Profile > User Experience. In the User Experience pane, select the tab of the application to be configured, or click the Default Application tab to configure all applications in the system profile.
See Mobile applications to learn how to configure User Experience mobile application settings.
To evaluate the results returned by the instrumented mobile application, subscribe new Measures for Mobile Actions in the Measure Configuration dialog box. To access it, click Settings > Edit system profile > Measures, then expand User Experience Management > User Actions > Mobile Actions and double-click the required measure. See Edit a System Profile and System Profile - Measures.
- A recent Apple iOS (armv7, armv7s, arm64 or later architecture, iOS 6 or later).
- Android version 2.3 or later.
When you have configured AppMon for mobile data collection, the Visits dashlet displays mobile visits, identified by mobile device, and shows all user actions per visit. To easily identify mobile visits in the dashlet, click Grouping and select either the Client type, Client family or Application.
Right-click a user action, and select Drill down > User action PurePaths to open the User Action PurePaths dashlet linked to server-side PurePaths. To limit overhead, a maximum depth of 10 nested mobile actions is evaluated. Deeper nested actions are skipped and not shown in the User Action PurePath.
The Transaction Flow dashlet can also visualize your mobile app PurePaths. To open it, right-click a PurePath you want to analyze and select Drill down > Transaction Flow.
In the transaction flow, zoom into part of the entry point flow to see where most of the time is spent. The icons that identify mobile actions and events are defined in the following table.
|Mobile lifecycle action (for example app start, display and redisplay of a view).|
|Timestamp for events of a lifecycle action.|
|Report value event.|
|Report error event.|
|Crash with attached crash report.|
|Recurring crash (no crash report attached).|
Mobile App Performance Overview dashboard
This dashboard shows UEM metrics for mobile applications. See Mobile App Performance Overview dashboard for more information on using the dashboard for analysis.
The following metrics are collected and available in various parts of UEM dashboards.
|Agent Version||Version of the Mobile Agent with which the application was instrumented (for example 126.96.36.1993).|
|Application Name||The mobile application name.|
|Application Build Version||
|Battery Status||Device battery strength (for example 70%).|
|Connection Type||Mobile, WiFi, LAN or Offline.|
|Network Protocol||Offline, 802.11x (for WiFi connections), LTE and others.|
|Device Name||The make and model of the device. For example, SAMSUNG-SGH-I727, iPhone 5S, iOS Simulator, google_sdk (if emulator).|
|Device Manufacturer||For example, Apple, Samsung, unknown (if emulator).|
|Total Memory||Device RAM, in megabytes (for example 1024).|
|Free Memory||Percentage of free RAM.|
|Number of Running Processes||The number of active application processes running on the mobile device.|
|OS Family||The operating system: iOS, Linux.|
|OS Name||The name and version of the operating system, for example iOS 7.0, Android 4.2.|
|Screen Resolution||The screen resolution in pixels, for example 480 X 800|
|Device Orientation||The default orientation for the device, for example portrait for a mobile phone or landscape for a tablet.|
|Device Carrier||The carrier that provides the signal for the Android device, for example AT&T. Android displays if the carries is an emulator. Not available for iOS.|
|CPU Information||The device's CPU, for example ARMv7.|
|Rooted/Jailbroken||Whether the device's software is rooted (Android) or jailbroken (iOS). Displays genuine if device's software is not rooted or jailbroken.|
The overhead depends on the instrumentation that you put into your app. It consists of:
- Data traffic to the server.
- Memory usage.
- Execution time of the action in the app.
All three factors mainly depend on the number of nodes that your instrumentation is about to produce.
For example, assume a user generates 20 user action per agent send interval (the default interval time is 2 minutes) and each user action consists of ten nodes: a root node and nine subnodes. The average node size is approximately 150 bytes. So ten notes add up to 1500 bytes (10 * 150) and 20 user action add up to ~30 KB (20 * 1500 bytes). Normal user actions consist of less than ten nodes per action, so overhead should be less than in this example. Also the agent uses gzip compression to reduce the data traffic to the server.