Analysing Mobile Apps – Prerequisites

This article is part of a mini-series on Analysing Mobile Apps discussing Overview, Prerequisites (this one), Coding, Debugging, and Analysis of mobile apps.

Today I walk you through the setup.

You will need to install some things, check that you can log into Adobe Analytics (“the mobile way”) and figure out where your tracking will go.

Those tasks are probably split between you (the developer) and your friendly marketer, so I’ll split them here as well.

I’ll start with the marketer’s actions, because the developer will need some stuff that the marketer makes.

For the Marketer

First thing to do for the marketer: make sure you can log into “Adobe Mobile Services”.

There is a good article in the help section about getting started using Mobile, which you can read and follow, of course. The important steps are the following:

Log into Adobe Mobile

1. Log into Adobe Mobile by using this URL: https://mobilemarketing.adobe.com/. You can use your Marketing Cloud or legacy login. Depending on whether you already have mobile apps or not, you will see one of the two following screens:

[Screenshot]
Adobe Mobile Overview with Apps
[Screenshot]
Adobe Mobile Overview without App

Create an App

2. Create a new app. You can either click on the big blue “Create New App” button if there is one, or you can go to “Manage Apps” and then use the “Add” link at the top of the list.

[Screenshot]
App Creation Screen
I am assuming that this is the first app, so we’ll create a new Report Suite for the tracking data. I am sure that if you have done this before I won’t have to explain and you’ll be totally capable of selecting the correct Report Suite yourself.

You should only have to edit one field: the “Name” of your app. All the rest should be populated automatically. Make sure the time zone and currency match your expectations!

See how the interface makes a report suite Id (rsid) for you based on the app name? Nice touch…

[Screenshot]
Create App Screen with some Values
Hit the “Save” link at the top and the system will create your report suite, configure it for mobile reporting and do some more magic.

I was going to write “Remember to write down the rsid, because you’ll hand it to your developer later”, but that is actually not necessary anymore.

When the magic has been done, the screen will look like this:

[Screenshot]
App Settings Screen once App has been Created
There is a lot more going on there now! I don’t want to go into most of it now, except that some things that you configure here end up in the config file, so changing them would require an app update. Better do it now, before the developer gets her hand on that file…

More Setup

3. Set up the tracking configuration.

[Screenshot]
Top Menu in App Settings Screen
Using the top menu, you can add “Variables” and metrics (Please tell me your app has an actual purpose! If it does: good. Make sure you add metrics for it and set them as “Key Metrics”. Those three metrics that are pre-selected are ok, but not enough!).

It makes sense to do this a bit later, when some data has already come into the report suite. Why? Because you can then use a nice drop down to assign Context Data straight to your “variables”.

[Screenshot]
Assigning Context Data to “Variables”
This obviously only works if the system knows what Context Data you are sending, and for that you need to send some.

You can also “Manage Points of Interest”, an interesting feature that lets you define geographic locations. If someone uses your app close to a PoI, the app will send the PoI name along with the tracking data.

You will probably want to enable “Location Reports”.

There are some options that you need to set regarding privacy and offline tracking.

[Screenshot]
Analytics Options in App Settings Screen
The Target and Audience options are not important in this context, but their existence hints at the fact that the SDK supports not only Analytics but also Target and Audience management, all in one library.

We’ll also enable “Acquisition”, the measurement of how people actually got to your app.

[Screenshot]
Acquisition Options in App Settings Screen
Now hit “Save” again.

You have done your bit. Time to hand over to the developer…

For the Developer

I’m pretty sure you have done some or most of these steps already, but you should probably follow at least from step 2 to the end.

Install IDE

1. Install an IDE. I will use Android Studio this time, because in the past, I have shown how to do it using eclipse and I don’t want to repeat myself 😉

So go ahead, download Android Studio and the Android SDK and all the bits and pieces you need for app development. I’ll wait.

Get the Adobe Mobile SDK

2. You need to obtain the SDK and config file. Your friendly marketer has done most of the work for you, actually. If she gives you a login, you can go to https://mobilemarketing.adobe.com/, find the app you are building, click on it and scroll all the way down until you see this:

[Screenshot]
Download Links on the App Settings Screen
You will need to download at least the config file and SDK, but I suggest you also download Bloodhound, the debugger. Feel free to also grab the sample app. A lot of people learn best by looking at existing code and that’s what the sample apps give you. Or you could just continue reading…

If you can’t get a login, ask the marketer to download those files for you. You can use the screenshot above to tell them what you need. You’re welcome.

Note: you can still download the SDK via the Developer Connection, but the way I have shown here makes sure all configuration is right. It should greatly reduce friction and is a lot less error-prone.

Install Bloodhound

3. Install the Bloodhound debugger for mobile. No question: you need a debugger. Even though I really like Charles, I decided to use Bloodhound this time. Both work just fine.

Setup – Add Lib and Config

4. Setup your app project for measurement. Let’s all start from the same point, an app that has just been created in Android Studio. For me it looks like this:

[Screenshot]
“Blank” App in Android Studio
First we grab the adobeMobileLibrary.jar file from the zip file you or your marketer downloaded and place it in the lib folder within your project.

[Screenshot]
Lib File in Mobile SDK Zip
[Screenshot]
Lib File Copied to lib Folder
For those of you who are used to eclipse: you might wonder where the assets folder is, right? We’ll have to make it. Android Studio uses gradle, which expects the folder under the main tree.

So let’s create that folder and copy the config file there.

[Screenshot]
Config File in assets Folder
It doesn’t really matter whether you download the config file separately or use the one from the zip file, they contain the same configuration.

[Screenshot]
App with Added Files in Android Studio
That’s it for today (and a lot it was!). Tomorrow I’ll show you what you need to put into your code so you get useful tracking.

13 thoughts on “Analysing Mobile Apps – Prerequisites

  1. Great posts Jan. Just what I need and hopefully I’ll get to implement our first mobile app to SiteCatalyst also this year. Can’t wait the following posts.

    I hadn’t even noticed that there was separate login to analytics for the mobile apps. (https://mobilemarketing.adobe.com/) A bit strange, shouldn’t the official marketing cloud be only one place where all the magic happens. 🙂 Now there is too two login url-addresses. Or can I access to this mobile stats screen directly from the original marketing cloud?

    Like

  2. If we have website for the service too, would it be ok to add the website data to same report suite (as the the mobile application)? Or do you recommend to use separate report suites for tracking website vs. mobile app? If we would save the data to same suite then we could easily answer questions as “how many unique visitors used both app and website version of our service?”. Especially if we would save unique loginID to an eVar. Or is this somehow blocked or what could be the pitfalls? Of course we would only have 75 custom variables and not 150 if we use 2 report suites. If you don’t recommend this then the plan B could be to make global report suite for these two suites, and that would be pretty much the same thing (if our license can handle the extra server hits).

    Of course we would “always” have to segment the data to get different metrics by mobile app vs. website. So this could be very time consuming, now the global suite starts to feel like the right answer? Damn! No! If we would have two suites then, I for example, would have two different loginID’s that would be copied to global suite and that wouldn’t give us the answer for unique visitors in app and website.

    Asked this also from ClientCare, but would be useful to get more insights around this before we make the final decision. Thanks again for all the comments you might have.

    Like

    1. You’re funny.

      If I actually _do_ manage to write something by Tuesday, I promise I’ll push back the currently scheduled article and post “yours” instead. Possible but not likely.

      Like

  3. If you do that, I should offer you a beer in the next Adobe Summit. 😉
    Seriously, no pressure… Write the post whenever you have the time, I’m sure I’ll get figured out what we should do on our situation (with the help of ClientCare).

    Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.