Analysing Mobile Apps – Tagging

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

I decided to stop yesterday when I felt it was getting too long. I was also unsure whether the next step was still setup or part of the actual coding. Doesn’t really matter, does it? And without further ado, let’s continue and make that app.

Configure Project

5. Configure your project properly. In addition to adding the library and config file, you need to make some changes to your project.

Let’s follow the Developer Quick Start.

Add two permissions to your AndroidManifest.xml file: INTERNET and ACCESS_NETWORK_STATE.

The first one allows the library to send tracking calls to Adobe Data Centres, the second one is necessary so the lib can detect whether it is on- or offline.

Code

Now we’re actually going to touch Java code, finally!

Most of the work when it comes to tracking is handled by the SDK. It only needs a couple of small nudges so it can do its job.

First one is to initialise it with a proper context. You do that in the onCreate() method of your main activity, like so:

	Config.setContext(this.getApplicationContext());

The method should look like this:

Note: If Android Studio doesn’t find the com.adobe.mobile.Config class, try File > Invalidate Caches / Restart… Worked for me.

Next, we want to instrument the onPause() and onResume() methods on all Activities so the library can see what users are doing in the app.

Right. That is all you need for a functional implementation. If you release like this, your friendly marketer will get all the lifecycle metrics like launches, upgrades, crashes, users, app states, location and poi (if she configured it), devices and app store reports (if she configured it).

She can even do some retention analysis with cohorts based on first launch.

Essentially, everything that the mobile product manager would like to see is there now. This is comparable but a bit further up the “this is useful” scale as the vary basic tracking I wrote about in Basic Tracking. What I’m trying to say is: we probably need more.

Why?

I guess the big question is: why did you build the app in the first place?

And based on the answer: what metrics do we need that can tell us if it does its job?

Your app might allow people to buy something. You will absolutely want to track that! Or your app has a button where users can share things. Track that as well!

The general concept is the same as on the web. You identify actions and track them. With the Mobile SDKs, you use Context Data “Variables” to do that. Success Events, props and eVars do no longer work. Remember the article on Apps vs Pages? most of it still stands.

Context Data

Let’s go back to what data can be tracked and how you can send it using Context Data.

I’d argue that there are three kinds of data that you would want to send into Adobe Analytics, mobile or not:

1. Dimensions — data that allows you to segment or break down. Examples of this could be: device, language, geo location, age group, level of engagement (aha? we’ll get back to that), some visitor ID, or maybe app version.
2. Events — things that happen and should be counted. Those will later show up as metrics in the reports. You would send an event when a user does something important, like share something, download something, buy something, anything that means they have been active and that aligns with the goals of your app.
3. Counters — data that increases some kind of engagement measure. I’ll point you to Ben Gaines’ timeless article Visitor Scoring which explains why and how you use “Counter eVars“. They are great!

In order to demonstrate all three of the above, I will add three buttons to my nonsensical app. I will display a question above those and the user can then tap one of the buttons as an answer.

Yes, I am contradicting myself. This app has no purpose at all, agreed. You’ll have to imagine those buttons do something important, say allow people to write a comment, share a comment and rate a comment.

Now that I have those buttons, I want to track them. In my case, I am going to:

• track the fact that a button has been tapped as an event “Button Tapped”,
• record which button has been tapped into a dimension called “Button ID”, and
• assign scores to the buttons based on how confident I think the user is. This will go into a counter eVar later called “User Confidence Index”

This is what the code looks like:

Note how I have put the data into a Context Data HashMap?

The “button_id” carries which button has been tapped and will later become a dimension. The “confidence_index” is set to some increase based on the button. This will later go into a counter eVar. And the action is always carried in “button_tapped”. This will later be the event. Naming the field and value identical is the common pattern for Context Data that is destined to become an event.

If you have read this blog, and specifically the article about Context Data & Processing Rules, you know that while your part is done now, your friendly marketer has to update the Processing Rules in order to actually track the data that you send in.

The buttons I built and the code that handle them are just simple examples. I hope your app has more functionality than that and I sincerely hope someone has a good understanding of how to track all that stuff.

You will have to add similar tracking code to any parts of the app that are considered important. That includes buttons but also activities. On some of them you might want to share more than just the lifecycle metrics! Use a cdata HashMap and pass it along where needed. Your friendly marketer and Processing Rules will do the rest.

Mobile App Acquisition

This post is getting long, but there is one more thing I need to explain: Mobile App Acquisitions, the mobile way to do Campaign Tracking. This is very important to your marketer!

Just as with other Campaigns, your friendly marketer will place tracking codes on any links she places that point to your app on Google Play (or the App Store). Those tracking codes will be passed through, and if you track them, she can not only see clicks on her links but also installs, first launches, launches, upgrades and all the other metrics she gets.

You will need to do three things for that to work:

1. create a BroadcastReceiver that captures the tracking codes,
2. add it to the AndroidManifest.xml file with an INSTALL_REFERRER intent filter, and
3. make sure your ADBMobileConfig.json file contains acquisition settings (it should if you downloaded it as I explained yesterday).

Here’s what it looks like for my project:

That’s it for today. The next article is about debugging all of this, and I’m pretty sure by now you actually need that, don’t you?