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.
![[Screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2014/08/140819-mobana-login-screen.png?w=300&h=197)
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!).
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.
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.
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!
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.
![[Screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2014/08/140819-mobana-versions.png?w=300&h=187)
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.
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.
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!
The customize menu is very confusing, but I guess I’ll figured it out when we start to get data and I can start analyzing.
It’s easy to filter data with custom variables / context data, but can I somehow access the custom directly? I mean, if we e.g. save form names to context data (map it to eVar1), can we just look that data: form names with form submission events?
Ah, noticed in here https://marketing.adobe.com/resources/help/en_US/mobile/reports_customize.html
“Note: Mobile app metrics are also available in marketing reports & analytics, ad hoc analysis, data warehouse, and other Analytics reporting interfaces. If a specific breakdown or report type is not available in Adobe Mobile services, it can likely be generated using a different reporting interface.”
It’s a shame if I can’t all custom data and reports type in the mobile interface. 😦
LikeLike
I guess Mobile Services have been built with the mobile PM in mind. Since added analysis is possible in R&A, the Mobile Services team probably felt they should concentrate on what’s important to a PM.
Just my guess, I don’t really know.
LikeLike
Ok. Could be the truth, and let’s wait how the mobile interface evolves and have to give feedback directly to Adobe too.
LikeLike