SOLVED
Mapping eVar to mobile 'trackAction' ContextData variable via Analytics Processing Rules...but with no access to Mobile SDK
1 Accepted Solution
Correct answer by
Ok, going to go through this piece by piece... it's strange that a.action isn't available to you... there should be based on that code...
What about plain old "actionname"? a.action and actionname are both set for us (maybe it's a difference in code bases? We use React Native)
Do you happen to know what your apps are coded with, I don't see any samples in the Adobe SDK documentation that look exactly like that... perhaps this is some sort of custom extension code that your developers are using, and there is a global function that connects with this...
Looking at your processing rule start... you are looking specifically for a context variable with a value of "log_addToWallet_pressed" but right now, that doesn't look like it should be a context variable... (again, unless this code is a custom
extension that is actually setting that as a value.... )
Context Data should be key/value pairs, something like:
var contextData = new Dictionary<string, string>();
contextData.Add("key", "value");
contextData.Add("key2", "value2");
contextData.Add("key3", "value3");
ACPCore.TrackAction("action name", contextData);
This should result in your a.action / actionname being set to "action name" and on that same call, three context variables are sent (key, key2 and key3) and the values of those keys are the values... etc.
It might actually help to see what the actual analytics call looks like.
For instance, in my raw analytics call, I see something like:
"payload": {
"ACPExtensionEventUniqueIdentifier": "...",
"ACPExtensionEventNumber": 66,
"ACPExtensionEventData": {
"contextdata": {
"site.Context1": "value1",
"site.Context2": "value2",
"site.Context3": "value3"
},
"action": "some action"
},
...
So I can actually see the separation between the action name and context variables. By seeing the raw data, it does help understand how to build your rules.
So back to your specific question around your rule... IF you do have a context variable called "addToWallet" and the value is "log_addToWallet_pressed" then it should work... but just be sure that this context variable and value is only set on actual actions...
Basically think of the conditions as simple identification that will trigger the corresponding actions...
Now the Actions or "Then do the following"
This is where you want to set your dimensions and events that correspond to the identified action.
So I'm going to come up with some really silly examples here... but let's say when "log_addToWallet_pressed" happens (assuming this is only set when that button is pressed), you want to trigger event1, event2, and set eVar1 to "yay money" and prop1 to "wallet"
This is assuming you are setting everything directly...
Normally you would also map context variables into your dimensions.. or even add additional Action level conditions (only ONE condition can be added in this context); such as:
With Mobile Apps you don't use Data Elements... Web and App Launch Properties are so different, you don't structure them remotely the same.
In a web property, you create a Data Element.. and that uses Javascript to get some value (either pull it from a value on the page, or pull from a cookie, or you have some custom JS code that you set, etc...) then you have a tracking rule where you add the Data Element to your direct eVar or prop, etc..
You don't do this on Mobile Apps... the context data is set in the app, and you use processing rules to set them to your eVars and props after Adobe receives the call; or you can set specific values (without a context variable) based on specific mappings like I showed above with "Custom Value"
The control you have in a Mobile App Property is a fraction of the functionality that you have in a Web property.
Yes, there are "Data Elements" in a Mobile App Property... but what you can do with them is severely limited.. the only thing I managed to do was concatenate some context variables.. which I can do in Processing Rules.. but since I had no "condition" logic in Launch for this, I ultimately gave up trying to use it....
I suppose if you wanted to set a hard-coded prop or eVar such with a value of "mobile app" (to distinguish all mobile app calls from web calls, I supposed you could.. but you might was well do that will processing rules and keep everything in one place....)
The main point is.. there are web specific extensions.. there are mobile app specific extensions.. you can not mix them in one Launch Property... and how you tag a site vs an app (technology wise) is completely different...
What you can keep the same is the suite (pass web and app data into the same suite), and you can control the values, naming syntax, events that fire per action, etc consistent....
As I mentioned in my first post, since I am also using a "Global Suite" that contains web and app traffic into one suite; I use the a.appid condition to ensure that my web traffic goes to Adobe as it was set in launch (no processing)... only my apps should be running the processing rules (with the exception of a few old sites that are not going through Launch that have some issues - I use some processing rules to fix those until the site itself can be fixed).
I have multiple Launch Properties, I have one for my Core Websites that run React, I have another for the Core Sites that run on .net, I have properties for each of the white label "extended sites" that we use, then I have another one for Mobile Apps.
Keeping the code bases separate means that yes, I have to go and add rules or dimensions multiple times for each variant.. but it also means that I can keep the different code bases clean and separate from one another (which is worth it for me)
Hi, first, I am not really sure what you mean by "trackAction context variable".... trackAction is a function (the equivalent of s.tl() on the web)... the same way trackState is a function (the equivalent of s.t() on the web)... both of these functions attach context data for mapping to your dimensions....
When a trackAction is called, it looks something like this:
MobileCore.trackAction("loginClicked", additionalContextData);
"loginClicked" is the equivalent of "custom link name" in your s.tl() call
s.tl(this,"o","loginClicked");
The additionalContextData is basically dimension values passed as context, that you then map using processing rules.
For instance, in my implementation, I would set up a rule for the above as:
The first "a.appid is set" is just a little protection to ensure this rule is ONLY run for my mobile app (and not my website) - this is something that is set by native apps... (if you have a value in "App ID" in your reporting suite for your mobile app hits, that means it's being set).
The second condition checks for the action (or "click name"), in this case "loginClicked"
Now that I have my conditions, I then set the rules I want to run.. this is where I would map the data sent in the additionalContextData into my props and eVars, and depending on my rules, I can set events here too.
The "Action Name" will be automatically set by Adobe (sadly it will look like this in your reports: "AMACTION: loginClicked" - you cannot get rid of AMACTION:)
You can set eVars through hard-coding if you don't have a context variable... as in for the "loginClicked" action, set eVar1 to "Sample Value".. or if you are being sent some context variables you can map those.
However, you really need to separate out your Launch properties... one for web, one for mobile app (they can send to the same global tracking suite) but you cannot install the proper mobile app extensions in the Web Property. Even when tracking to a global suite, and significant code or infrastructure differences should have it's own property... or you will drive yourself crazy trying to make it all work... and since Mobile Apps require completely different integration you cannot mix those.....
For your website, you don't need to use processing rules to set the values... leave all that work for Mobile Apps.... if you try to do everything in processing rules you will seriously hurt your ability to test your website.... at least for Mobile App there is an extension called AEP Assurance (or Project Griffon) so that you can test the context data AND the post-processed data... that doesn't exist for web properties. Just make sure you know what values should be set to your dimensions, set them normally for web, then use processing rules to set them for your app.
Also, there really isn't a lot of control in the Mobile App Property, I pretty much use it exclusively to set the tracking suite and manage the extensions..... ALL tracking values I set in Processing Rules using Context Variables.
Our developers also work exclusively in SDK5 (and have for the past 2+ years)... I work closely with them to make sure that all my context data is set as needed so that I can make efficient processing rules; it might be worth making a friend on your dev team
@Jennifer_Dungan Thank you so much for your thoughtful reply! And I apologize for the initial confusion with the "trackAction context variable" reference (I actually meant to say "trackAction Context Data"). I was pretty sure that I was on the right track but there are still a couple of knowledge gaps I have which still need to be filled, so if you'll allow me to bounce a bit more off of you I'd really appreciate it.
The scenario we're working here is to capture the user clicks tied to a certain button function in a mobile app. Here's the actual code hook from the mobile developers that I'm looking to capture:
void _logAnalytic() {
locator<Analytics>() .trackAction('log_addToWallet_pressed');
}
My initial thought was to create a GENERAL trackAction Data Element that I could apply to an eVar and map to its associated Context Data function via Processing Rules, so that ANY 'trackAction' function could be pulled into Analytics. However, yesterday I discovered that no 'a.action(Context Data)' entry appears in the 'CONTEXT VARIABLES' section of the dropdown selection list in Processing Rules (I assume this means that the mobile team hasn't configured or activated it in the SDK5 controls, but that's just a blind guess).
At any rate, as of right now, the only thing that I have to work with in that list is the actual Action Name for the trackAction in question...
log_addToWallet_pressed
...which is already an available items of the "Action Name" Dimension in Analysis Workspace, although currently it's showing zero instances, hense, the need to make this tie-in through Processing Rules. But instead of creating an all-encompassing 'trackAction' Dimension, I'll have to settle for one to satisfy the specific need with "log_addToWallet_pressed.":
So, with all that said, would it work to construct the Processing Rule entry like this?
...but if so, what would be the corresponding "Then do the following"? I have created a 'trackAction' eVar, but I'm not sure what to do with regard to the Data Element which would inform it. And I believe that's where the issue of lumping our Web and Mobile into a single Web launch property comes through to bite our collective behind, because in a Mobile Launch Property, the configuration of a MOBILE Data Element is easy (I know this because I have an instance of a Mobile Property in Launch but it's not connected to anything).
So, I would think the Data Element would have to be configured with Custom Code, but couldn't guess exactly what it should be.
Any other ideas? Documentation? I know I'm asking a lot but stuff like this has been a thorn in my side for a very long time.
Thanks again for your help!
Correct answer by
Ok, going to go through this piece by piece... it's strange that a.action isn't available to you... there should be based on that code...
What about plain old "actionname"? a.action and actionname are both set for us (maybe it's a difference in code bases? We use React Native)
Do you happen to know what your apps are coded with, I don't see any samples in the Adobe SDK documentation that look exactly like that... perhaps this is some sort of custom extension code that your developers are using, and there is a global function that connects with this...
Looking at your processing rule start... you are looking specifically for a context variable with a value of "log_addToWallet_pressed" but right now, that doesn't look like it should be a context variable... (again, unless this code is a custom
extension that is actually setting that as a value.... )
Context Data should be key/value pairs, something like:
var contextData = new Dictionary<string, string>();
contextData.Add("key", "value");
contextData.Add("key2", "value2");
contextData.Add("key3", "value3");
ACPCore.TrackAction("action name", contextData);
This should result in your a.action / actionname being set to "action name" and on that same call, three context variables are sent (key, key2 and key3) and the values of those keys are the values... etc.
It might actually help to see what the actual analytics call looks like.
For instance, in my raw analytics call, I see something like:
"payload": {
"ACPExtensionEventUniqueIdentifier": "...",
"ACPExtensionEventNumber": 66,
"ACPExtensionEventData": {
"contextdata": {
"site.Context1": "value1",
"site.Context2": "value2",
"site.Context3": "value3"
},
"action": "some action"
},
...
So I can actually see the separation between the action name and context variables. By seeing the raw data, it does help understand how to build your rules.
So back to your specific question around your rule... IF you do have a context variable called "addToWallet" and the value is "log_addToWallet_pressed" then it should work... but just be sure that this context variable and value is only set on actual actions...
Basically think of the conditions as simple identification that will trigger the corresponding actions...
Now the Actions or "Then do the following"
This is where you want to set your dimensions and events that correspond to the identified action.
So I'm going to come up with some really silly examples here... but let's say when "log_addToWallet_pressed" happens (assuming this is only set when that button is pressed), you want to trigger event1, event2, and set eVar1 to "yay money" and prop1 to "wallet"
This is assuming you are setting everything directly...
Normally you would also map context variables into your dimensions.. or even add additional Action level conditions (only ONE condition can be added in this context); such as:
With Mobile Apps you don't use Data Elements... Web and App Launch Properties are so different, you don't structure them remotely the same.
In a web property, you create a Data Element.. and that uses Javascript to get some value (either pull it from a value on the page, or pull from a cookie, or you have some custom JS code that you set, etc...) then you have a tracking rule where you add the Data Element to your direct eVar or prop, etc..
You don't do this on Mobile Apps... the context data is set in the app, and you use processing rules to set them to your eVars and props after Adobe receives the call; or you can set specific values (without a context variable) based on specific mappings like I showed above with "Custom Value"
The control you have in a Mobile App Property is a fraction of the functionality that you have in a Web property.
Yes, there are "Data Elements" in a Mobile App Property... but what you can do with them is severely limited.. the only thing I managed to do was concatenate some context variables.. which I can do in Processing Rules.. but since I had no "condition" logic in Launch for this, I ultimately gave up trying to use it....
I suppose if you wanted to set a hard-coded prop or eVar such with a value of "mobile app" (to distinguish all mobile app calls from web calls, I supposed you could.. but you might was well do that will processing rules and keep everything in one place....)
The main point is.. there are web specific extensions.. there are mobile app specific extensions.. you can not mix them in one Launch Property... and how you tag a site vs an app (technology wise) is completely different...
What you can keep the same is the suite (pass web and app data into the same suite), and you can control the values, naming syntax, events that fire per action, etc consistent....
As I mentioned in my first post, since I am also using a "Global Suite" that contains web and app traffic into one suite; I use the a.appid condition to ensure that my web traffic goes to Adobe as it was set in launch (no processing)... only my apps should be running the processing rules (with the exception of a few old sites that are not going through Launch that have some issues - I use some processing rules to fix those until the site itself can be fixed).
I have multiple Launch Properties, I have one for my Core Websites that run React, I have another for the Core Sites that run on .net, I have properties for each of the white label "extended sites" that we use, then I have another one for Mobile Apps.
Keeping the code bases separate means that yes, I have to go and add rules or dimensions multiple times for each variant.. but it also means that I can keep the different code bases clean and separate from one another (which is worth it for me)
