Welcome to the last article in the mini series on Mobile App Tracking. If you haven’t yet seen the others, here they are: Overview, Prerequisites, Tagging, Debugging and Analysing (this one).

This week (remind me never to post 4 articles in a single week ever again!), we’ll look at how the implementation you made helps your friendly marketer. On top of that, because of the way the Adobe Mobile Services are made, I’ll show you what you or a mobile product manager can learn from the data!

Accessing the Data

Chances are you have never logged into SiteCatalyst Reports & Analytics, right? You might not even have an account!

My personal opinion is that you should have one. The UI of the Adobe Mobile Services has been built with the needs of a mobile product manager in mind, the needs of those who actually make apps. I’m sure you can learn something if you look at that data. Therefore you should.

If your friendly marketer has given you credentials, go to http://mobilemarketing.adobe.com and log in.

Note that you do not need access to the Marketing Cloud in order to log in. You can just click on “Sign in with Analytics account” and use the same credentials you use to log into Reports & Analytics.

Overview

As soon as you are logged in, Mobile Services will show you an overview of all your apps with the most important metrics (remember? you selected those in the prerequisites!).

It’s worth explaining what you can do with the menu on the left.

At the very top, you’ll find a drop down that usually says “All Apps” when you log in. You can use that drop down to select one app that you want to look at.

If you select an app, the screens changes and you’ll see the Overview for that specific app.

You can get to the exact same screen if instead of selecting the app in the drop down, you click “Manage Apps” in the menu then click on the app on the right, then open “Usage” in the menu and click “Overview”. Yes, I like the drop down better as well.

Cohorts!

One of the most mobile-specific reports is the “First Launch Cohorts” report.

It essentially shows you how many people are still using your app days/weeks or months after they first launched it.

We all know how people think an app sounds great, download it but then do not magically morph into users or even power users. A cohort analysis is a really good way to follow how your app is doing in converting first launches to actual users.

So in the week called “Week of First Launch”, 3 users launched my test app for the first time. A week later, one of those 3 was till using it, then a week later noone did. Bad. Hopefully your app will look better.

A cohort analysis is typically based on a triangular table, of course.

Paths

You and your friendly marketer will know path reports from standard web analytics. The idea is to somehow figure out how visitors are moving across your site. Where do they come from before they see a product? Where do they go after reading about that credit card offer? Things like that want to be answered.

No difference for apps. You might have less Activities and Views then on a site (a lot less, I hope), but the idea is the same. You have likely designed the app for a particular flow, and it would be useful to know whether your users agree. You might discover easier flows!

You can expand nodes and zoom in on them. And if you hover over the right or left side of a node, you can see where people went with colour coding.

On top of the “View Paths” report you also get the “Action Paths” report, which I think is actually more important. Remember how actions do not track Views or Activities but the things your users are actually doing with your app?

Using the “Action Paths” report you can find out in which specific order they are doing them.

Think they look at their account first, then make a transfer? Or the other way round? Look at the data and you’ll know for sure!

Versions

Now here is a report that is squarely aimed at the tech folk.

You can see how many active users are on which version(s) of your app at any given point in time.

It’s an unfortunate truth that not all users upgrade. Sometimes people actively decide not to, a situation developers dread for the support implications.

But know whether your latest version propagates quickly can help product management gauge the popularity of changes or the impact of taking some away.

Technology

Another one for product management and development. Find out what devices and operating systems your users are using.

This is practically a life-saver on Android, I hear.

Mine looks very simple because I have only used two real devices and an emulator to look at my test app. Yours is likely going to be very colourful and pretty fragmented, especially if you have an Android app.

Acquisition

I’d love to show you screenshots of the Acquisition reports, but I haven’t got any data.

These reports are similar to campaign tracking on a standard web site. Your marketer will spend some money to get people to see your app. They’ll likely put a link to iTunes or Google Play somewhere on the Internet. Just as with campaign tracking, they’ll want to know whether those links have brought new users or not, and that’s what the Acquisition reports do for them.

On Android, this works partly through the usual Google campaign tracking mechanism, partly using a Distimo integration with Google Play. On iOS, there is no handing through of links, so the system relies fully on the Distimo integration with iTunes.

Location

The location reports help you and your friendly marketer find out whereabouts your users are most likely to use the app.

There are a couple of interesting applications of that knowledge, not the least being targeting.

One fun feature is the management of so-called “points of interest”. You can manage them in the UI or code them into the JSON file yourself. Each point is a place on Earth along with a radius and a name (for example “Basel Office” or “LAX airport”). When the device is within the radius, every tracking call will send the name of the POI along with the data.

Since the library has access to the POIs, you can not only track them but also use them in Target. An application might be to show a coupon when a user is in your app and close to a specific store.

Simplicity

I have written a lot about the virtues of simplicity. The Mobile Services are something that goes perfectly into the right direction, I think.

Note how I did not once talk about specific “variables” or Processing Rules at all! You essentially get a lot of very tailored and therefore useful stuff right out of the box.

Of course this works because a) app development is not as complex as web development from the point of view of user interaction. Apps tend to have sharper focus. Also, b) the challenges and opportunities marketers have with apps are currently limited when you compare with the web.

I love how our product management team has taken a look at the eco system, noted the differences and built something incredibly easy and useful.

We’ll stop here, the article is long enough as it is.

Is there anything else you want me to explain regarding mobile apps? Anything I should elaborate on? Or explain better? Do you want sample code?

Let me know!