Adobe Client Data Layer - Track Your Visitor Data

Transcript

All right, hello everybody and welcome to this session about the Adobe Data Layer and how to use this tool to track your visit on data. So I’m Jean-Christophe, I’m a senior engineer at Adobe in Switzerland working for the AEM sites team. I will co-present this session with Laurentiu and then I will let them introduce themselves. Hey, my name is Laurentiu, I’m a software engineer with Adobe Commerce based in Bucharest. I did the initial development for this data layer integration with the core components, so this is why I’m presenting this today. And next to you, Ben. Hello, thanks Laurentiu and good evening from Zurich, Switzerland. My name is Ben and I’m an Adobe senior consultant specializing in our cloud offerings. Okay, thank you Ben, thank you Laurentiu. So here is our agenda. So I will go through the first part, it’s about the Adobe data layer. Then I will hand over to Laurentiu who will discuss the integration of the data layer with the AEM core components and with the custom components. And lastly, Ben will go through the integration of the data layer with Adobe Launch. And he has prepared a really nice demo, so stay with us. The Adobe client data layer. First, what is a data layer? So a data layer is basically a JavaScript store helping to collect data about the visitor experience on the page and to use and communicate this data to digital servers. About a year ago, we released the first version of the Adobe data layer. So it provides a very simple and basic API to register data, to trigger events, to get the current state of the data layer and to register and register listeners. First things first, to use it, you first need to load the script on your page using the script tag and declare on the Adobe data layer array as a simple JavaScript array. As soon as you’ve done this, you can use it to push data into the data layer. So first example, I’m pushing a page object in the form of JSON with the title and some you can push some properties into the data area. Use the same mechanism. This is the push method, the native push method of the array to push events by using the event key and the event info key one. Together with pushing events, you can also push data as is done in the second example. To delete data, you would use the nerve of the undefined key one as this example. And now comes an interesting part. You can also push functions into the data area. What this does is it actually register the function and as soon as the script is available on the page, this function gets executed. So here I get back a reference to the data area. This is called DL in this example. And then I can use some custom methods of the data area. So here I’m using the get state and the add event listener. I can get the nerve state of the data area by using the get state method. And you see here an output in form of a JSON representation of my data layer. So page with a few components, hero, accordion and a few accordion items. You can also get a specific part of the data area by giving the path to the objects. So here I’m getting some information about the hero component. I get the title and the link of it. To register an event listener, I use the add event listener. You specify the event name. So here it’s adobe data area change. So whenever there is a change, the handler that I specify here will get executed if the object that I specified here with the path is being changed. And in this example, you see that we have two objects because those two objects trigger the adobe data area change event. To register, you would use the remove event listener, specify the event name. And you can also specify specific handler that will then be unregistered. So this is about it for the API. There is more information on the project. So this is an open source project available on GitHub. You can go through the documentation, you can ask questions, you can open tickets, send us pull requests. We would be happy to have some interaction with you. So now we’ll hand over to Laurentiu who will go through the information. All right, so you just saw how the data layer API works, how you can add data to it, and how you can register event listeners to listen for event changes in the data layer. Now, AEM Core Components provides an out-of-the-box integration with the data layer, meaning that it will automatically populate it with each component that is present on the page by generating its data as a JSON in a data attribute of each HTML script. And this integration comes with the JavaScript utility that captures all the generated data from the components and pushes it to the data layer. The same JavaScript utility also adds events handlers for click events, meaning that if you have any component that is clickable, you have, I don’t know, links or buttons or whatever, you can register event listeners for that. They will fire events and you can register event listeners for that, so you know when a certain component was clicked. Then there’s special components like the accordion or carousel that have custom events like showing or hiding certain items. And for those, the out-of-the-box integration will also push those events into the data layer, so you can subscribe to listen for those changes in the special components. Now the way it works is every component generates its data that will be pushed into the data layer. That starts from the back end, from the Sling model. In the core components, every component will implement this interface called component, which has two important methods that are mandatory for the data layer generation. The first one is the ID, the get ID one, which will generate, should generate a unique ID for each component that will make it easy to then identify in that data layer. And the other one is the get data, which will generate the actual data that the component will present into the data layer. There’s an intermediary state in the core components for each component that implements that component interface, and that is the abstract. It provides a default implementation for the get data method, and what it does, it differs the implementation and the generation of the data to the get component data method. Which in turn will be overridden by all the components that extend this abstract component. Now this provides a default implementation, meaning that it will generate a minimum amount of data for each component that will be present into the data layer, and that minimal data is represented by the ID of the component, its name, and the modified date. Oh, its type, sorry, and the modified date. Now every other component that implements that abstract component will, as I said, override this get component data, and will use a data layer builder utility, which was, it’s quite a new feature that was added in the latest versions of the core components. You can use that builder to extend any other data layer information that was already generated. So in our case, we’ll just extend the default implementation provided by the abstract component, and then add two more elements to the component data, which is the get data method. The component data, which is the title and the link. Now this example comes from a button component, which also provides a link. To add this, to make this data available to the client side, we need to render it in the DOM. So the way it works, we definitely have to give the ID, which is mandatory to identify it later on. We also generate the JSON representation of all that data that was provided by the SlingModel, as you can see here with the data CMP data layer attribute. And also if you have any clickable HTML elements, you will add, we will add the data CMP clickable attribute as well. Now all these data attributes will be leveraged by the JavaScript utility. To collect all that data, push it to the data layer, and then generate the proper events. As you can see here, for example, it gets all the data layer JSON attributes, the CMP data layer, and it pushes it one by one into the data layer. And then it pushes an event called CMP loaded. So if you have an event listener registered for this event, you will know that all the data is now available into the data layer, and you can start processing it wherever you, however you please. Now we also attach default click listeners. So we do this to generate the proper click events into the data layer. So we attach event listeners on each clickable element, and when that element is clicked, we will generate a payload that contains the ID of the component that was clicked. So you can then have your own event handlers processing this. Now to have all this working, you need to enable this data layer integration. And the way it’s done is by using a context-aware configuration, like it’s customary in AEM. So you have to create a sleek config under the pad that you see on the screen. All of this is also available on the GitHub page, so you can find out all the information about how you enable it. You don’t have to squint at the small font over here. But basically you add the context-aware configuration and everything should work. Now you may also have your own custom components built on top or not on the core components. And if you want to leverage the custom, the out-of-the-box integration to get all of that custom component data into the data layer, you basically have to apply the same pattern as was done with the core components. So first step would be to define the properties of that component that you want ending up in the data layer. Then you must have the component unique ID that will also be present in the custom component HDL. You have to render all that data that you defined earlier into the data CMP data layer attribute. So it is picked up by the default integration and it’s pushed into the data layer. And in order to do that, you can generate the JSON data structure in your model using the data layer builder utility. So basically if you’re using an extender pattern, so you just modify a core component, you can just extend the provided data for the data layer of that component that you’re extending. Otherwise you can generate the data however you see pleased, however you’re pleased, but it only has to end up into the DOM eventually. So for your SLEEM model, you basically have to generate an ID and generate a component data. The component data is an interface, so you have to implement this in any way you want. So you’re basically free to generate any data you want with this data layer builder utility. Now as I said, you also have to provide it to the front end and that is done with data attributes. And if you also want to leverage the default integration for events, for click events, you just add the data attribute data cmp clickable and you’ll have that provided for you out of the box. For any other custom events, you should trigger those from your component client libs associated with the custom component. That was pretty much it from my side. I will hand it over to Ben to show you a small demo with the Adobe Launch and Target. Thank you so much, Lorenzo. You should already be able to see my screen. Perfect. All right, now that we’ve heard how you can actually get started by using the ACTL, what the computed state is and so on, the question is how can you actually do the tracking in a in a scalable way? And the answer is Tag Manager Adobe Launch. Now if we talk about integrations, with Adobe Launch in terms of launch, this is realized with so-called extensions. And what does an extension do for you? Well, in this case, we’ve built the ACTL launch extension to provide you with a couple of really helpful features. First of all, the extension allows you to load and inject the library if required. So as a side note, if you’re running your page not on AAM or did not inject the JavaScript library via AAM directly, the extension would take care of that. Then, of course, one of the main things here and what I’m going to show you in my demo later is how you can react to event pushes and data pushes. Of course, the extension also allows you to retrieve the computed state entirely or for a given path. And then there are some useful utility functions like pushing data into the ACTL object but also renaming it and resetting it if this is required in your implementation. Now what would be a good conference talk without a demo? Let me actually show you how this would look like in real life. In order to show you, I went over to our cool weekend site and added some basic tracking and some basic personalization. Now as Laurentiu already told you, if you load the page, the data layer is going to get populated with the CMP loaded event. So this is actually what I’m listening for. So once I have this event, I’m going into the state, checking out all the relevant information for my tracking and fire our analytics call. So if I refresh the page, you can see here on the right hand side, let me just zoom in a bit, you can see I’m tracking stuff like the page name, a description, language, a category, and so on. So that was actually the page load tracking. Now you’re wondering how can I track custom events? Well, in the end, it’s just a different name. So instead of listening to CMP loaded, let me show you in the data layer how it looks like. See all the components populating here, information. And in the end, we have the CMP loaded event. Now, for example, let’s say I want to track the showing of a new component. So if I slide here to the right, you can see the San Diego surf spots are showing and an additional server call is fired with a CMP show event. And now also populating here the event with the relevant information like the San Diego surf spot and so on. In the data layer, you can again see that here I have a CMP show event with the relevant event info telling me which component was shown now and so on. So if I navigate back again, the CMP event show is fired. And this is just a basic implementation. And depending on your needs, you could now set up your listener to only modify once in a session or once per page load, whatever you define. Right. So let’s check out some trips here. And in order to do some meaningful personalization, I thought, why not listen to the preferences of our user? So I’m actually hijacking the call for analytics here. So when I click on skiing, let’s pretend I like skiing. It’s a fact, by the way, I really do. So I click here on skiing on the right hand side, you see again that I clicked the skiing category in this component show. But what I also did is to send this information to Adobe target, our personalization engine. So let me click here again, just to target really knows that this is my interest. And if I continue to serve now, for example, I’m clicking on the magazine here, I set up a basic personalization to show me personalized content based on my interests. If I go back to the adventures and my interest change, again, I retrieve this information from the data layer. Let’s say surfing is my new sport. And this is now just one component show, right? You could implement that with every other component or page views. So for example, for every page I’m browsing, which is related to the surfing category, you could send this information to Adobe target to make this real time scoring even more meaningful. Now, let me just click two, three more times that we actually now tell target skiing is outdated. Now I’m really into surfing. If I go back to the magazine, you see, I get the personalized content here based on the information we’ve collected from the data layer. Pretty cool. And again, this is just very basic setup. There are basically no limits. So whatever information you put in the data layer, you can later on use to track the behavior of your visitors and you can use it to personalize and show the most relevant content you can imagine. Okay. So now that we’ve seen how it looks like in the end, I want to show you how it looks like in launch. Let me head over here. In launch, you see the catalog. And of course I installed the Adobe client data layer extension. Where do I use it? Well, under rules, I created basically three rules. One, to set all my variables for the analytics tracking call and fire the beacon. That was when I initially showed you the page load tracking and the CMP show event. In addition, I need to load and fire target at the page load. This is the rule to make actually the personalization happen on the magazine page. On the magazine page we see here. And then this call where we tell target what is the category I’m interested in. But let me show you the analytics call first. How does it look like actually? So here we have two potential triggers for this rule. One is the page load and one is the CMP show. Now you can see this event is based on the Adobe client data layer. And this is provided from the extension I mentioned. So if I click on it, you can see the extension is the ACDL extension. And the type is the data push. So far not surprised, I guess. What am I listening to? Here we could define to listen to all changes, all events. But in this case, I’m only interested in the CMP loaded event. Again, I want to use this pattern to not just track the page load, but also the CMP show. So the component show. So actually here, it’s pretty much the same. I just added a new event listener with a CMP show. Okay, so once this is pushed into the data layer, what’s happening? We are clearing all analytics variables, we’re setting the variables. So here is where the magic happens. We look into the data layer, or the event info of the data layer, whatever you need, you set all the analytics variables, and in the end, I’m just sending the beacon. Pretty similar here for the tracking of our category to the personalization. The trigger is in this case, only the CMP show, right? So that was my trigger on the implementation. Whenever I switch the category, I have a new component. And I’m just firing a call to target indicating what is my new category affinity, or at least what is the new category I’ve decided to look at right now. Of course, there are many, many more things, but for the sake of this conference talk, we’re limited to showing you how the basic concepts work. And in the end, we have collected quite some resources. So, Chase, you already posted this in the chat, but feel free to check it out. So if you want to know more about the data layer itself, or the integration with the core components, the extension, or even an example, how you can collect data with analytics, feel free to check out the resources. If you would now like to start with the ACDL, what would be my suggestion? My suggestion would be to head over to the launch extensions, install the ACDL extension, enable the data layer in AEM, and get started, play around with it, make some experiments, and check out the resources. Now, we still have some time for some Q&A, so I would suggest please just drop some questions in the chat, and we’re gonna stay here for some more minutes and answer them. Thanks a lot, and see you in the chat. So I see a question about the custom components, if they were created in JSP and not the HDL. Well, the main, the most important thing is that the data reaches the DOM, so it goes to the front-end. It pretty much doesn’t matter what the data looks like, as long as you respect the data attributes and you render the JSON there, you should be fine. So that’s the most important thing for this out-of-the-box integration. I see another question, can we use the category and make user segments in target? Yes, you can do that, and that’s actually what I did. So whenever I send information to target, I used the built-in category affinity. So based on that affinity, I created a couple of segments, and for each segment, I then showed the respective content. So yes, you can use it to do segmentation. Why is clearing the variables relevant? Well, this depends on your setup, but if you have some, if you set some EVARS, which you not want to be on the next call, you need to clear them, right? So if I sent something specific to, for example, one component view and the next event, I don’t know, a download button, should not be associated with the same value, I need to clear it. So that’s why I used the pattern clear set send, so I’m always clean and I always set all the stuff I need. But this is a matter of taste. So there is another question, can ACDL be enabled selectively for chosen components, or is it a global configuration? Actually, it’s yes, this is enabled for site, so there is a global configuration, but then you can also enable it for a component of your choice. So you can decide not to enable it for one, just as Laurentiou said before, it’s by playing with the DOM and the data attributes. So if you don’t have the data area specific attributes, then this won’t be part of the data area. I see a lot of questions regarding the migration, so co-assistance of an older CEDDL, and what is the recommended way to migrate to ACDL? Well, this is probably not a completely straightforward thing you do in one morning. What you can for sure reuse is the structure of the data layer itself. So you could say I have already structured all the page information in your custom implementation, if I’m not talking about the default AM information which is pushed, but the rather custom data layer implementation, right? So if you have that, you can already inject this. Other than that, you will for sure have to take some time. But depending on the time, we can also follow up with that question later on. Yeah, regarding the follow-up, I’m sure there are a lot of clients having the same questions, so probably we will even have a, maybe I cannot promise, but as this is a frequent request, I can think of a post somewhere which describes some potential migration paths. Lorenzo, JC, is there a way to trim the out-of-the-box component information to speed up the performance? Well, the thing about the core components is that they actually provide a minimum information regarding that component that is relevant. So there’s a lot of things that we can do to actually make sure that we have the best components. There’s no way to trim it from the core components, but again, you’re free to do whatever you like with your own custom component. But again, all the data that was by default provided to the data layer was carefully selected to give the proper information about that component, because if you trim it any further, then it will make no sense. You wouldn’t know what component it is and what metadata it contains. That will be relevant, actually. Got it. Thanks. All right, we’ve hit the time, so thank you, everyone, again for your attention and for your interest in the ACDL. As mentioned, the slide deck is going to be shared with you, the recording as well, and we’re looking forward to follow up with you regarding all the discussions and migration paths and so on. All right, have a nice day, afternoon, morning, wherever you are, and see you soon. Thank you, everybody, for attending. See you. Bye-bye.