July 2015
Volume 30 Number 7
Google Analytics - Analyze User Behavior in Your Windows/Windows Phone App with Google Analytics
App development is by definition an iterative process, so you’ll want to understand, in the shortest possible time, how your app is used and how a new version or feature may impact user behavior. How much is a feature really used? What is the user behavior on a specific page? How much time does a user spend to accomplish a specific task? What are the most common hardware configurations? What’s going on when a crash happens? How successful are trial versions and in-app purchases? Do your users run the app offline? These are only some of the questions a telemetry system can answer.
There are a number of telemetry providers that officially support Windows development (bit.ly/1KGgAdQ), and Microsoft Azure includes Visual Studio Application Insight, which is also integrated in Visual Studio 2015 (bit.ly/1EeM8Ui).
Google Analytics, thanks to the Google Analytics SDK for Windows (available on Codeplex at bit.ly/1zXfvxJ), is also easy to integrate into a Windows or Windows Phone app (both Silverlight and Universal).
In this article, I’ll focus on Google Analytics, because it’s one of the most widely used providers on other platforms, including the Web, and it’s a great choice if you’ve already instrumented a Web site with Google and want to use the same account for apps. I’ll describe how to collect telemetry information with Google Analytics, and analyze the collected data, such as installed app versions, geographic distribution, and user behaviors, and how to perform an A/B Testing.
Understanding telemetry concepts is useful no matter which provider you use. A great starting point on this topic is Kraig Brockschmidt’s deck from Build 2014 (bit.ly/1QGIsSO).
What Is Google Analytics?
Google Analytics was originally built to track and analyze user behaviors on Web sites. Over time, Google extended its support and tools to apps, and now an SDK is available for iOS and Android, as well. Google also provides a measurement protocol that lets you make HTTP calls to send raw user interaction data directly to Google Analytics servers (bit.ly/1kHgDYz). This allows you to determine how users interact with their businesses from almost any environment. The Google Analytics SDK uses this protocol for Windows 8 and Windows Phone. The SDK is an independent, open source tool set that aims to have feature parity and API similarity with the official Google Analytics SDK for Android.
Integrate Your App with Google Analytics
To integrate an app, first you need to access the Google Analytics dashboard with a valid Google account, then create at least one application account that can access the administrative area (bit.ly/1kPLnqG). It’s also a good idea to create separate application accounts for development, beta testing and production. This way, you keep the data from each set separate, and avoid polluting your important production data with bad data from other developers and beta testers.
An application account uniquely identifies an application (Contoso, for the purposes of this article). In this context, an “application” really refers to a collection of apps available for different platforms and/or Web sites (Contoso for Windows, Contoso for Android, Contoso Web dashboard), all of which send their telemetry information to the same account. Each application may also be available in multiple versions (Contoso for Windows 1.0, Contoso for Windows 1.1, Contoso for Android 2.0.1).
When you create the account in Google Analytics, you also need to define one or more properties. Here, a property is an app or a Web site for your account. An app property can have multiple versions, and it’s logical to have a property for each supported platform (for example, ContosoW8, ContosoWP8, ContosoDroid). After you’ve chosen names for your app and answered a few questions to classify the business scope of the app, Google Analytics generates a numeric account ID and a tracking ID with the format UA-xxxxxxxx-x, which represents your platform-specific app in Google Analytics and will be used in all telemetry communications sent from the app.
In my sample scenario, I have a universal application (W8.1 and WP8.1), so I created two property IDs in one Google Analytics account. To enable my app to talk with Google Analytics, I’ll use a NuGet package. To do this, for both the Windows and Windows Phone apps, right-click on References, select manage NuGet packages, and add the package “GoogleAnalyticsSDK.” This package adds a couple of references and the file analytics.xml, shown in Figure 1, to your Visual Studio solution. You’ll have to edit this file so the app can use the correct tracking ID you created earlier.
Figure 1 Analytics.xml for Windows and Windows Phone App
<?xml version="1.0" encoding="utf-8" ?>
<analytics xmlns="http://googleanalyticssdk.codeplex.com/ns/easytracker">
<trackingId>UA-60759067-2</trackingId>
<appName>ContosoWindows</appName>
<appVersion>1.0.0.0</appVersion>
</analytics>
<?xml version="1.0" encoding="utf-8" ?>
<analytics xmlns="http://googleanalyticssdk.codeplex.com/ns/easytracker">
<trackingId>UA-60759067-1</trackingId>
<appName>ContosoWinPhone</appName>
<appVersion>1.0.0.0</appVersion>
</analytics>
Finally, you must ensure your app is authorized to use the network. For the Windows Phone app, select the ID_CAP_NETWORKING capability in the WMAppManifest.xml file; for Windows 8, select the Internet (client) capability in the package.appxmanifest file.
Instrumenting the App
The first category of information most developers want to track is user navigation. Using this SDK, you need to send the correct event every time a user accesses a page. The Google Analytics SDK exposes the SendView command for this, and the natural place to call this method is the Loaded event of each page:
void MainPage_Loaded(object sender, RoutedEventArgs e)
{
GoogleAnalytics.EasyTracker.GetTracker().SendView("Main");
}
void Page1_Loaded(object sender, RoutedEventArgs e)
{
GoogleAnalytics.EasyTracker.GetTracker().SendView("Page1");
}
void Page2_Loaded(object sender, RoutedEventArgs e)
{
GoogleAnalytics.EasyTracker.GetTracker().SendView("Page2");
}
Keep in mind that a “view” is not just an app page; you also need to consider other aspects of the UI that focus the user’s attention (such as the settings panel and dialog boxes) that you want to monitor and analyze.
SendView requires a string parameter that uniquely identifies the page or UI aspect you’re tracking. This name will appear on the Google Analytics dashboard and on reports as the reference for your page. It should be generic and meaningful and easily associable with the source page. It must not be translated even if your app supports multiple languages because it would be interpreted by the analysis system as a different page. In other words, unless you specifically want to differentiate telemetry data for localized versions of your app, make sure the identifiers you send to Google Analytics are not themselves localized.
Now the app is ready to send its first page-navigation telemetry information. To see it, open your app and navigate through the pages for a while.
User Navigation and the App Version
Within a few seconds, the navigation data is ready and available for your analysis. Go to google.com/analytics and sign in to access your homepage. Then click on the All mobile App Data link below the property you want to analyze (in my sample, the property is ContosoW8 or Contoso WP8).
The welcome dashboard shows historical data for the last 30 days, not including the current day. If the account is new, most likely all charts will be empty. There’s also a dashboard area dedicated to the most recent data, which you can access by selecting the Real Time button on the left side of the dashboard.
The Overview page indicates the number of active users, and shows the screen view in real time with a detailed graph for the last minute and the last hour (see Figure 2). Vertical bars on these graphs show user page accesses.
.png "Real-Time Data Dashboard")
Figure 2 Real-Time Data Dashboard
You can also see a list of the most active screens in the last hour, with the number of active users. The name you’ll see on the dashboard is the one used as the SendView parameter in the app code. Figure 2 shows real-time sample data in “Caledos Runner,” an app I developed that uses Google Analytics to collect usage data. I wanted to show real data in the app so you could see how much information you can get from this tool—and the corresponding potential.
Each screen name is clickable so you can slice the data and analyze the specific use of a page. One of the most important pieces of information here is the time spent on each page (or, better, on each view). After clicking a screen name, you can add a metric showing average time on screen to the graph, by clicking Select a Metric from the Explorer tab.
One great tool Google provides is the Behavior Flow report, shown in Figure 3. Thanks to the SendView API, this tool is available by selecting Behavior from the Reporting tab on the dashboard, and it lets you analyze how users move across your app’s pages from the beginning of a user session. The graph is composed of a sequence of screens (first screen, second screen and so on), and shows the number of user sessions that connect and exit. For the session exit, you can see the next page accessed (ordered by session number) and the number of users who leave the app from that page (in red).
.png "A Sample Behavior Flow Report")
Figure 3 A Sample Behavior Flow Report
This tool allows you to understand where users spend their time when they use the app, and you may eventually decide to make access to popular pages easier by providing a bigger, more recognizable button. Figure 3 shows that in my app, the top three next screen destinations from the main page are askcloud, running and activity detail. This suggests it’s probably a good idea to give a central and visible position to the corresponding buttons on the main page, or to move some of the functionality users find on those pages to the main screen in order to reduce the time and the number of taps users need to accomplish these activities.
You’ll also want to know which version of your app is being used, and this information comes from the devices using your app. On each call, the SDK sends the app version provided in analytics.xml so you can slice your data and find the version used. Historical app version data is available under Audience | App Versions in the left pane of the dashboard. Figure 4 shows what typically happens when I release a new version of my app to the store. Because the default behavior on Windows Phone 8.1 is to automatically download and install the new version of the app when available, within a few days more than 90 percent of the user base migrates to the latest version, (though a long tail of less than 10 percent of users remains who, for some reason, can’t or don’t want to upgrade).
.png "App Version Data")
Figure 4 App Version Data
Other dimensions you receive “for free” with navigation tracking are the location, language, device name (which isn’t 100 percent accurate for Windows Phone) and network service provider, while on the measures side you can find the number of sessions, unique users and unique new users.
With this information, you’re able to answer questions such as: What’s the most active country or city? Where have I had the most new users in the last month? With this new version, are my customers using the app more or less? And in this context, the only limit is your imagination because you can set custom events, counters, dimensions and metrics.
How a user navigates from one screen to another is a good starting point for understanding how your app is used, but there’s much more information available, more related to the specific domain of your app. This type of information can be tracked as a custom event, which usually involves some generic user interaction or information that makes sense to be bubbled up to the developer team. An event consists of four fields you can use to describe a user’s interaction with your app content:
- String Category
- String Action
- String Label
- Long Value
Because all custom events go in a single common list, the category, action and label fields help to identify specific information you want to analyze.
The information collected in this way is very generic, and this is where telemetry becomes an art. To give meaning to the data, you start with the question you want to answer, which leads to the telemetry design, which then leads to the instrumentation you need. So let’s start with an example approach.
Question: My sample app has many functions, triggered by buttons on various pages of the app. I want to understand which functions are used more, to focus my development effort in the right direction.
Telemetry Design: The main functions of the app are triggered by buttons, so if I track the clicks on those buttons, I’ll probably gain a better understanding of user preferences. The telemetry’s success metric will be the number of clicks I receive from each button.
Instrumentation: I can go to the click event of the selected buttons and track the event.
The following code shows how to record that a user has clicked the “play” and “stop” buttons:
private void buttonPlay_Click(object sender, RoutedEventArgs e)
{
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
"ui_action", "press", "play", 0);
// Your code here
}
private void buttonStop_Click(object sender, RoutedEventArgs e)
{
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
"ui_action", "press", "stop", 0);
// Your code here
}
As in the previous user navigation analysis, you have an Events table under both the Real-Time and Behavior groups. Depending on the type of analysis you want to do, you can select the appropriate view, historical or real time.
Events are shown for a specific time range (the default is one month), so you can see the number of events grouped by the top category, action and label in it. You can drill down on a specific category and on a specific event action and you can also change the date interval for the analysis.
For a specific event category, action or label, you can find the total number of events, the number of unique events, the sum of all the values and the corresponding average value.
Figure 5 shows a sample list of events, and Figure 6 shows the total, unique, sum and average values for the group Grp1.
Figure 5 Sample Events
| Group | Action | Label | Value |
| Grp1 | Press | Button1 | 1 |
| Grp1 | Press | Button1 | 2 |
| Grp1 | Press | Button1 | 2 |
| Grp1 | Press | Button2 | 3 |
| Grp1 | Tap | Label1 | 4 |
Figure 6 Summary Values for Grp1
| Total Events | 5 |
| Unique Events | 4 |
| Event value | 12 |
| Event average value | 2.4 |
A real-world example of use can help you better understand the potential of the tool. For “Caledos Runner,” I wanted to understand how much the app was really used for tracking activities, and because I didn’t want to force the user to register for an account in order to use the application, I used events to track this information.
On app start, I tracked an event for each registered user, and a different event for each user who isn’t registered, with code similar to the following:
if (!string.IsNullOrEmpty(currentUser.AccessToken))
{
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
"user", "Cloud", "Registered", 1);
}
else
{
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
"user", "Cloud", "Unregistered", 1);
}
I’ve discovered that 55 percent of users don’t send their data to the cloud, so in order to get a precise profile of my users, at the end of each GPS activity the app sends one event with information about the distance covered, and one event with the total elapsed time of the activity, using code similar to the following:
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
"activity", "outdoor", "time", (long)CurrentFitnessActivity.Duration);
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
"activity", outdoor", "distance", (long)model.CurrentFitnessActivity.TotalDistance);
As a result, I’ve obtained the data shown in Figure 7 for the first week of February 2015.
.png "Custom Events Sample")
Figure 7 Custom Events Sample
What this analysis says is: In the first week of February, the app has successfully tracked more than 15,000 hours (54,000,000 seconds) and 51,000 Km (32,000 miles). The average user uses the app for an activity of about 5 Km (3.1 miles), covering the distance in an hour and a half (5,400 seconds).
Good to know, but not enough! This is just an average usage view, but more likely you’d want to know how that usage is really distributed. This is a multisport app, so you’d want to know the most popular sport and whether that popularity comes from a small number of users using the app often or a lot of users using it, but for only a short amount of time.
This is where Google Analytics custom dimensions and metrics can help. Custom dimensions and metrics allow you to bring additional data into Google Analytics that can help you answer new questions about how users are interacting with your content. A metric is a count of a data type that’s summed up across your Google Analytics hits. A metric corresponds to a column in a report. Dimensions allow you to break down a metric by a particular value, for example, screen views by screen name. Dimensions correspond to the rows in a report (bit.ly/1lOry2r).
There are two main steps to implement a custom dimension or metric:
- Define the custom dimension or metric using the Google Analytics Web interface (bit.ly/1Je9RJQ).
- Implement code to set and collect custom dimension and metric values.
Each Google Analytics property has 20 available indices for custom dimensions, and another 20 indices for custom metrics. Once a dimension or a metric is created, your code can refer to that metric or dimension using the corresponding index.
Getting back to my question, to understand the sport breakdown I created a Dimension, Activity Type, with scope, Hit, and used the following code to track this information on the view shown by the app during a fitness session:
GoogleAnalytics.EasyTracker.GetTracker().SetCustomDimension(1, activityType);
GoogleAnalytics.EasyTracker.GetTracker().SendView("Running");
A/B Testing
A/B testing is a term marketers use to refer to testing that provides insight into visitor behavior, with the aim of increasing the conversion rate. (According to Wikipedia, the conversion rate “is the proportion of visitors of a Web site who take action to go beyond a casual content view or Web site visit, as a result of subtle or direct requests from marketers, advertisers, and content creators.”)
In the app development world, A/B testing means testing two different versions of an element (such as a page or a button) using a metric that defines the success of one scenario over another.
Suppose you have two designs of a page, A and B. Typically, A is the existing design (the control), and B is the new design. You can split your user base between these two versions and measure their performance using a metric that makes sense for your app (perhaps clicking on a specific button) to find your success metric or your conversion rate. At the end of the test, you select the element that performs best.
In other words, suppose each design is a different app page with its XAML file (page3v1.xaml and page3v2.xaml). On each page you have your target—the button you want the user to click—and you can use the click event of the button to track a custom event that recognizes a successful click of the button. By taking advantage of the MVVM pattern, you can decouple the view from model and the view model, so you can easily have two XAML files that contain the same logic and data.
You can then use code like the following to bring users to the pages to test, splitting navigation evenly between versions A and B of the page:
if (DateTime.Now.Second % 2 == 0)
this.Frame.Navigate(typeof(Page3V1));
else
this.Frame.Navigate(typeof(Page3V2));
You can track the success of the layout by recording the button click using:
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
"ABTest", "Scenario1", "pageV1", 0);
or the button click on the first page:
GoogleAnalytics.EasyTracker.GetTracker().SendEvent(
"ABTest", "Scenario1", "pageV2", 0);
and on the click of the same button on the second page.
The total number of events for each label (PageV1, PageV2) determines the most successful page. At the end of the test, only that page will remain in the application, while the other can be removed.
Wrapping up
In modern app development, telemetry and analysis tools can make a real difference in terms of how quickly you can identify user behaviors, as well as application problems and their resolution. In this article, I’ve discussed only a small sample of the scenarios that can be analyzed. The number and type of such scenarios is limited only by your imagination and curiosity.
Nicola Delfino is an application development manager in the Microsoft Italian services division and the author of “Caledos Runner,” one of most successful fitness-tracking apps for Windows Phone, which gave him the opportunity to use telemetry to discover and analyze how people use his app. You can reach him at nicold@microsoft.com or nicola@caledos.com.
Thanks to the following Microsoft technical expert for reviewing this article: Kraig Brockschmidt