pass an eVar as an array in Mobile code

[jaishal]

Hi everyone,

I have a quick question. We need to pass a specific eVar as array in the mobile code to receive the data in adobe. Here is my though process:

i need to see if a single customer is seeing 3 offers on our app, we want to capture all the 3 offers in a single analytics call.

What we have done is :

offers: [{code1:<offer code1>, type1: <offer type1>, name1: <offer name1>},

           {code2:<offer code2>, type2: <offer type2>, name2: <offer name2>}]

We are not receiving data in Adobe so seems to be an issue. What is the correct way of passing an eVar as an array in mobile apps? How the processing rules needs to be set up for that ? Any Documentation would be of great help 

[Jennifer_Dungan]

Adobe Analytics won't support arrays, all dimensions are simple text.. since you mentioned processing rules, I am assuming you are not trying to do this in CJA...

However, are you using the old ACP SDK, or are you using the newer AEP SDK and XDM Streams? Or maybe you have upgrade to XDM, but are just using the Analytics Keys to send data directly to AA dimensions or context variables?

We are still using the old ACP, and processing rules are pretty limited functionality, it only supports strings as well, there is also no "splitting" or processing the data into pieces.

However, if you are using the old ACP, or using the Analytics Keys to pass data direct to AA, I should be able to help, I have a lot of experience with Processing Rules and collecting Mobile App data, but I really need to know the end result / expectation so that I am leading you in the correct direction.

[jaishal]

Hi jennifer, yes we are using old ACP trackState and trackAction functions to send data to AA

[Jennifer_Dungan]

OK, so we probably have a very similar setup.

So what are you trying to do? Are you trying to populate your s.products variable? Or maybe set up List Vars? Those are the two most likely uses I can think of... but again, I understand your needs.

[jaishal]

Okay so i will give you the scenario:

I want to capture the offers a customer is seeing. So lets say the customer is seeing 3 offers so i want o capture all the 3 offers in a array. meaning, we have offers.code and offers.type.

For offer 1, 

offers.type="value", offers.code="value"

for offer 2,

offers.type="value", offers.code="value"

In web we have similar setup,

offers{

(offer1)code="value", type="value";

(offer 2)code="value", type="value";

}

Now how do i ask my developers to pass the offers variable and how do i set it up in processing rules for it to receive the data in AA as an array

[Jennifer_Dungan]

How is the information being collected on Web? Your data layer might be an array, but it's not "going to Adobe" as an Array, since AA only supports text.

I assume you are using Launch to process that array into an eVar or List, or some dimension... can you share the final output?

[Jennifer_Dungan]

I am asking because in many cases, while you can collect the same information as web, in many cases you have to approach it differently.... 

You do not have as much control over data in Processing Rules, there are somethings (i.e. Products List) that cannot be mapped with Processing Rules, etc.

For mobile apps, you sometimes have to get your developers to do the work, and you simply take the results and pass it through... I know that this is less than ideal in some cases, but sadly, it is sometimes the only option....

Knowing the final result of the data will help me to help you get the desired result.

[jaishal]

Here are the attached screenshots:

i am sharing 2 screenshots : 1 one from the console log(Data layer) and 1 from the (AA, how it looks )

example is of a variable. : notification which is similar to offers. It is an array

[Jennifer_Dungan]

Ah, ok, so your final eVar is just a big string that looks like:

banner|[na]|overview-banner-top|includes unlimited Canada-U.S. calling. Available at....|account,notication|[na]|[na]|Need....

First off, you should know that this value is being truncated at 255 characters (so you are probably missing details that you think you are collecting, but aren't).

Secondly, because these values are being condensed into a single string, this will be harder to separate out to individual values later... You can't even really use classification rules because you could have any number of items being passed... and from a single string like this, you can't even reuse classifications to represent the type, name, id, etc... because only one value can be mapped at a time.. not multiple.

If you really want to replicate this, then you will need your developers to collapse the values to a string just like your final version... making sure that the same order of fields is used, with a pipe delimiter on your fields, and a comma delimiter for each item...

Basically, you will need to tell your devs to create a context variable string that contains "banner|[na]|overview-banner-top|includes unlimited Canada-U.S. calling. Available at....|account,notication|[na]|[na]|Need...." and pass that... then you just map that single context variable into your eVar27.

Or, you might want to consider changing your approach to using a list variable, using a similar structure, but allowing each item to be recorded separately. Lists act like eVars, except that each item in the list is limited to 255 characters, and you can pass as many items as you want.

You can send the information the exact same way into your list:

s.list1 = "banner|[na]|overview-banner-top|includes unlimited Canada-U.S. calling. Available at....|account,notication|[na]|[na]|Need....";

But, the difference is that you will set up "," as your delimiter. This will result in each item coming through on a separate row in your table:

1. banner|[na]|overview-banner-top|includes unlimited Canada-U.S. calling. Available at....|account
2. notication|[na]|[na]|Need....

You can then create classifications on your list for "type", "name", "id", "message" and "position"

But since each line will be processed individually, you can get all the data from all notifications processed.

So if you look at Classification "Type", you will get:

1. banner
2. notification

For you mobile app, you will still need your developers to make the entire thing a string that follows the exact pattern.. but instead of passing it to an eVar, you would pass it to a List dimension....

Anyway, the mobile app solution is the same.. you cannot pass an array, or map that array in processing rules... you will need to instruct your developers to build out the entire string, setting all the proper order of values and delimiters.

[Jennifer_Dungan]

I have something similar in our apps, this is how I would instruct / create the requirements for our developers:

---------------------------------

For the array of notification data, please create a string of all the data in the following order:

{type}|{name}|{id}|{message}|{position}

Delimit each notification with a comma.

// Provide an example of the JSON / Array

// Provide an example of the final string

// Tell them what context variable name you want it passed as

------------------------------

[jaishal]

so if the devs pass something like this,

notification: [{notification.type}|{notification.name}|{notification.id}|{notification.message}|{notification.position}, {notification.type}|{notification.name}|{notification.id}|{notification.message}|{notification.position},{notification.type}|{notification.name}|{notification.id}|{notification.message}|{notification.position}]

Is this the correct format?

what should be the context data variable? 

should it be just "notification" ? How do i map it to Adobe analytics using processing rules?

[Jennifer_Dungan]

You won't need that initial "notification: "

Basically, the string value that you see being sent from your website in eVar27, you need to match that format exactly; if you want the data to come into your suite and be available the same way.

I am not sure how you currently test your analytics, but if you are using the Adobe Experience Platform Debugger, and you look at eVar27 when the tracking call is being made, you can click on it and see what is being sent (note, the 255 character truncation probably won't have happened yet, so you are sending a lot more data that will end up in your final tracking).

Now, as for the context variables, I expect you already have other tracking also using this... you may have all your custom context variables under a specific namespace (i.e. corpx) or you might just be sending them directly into the context area. You might want to match up that, and make sure that whatever name you are using doesn't interfere with other context variables in use:

Example:

contextVars = { }
contextVars["myapp.notificationBanners"] = "....."
ADBMobile().trackState("Home Screen", contextVars)

// This will put your context variable "notificationBanners" under a namespace of "myapp", so you would find that in processing Rules under "myapp.notificationBanners"

// OR

contextVars = { }
contextVars["notificationBanners"] = "....."
ADBMobile().trackState("Home Screen", contextVars)

// This doesn't put the context variables under a namespace, so in Processing Rules you will just see "notificationBanners"

It doesn't matter too much, but you probably want this to be consistent with your other context variables.

As for mapping in processing rule, once you have data start sending to the server in your context variable, it should be available in the selection (you can of course set this up in advance, but you have to be sure that you and the developers are completely in sync on the namespace and spelling of the variable name so that when data does start flowing, it will be properly mapped)

Here is how I like to make my mobile app rules:

1. I always put in a condition to check if the call has an app id, so that nothing I do in the rule will ever fire on my website

2. Because there is limited rules, I often have a "general page view" rule, and a "general action" rule, where I set all the global values, then I create specific rules for more complex logic to only set the values within those contexts.

In this example, I am going to assume this is part of a "global page view" rule:

So my conditions look specifically for my app (a.appid is set), and only look at TrackStates (not TrackActions) by looking only at calls that don't have an action name, you should customize to your needs...

Next, in the "do the following", I simply overwrite the value of the dimension with the context variable...

Again, here, I strongly recommend changing your implementation to use a list variable for web and app, but again, that is up to you.

[jaishal]

Okay got it, thanks for this. 

Now the thing i am worried about is 255 character limit. My main goal is to see what are the different kinds of notifications a user sees when he lands on a specific page. 

For example: 

When the user lands on a tab , there are 3 alerts that get triggered and we want to know all the 3 alerts for that specific customer and also how many times each alerts gets triggered as well. 

On web , it is possible as we are using adobe launch for getting the info. Attaching the screenshot for notification logic on Adobe launch. With this logic, we are able to see every offer a customer is seeing. 

On mobile to get the same logic, we are trying to get the same data. Now how do we get the same result for app? 

If we pass contextVars ["myapp.notifications"] = "[notification.type|notification.name|notification.id|notification.message|notification.position, notification.type|notification.name|notification.id|notification.message|notification.position]"

"," is a delimiter for 2 offers. How will this work out in app?

[Jennifer_Dungan]

The 255 character limit is affecting your web traffic right now... eVars can only hold 255 characters... anything above that is truncated. The Database field on the Adobe server will not hold more than that.

Even if you are sending all the data to Adobe with Launch, I can absolutely guarantee that it's not all available in your reporting. As soon as I saw your example, I had to mention it. 

It's not a mobile app limitation... it's a eVar limitation.

https://experienceleague.adobe.com/en/docs/analytics/implementation/vars/page-vars/evar

Each eVar is a string that contains custom values specific to your organization. Their max length is 255 bytes; values longer than 255 bytes are automatically truncated when sent to Adobe.

---

This is why I am suggesting to use a List instead.

https://experienceleague.adobe.com/en/docs/analytics/implementation/vars/page-vars/list

Each list variable is a string that contains custom values specific to your organization. This variable does not have a maximum byte count; however, each individual value has a maximum limit of 255 bytes. The delimiter that you use is determined when setting up the variable in Report suite settings. Do not use spaces when delimiting multiple items.

---

Regardless of sending the data straight to the eVar (in Launch from your website) or through a context variable that is mapped to the eVar in your mobile app, the data is processed exactly the same.

For a simple example, let's use:

"example1|value1|id1,example2|value2|id2,example3|value3|id3"

Let's pretend the character limit is 35 characters for an eVar, when this goes to Adobe, you will only get:

"example1|value1|id1,example2|value2"

This means that "|id2,example3|value3|id3" was all lost.

However, if you use a list, set up with a "," delimiter, all the data will appear in Adobe, the comma will split the values to a new tracking row, so:

1. example1|value1|id1
2. example2|value2|id2
3. example3|value3|id3

If you are sending the string to the List Var using Content Variables, the comma will be processed the exact same, splitting the values on the commas.

You just need to be sure that there are no commas in any of the text. So in the code you just attached, you might want to apply another regex replace on commas, at least for name and message (the two most likely to contain a comma). OR you might want to choose a different delimiter... whatever you choose, you need to make sure that the delimiter cannot be a part of the content.

You can also show your code to your mobile developers... they will be able to see the logic that you are doing to parse the notification data, and they can better replicate it.

As long as your developers are including the comma in the correct spot in the string, i.e. joining each notification with a comma, Adobe will process it the exact same way. I have a very similar tracking in my own site and apps, I use colons and pipes.  Colons between each of my values, and pipes as my list delimiter. It doesn't really  matter what you use, so long as those characters don't appear as part of the values and break the list logic.

[jaishal]

My Developers are sending notifications value in this format as a dictionary of arrays:

"notifications": "[{\"notification.type\":\"enrolled subscriptions\",\"notification.position\":\"NA\",\"notification.message\":\"NA\",\"notification.name\":\"more|subscriptions|Start streaming Disney+ movies, TV series and Originals now!\",\"notification.id\":\"NA\"}]"

Looks incorrect format to me and wanted to check with you and how do we map it to eVar with the keys that they are sending?

[Jennifer_Dungan]

Yes, your developers are trying to send it as JSON... they have to convert it into a single string value. No [ or { or ] or } unless they are part of the literal text...

Like in your example, your "NA" we actually showing as "[na]", in that case, to match what you have from your website, you will want to match that value.

[jaishal]

Okay to confirm if we send the value in single string value like contextVars[notification]:"notification.type1|notification.name1|notification.id1|notification.position1|notification.message1,notification.type2|notification.name2|notification.id2|notification.position2|notification.message2,notification.type3|notification.name3|notification.id3|notification.position3|notification.message3". Is this correct format?

Now if we map this notification to eVar27 then in Adobe analytics, it will be 

eVar27: "notification.type1|notification.name1|notification.id1|notification.position1|notification.message1,notification.type2|notification.name2|notification.id2|notification.position2|notification.message2,notification.type3|notification.name3|notification.id3|notification.position3|notification.message3"

but then how will know how will i seggregate the notification.type, notification.name, notification.id,notification.position,notification.message using classification as we do for web? 

[Jennifer_Dungan]

Yes, though you might want to add a note to replace null value with "[na]" to match your web implementation.

Also, as per your screenshots, you are not yet segregating your web data... unless you are using classifications, in which case, the same classification logic will apply.

[jaishal]

This the classification rule builder we have for web (attached screenshot). Will this work for mobile app regarding the format we have ?

On web we pass the key notification.type, notification.name,....

My devs are asking as to if we remove the {,[,},] It will not match the web implementation as in web it is an array and in mobile app it would be string 

[Jennifer_Dungan]

It should! 

And since you have that, matching the format and values is all the more important. Differences could cause the regex to not work... it was probably those [ and { that were causing issues if your developers already started sending data in the JSON format causing issues.

[Jennifer_Dungan]

Your web implementation is not JSON right now.... it's a string. The data layer is JSON, and your script is putting data into an array, then flattening that array into a string.