Hi guys,
The business team wants to be able to use the flow visualization for our mobile app (low code system), however, we do not have "pagenames" set up there.
We are now testing to implement trackstate to get this done.
The dev already did a sample setup in the app code and I now need to test it out on adobe. Do I have to do like the trackaction and set it up as a processing rule and events on the report suite?
If so, is there any documentation explaining how?
thanks in advance
PS: our set up was done with mobile services site and since its end-of-life our settings automatically migrated to processing rules. Because we use low code for the app, I was informed by the devs team that our SDK setup is not the same as a native app. So far we have not used launch for our app life cycle, just used it to set up extensions with adobe campaign.
Solved! Go to Solution.
Views
Replies
Total Likes
For pagename alone, it requires no processing rule.
The first parameter of the trackState() function is the pagename will be populated to "Page" dimension, https://aep-sdks.gitbook.io/docs/getting-started/initialize-the-sdk#track-app-states-and-screens-for....
Anything goes to the second parameter of trackState() and both the first and second parameters for trackAction() require processing rule.
Yes, mobile apps require you to use processing rules.. unless you are using the most basic tracking where you are only passing items to your tracking that you can have in the tracking call (pageName, events, channel, etc)
Everything else should be passed a context variables and mapped using processing rules.
trackState are page views
trackActions are actions (clicks, other trigger items, etc)
Both can pass context variables...
How you set this up is really up to you, there are many ways to do this... you could have your developers set the final values for each prop/eVar and create context variables for each that you can just create a one to one mapping for...
Other implementation strategies build out context variables like contextual data layers (alias, id, category, etc) and use those to concatenate in processing rules to build out the props and eVars...
There is no "right way" to do this, it comes down to preference, and if you can ensure your developers can set the values and formats of those values as you need them (cause if they don't, there's not a lot of options for modifying after the fact)....
I use the second model... I can look at individual values and put them together... IF a value is missing I can compensate by overwriting the missing value using rules based on the values that are provided. And because processing rules follow a specific order, I can do those compensations before the dimension value is built.
But this is also more work, so it really comes down to how comfortable you feel with processing rules to cover your needs.
For pagename alone, it requires no processing rule.
The first parameter of the trackState() function is the pagename will be populated to "Page" dimension, https://aep-sdks.gitbook.io/docs/getting-started/initialize-the-sdk#track-app-states-and-screens-for....
Anything goes to the second parameter of trackState() and both the first and second parameters for trackAction() require processing rule.
Thank you!
I wasn´t sure I needed to setup any rules, etc to see it.
We just did a test and can see the pagename in the "page" dimension and also in the "screen name" one..
Just an extra question now, is it possible to see what actions were done on specific pages?
eg. this is our test, with a dummy app page.. this page has some buttons we are tracking with trackaction.. would be nice to know that in page x, those y buttons are being clicked the most, etc.. The reason to filter that by page is that we have the same buttons on different pages sometimes.. so it is interesting to know which of the pages this button is getting the most hits from.
Views
Replies
Total Likes
If you want to know the page for Actions, you will need to configure a custom prop or eVar (I suggest eVar as the length is greater - 100 characters vs 255 characters) that duplicates your pageName value. (if using an eVar, make sure it is set to Hit level expiry)
I would set this eVar (or prop) on ALL page views and actions, for web and app. This will allow you to have the same action to page correlation everywhere, if you use the eVar when you have long page names (greater than 100 characters) it won't be truncated, and is just a standard recommendation that you will see in most implementation recommendations.
You cannot set pageName on Actions (well you can with processing rules, but you shouldn't)... IF you do this, your actions will also start counting as page views, which is not the intended result.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies