We wrote another article on how to use an event-driven data layer (EDDL) with Adobe Data Collection manually and in general. In the end, we picked up a Data Collection Tags Extension called “Adobe Client Data Layer” (ACDL). This is what we’d like to introduce today.
Where is this coming from
Everyone’s issue when using EDDLs is that they are built on an array with probably the same event one following the other. As long as there’s no physical new page load on a website (which is the case for most modern implementations) all data layer pushes are aggregated in an array. Let’s assume you’re pushing to views of pages on a single-page application (SPA) website, your data layer would look like this.
[
{
"event": "pageLoad",
"page": {
"name": "verrodata Sample Page for AEP"
}
},
{
"event": "pageLoad",
"page": {
"name": "verrodata Sample Page for AEP"
}
}
]
For the first entry is array number 0 and the second is 1 the object path would look like this:
[0].page.name (for the first) [1].page.name (for the second)
As we all know, we can’t use “array-numbers” in a common data element in Data Collection, and using page.name
will result in an error, as it doesn’t exist as it would do in a Customer Experience Digital Data Layer without arrays.
In our previous post, we described how to get the computed state with custom code, but Adobe Consulting is helping us to keep it easier in a more interface-friendly way.
The Adobe Client Data Layer extension
First, you can add this extension via the extension library in Data Collection Tags. There’s no need to configure the extension itself. Besides that, you can configure a data layer name, if it doesn’t match the expected standard (adobeDataLayer).
After adding the extension, you’ll get a new option when creating a Data Element. Let’s assume we want to create a Data Element for the last pushed page name to our data layer. We create a new data element, name it as you want, and choose the extension “Adobe Client Data Layer” with the Data Element Type, “Data Layer Computed State”.
After that, type the object you want to extract from the data layer. In our example page.name
. It’s not necessary to take care of the array-number, as the extension is taking care of navigating to the last (highest object array-number) existing path with this object.
You can now use these Data Elements in Rules as done before.
Regarding the Rules
While Adobe Data Collection Tags Rules can handle custom events that come with the Core extension, it makes more sense to also use the ACDL extension to configure your event (trigger).
So, when adding a new event to your Rule, just choose the ACDL as an extension and the event type “Data pushed”.
In the right block, you’ll see the configuration with different options to listen for. In most of the cases, it’ll be a “Specific Event”. You might name it “pageLoad” for the typical page tracking push, but that’s up to you.
If you like to read more about the differences between those settings, I’d recommend the wiki page of the extension.
From my point of view, using Data Elements in this way is most effective and easy to maintain, but you could alternately directly point to the object that is provided from the push event. You have two options for that:
- message: The item that has been pushed into the data layer.
- fullState: The full, computed state of the data layer.
This information is typically referred to by using the %event.fullState%
syntax in Launch text fields or the event.fullState
syntax within custom code.