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:
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.
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…
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:
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…
3. Set up the tracking configuration.
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”.
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.
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.
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.
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:
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.
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:
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.
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
So let’s create that folder and copy the config file there.
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.
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”
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?
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.
Do you mind if I answer that in an article? Could be a bit long…
Sounds good. (Hopefully in the next few days, no pressure… ;))
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.
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).