In this article, I would like to introduce some concepts that I think are needed when you work with CJA. For legacy reasons, organizations or people tend to think that the CJA Admin or CJA users do not need to learn Data Architecture.
It is true that for a long time analytics tools were “easy”, and I used quote here because it was very simple in setup, you have a flat design, that you can associate with events.
If you are lucky, if you had Adobe Analytics, you had the opportunity to use nested elements, sort of arrays via listprop, listVar and especially with product tracking.
Product tracking in Adobe Analytics is considered one of the hardest thing to do correctly. And I know very well because my most successful page is the one describing the product variable in Adobe Analytics.
However, with the switch to CJA, the data is now being ingested into Adobe Experience Platform and the old Analytics team needs to understand how the data is being represented, ingested and how that affect the reporting setup.
Basically, I am always preaching to the Analytics team in-house to get upskill via formal or informal training, because it is very important for the success of your migration from your legacy tool to CJA to understand the different way data interact in CJA.
Flat Representation
The easiest way to represent data is to use flat representation.
A flat representation is very similar in terms of behavior when you compare it to the Adobe Analytics interface.
In this blog post, I am calling flat, something that is not included into arrays and which requires to be expanded. I consider flat, also nested elements, even if that does not sound logical, you will see why later.
An example of a flat representation of data would be:
In the example above, you can see that all elements that contain a value are nested within 2 objects : _emeaconsulting and analyticsObject.
Even though they are nested, and are related to each other, we call them nodes as well in AEP, we are considering such structure as flat because of the implication in reporting.
Implication of Flat structure
Elements contain in flat structure are all related to the global event information. They are 1:1 relationship with the eventType per example and will always be the easiest to interpret and analyse in your reporting.
Even if they are easy to interpret and report one, they are not that easy to group and define in the first place. Please take time to understand the different business area and needs of your reporting before you start creating the fields.
Remarks on flat structures
- Why not putting everything at the root level, on _emeaconsulting ?
Mostly because you could have twice the same field. Per example, Name, for the name of the user and the name of their company.
Having a node call person and a node called company would help you understand the context of that field - How do you structure custom fields ?
When creating nodes and fields, it may be easier to create one big mix of them for your Analytics.
It is encouraged to try to modularize your schema and your data representation.
So you try to create custom Field Group for each of your business case, one for consent, one for identity, per example, and these Field group can be re-used by other schemas.
Simple Arrays
Where in Adobe Analytics you could have listprop and listVar to group multiple elements into one variable, you can now represent these via arrays of native data type.
You can have array of string, integer or double to represent when there are multiple elements of the same type and representing the same thing that has been used.
The most common example of such fields is the possibility to use multiple filters.
On an e-commerce website, you could filter for t-shirt size, either “S”, either “M”, either “L”.
But you could actually use a combination such as “S and M”.
Example of a payload with simple arrays:
Implication of arrays
Simple arrays are deconstructed and have then a relationship 1:n to the event information.
Because they are arrays, they could contain many elements in one event, you end up with multiple rows in your event for a single fields.
If you have arrays of double and integer, their values will be sum on that event.
So in our example, myIntegerArray will display 6.
You can now export the simple array structure in RTCDP destination but they may still be complex to deal with for segmentation purposes. Because of their 1:n relationship, if I am looking for when myDoubleArray contains “5.5”, the example will work but this is not the only value contain in the field. You need to be aware of that.
Note: you can always transform a number into a string in the Data View configuration.
Remarks on array structures
- The array elements are well-supported in CJA but may end up being incorrectly interpreted because users do not know that they contain multiple elements.
In our example of size, you could define the size that is the most used, but you would never be sure to know if the size is used alone or with another one.
For that reason, we recommends to have clear naming convention and/or descriptions for these fields.
Array of Objects
Now is coming most interesting data representation for CJA. The array of objects is a very powerful data model to represent your data and their relationships.
The good thing about arrays is that you can pass multiple elements within one request, so if something is present multiple times in your event, you can now represent that with a single field.
However, the issue as you have seen above is that the data is then aggregated or split at event level. So it is very hard to analyze the different elements of your array.
For that reason, Array of Objects is providing your the solution.
You are basically defining an object that can come more than 1 time in your event.
The good thing is that the elements in that object are related to each other, so it makes the reporting way easier in CJA.
In this example below, we have defined the analyticsObjectArray as an object and define it as an array. So a payload could look like this:
In the analyticsObjectArrays, myString and myInteger are actually related to each other, so element1 will display 10, where my eventType (testEvent) will display 30 (20+10).
Implication of array of objects
Array of objects are super powerful in CJA, they are automatically deconstructer in CJA table in a way that makes sense to the end users, if you know the expected behavior.
However, Array of Objects are very tricky to deal with in AEP, as it will qualify the whole profile for an event, if one of the element of the array is valid. This problem is also appearing in CJA, if you try to create a Filter for myInteger in the array that are superior to 10, both element 1 and element 2 will validate that condition, because in the event, there has been an element that was superior than 10.
n the same way in AEP and in CJA, these solutions pay the price that they are looking at event level, or profile level of the event. Not at sub event level.
I wish that CJA and AEP will make it possible for filters and segments that can look at sub event level, but I am not sure how the UI would look like for it.
In any case, I hope that these elements were helpful for building your CJA schema.