Disclaimer: I take no responsibility if my tips and tricks aren’t working. Do your own conclusions and test everything yourself before going live with these code examples and tips. Please also note, this is not a step by step guide (links to better resources included) – just random tips and learnings about Adobe Analytics mobile application tracking for application newbies as me. UPDATE: MY CODE EXAMPLES ARE FOR ANDROID VERSION! 

 

I have done few tagging maps (=instructions for the coder how to implement analytics tags) for mobile applications too, but that was few years ago. Our company is making a new mobile application and that’s why few weeks ago I got the opportunity again to start learn how to make Adobe Analytics tags for mobile application tracking. Fortunately we have experienced coder who finally makes the implementations, but I need to understand how the tagging process goes and with tagging map I need to explain in very detailed way what we need to code etc. I’m the analyst and coder is “just” a coder who doesn’t (necessary) need to understand what we want to measure eventually.

I have done hundreds of tagging maps, but I was sure that it was different game with mobile apps – Oh boy, I was painfully right. That was the reason why I decided to make this blog post – so called newbie’s getting started guide for Adobe’s application tracking & tagging. If you are starting your tagging process and usage of the Adobe’s mobile services then hopefully my tips will save you some time and that’s is the purpose of this post.

Dude, read the manuals!

It’s good to be agile and very often the quickest way to learn is to just get your hands dirty with the code and settings. However, if you are faced with a totally new thing, it might be good to read the manuals with enough time. Don’t just scan the text and think you are the master of mobile tracking. I made that mistake, and now lesson learned. If you read Adobe’s own guides with enough time, and read also amazing blog post series by Jan Exner about mobile tracking then you should get started even without my blog post. If I had read those more carefully, I would have saved few grey hairs.

Adobe’s official help section links: https://marketing.adobe.com/resources/help/en_US/mobile/home.html
Quick shortcut to coding with Android: http://microsite.omniture.com/t2/help/en_US/mobile/android/methods.html (we started with Android)
Link to Jan’s posts: http://webanalyticsfordevelopers.com/2014/08/05/analysing-mobile-apps-overview/ (total 5 different posts)

However, if you are just starting your journey with Adobe Mobile Services then continue reading my blog post. I have also added some good and simply code examples about tagging custom variables, because at least to me all the examples in Adobe’s or Jan’s post weren’t maybe so easy to understand. Of course, I encourage all visitors to share your own tips and please comment if I have understood something wrong. So with some shame I’ll want to share my favorite mistakes and learnings.

Adobe Mobile Services, where are you?

Adobe Marketing Cloud should offer us one place to login and access to all tools. If I want to make new report suite for mobile application, should I add a normal report suite from the admin section or what? That’s not necessary. Finally I found the right url where to start: https://mobilemarketing.adobe.com/ Although, still bit confused, why mobile services aren’t inside Marketing Cloud? Anyway, this was the place to be.

Update: Adobe fixed this issue on August (?) release and added link to “mobile services” at the main menu of Marketing Cloud.

This looks pretty awesome that Adobe Analytics has invested so much to application tracking that they have done totally new interface just for application analytics. There is a bit new logic how you can analyze data, but it looks pretty straightforward and Adobe’s help section comes handy when learning how to use sticky filters and how to correlate or segment the data. Maybe in the future I’ll do another blog post about analyzing application data, but for now, let’s focus how to get tracking going on etc.

Mobile suite, SDK files, basic calls and default metrics

Wow, Adobe has made this so easy for us. Absolutely fantastic. No tips for this one. It was super easy to make the new mobile report suite and all the setting were quite straightforward. Got all the SDK files, config file etc and sent those directly to our coder with some tips from Adobe and he got the codes/SDK’s up and running in a heartbeat.

Quick shortcut to Jan’s post – how to make the mobile suite http://webanalyticsfordevelopers.com/2014/08/06/analysing-mobile-apps-prerequisites

Sending custom data – forget about Dre, props, eVars and events

Sorry, you can still listen Dr. Dre or whatever gets you going on. 😉 Adobe’s tips to tracking custom variables weren’t so easy to understand – at least to person as me who isn’t hardcode coder. After understanding the logic behind the context data, all Adobe’s examples opened to me also, but not at the first look. And yes, like I said before, I was stupid and not reading the guides with enough time and focus. So not blaming Adobe only, but Adobe please remember that it would be very useful to give users full code examples with detailed comments and not just give one line code examples (out of the context).

We noticed that there were instructions to use context data etc, but somehow we ignored them and jumped right to the basic stuff as how can we make a pageview aka screen view hit or custom link (actions) to Analytics. This is easy with these calls:

 Analytics.trackState(“<nameOfTheScreen>”, null);  (for screen views)
 Analytics.trackState(“loginScreen”, null);  (real example)

 Analytics.trackAction(“<nameOfTheAction>”, null);  (for actions)
 Analytics.trackAction(“formSubmission”, null);  (real example)

But what if we want to send information with custom variables? Could it be something like this Analytics.trackState(“eVar2”, something); No, no and no. Wish there would have been better example codes with custom variables, but there wasn’t. After couple of hours of frustration we figured out that of course, just as in website we send custom variables aka additional data always TOGETHER with pageview or custom link. So, we found the answer and tested it and works great, all good. One of our example:

 HashMap cdata = new HashMap<String, Object>();
cdata.put(“UserID”, “122121212121212121”);
cdata.put(“UserGender”, “male”);
cdata.put(“UserAge”, “18”);
Analytics.trackState(“Homepage”, cdata); 

That was just a stupid, but working example of how ro send custom data with trackState call.

Adobe says “we recommend grouping your context data variables using “namespaces”, as it helps you keep logical ordering.” For example “product.type”:”hat”. So our code example would be better like this:

 HashMap cdata = new HashMap<String, Object>();
cdata.put(“user.id”, “122121212121212121”);
cdata.put(“user.gender”, “male”);
cdata.put(“user.age”, “18”);
Analytics.trackState(“Homepage”, cdata); 

Maybe it would be even better to use “_” and not “.” in the context data names, but however you or coder likes.

So the biggest thing to remember is that in version 4 (SDK), you can no longer assign those types (prop, eVar, events) of variables directly in your app. Instead, the SDK uses context data and processing rules to map your app data to Analytics variables for reporting. -> Yes, we are forced to use context data which just fine and actually much easier for the coding because we can do the mapping later from the admin panel.

• You can change your data mapping without submitting an update to the App Store.
• You can use meaningful names for data instead of setting variables that are specific to a report suite.
• There is little impact to sending in extra data. These values won’t appear in reports until they are mapped using processing rules.

About the mapping

Login to Adobe’s mobile services and in “manage app settings” go to “manage variables and metrics”, there you can do the mapping for the contex data you have coded to the application. Please note, you can’t see the data before sending test hits or getting live data. Only the “out of the box” variables by Adobe are visible by default.

Now you can look by the name of the context data. If you name your context data with good logic you see for example all the data related to “user” and then it is easy to choose the right variable. And field on the left you decide what you want to call the variable eventually inside analytics (stats). (These pictures are from earlier examples where the name of the context data were really “userage”, and not “user.age”. Wanted to make that clear, so you don’t get confused.)

At the end you could do the mapping like that. You get the idea?

Ps. Just reliazed that maybe it would also wise to give the friendly name with same logic and always start by “user”: “user age”, “user gender”… and that way it would be easier to see all the variables related to users when you choose variables in the dropdown menu inside Adobe Analytics.

How about events

 cdata.put(“formsubmission”, “1”); 

is the right format and I prefer that style, although, I believe this should also work just fine
 cdata.put(“formsubmission”, “formsubmission”); 

I like more of the first example, because that way you surely remember (even looking the code itself) that it is going to be an numeric event and not any other custom variable.

Yes, again you have to do the mapping for events too through the settings in Adobe’s mobile services. Not sure are admins only allowed to do the mapping, I guess or at least you need some kind of rights to access the mapping section.

Why to use events, if we could just easily make action call and that way we could get data from different action:

 Analytics.trackAction(“formsubmission”, cdata); 

 

If we add context data with “event style”, we can correlate data much more or at least much easier. The real benefit comes when we need to add many events to the same data on the same page (e.g. last touch channel with different events). You couldn’t do this with only actions. This is basic stuff that you are probably already familiar by tagging normal websites.

We want more, we want more…. code examples!

Of course we probably have many different forms and to get form submissions by different forms we should code something like this:

REGISTRATION FORM SUBMITTED:
 HashMap cdata = new HashMap<String, Object>();
cdata.put(“form.name “, “registration”);
cdata.put(“formsubmission”, “1”);
Analytics.trackAction(“formsubmission”, cdata); 

FEEDBACK FORM SUBMITTED:
 HashMap cdata = new HashMap<String, Object>();
cdata.put(“form.name “, “feedback”);
cdata.put(“formsubmission”, “1”);
Analytics.trackAction(“formsubmission”, cdata); 

 First row starts the mapping of the context data. Yes, start always that way.
Second row is for form name and the unique form name that I have wanted is “feedback”.
-> After the first hit you can map this data in Adobe Analytics.
Third row is for numeric event that is called “formsubmission”.
-> After the first hit you can map this data in Adobe Analytics.
Fourth row is the actual call/hit that sends the data to Adobe Analytics and this is always “trackAction” for actions or “trackStates” for different screen views.

Note: You have to start sending context data before you can do the mapping for custom variables.

States vs Actions, and how about full path reporting?

We should always use ”state” call for different screen views and “action” call for actions. However, it would be good idea to always send one unique variable where we could save always the name of the state or action call and that way we can get really full path reporting what users have done in the right order.

Out of the box there is path reporting for both states and actions. So we can get user paths:
State1 -> state 2 -> state3 10% of users
State1 -> state 2 -> state1 -> stateX 20% of users
StateX -> stateY -> stateX 5% of users
Etc.

Out of the box we also get so called action paths.
ActionFormSubmission -> ActionOpenCamera -> ActionUploadPhoto XX% of users
ActionOpenCamera -> ActionUploadPhoto -> ActionFacebookSharing XX% of users
Etc.

And here comes my idea: I would like to get “full paths” of the users including both screen views (states) and actions.
StateHomepage -> ActionLoggedin -> StateFiles -> ActionUploadphoto  23% of users, etc.
This kind of pathing report could be sometimes useful, but by default we can’t get this kind of data, so EVERY TIME (!) we make states or action calls we should add one variable/context data to that hit:

In actions:
 cdata.put(“ActionOrState.name “, “<nameOfTheScreen>”);  etc.

In states:
 cdata.put(“ActionOrState.name “, “<nameOfTheAction>”);  etc.

That way I could map the context data “ActionOrState.name” to SAME prop or eVar variable and that way I could make these “full paths” how user flows on mobile application.

How to count unique users

The appID is captured in the lifecycle calls automatically. However, depending on the business case, you can store the appID in custom variable (eVar) as well. I believe this is enough in most cases, but it’s not perfect because one user could use multiple devices.

If your application can be used only with login, then you could save the unique userID by the application to Adobe Analytics (eVar) as well and that way you could get more reliable count of unique visitors. Remember to save userID with some random numeric value and not use identifiable data as email address or something like that. Remember also do the necessary adjustments for the terms of use. I also have to study bit more what kind of restrictions there are to application tracking with user and location information etc. These can also vary by countries etc.

I’m still waiting answer from Adobe’s mobile experts about the question that is there default userID by Adobe or do they only use appID and other resources to count unique visitors. They said already that this new ID system isn’t working in mobile applications http://microsite.omniture.com/t2/help/en_US/mcvid/mcvid_customer_ids.html

Too much information?

Hopefully you can understand my tips and tricks. Please, ask more help if needed. I’m sure that in Adobe’s help forums you get much more help from experienced coders but I’ll try to help if possible. Anyway, this was good training for me too, because I usually understand and learn new things much better when I write the code myself.

And now I’ll start to do the tagging map for the application. Wish me luck. Noh, don’t need it… I’m now master of application tracking. 😉