Getting started with Adobe Analytics mobile application tracking & (Android) tagging

 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:
Quick shortcut to coding with Android: (we started with Android)
Link to Jan’s posts: (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: 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

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(“”, “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.)

application mapping data 2

application mapping data 1

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:

 HashMap cdata = new HashMap<String, Object>();
cdata.put(“ “, “registration”);
cdata.put(“formsubmission”, “1”);
Analytics.trackAction(“formsubmission”, cdata); 

 HashMap cdata = new HashMap<String, Object>();
cdata.put(“ “, “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

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

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(“ “, “<nameOfTheScreen>”);  etc.

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

That way I could map the context data “” 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

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. 😉

About Antti

Digital Analytics Manager specialized in Adobe Analytics, Online personalization, SEO, CRO...

15 thoughts on “Getting started with Adobe Analytics mobile application tracking & (Android) tagging

  1. Hi Antti,

    The visitor identification on mobile devices works with a random visitor ID that is generated when the app is first installed. The visitor ID is stored with the app data, which means it is deleted when the app is uninstalled, but it does survive updates.


    1. Thanks Jan for the comment (and again big thanks for sharing Adobe Analytics related tips and trick on your great blog).
      Could you be more accurate on your comment and explain that as you would tell to your kids about it… 😉 I mean, what do you mean by “random visitor ID”? Is it a different than AppID that is generated from the first launch? Or that is the same thing, at least AppID works in the same way.
      Whatever your answer is, everyone should remember that if one person uses the application with two different devices then Adobe Analytics shows 2 unique visitors, right? So the only 100% sure solution to count unique users would be to save userID generated BY THE APPLICATION itself (and not Adobe) to an custom variable eVar (and of course there must be login before usage), right?

      1. Hi Antti,

        I am not sure what the exact algorithm is the SDK uses, but I know that the visitor ID looks more like the one in an s_vi cookie and not like the app ID (which is essentially the name of the app plus a version (“myapp 1.1”)).

        You are right: the same app used by the same user on two devices (iPad + Nexus 5 in my case) would be counted as 2 users.

        And you’re also right: if your app can generate a user ID (make it an anonymous one!), possibly after login, you can use that as the visitor ID and you will then see me as a single user regardless how many devices I use.

        Keep in mind that this messes with the lifecycle data, though! “First Launches” will definitely be sent before you can id the user, and I suspect other things, too.

        1. Thanks for clarifying that. So the actual algorithm for generating visitor IDs isn’t public and don’t need to. Yes, we should debug the app and see what data it sends on s_vi etc.

          Great comment about the lifecycle data. I’m also little sceptical for trying to change Adobe’s default way to count uniques so it goes how it goes (IMHO), and if possible (login exists) then we could save (random) userID by the app itself. That could be just a good way to do problem solving if needed for certain ID and way to double-check are there big differences in uniques by Adobe vs userID by the app (in eVar).

          Want to say that there isn’t any problems with these, just trying to understand the logic behind unique visitor counting. 🙂 And at the end of the day, the real KPI could be active users in week/monthly so the unique visitor isn’t the real thing to follow, I guess.

          Btw, I was little confusing… by AppID I meant deviceID that would be unique for the device, if that kind of info even exists, have to study more…

  2. Finally a useful page with code examples! We are using the Adobe Mobile Services PhoneGap plug-in. I suppose in our case we should be able to just pass an object with name/value pairs since there is no “HashMap” in JavaScript. I guess my only question is will using “evar2” or “prop2” in the cdata work? Our implementation guide uses these variables along with custom events.

    Is this correct for PageView tracking?
    window.ADB.trackState(“stateName”, {

    Event tracking?
    window.ADB.trackAction(“customEventName”, {

    1. Thanks AJ for your feedback, great to hear. 🙂

      I’m not familiar with PhoneGap plug-in. But to me the code looks ok, however, you should just test it and see what goes through. In normal Android we just use context data and the code itself shouldn’t contain any default (prop,eVar) adobe variables and in the mobile settings (in adobe mobile services) we map the context data with eVars and props, but I guess this might be different with PhoneGap? Like I said, I had to do some test hits before understanding the “whole picture” how the hits are sent in Android. Have you already gone this through:

      Eventually someone from Adobe should be able to help you if you send email to clientcare if you run out of ideas. Good luck with the implementation process.

  3. Hi Antti,

    thansk for the useful info about Adobe Mobile App Analytics implementation.

    i do also like your idea of the “full path” data, including states and actions all together.

    if i implement as you described above, i would probably only see the full path data in the way of breaking down the states or actions data by eVar or Prop mapped by the context data “” isn’t it?

    how would we see such data you described like
    StateHomepage -> ActionLoggedin -> StateFiles -> ActionUploadphoto 23% of users, etc.
    in the report?

    i would appreciate your feedback!

    1. Hi Sonny, nice to hear you like my post.

      Not sure did I understood your first comment about breaking down the state etc. However, if you eventually just want to understand how to get to see report for user’s full path then I can try to give more detailed answer.

      So every hit user makes on your mobile app needs to be send to Adobe and as we know there can be 2 kinds of hits; states and actions.

      In actions:
      cdata.put(“ “, “”); etc.

      In states:
      cdata.put(“ “, “”); etc.

      The key is to use same naming on both states and action hits, my example above uses context data named “pathstateaction”, but you can use any name you want to.
      This way every hit contains data for that context variable.

      Then we go to admin setting in Adobe Mobile Services and we can map that context variable to prop. This way that prop always contains all values that are stored in “pathstateaction” context variable and now that prop contains all hits and we can see the so called full path.

      Hmm…maybe you already knew that based on my blog post, but wanted anyway go that through once more. So I guess you are wondering where you can open that full path report directly and without making some kind of breakdown… Well, that is a good question and I can’t answer directly. Have to login to mobile services and let’s see what I can accomplish. =)

      There are “view paths” and “action paths” that we could see directly, but where could we see this prop / full path report.

      I haven’t analyzed mobile data for few months so have to investigate this one too. Well, looks like there isn’t direct report available for props, but you can go to “Funnel” -> in “funnel steps” dropdown choose that prop and then you can choose different actions and states and build your own funnel. This way you can see both actions and states in the same path report. Yes, this takes some manual work, but this is the best way I know. Please comment if you find some kind of pathing for props where you would automatically get all the top paths just like in out of the box “view paths” and “action paths” reports.

      And as you said, you can breakdown/filter with this prop data on almost all reports, but I guess that funnel report is the best way to go, even though you need to manually select all the hits you want to see.

      Anyway, did you got the answer you were looking for? 🙂

      1. Hi Antti,

        thank for the prompt reply and explanations.

        now i understand your idea. Surely we can have all user actions and states in one prop or eVar by mapping map the context data “” to the SAME prop or eVar.

        However, i think the data in such prop or eVar wouldn’t store the action/states data sequentially, but the total number of instances for particular actions and states, would it? Not like what we would like to see, StateHomepage -> ActionLoggedin -> StateFiles -> ActionUploadphoto 23% of users, but StateHomepage 100, ActionLoggedin 50 and so on.

        By the way, the funnel would help see the sequential full path data. But it wouldn’t also help identify the full path of users going through as it’s based on the pre-defined path by us to see as a funnel.

        Also if the funnel report is the best way to see the full path, wouldn’t we need one dedicated prop/eVar as we can simply choose the relevant actions or states directly in the funnel configuration, which are already available?

        do i again misunderstand your idea? How do you think?

        1. Yes, good to hear that we are on the same page regarding this ”save all hits to same variable” situation. 🙂

          I have to clarify that we can’t see percentages like “23% of users” etc. This was stupid example from me and in mobile analytics interface (in funnel reports) we can only see raw numbers as: Homepage 13,000 -> Product page 9,000 and so on.

          Ah, you are also talking about eVar variable. I should have make more clear that you would need to use only prop variable and in the admin section of Adobe you would need to enable pathing report for that prop, and this way you should get the data in sequential order. So this works only with prop and pathing enabled. Makes sense? (if anyone from Adobe is reading this, then please comment if I have understood something wrong, but pretty sure I’m correct on this one)

          And just realized that you can also look mobile data through normal Adobe Analytics interface and there you can go open all kinds of cool path reports for this prop and you get even percentages etc. Boom! Case solved? 🙂 Now all makes sense, or did you have other questions? Not sure did I understood your question:

          “Also if the funnel report is the best way to see the full path, wouldn’t we need one dedicated prop/eVar as we can simply choose the relevant actions or states directly in the funnel configuration, which are already available?”

          Yes, we would need that pathing enabled prop where all the hits are included and then we could manually choose whatever we want to our own funnel.

          Ps. PLAN B: It could be bit confusing to send all hits as states, but anyway it is possible and that way you would see all hits in the states funnel too and get full paths without extra prop. =) I’m assumming that the default states path in mobile analytics is in sequential order…

          1. thanks again for the reply.

            now, i understand what you meant by the full path, using the one common prop for states and actions. it makes sense!

          2. Ok, great to hear that we figured out this one 🙂

            Ps. Subscribe to my blog, I tend to write quite seldom, but when I do it is pure magic… (yeah right) 🙂

  4. Hi Antti,

    Thanks for the descriptive article on Adobe Analytics integration. I do feel that the code examples shared by Adobe are not very comprehensive and talk very little about the custom variables and props.

    However, your blogs seems to cover most of the points very well, and I wish if Adobe can similar examples as it would the lives of developers much easier.

    Currently, I am develop an iOS app and integrating the iOS SDK of Adobe Analytics into it. Now, setting the context dictionary (hash map in android) can I simply pass the propName: Value. e.g. prop6: “John”, though Adobe documentation recommends to pass the Context Data key e.g., but I am wondering if I can achieve the same using the prop name directly instead of passing the context data key.

    Also, due to some unknown reasons I cannot seem to configure the Context Data field in Manage Variables and Metrics section of Adobe Mobile services dashboard. Currently Context Data field (and all other fields like friendly name) are disabled and I am not able to make any changes into it. Due to this restriction, I was thinking of passing the prop name in the context dictionary instead of its context data key.

    Kindly share your thoughts on this.

    1. Thanks Sandeep for the comments and glad to hear my posts are helpful. Adobe has improved lot of their help sections etc, but of course real life examples are much needed too.

      Adobe documentation recommends? Oh, ok. At least I learned from the hard way that you CAN’T implement props and eVars directly in the code, it just does not work. Not sure is the situation anymore like that, but could be. Here is the highlight of my post:

      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.

      If you are able to access mobile settings, then I would assume you could edit variables. But I guess you should check is you username in the “mobile app admin” group? If you are and not able to edit then it is a bug or some other reason… and you have to contact ClientCare and ask help.

      Hopefully you are able to figure out all the things you need. I really love the mobile reporting in Adobe, but of course implementation process (at least the first time) can be little tricky. Just test different codes and settings and usually you can figure out pretty much anything… 🙂 But ask anything if you still need help.

Leave a Reply to Antti Koski Cancel reply

Your email address will not be published. Required fields are marked *