Tracking Mobile Apps

So far we have explained what basic tracking of web pages looks like.

Today we’ll broaden our horizon and briefly introduce how mobile apps can be tracked — apps for iOS, Android, Windows Phone 8, apps developed for iOS or Android using PhoneGap, apps for WinRT (Windows 8) or even OS X and some other mobile operating systems like RIM, Symbian or Windows Phone 7, XBox or even Flash/Flex.

The idea is relatively simple:

1. Add the Adobe Marketing Cloud Mobile library to your app,
2. Tag the different “screens” of your app as if they were web pages,
3. Decide whether you’d like to see “offline data”,
4. Configure a report suite for your app tracking,
5. Develop and debug, as usual.

So let’s look at the steps one by one.

AMC Mobile Libraries

When you tag a web page, you use Javascript and a file called s_code.js that contains the definition of all Analytics-related functionality used on the page.

For mobile apps, the Mobile Libraries do the same job. They define the neccessary environment, methods and stubs that you can use when you build tracking into your apps.

For some of the libraries, there’s more.

On iOS, Android and Windows Phone 8, you get what we call “Lifecycle Metrics” when you tag up your app. Those metrics include data points like app installs, launches, engaged users, install date, launch number, days since first use, OS version and many more. The documentation lists all lifecycle metrics.

These allow your friendly marketer to judge how engaged users are with your apps or to run mobile cohort analysis, extremely useful especially if your company is relatively new to apps in general.

Updates

The libraries get updated every now and again. Sometimes, the update requires code changes on your end or configuration changes in Adobe Analytics. The move to v3.x of the libraries on iOS and Android was such a case. Point releases should usually be “compatible” and only require a drop-in of the new lib and a recompile.

Tagging

It’s best practice to treat apps almost exactly like web sites. The equivalent of a web page would be an Activity on Android or a View on iOS. When an Activity or a View loads, you should track it just like you would a web page when it loads. So where you’d use s.t on a web page, you’ll use trackAppState in a mobile app.

The libraries contain a TrackingHelper class that you should use as a container for functionality you want to add. The example in the documentation speaks about tracking logins, but it obviously applies to all sorts of tracking. Use it!

The examples in the documentation also heavily use the so-called “Context Data variables”, which we haven’t mentioned yet. In a nutshell, they “replace” the usual Analytics “variables”. Context Data variables are more like a hash map and they should make it easier for developers to know what data to put where.

Offline Data

We’re talking about tagging mobile apps. Apps run on mobile devices, phones and tablets, or maybe cameras. Mobile devices tend to be carried around and they tend to drop off the network every now and again. Now that might prevent your app from running, but most likely it doesn’t; people will still be able to use your app without network access.

That raises the question: how do we track the app when the device is offline?

Two possibilites: only track when the device is online, or track all the time and buffer when needed.

The libraries can do both, and they handle the buffering for you for option 2 if you tell them to.

Consider this:

• For offline tracking to work, the tracing calls have to be “timestamped”, meaning the libraries will transmit them with a time stamp that tells the collection servers when the tracking actually happened.
• Those tracking calls can only be processed if the collection and processing queue knows that they’re timestamped — the report suite needs to be “timestamp-enabled”.
• If the report suite is timestamp-enabled, all tracking sent into it has to be timestamped!
• If you want to track mobile app traffic and web traffic into a single report suite, you have to add timestamps to your web tracking calls (which you can do if you use code H.24.4 or later).

We reckon your friendly marketer will discuss whether mobile app traffic and web traffic should be tracked into a single report suite or separately, but just one thing to think about: do the site and the app have the same goals and do they provide roughly the same functionality? If so: track them into the same report suite.

Once you have decided whether offline tracking should be used, you can contact ClientCare and ask them to enable timestamps for the report suite(s) in question. Only they can do it.

Develop and Debug

We won’t be telling you how to develop, but we can help you with the debugging.

The usual approach is to configure your emulator or device to use a proxy and then use your favourite debugger and check the data being sent in the tracking call by looking at the URL — really not that different from how you would debug on the web.

We hope that makes sense.

Remember that there is a ton of material on developer.omniture.com and that you can always contact your Account Manager and get help from Adobe Consulting should you need it. We think you won’t.