Adobe Client Data Layer - Event-Driven Data Handling

Transcript

So welcome again. Thanks for joining. Let me introduce myself before we get started. My name is Ben. I’m working for Adobe as an architect. Now depending on the project, I am working as a data or enterprise architect. But usually I’m the executive technical lead of large-scale experience platform projects. I’m also the lead author of the ACDL launch extension and currently I’m supervising the respective extension team. So I’m making sure that we’re aligned with the product features and the future so that you can be the most successful and you have all the tools you need to implement this scaling and flexible data collection setup. I’m based in Zurich, Switzerland and if you want, feel free to follow me on Twitter and Facebook. What are we going to do today? Well, first of all, I want to start and actually make sure that we all understand the problem we’re trying to solve with the ACDL. After we understood what the problem is, I’m going to introduce the ACDL itself. So making sure that we have a common understanding of what the ACDL is and what the process is. Then I want to highlight some recent changes followed by some best practices and advices I would like to give you on your way. Then we’ve reserved enough time for a demo in which I’m going to show you how an actual setup can look like, what to look for and whatever we’re going to discover in the scope of this demo. I think you can benefit from that greatly. In the end, we will have some time for Q&A, so please make sure you post your questions in the chat. I have some colleagues already in the meeting here, in the session, so thanks guys. Feel free to post your questions and they will try to answer it and in the end, the questions which are probably relevant for everyone, we can have in the Q&A session. So please make use of the chat and there is a Q&A section as well. If there are some answers and questions already answered, you will see them, so feel free to check it out. But let’s get started and see why we actually need an event-driven data layer. Now if we look at the current state of the web implementations of a data collection, I think we can all agree on the fact that there is an increasing complexity of those setups. In the past, we’ve had less features on the website, less complexity in overall web scenarios, so now there is more complexity, more data to track and it’s becoming significantly more complex in the near future already. One aspect of the base for an event-driven data layer is the asynchronous nature of events. So on a modern website or a single page application, you have all kinds of events. You have an interaction with the shopping cart, you have product impressions, you have maybe a stock price ticker on your website or just an impression or an interaction with the component. So all those things are asynchronous and in the past, I’ve seen a lot of customers struggling with those timing issues where you need to wait until the data is ready so you can then track exactly this. But this was always quite a tedious process to make sure that we have all those data points collected at the right time. One thing which adds on that is keeping track of the current state. So like I said, on the website, you might have some filters, the user is searching for a specific kind of product and you want to make sure when you perform the actual data collection that you have knowledge about the current state. So all of that is also quite a challenge. So in traditional legacy implementations, it was really hard to keep track of what exactly happened over time on a page so that when a new event happens, we know exactly all of the past, merge that together and then have a consistent tracking. One more thing we want to solve is the decoupling between content and tag management. So what does that mean? We want that the CMS is only responsible for rendering the site, showing what is actually on it and then we have the tag management which should decide what should be tracked, when and where and what is the mapping. So we want that to be decoupled. We don’t want the CMS to actually go ahead and implement this logic. And the data layer is actually the interface where the CMS talks to our tag management. So now that we know what we actually try to overcome, let me introduce you the ACDL and its corresponding launch extension. The ACDL itself is a JavaScript library which allows you to interact with the data layer, collect data and events and then also to listen to those events and do something meaningful with it. To be more precise, it provides you an API to do the following things. You can register data which is then merged into the computed state. You can trigger events which are associated to data which is stored in the data layer. But you can also retrieve this computed state which is basically the collection of all the history which has happened on a single page. And then obviously you can also register listeners which will then be fired once a specific event or data change occurs on the page. So that’s the JavaScript library itself. Now to make your life even easier, we’ve built a launch extension. Now this launch extension has several features and let me go through those features now. So obviously we need to load the ACDL library at some point. Now if you are a customer who is using AEM, the library comes out of the box. But if you don’t use AEM or you don’t use the AEM core components which come with the ACDL, you can just load and inject the ACDL script directly from the extension. I’ll tell you some more details about that in the best part of the video. But just so you know, if you have a website, you need this library. You can just use launch, click on inject and it will inject the library for you. Then obviously the probably most important feature is the listener for a specific data layer push. So we want to react to data layer pushes. Then obviously we also want to use the payload. So whatever is in that event we want to use later for our data collection. But we can also retrieve the computed state of the data layer at any point in time. And we can retrieve specific paths from the data layer. So those are some of the capabilities of the ACDL. Now we have the library, we have the extension. Let’s have a look what some really useful features are. Let’s have a look what some recent changes are. Some of you might recall that we’ve had this session already in different or in other conferences. But over the time there were some changes I want to highlight here. The current version of the extension is 2.03. And there was an issue when you would load the ACDL twice. We’ve luckily or happily fixed that issue in this version. So what happened is if you would use the core components in AEM, you usually load the data layer in the body. Now if you use launch as well and inject this library, it would first inject it once in the head with whatever version you have in launch. And then later it’s included in the HTML and you would load it twice potentially with a different version. So that would break then the existing listeners and your data collection is broken. So we fixed that issue even if you are now using or injecting it twice with the latest version, it will still continue to work. However, I would still recommend you to only inject it once for consistency and performance of course. Then one more thing which is quite important to highlight we removed the event.beforeState and afterState. That was a design decision made by the ACDL core component development team that was usage and also performance especially reasons. So now to be backwards compatible, we’re going to return or we’re currently returning an empty object. So if you have still an implementation where you use before or after state you might wonder why you never receive anything. This is because we’re now returning an empty object. So all the customers who are using this we’ve notified. So if you’re one of them or working together with one of the customers who still use it make sure that you’re aware of that and you can change that. So just remove the usage of before and after state. All right. Now obviously I’ve already supervised quite a lot of projects where we’ve used the ACDL, Web SDK and so on. And let me give you some guidance on some points which I find especially interesting. One point which is already highlighted in the configuration itself is the renaming of the data layer object. You might be one of the customers or work with a customer who have already a data layer object in the structure of the ACDL but you are using a customized name. Yes there is an option to rename the data layer in the extension however due to how it is done technically and how it’s possible technically I would not recommend you to do it. So currently the ACDL library itself does not completely support this name change natively. So if you have a look how it’s working behind the scenes it does work but it comes with some limitations which are highlighted in the configuration. So only do it if you do not have any other way of implementing it. Then one point which is crucial is I would strongly recommend you to load the ACDL via launch. Now you might wonder why shouldn’t I load the library with AEM or CMS and that has basically two reasons. So first of all it’s the consistency and the time to market. If you upgrade the library and you inject it in launch it’s a simple click on upgrade and publishing a new launch library. So then you already have all the new features and all good. If you’re hosting the library in your CMS it takes usually a release and that takes time to get the new version in there. One more reason is that you should stay consistent between the version of the launch extension and the actual library version. So if there are at some point differences you should make sure that you have the same underlying structure and version. Okay so that’s the second reason. And one more thing this is not a hard limitation but most of the times in the CMS I see the library being injected somewhere in the body. So I think out of the box AEM injects the ACDL library at the end of the body. But that means that whatever rules you’re listening to like the page load will only get fired once the body is completely processed the ACDL is injected, the events are processed and the rules are triggered. So that is pretty late. If you load the ACDL via launch you can basically assume that as soon as launch is loaded ACDL is there and you can process the events. So it’s usually the easiest way to get the ACDL on a website. Just inject it in launch and make sure you don’t load it twice in the CMS. Then another thing which is important then another thing which is crucial use the data layer and use the event payloads and the computed state as much as possible. So you do the data collection already in this place so we want to make sure that this payload is used properly. And then one sentence which might seem pretty short but it’s actually insanely important is to have a clean and well-defined data layer structure. It makes your life a lot easier. If your data layer is clean and well-defined you can basically implement in the Tag Manager just the mapping to whatever variables you want to track. So you will see that in the demo why this is so important. But said that I’ve worked with a customer where we designed a very flexible but still generic setup or structure in a data layer and this customer is now using basically one common data layer structure across more than 300 websites. So then you can scale and whoever implements a new website we just give them the specification that’s the data layer and it will seamlessly work with our existing data collection rules. So make sure you spend enough time on designing a data layer. Think about your use cases. Think about what information do you want to collect. Give it a nice structure and then write it down. So that’s for sure something I cannot underestimate. Spend enough time in the data layer design. Perfect. Now we have a lot of time so let me show you how this thing can actually work. I’m going to switch my screen and show you a website where I’ve actually added the ACTL. Some of you might know the weekend site. It’s one of our AEM demo sites and I’ve prepared a demo here. Now in the previous sessions we had I showed you how you can interact with Adobe Analytics and Adobe Target with the ACTL. Today I want to use the Web SDK. So for those who are not familiar with the Web SDK, the Web SDK is basically the new way of collecting data at Adobe or at least in the web. It’s one library where we can send data in a structured format so in the schema in the XDM format to our Edge servers and from there it will be then forwarded to whatever system we configure. So in our case we could say send the data to Analytics, to Target, to the experience platform or do some customized event forwarding to your own endpoints or to Facebook or LinkedIn, whatever it is. So that said I want to use the Web SDK here to collect data and we could still then decide where this data should be forwarded. Alright so let’s simulate a page load. I’m going to paste Data Layer Push in there. So this is basically my payload. The event is the page load. I don’t have any event info. The page has a name but I’m not populating that one here. I’ll use the core components. We have a section, a view name and referrer should be internal. So of course this is just an example in real life you would have a lot more information about the page potentially about the products on the page and so on. Let’s just fire that one. Now we see this is executing the send event command and I’m going to show you in detail what is exactly set but so just so you see this is firing our page load. Let’s do the same with the CTA click. Here in the CTA I would have just the event info. This is the type other and the target URL is wadernick.com. So if I send this event I want to leverage the state of the data layer. So the page name the section, the referrer, whatever we have here that should be taken into account. Same could be true for an app download. So let me fire that one as well. Event type here is download I have a target URL and the event itself is app download. So as you see that fires again a web interaction and we’re all good to go. So now the platform the edge network has received those requests and depending on our configuration that would be now forwarded to analytics target platform Google, Facebook, whatever we do. Okay so I’m going to have a look later into what exactly we’ve set here. But let’s have a look at how this actually is set up in launch. Yeah I’m going to refresh my session on there. As you see I’ve just installed four extensions. Obviously I need core. I’m using the ECGL. I’m using the web SDK and the mapping table. If you don’t know the mapping table you’ll see later in the data element section and how I’m using it and it can really be handy. So from the configuration I didn’t do much here. It’s really just the default. I configured here my data streams. I have one instance and that’s it. Same for the other extensions. There’s nothing special configured. We can have a look here in the ACDL. Again check out the warning of the core components which are loading the library automatically and also about the renaming. So you can go through all those things here and the additional documentation after the session. Now let’s check out the rules I’ve set up. And you might wonder is that really what he intended to do? Yes I really just need a single rule. And that’s not just the case for my demo. I’ve successfully implemented this kind of setup with a big customer where we’re tracking dozens of events and this is scaling extremely well. So we just need this single rule. Maybe one more for consent depending on where you are geographically. But that’s basically it. So let’s check out that rule. In that rule we are listening to all the events which can happen. So in our case we have the page load, CMP loaded which comes from the AEM core components directly, CTA click and so on. So if you would like to now listen to video end you would just add a new ACDL listener here and listen for the video end, pause, component click, component interaction scroll, whatever it is. Now let’s have a look how this actually is configured. I’m using the ACDL extension event type is data pushed and I’m listening to the specific event of a page load. The time scope is all so I want to listen to everything which happened before the data layer was initialized. So whatever you push into the ACDL before it is initialized and to everything afterwards. So I’m leaving that scope on all. Same is true for the rest of the elements. Depending on your setup you could even go ahead and say listen to all events. But I would be rather careful because that might trigger the rule unexpectedly. So I’m rather a friend of explicit things so everything is defined here and you can see what is triggering the rule. Now you might wonder why don’t I need any conditions? I don’t want to track the same stuff if there is a CTA click and the page load. Those are completely different, right? Well yes, you’re absolutely right. They are very different and traditionally you would have multiple rules with multiple conditions. So on this type of page I need that rule which sets this variable or these variables and then I have three more rules and five exceptions and so on and so on. But all of that is not necessary if we have a clean data layer and a bit of a clever setup. Why is that the case? Well I believe if you have a clean and defined data layer then you shouldn’t need to do a lot of mapping and investing in complexity. So whatever we have we really should just focus on mapping whatever input we have to our respective output. So let’s check out this action here. So in this action I’m just using two data elements. One is the mapping type and one is the XDM. So you’ll see those two data elements now in a second. The rest is the default configuration. The event type is basically one of the predefined types. In our case we’re just going to use page views and link clicks and for the XDM that’s where the real magic happens. So let’s jump directly into it. In the XDM we’re referring to this schema and this schema gives us the structure of the XDM. So in this example I’ve just populated the web. In your case you might want to populate whatever custom fields you have. But now for the sake of simplicity let’s just check the web page details. So you see in the site section for example I’m referring to the event full state page section. That’s going to be automatically retrieving the full state at the time the event was fired then page dot section. Same for the view name and that is actually one trick already. If you have a CTA now and we see in the CTA or here we didn’t push this page information but because it is already in the state we can leverage it here. So we just put it in like that. Now for the page name I’m going to show you how the core components can be referenced as well. One thing you need to consider for the page views here you need a value and you see it’s a number. It’s not enough to just put in a string. It really needs to be a number. And depending whether it is a page view or a web interaction this should be one or zero. So let’s check this out here. This is exactly the opposite. That should be zero if it’s a page load and one if it’s a web page interaction. I’m going to show you how this mapping is done. But let’s just go back to the page view and show you how this mapping is done. But first let’s check for example the type and you might think well I don’t want to set this type if I have a page load, right? Yeah I don’t want to do that. So do I need a condition? No I don’t need a condition because here I’m referring to the event info dot type. And let’s check. You see here in the CTA case the event info is type other. In the page load I don’t have this type in here at all. So this is going to be empty for a page for a page load. Same for the target URL. So those fields are just going to be empty. And this is already the the clue behind this whole setup. I just populate whatever I have into the right field. It’s really just a mapping from A to Z. So based on that I can fill all my fields. Now looking at the time I maybe need to speed up a little. I’ll show you one more thing of the mapping. So let’s check how I did the mapping for the one and zero. So in this I’m basically using the mapping table data element. So I’m querying the message event which is in our case it’s page load or CTA or app download. And based on that I’m then going to return based on the match an integer zero or integer one. So if it’s a page load or CMP loaded I want to say this is zero for everything else. It’s a regular expression matching everything. For everything else it’s going to be one. And that’s basically it. You can have a look at the details how this is implemented and how you can reference the core components. But for the sake of time I’m going back to the Q&A now. And later I’m going to share at the end of this presentation I’m going to share a link collection where you can find the best just released recently which includes exactly this example. So in this example you have all the code and whatever is used in this what I’ve just showed you. Let me just share that again. Right. So if there are any questions then I’ll have a look now and those are the resources. But you’ll find the link collection later after the session is over. This will be accessible for all of you. Alright. Now let me actually look in the Q&A now. Should be something like interface Adobe Data Layer Okay. Let’s check the questions. There are no unanswered questions. That’s good. Seems like you guys already had a good time in the Q&A. Perfect. Any other questions? If so, please just post them now. Either in the session chat or in the Q&A. Alright. Let me check the session chat. Is the mapping table extension required to use the ACDL extension? No. The mapping table is not required. It’s just very very handy and it’s used by hundreds of customers in production. So it’s basically a very powerful tool where you can do whatever if else nested concatenations and queries in a very visual and easy to see way. So like you’ve seen I’m mapping based on the event type, based on a given payload and so on. So feel free to use it but you don’t have to. If you like a lot of JavaScript code and complexity go ahead. If you like it easy and scalable use the mapping table. You don’t see much in terms of API documentation. Well there is a nice wiki which is in the in the resource link. Let me share that screen quickly again. So here you should see the resources. There is a link to the ACDL library on GitHub and in the resources tab you can see the link to the GitHub and in there there is a documentation about the API of the ACDL actually. So again this will be shared after the session but in there you will find everything including the Web SDK best practices what I’ve just showed you step by step tutorial. Same for the old analytics and target implementation. Thanks for posting Julian. Then which AEM versions can utilize the ACDL integration? So that’s a question for my colleagues in the chat. So I’ve actually asked one of the AEM experts to be here as well. So I would believe, I don’t want to say anything wrong now. So it really depends on which version of the core components you’re using. So Elisa is the question from which version on of the core components the ACDL is included? Okay so let’s see what my colleague can answer in the chat. Then I see one more question from Simon in the Q&A. How would you trigger let’s say showing some target content after waiting for both a particular library to load and some async call to get some data into the data layer? So let’s see. I want the target content for both library loaded and some asynchronous call to get data into the data layer. Now the library load that would be one event. I assume you are not talking about the ACDL library loaded but some external library loaded. So that could be one thing. So once this library is loaded you would trigger an event, push it to the ACDL and then you would say maybe you have to wait for two events. So you could say once this event is fired I’m writing something in the state and in the state now I know okay library XYZ is initialized. And then next time I get this asynchronous call to get some data into the data layer I can use that and say if I have the library initialized in the state and this event happens then I can fire my target content. So that’s the state. That’s the advantage of the state. The other question would be what would you like to do if you get this call before the library is initialized? So then it’s anyway up to you if you just discard the call or you keep on waiting until the library is there so then it’s up to your business logic. Alright. Any other questions I’ve missed out? I see someone wanted to see the data layer state. Yes. Let me show you that to you. Here we go. Get state. Now you see this is a mix between what we’ve set in our events like this view, referrer, and what the core components are delivering us. So like I said before, we’re going to have to check the data layer that we’re delivering us. So like you can see here the page and this hash is coming from the core components this section is coming from our custom code or from our custom data layer push. So now if you check the DC title you will see that this is sent in every request here. So if you check the web page details, the web page name is going to be the one provided by the core components and the site section and so on is picked up automatically from our payload. If you check the web interactions you see here the link click is set to one the page view is set to zero and we’ve set our type and name. So that is actually the magic behind all that. So thanks for answering the question from Elisa. ACDL is available as part of the core components since version 290. Latest version 2.x of ACDL was provided as part of core components 215. Perfect. So there you go. Thanks for answering. So now we’re going to check the data layer and see what we’re answering. Alright. Perfect. So thank you very very much for your attendance. It was a cool session and I think there’s a lot of potential when you use the ACDL and an event-driven data layer in general. So it gives you a lot of flexibility and if you have a clean setup, I cannot stress this enough. If you have a clean setup the mapping to an EVAR in analytics or a field in a schema is really easy. You don’t need to do a lot of transformations ideally. So if you have a good data layer your life is going to be easy. So invest some time, make sure you have a clean setup and then you’re ready to go. Alright. So again I promise to share the slide deck with you with all the links and you can also check out this best practice guide with a complete tutorial of how to implement it yourself and whatever you’ve seen today. There will be a recording as well and make sure to check out the previous recordings as well of the previous Adobe Developers Live and ADAPT 2 conference where we showed how to use the traditional Adobe Analytics and Adobe Target extensions and ACDL to work together. So with that said that I wish you all a nice day, evening, afternoon, wherever you are and all the best. Would be nice to keep in touch with you on LinkedIn. Reach out if you have some interesting success stories about the ACDL or the Web SDK. Talk to you soon. All the best. Ciao.