Validate Your Mobile App Measurement Implementation

I’ve had a number of questions recently from customers asking how to validate mobile application analytics implemented using Omniture App Measurement Libraries. Depending on the situation, there are a number of methods which can be used to validate and debug analytic implementations in native mobile apps. The details in this post are fairly technical so if you’re not the person responsible for validating your app analytics, you should pass on the following details to the lead responsible for validation.

Four common methods for capturing analytics requests from mobile apps were contributed for this post by Shawn Austin [ClientCare], Sam Kuttler [ClientCare], and Carl Sandquist [Omniture Consulting Services]:

Simulator
_
Requests triggered by App Measurement libraries can be examined from within the development or simulator environment. The following example uses syntax specific to the iPhone but the methodology is very similar for Android, Blackberry, and Symbian._

Pros: Debugging integrated within the development environment
Cons: Requires source code and familiarity with native code

  1. Place tracking code appropriately within the iPhone application (as described in the AppMeasurement for iPhone implementation guide). Since debugging output needs to be exposed to the development workstation, you will link to the libOmnitureAppMeasurement-iPhoneSimulator.a library (as opposed to the libOmnitureAppMeasurement-iPhoneDevice.a).
  2. Enable debugTracking (debugTracking = YES). Typically this is done after the “s” instance has been declared. Here’s an example:
  3. – (void)applicationDidFinishLaunching:(UIApplication *)application {
    OMAppMeasurement * s = [OMAppMeasurement getInstance];
    s.account = @”reportsuite”;
    s.debugTracking = YES; //prints debug requests in console
    s.pageName = @”iPhone App Test”;
    s.dc = @”122″;
    [s track];
    }
  4. Save the file.
  5. Within the Xcode application open the Console window (Run > Console).
  6. Run the iPhone Application (Run > Run)—the iPhone Simulator should launch. HTTP requests to Omniture should appear within the Console window as appropriate actions (per the coder’s design) are taken within the iPhone application.

[update] Note: you can validate requests on an actual device by compiling and running the application on a device connected to your development machine. Requests may be viewed in the console.

Proxy Server

By configuring WiFi proxy settings on your mobile device and using a packet sniffer on another computer attached to the same network, you can watch http/https requests made by the application, including requests sent by the App Measurement libraries.

Pros: Quick to set up, exposes measurement behavior on actual device
Cons: May not work for all network configurations (e.g. WiFi and LAN must be on same subnet), not all mobile devices support proxy settings (e.g. older versions of Android).

  1. Download and install software with packet sniffing and proxy server capabilities. Our example below demonstrates Charles but a number of other software packages are available with similar functionality.
  2. Connect your mobile device and your workstation to the same WiFi network. You may want to disable the “mobile network” radio to ensure your mobile device is connecting exclusively through WiFi.
  3. Determine your computer’s IP address on the local network. This can be done on a windows machine by choosing Start > Run > type in “cmd”, click OK (a command window should pop up), type ‘ ipconfig’ at the command prompt and hit Enter—resulting output includes your computer’s IP Address
  4. Open Charles, choose Proxy > Proxy Settings and make sure “Enable transparent HTTP proxying” is checked. You should also note the port (8888 in this case).
  5. Configure proxy settings on your mobile device to use the same IP address as your desktop and the same port set in Charles. To perform these steps on the iPhone:
    1. Go to Settings > Wi-Fi and tap the blue arrow next to your WiFi connection.
    2. Scroll to the bottom of the WiFi Connection settings and tap “Manual” under HTTP Proxy.
    3. Type in your computer’s IP address for the Server (as recorded in Step 3) and port specified in Charles (8888 in this case). When you are done it should look something like the following:
  6. Launch the application you wish to validate or debug—you should see packets appearing in Charles from your mobile device.

Note: If you need to examine measurement for secure requests, follow these instructions for sniffing secure packets.

Virtual WiFi Access Point

Turn your desktop into a Wi-Fi Access Point using the wireless card to create the hot spot and the hard-wired connection for internet access. Once your mobile device connects to the WiFi Access point, you can monitor the internet traffic going through your desktop using a network packet sniffing utility.

Pros: Easy to set up, works for any mobile device that can connect via WiFi
Cons: Hardware requirements (need a PC with Windows 7 or a Mac), requires computer with both WiFi and LAN

Create WiFi Access Point in Windows 7:

  1. Download and install software with WiFi sharing capabilities. Our example below demonstrates Connectify but a number of other solutions are also available. Connectify supports most wireless cards but you may wish to verify your card will work prior to the install. Theoretically, connection sharing can be done without additional software like Connectify in XP or Windows 7 by configuring a Wireless Network Connection; however, in practice the connection tends to be very flaky if it works at all.
  2. Configure a new wireless connection in Connectify—you’ll need to specify the network name (“Wi-Fi Name”) and password, choose “Access Point” for the Mode, and choose “Local Area Connection” (the hard-wired internet connection) for “Internet”. If you don’t have “Access Point” as an available option, then your wireless card is probably not supported by Connectify.
  3. Once your settings have been specified, choose the “Start Hotspot” option, and your network should be created and become visible to the mobile device within a few seconds.

Create WiFi Access Point in Mac OS X:

  1. Enable “Internet Sharing” in order to broadcast as a Wi-Fi network and become visible to the mobile device. Go to System Preferences -> Sharing and choose “Internet Sharing” (but don’t actually check the box yet), then click the “AirPort Options” button in the lower right:
  2. Select a network name and choose a password (this will be the network that we will connect the mobile device to):
  3. Click “OK” to return to the previous window. Select the checkbox next to “Internet Sharing” to activate the new network. You should see “Internet Sharing: On” like in the image below:

Configure Network Packet Sniffing Utility:

  1. Now the WiFi network is set up, configure your mobile device to connect to this new Access Point. Select the new network from the list of available networks on the mobile device and then enter in the password used when configuring the network. You can verify internet is working on the mobile device by browsing the web.
  2. Next, we’ll need to download and install a network packet sniffing utility. The following example uses Wireshark. In Windows 7, the install was straightforward and Wireshark worked the first time I opened it. The Mac version of Wireshark was not as easy to install (Wireshark did not recognize any of my network interfaces at first). If you are doing a Mac install of Wireshark, be sure to first read and follow the directions in the “Read Me First” text file (that comes bundled with the download). Once those changes had been made, further configuration still had to be completed (see this guide); but ultimately I was able to get Wireshark installed on MAC.
  3. Open Wireshark. On the initial screen, choose “Capture Options”, or the menu item Capture -> Options.
  4. For the “Interface”, choose your wireless network adapter. Also, make sure the promiscuous mode checkbox is enabled. Click “Start”:
  5. You should now see a screen containing all Network Traffic passing through the wireless adapter. To isolate just the Omniture requests, add the following Filter: http.request.uri contains “/b/ss/”.
  6. As the screenshot shows, the filter now displays only Omniture packets.

Hub

If none of the above methods work for you, you can modify your network configuration by adding a hub to provide visibility to all the requests sent on the subnet below the hub.

Pros: Allows visibility into network requests when other methods can’t be used
Cons: May need to purchase a hub (for this example, a dynax DX-EHB4 was purchased from BestBuy for $25 USD)

  1. Add a hub to your wireless network. The computer you will be using to monitor requests and the wireless router your mobile device will be using to connect over WiFi should both be plugged into the hub.
  2. Follow the instructions above to set up and configure Network Packet Sniffing Utility.

Note: if the hub method doesn’t work in your situation, Wireshark has documented a number of additional Ethernet packet capture configurations.

I can see the Omniture requests, now what?

Now you’re able to see the analytics requests, you’ll want to validate measurement is occurring at key usage milestones (e.g. app launch, screen view, etc.) and that the proper variables are set at these milestones. As you review the requests, you’ll want to reference one of the manuals below which map query parameters back to Omniture variables: