See Trackactions made in each screen - mobile app

[fern1]

Hi!
I asked our dev team to implement trackAction and TrackState for our app so we can have page names for each screen and see the actions done. It is working and I can get the data for them individually (see the screen names instances and Actions/Custom links instance results).

However, I've been trying to see the actions that happened on some specific screens but got 0 results. Is it possible to do that?
Ex:

I also tried the opposite, making a list of the actions and breaking an action down by the screen name (the same action can happen on different pages on our app, so I would like to know which page this action is working the best).. but the same happen.

Is there a way for me to know app actions that happen on a single screen?

[Jennifer_Dungan]

Hi, 

So trackState is a page view event, and trackAction is a click or an interaction event.. the two don't correlate with one another, and if you are firing both for every screen loaded you are using up 2 server calls each time.

If you want to know the page name on your actions, it's best to create a context variable like "site.pageName", then map that context variable to a prop or evar which is tracked on both page views and actions.

So for instance, lets say you have an app using the following flow:

1. User Opens App (lands on the home page)

2. User Clicks on a Link to go to Page 2 (you don't probably want an action at this time... just the page view on Page 2)

3. Use Clicks on an interaction item on Page 2 (you want to track a trackAction here)

So 

you would set up a context variable site.pageName

1. on the home page, with your trackState call, you would also pass this context variable

additionalContextData.put("site.pageName", "homePage");
MobileCore.trackState("homePage", additionalContextData);

2. On page 2, you would do the same trackState (except both the standard pageName value and your custom value would change to "page 2" or whatever you want to call it

3. When the user interacts with the element you want to track

additionalContextData.put("site.pageName", "page 2");
MobileCore.trackAction("Interaction Clicked", additionalContextData);

Important Note: do not map your site.pageName value to Page Name using processing rules (this will make all your actions also count as page views which will inflate your page views)

A lot of Adobe clients already use this eVar Page Name concept on their web pages, since the default Page Name is not available on Custom Links, and the default Page Name is limited to 100 characters, whereas if you use a Hit Level eVar, you can store 255 characters.

[Jennifer_Dungan]

To add some additional clarification:

trackState is the equivalent of the s.t() call on Web

trackAction is the equivalent of the s.tl() call on Web

When you track a click on your website, you don't track both s.t() and s.tl() - this will massively inflate your page views.

[fern1]

Hi Jenn!

Thank you for getting back to me as usual. 
I´m a super beginner here so bare with me some more and forgive me for any mistake I might say..

Just to contextualize you, when our app was first setup by a consulting company, they did that still using mobile services. and that's how they showed us how to do, as custom metrics. However, once they did the handout is when the mobile services end-of-life happened. So now all the actions that we previously insert there were now as processing rules and success events. Moving forward, we are still doing that for every new action we need to track in the app.

However, we later found out that we didn't have any screen name for our app as the trackstate was never mapped out. We use a low code system for our app, and the dev team had to create a plugin so we can use Adobe in the app. This also means that because our app is not native, the way SDK is inserted there and all the trackstate, actions, codes work a bit differently also. Now we do have screen names.

so now I'm afraid that we might be inflating pageviews. How can I make sure we are not?

[Jennifer_Dungan]

I hear you... Mobile Services was a lot easier to use than processing rules... 

I'm also guessing with what you are describing that you are not using AEP Assurance so that you can easily look at all your analytics calls and the subsequent post processed results. Are you using something like Charles or Fiddler to test your tracking? (sadly Android doesn't typically work with this method since the security settings prevent the proxy connection from working)

You really need to watch your tracking calls with high scrutiny to see what is happening.

If you can't watch the calls directly, is it possible to create a completely isolated Dev or QA suite, that you can replicate ALL the processing rules and connect a copy of the app to...  this would allow you to test in isolation... keeping track of every page and action you test, then checking the data an hour or so later.... It's not an ideal testing scenario... but it may be your only option....