51ºÚÁϲ»´òìÈ

Hey everybody, welcome, welcome, welcome to Experience League Live. Got my shirt going and everything here for you this morning. And welcome to the show. Let me get that going there. There we go. So my name is Doug. I’ll be the host today. We got a great show coming up. Before we jump in and get talking about the show, I want to let you know that we are brought to you by experienceleague.adobe.com. So Experience League is your one-stop shop for everything self-help. And so we have, you know, the documentation is on experienceleague.adobe.com. You’ve got tutorials and courses in the community and everything’s there for you so you can, you know, teach yourself all this great stuff so that we can, you know, teach you through tutorials as well. So I hope you’ll go there and get used to going there for all of your self-help. Okay. So we’re going to talk today about the Web SDK. We’ve got two great guests. So let’s get these guys in right away. First of all, coming up right here, we’ve got Mitch Rice. Hey, Mitch, how you doing? Yeah. All right. How you doing, Doug? Good, good. And then let’s get Joe in. We’ve got Joe Corey. Joe, that was a bigger one. I don’t know. We get… And if we, you know, we’ll choose a word or something. If we say the magic word, I don’t know what it is yet, then we’ll give one of these. That’s right. So whenever we have something good, we’ll sound the air horn today for you. So welcome, guys. Welcome. We’re going to talk about this is the way to migrate the analytics to Web SDK today. So we’re excited to dive in and talk about that. Before we get into the topic, let’s just take a minute and let the people know who you are. So, Mitch, tell us your title and what you do all day. Let’s start with that. Yeah, definitely. So my name is Mitch Rice. I’m based here in Utah and I’m the product manager for data collection. So that means I own the SDK, the Edge network and then a couple of other things as well. I’ve been with 51ºÚÁϲ»´òìÈ for probably about 10 years now and yeah, loving it. Awesome. Great. Joe, tell us what you do. Yeah, so Joe Corey, I’m the engineering manager on the web portion of the data collection. So my team owns the Web SDK, the tags extension and the debugger that we’re going to see today. Awesome. Great. So we’ve got the official brain trust today and then we’ve got me. So maybe I’ll try to keep it light and you guys get into the meat of the stuff. Okay. And so, yeah, before we dive in, Mitch, it said that you like to go hiking, especially to see the petroglyphs. Is that right? Is that what they are? That’s what I do on the weekends. Yeah. Yeah. In fact, I’m going camping tonight. I’m looking forward to it. We’ve got beautiful weather in Utah right now. So I’m going to go camping and then try to get back in time for my first meeting tomorrow. Well, I mean, if you have, you know, if you have wherever you are, you know, if you have a connection, then, you know, you can just pretend like the trees and everything in the background are just, you know, a background for teams. So don’t you like this background that I put on my computer? Yeah, I could do that. I guess I could just take my laptop camping with me and take the meetings up there. That’s right. Cool, cool, cool. So, Joe, your fun fact, Australia, right? Yeah. Tell us about how you ended up sailing, I guess, or something in Australia. Tell us a quick story there. Give us the short story. Yeah, the short of it is the company sent us there to deal with an escalation. They sent us for a whole week and we were able to fix it in one day. And we spent the rest of the week sailing and bike riding across Australia. Oh, okay. Nice. I thought, you know, it was in an earlier life maybe where you’re like, you went there and you’re like, oh, this is my thing now. And you quit your job and you bought a little sailboat and that was your life for a while. I wish, no. That would have been a better story. No. It would have been. Awesome. Okay. Well, that’s great. I hope to get there someday myself. Awesome. Okay, guys, great. We got a lot of great stuff to talk about today. So let’s dive in. And I think if I’m not mistaken, you guys can correct me, but I think that we’ve got some stuff today, a little bit of stuff for people who are still kind of getting used to, you know, what Web SDK is. So we got a little bit there, but we’re going to maybe focus on the migration of, you know, analytics and a little bit of target, but mostly analytics to Web SDK from app measurement, you know, implementation. So I think we’ve got a little bit for today for people who are pretty new and a little bit for people who maybe have already been dipping their toe in this migration and we’re doing it kind of what as of today we’re going to call it the old way. So is that fair? Yeah. Yeah, it is. And maybe just to provide a little bit of background. Yeah. You know, we’ve been doing edge data collection for experience platform now for a couple of years. And one of the things that we’ve heard from a lot of customers is that moving to the Web SDK on its own is not necessarily super difficult. But when we combine that with the need to migrate to XDM at the same time, there’s a lot of baggage that comes along with that. And so what we’ve been working on over the course of the past several months is trying to decouple, you know, that that move to the Web SDK from the migration that’s required to XDM. And so that’s what we’re hoping to talk about a little bit today is what decoupling those has looked like and what it means now if you want to move to the Web SDK without necessarily having to adopt XDM right away. Yeah. Cool. Should we move over to some slides for you, Mitch? Let’s do. Let’s try this. All right. Great. Yeah. So, yeah, before we really get into the demo, let’s just cover a couple of basics related to edge data collection and then we can jump right into what this might look like. So most people here should be familiar with the platform edge network. Basically, it’s a number of servers that we’ve distributed around the globe. These servers are able to interact with all of the experience platform and experience cloud solutions. So what that means is that when you send data to the edge network, you’re able to send this to 51ºÚÁϲ»´òìÈ Experience Platform, as well as the experience cloud solutions like Analytics Target and Audience Manager. So along with the edge network, we’ve also built a Web SDK. We’ve got a new mobile SDK. And basically, these are the means by which you’re going to communicate with the edge network. We’ve also built a server to server API that communicates with the edge network. The server API is a little bit unique because it supports authenticated interactions with the edge network. The cool thing about building all of these from the ground up is that the SDKs in the API all use the same methods, use the same API calls in data format to communicate with the edge network. So the data format, as I alluded to just a few minutes ago, is XDM. And while it provides the ability to use the exact same data format to communicate with all of the 51ºÚÁϲ»´òìÈ solutions, there is a significant amount or there is some work required in order to be able to set up your XDM schema and get some of your data converted over to it. And so like I mentioned, our goal here is let’s decouple that move from all of the data formats that you have been using to XDM from the move to the Web SDK or to the mobile SDKs.

So on the other side of the platform edge network, we’ve got the 51ºÚÁϲ»´òìÈ solutions. So the platform edge network is capable of interacting with all of the experience platform solutions, including Journey Optimizer, Realtime CDP and Customer Journey Analytics. Additionally, the edge network is capable of interacting with Analytics, Target, Audience Manager. And you can control how the edge network interacts with each one of these solutions using something that we call data streams. So basically, data streams is a control panel that you can use basically to quickly and easily toggle which solutions the edge network is going to be interacting with.

Yeah, cool. So if I’m looking at this, I don’t know, you’ve kind of made the dim to the left hand side, but which is fine. But so the data collection you’ve got over there on the far left, data collection in platform tags. So, for example, I think we’re going to look at like the Web SDK in tags, right? Formerly known as launch for those of you who know it as launch. And then that can send the data over to the platform to the edge and then the edge through the data streams will kind of be a traffic cop, right? To say, oh, we’re going to send this data to Analytics, Target, Audience Manager or to the platform. Exactly. Yeah. OK. Yeah, so kind of the final element of edge data collection is something that we refer to as event forwarding. So with event forwarding, you have any event that’s sent to the edge network is eligible also to be sent or forwarded on to a variety of third party destinations. So if you have use cases where you’re wanting to send information to a data warehouse or to a conversion API, you can actually extract any values from the events that you’re sending to the edge network and forward it on to anyone, any of these third party destinations. So we’re probably not going to cover this too much today, but just want to kind of give you a full picture of data collection in all of its composite parts.

Yeah, nice. Yeah, I like how this is set up so that we can see that data kind of mostly moving from the left to the right and of course, some responses and all that. But getting that data into those different applications and I guess like we said, you’ve been talking about decoupling this. So before we had the stuff that we’re going to show you today, everybody, you basically had to, and you guys correct me if I’m wrong, but you basically had to put it into XDM and then bring it back to like props and EVARs for analytics, right? Exactly. And the same thing for a target or audience manager. You had to like, hey, bring it over. You have to go into XDM then, oh yeah, let’s bring it back to props and EVARs. And so that’s where you’re decoupling that need to do that. Is that right? Yeah, absolutely. And one thing that we’ve heard from a lot of customers as we’ve spoken with them is that even though they’re really interested in moving to the experience platform solutions, they don’t necessarily have the ability just to cut over and forget about all the data and everything that they’ve been doing with analytics, target and audience manager for all these years. And so what we’ve heard from customers is that, yeah, let’s make this cut over to the experience platform solutions. We need to keep sending our data to our legacy solutions. And what we’re going to show you today is really kind of the best and cleanest way for a customer to be able to do that. So let me actually show you one of the key changes that we’ve introduced recently. So basically on this slide, we have a sample payload that could be used to send data to the edge network. You can see within this payload that we have here at the top, we’ve got an XDM portion of the payload. We’ve also at the bottom, we’ve got a data portion of the payload. So until now, we’ve really told customers, bring your data object to the edge network. And that should mostly be your data layer and then extract values from that data layer, map it into XDM and then go through that process that you mentioned just a minute ago of converting these values to XDM. And then getting them back into the formats that are compatible with the experience cloud solutions. Basically, what we’ve introduced here is the ability just to pass this data through in the legacy formats without having to do any remapping or anything like that. So basically here in this object, you can see that we’ve got our event string and our product string that are both part of this analytics object. What this means is that you can pass through those key value pairs in terms of your payload, and you don’t really have to worry about doing any sort of mapping. So if you’re familiar at all with how things were done previously, products does not need to be mapped into product list items in order for this data to pass through to analytics the same way that it always has. Basically, you just provide this value and it’s going to be processed the same way that it always has been. Same thing for everything else here. So it doesn’t matter whether or not we’re talking about the products variable or props, or context data for analytics, or even any of your audience manager information or target parameters. All of that can be passed through without having to really massage this data and be able to get it into those solutions, the experience cloud solutions.

Yeah. And you mentioned the different ways we have the Web SDK and everything. We not only do it by code like this, but we’re going to show you that you don’t have to put it into code because we can use tags and just do the mapping, just like you used to in tags and launch into the analytics variable. But now we can just kind of map it into the data variable. Yeah, absolutely. So this is kind of what it would look like if you were doing the code client side. Like you said, you can also do it in tags. We’ve also got a tool that we refer to as data prep for data collection that allows you to take any value from an incoming payload and then map it into XDM as necessary. Nice. Hey, before we get moving too far, we have a question. I’m going to bring it up because it was partially about event forwarding and we’re not really coming back to event forwarding too much in this call. So I’m going to pop it up here before we move on too far. And so I think we want to talk about cost a little bit. And so here’s the question, right? Does 51ºÚÁϲ»´òìÈ charge any cost for event forwarding, which is a server call used to forward from Edge to Analytics? OK, we’ve got to make sure we’re talking about the same thing here. Now we have Web to Edge one and Edge to Analytics two. Not sure I totally get what is there, but can you guys kind of speak to this a little bit? Yeah, absolutely. So in terms of this diagram here, sending requests from the Web SDK, Mobile SDK, Server API, sending that to the Edge network is going to result in requests that are being sent to a variety of different upstream solutions. So, for example, if you’re sending a request using the Web SDK to the Edge network and then you’re forwarding that request on to Analytics, you’re going to be charged the exact same that you would if you were using App Measurement Library. So there’s no change in terms of whether or not you’re sending to the platform Edge network versus the Analytics Edge network.

When it comes to these third party destinations, there is a per request charge. For example, if you wanted to send this on to a meta conversion API or a Google conversion API.

So if you are planning to send data to a third party, yeah, there is a charge for that. But for any of the 51ºÚÁϲ»´òìÈ solutions, any of the costs associated with that would be exactly the same as the costs associated with sending it with one of the other APIs that you can use to interact with the 51ºÚÁϲ»´òìÈ solutions. Okay, great. Thank you.

Great question. So, yeah, let me go ahead and pull up the next slide here. So moving on from the prior slide that we had where we were kind of showing the anatomy of a request being sent to the Edge network. One thing that we’ve heard from a lot of customers is that they really, they would like more guidance in terms of how they should be moving to the Web SDK and to Edge data collection and what that process might look like. And so this is, let’s say that this first slide here basically represents in your existing implementation. Now, you may or may not be using all of these solutions, but as a general rule, you know, in the upper left hand corner, we’ve got the analytics extension, we’ve got the target extension and audience manager. And each one of those extensions are sending data to the respective solutions with data that are in a very specific format. So for analytics, you’re sending props, EVARs and events in your context data. For target, you’re sending your parameters. What we’re proposing with some of the changes that we’ve made is that keep sending those key value pairs that you have and that you’re using right now. So keep sending your props, EVARs and events, your target params using the Web SDK rather than the individual libraries that you’ve been using previously. Once those values or once those different pieces of data have been sent to the Edge network, you can then use data prep for data collection to map any value from that incoming payload into XDM. So the moment that you start sending data to the Edge network, you are given the you then have the ability to send that data to the experience platform solutions and to third party destinations using event forwarding. And so what we’re recommending to most customers is go ahead and send your props, EVARs and events. Those values are going to flow through completely untouched to the respective experience cloud solutions. So in this particular case, your props, EVARs and events, they’re going to continue to flow to analytics completely untouched. But you have the ability using data prep for data collection or potentially even tags to map this data into the XDM that’s going to be required to be used with the experience platform solutions. So ultimately, this is what your payload is going to look like just before it’s sent to each one of these respective solutions. So this is this is really the approach that we’re recommending that most customers take in terms of being able to move to Edge data collection with as little effort as possible. Now, if at some point you choose to disable the experience cloud solutions, it’s just a matter of then going into data streams and turning those solutions off. All of that data will still continue to flow to the experience platform solutions. And all of those mappings that you’ve done will continue to work in the same way that they that they always have. Yeah, you get to choose where you know where it’s going at any given moment. Yeah. Yeah. Yeah. Pretty really easy. We’ll see in data streams in a second. Right. Pretty, pretty easy to map things and send it over. I do want to pull up a quick question here by Brian who might be worried that app measurement is going to be going away. And then in the second question said, if it’s true, then when? So so as we’re talking about this, we maybe want to reassure anybody about that. Yeah, app measurement isn’t going anywhere anytime soon. There are no plans to deprecate it in the near future. Yeah, so we’re good there. And I’ll keep keep an eye on these questions. We’ve got some other ones here. Let’s see. Joseph, can I keep the is a good question here. Can I keep the 51ºÚÁϲ»´òìÈ Analytics extension and remove the sending portions? Then I create a data element that formats my S object to match the schema and send to the SDK. I think we’re going to kind of show you. Yes, Joseph, how this will work. So I hope that we’ll kind of answer this as we move forward. Right, Joe. And just kind of show exactly how this will this will work. And yeah. So let’s table that a little bit. So if we can, we’ll show you how that will happen. OK. Cool, cool, cool. Can we go to the question from Eshaan? It’s something that Joe, I think, can show in just a second as we are as we’re running through the initial configuration of the Web SDK. But the question here is, is there a way to retain the same unique visitors when we migrate from 51ºÚÁϲ»´òìÈ Analytics to the Web SDK? And we do have a way to help migrate. Joe will show what that configuration looks like. But it’s actually really, really straightforward. So to to maybe take a bit of a step back. We still use the ECID as our primary method of identifying visitors in analytics, regardless of whether or not you’re using the Web SDK or that measurement. And so as long as that cookie still remains on the on the end user device, both of those libraries are able to pick that value up and then and then report that to analytics. And so you shouldn’t see any sort of visitor clipping or anything like that associated with moving to the Web SDK. Great, great. Yeah. And Joseph, just as a follow up, keeping your analytics extension, you can do that. But if you’re going to. Because what are the ramifications, Mitch and Joe, about, you know, if you if you migrate over to the Web SDK like as well and you still have your analytics hits going in. Via the analytics extension. Yeah, I think it’s right. Yeah, I can I can get to it in my demo for a little bit. I think his question is he wants to remove the send beacon action, replace it with send event. But he wants to keep the data layer and all the data elements using the extension because it would require some cleanup. Right. And today you sort of we can dig into it when we get to the demo for sure. You can use that variable with send event, for example. That’s not supported today. OK. I think somebody’s let’s. Mitch, is that what you were going to show? Do you show me move over to. Yeah, let’s go ahead and just jump into that demo. Yeah, Joe, why don’t you share me kind of look at some of these. Questions here. While we’re. Move that over there for you. OK. And I think I think going through some of this will answer some of these questions. So let’s get going and I’ll kind of try to keep an eye here out anyway. But but Joe, why don’t you jump in here? OK. And you can pause me if I don’t cover something and I’ve moved away from this area. Just pause. OK. OK, so let’s let’s set a little context and then we’ll jump into the demo. So we put together a very simple website for you today. It’s just a little e-commerce website with clothing on it. It has a banner in the middle that would be personalized by Target. You can add stuff to the cart. And we did create a Target offer where if you add, you know, product for more than one hundred dollars to this. Let’s add this dress, for example, if you have more than one hundred dollars in your cart and if you go back to the home page, you are going to see a very simple Target offer. And from a from an extension perspective or from a data collection implementation perspective, we have a simple property. The usual suspect analytics, Target and visitor ID or ID service implemented. We have three simple rules, one of the maybe the most complicated one, if any, is this one, because we want to send the cart total basically to Target to qualify for the offer. Everything else is just simple strings, page name, property name. And then if we go up, we have three also simple rules. We have an analytics page view where we’re using set variable, send beacon, very, you know, vanilla setup. And we decided to have another a custom link click that we’re going to show you how to migrate as well. And of course, there’s the the Target personalization offer. And this is where we send the cart total to qualify for the offer. So this is really the setup. And we’re going to try to see how time allows, but we’re going to try to migrate all of that to the Web SDK. And, you know, I have the debugger open here just so we can show changes as we go. As you can see, we have. Yeah, that was some of the questions about, you know, are we going to can we still see, you know, in the debugger, can we still see stuff as we move to the Web SDK? So yes, John’s going to be showing some of that. Yeah. Yeah, absolutely. So, you know, if you go to the network, for example, you can see the analytics hits and you can see this is because I switched to it. You can see the target page, you know, the target hit. Everything is still here. We just added the Web SDK as a new SDK. OK, so let’s start by installing the Web SDK. And we’re going to go to the catalog, we’re going to look for Web SDK. This is an internal org, so we have like a bunch of testing ones. We’re going to use the latest and we’re going to hit install. I’m going to try to cover some of those questions as I go through this. I’m not going to cover everything in detail, Doug, but in general, it has like one configuration page. This is where you connect your Web SDK to a data stream, which is similar to that UI that Mitch was showing. Let me hide this out of the way. We’re going to choose the Summit sandbox. And then I went ahead and created an empty data stream for us for today. So we’re going to go in and are we going to go in and see the data stream in a minute? Yes, I have the data stream actually. Yeah, it’s good. I just want to make sure that we’re going to see that right. OK. Empty and simple. And then we’re going to start adding to it as we go. We have a simple privacy section. Somebody asked about migration. The config to enable migrating the EC ID from visitor API to the Web SDK is on by default. You can turn it off if you’d like. But if you don’t want any visitor clipping, this is how you would do it. Another person asked about third party cookies. This is how you would turn off third party cookies. As Chrome starts releasing the change to drop third party cookies, we’re going to sort of deprecate that whole concept of third party cookies in the SDK. And you don’t have to do anything. It would just work. There’s more details here. I’m going to try to skip just for the sake of time. The only thing I’m going to do, I’m going to disable click tracking, mainly because I want to show you how you can migrate a custom link click. That’s the only reason I’m doing this. Otherwise, the SDK is able to track clicks for you if you’re OK with that. And that’s it. I’m going to hit save. OK. The first thing I want to do before even I start migrating the rules, I am going here and I’m going to create I’m going to add a service to our data stream. We’re going to start with analytics. And the only thing you have to do is just specify which report suite you would like to add. Time out. I’m going to be the be the guy, the timeout guy a little bit. So, yeah. So when we were looking at the architectural drawing and we had the edge in the middle, it’s kind of where I picture also this data stream, you know, UI living right there. Right. That’s kind of this. So you guys see there on the left side, it’s data streams. You go in and created. Joe just went and created a new data stream ahead of time and just named it and didn’t do anything else. Is that give me a new data stream and that’s it. It’s a name, right? That’s all it really was as far as creating a new data stream was just saying, give me one. And then he just named it. And then and then now you’re you’re saying, oh, yeah, I’m going to stuff that comes in here from the Web SDK. I’m going to send to analytics, you know, and then explicitly to this report suite. Exactly. And you can optionally send it to multiple reports, please. Or you can start doing some override stuff again. It’s a little bit over the scope of this demo, but lots of things. Simple. Yeah. Simple. Just we’re going to add analytics. And now what I’m going to do is I want to show you. So we are going to migrate basically these rules into the Web SDK world. Everybody who has used SDK, the analytics extension, I guess it’s called before, is used to this UI. They’re used to set variables where you go in here and you can set stuff on the global S object. Right. So these these naming should be, you know, familiar to people. So if you go to custom code, for example, all we’re doing in this UI is just populating variables in this guy, the S object. So I have a little custom code here that we’re setting and I have a couple of little variables and props that we’re saying we’re going to do the same thing with the Web SDK extension now. But the only main difference is that we introduce this concept of a variable, mainly because we want to avoid doing the whole global S object concept. We want it to be a little bit more contextual and more, you know, useful, I guess, because you can create multiple variables. We introduced this concept of a variable. So a new data element type. Yes, sir. A new data element that I’m going to name it page view variable. And we’re going to choose the Web SDK and the type is variable. I’m going to go slow here, but if you see any questions, just pause me. Yeah, there’s a billion questions, which is wonderful. I’m sorry. Let me let me just pause and say, you guys, don’t worry if we don’t get to your I’ll try to get to as many questions as we can live. If we don’t get to your question live, we’re also going to have a community discussion that I’ll point you to at the end. And we’ll answer the questions that will bring them in from the call. And you can continue to ask there. But we want to get to as many as we can while we are moving along. But yes, so keep going, Joe. And I’ll go to. OK, so for the sake of this demo, I decided to create two variables, one for the page view hit and one for the link click hit. You don’t have to you know, you can. And you can create your workflows, however works for you. I like to keep things clean for each event. I’m going to create a separate variable. And similar to what Mitch was showing you, if you’re sending data to platform, this variable type would be XDM. For today’s demo, we’re going to send data in the data format. So we are going to choose the solutions we’re going to send the data to, mainly because we’re going to regenerate a UI for you. So that’s all we have to do here. We’re just going to do a page view variable. So that was remembering what Mitch showed us about the variable called data. Right. Sometimes it’s a data variable. Yeah, but it’s called data as well. Right. So don’t get that mixed up. Yeah. And so as you were looking at. OK, so. Exactly. So here’s what we’re going to do. I’m going to start replacing these one at a time. I’m going to start with set variable and we’re going to replace it with our own version of that UI. And we call it update variable. Now, we made some enhancements. This is a little bit big because I zoomed in my page, but we made a little bit of enhancements to this UI. We have sort of pre-generated the little tree structure for you to show you that data object in a visual fashion. You can set your variables here. Your E-vars, for example, let’s say I set, you know, E-var one to page type. Just going to keep it simple. Doesn’t really matter what we do here. You can set your props. I’m just going to set my prop one, for example, to maybe the property name. You know, you can set your events. If this is like an add to current or something, you can set your context data, which I think this is new. And, you know, we didn’t have that set variable. You have the additional properties section where everything else goes in here. Like, you know, maybe the link name, which we’re going to use soon, or the product string, which is an extremely important concept, which we’re going to cover again in a little bit. And then there’s the custom code section. Can I stop you before you go on the cover, for example, scroll up a little bit. So as you are creating this action, kind of to mirror or replace the action that was already there for analytics, as you migrate from analytics over to WebS-C-K, what you would normally do is probably like write down or something, right? You’d know what you have in the analytics action. Oh, I’m setting E-var one to this, E-var two to that, E-var three to that. And then when you come in here and you’re updating this S-D Web-S-C-K variable, you would set the same ones. Yes, sir. Right. So we just didn’t happen to look at, you know, to write them down and replace it in here. But as you’re putting, you know, whatever in E-var one and prop one here, basically what you guys would be doing is like, you know, mirroring exactly what you had in the analytics action and putting it in the Web-S-C-K action. That’s the migration. Exactly. Yeah, exactly. I’m skipping some steps for sure. But the other so I’m glad you asked me to scroll up, Doug, because one new thing that we’re doing here is that we’re allowing you to have a text editor, which is sort of new. It wasn’t there in that variable. So you can like copy stuff from like a, you know, a console log and then you can just paste all your variables in here in one shot and you can go back and forth. Yeah, that’s really cool. And then the last thing for people who are used to set variable and clear variables, you can have we have the same construct in here. I won’t be using it because I decided to go with a different variable for each type of event. So I’m not going to be recycling the same variable. OK, let’s go to custom code because there’s quite a bit of stuff that we’re going to use here. I won’t cover this for now, but I went ahead and sort of pre-created the custom code that I want to use. So this was the code that we had in the legacy analytics. I’m going to copy this. I’m going to make it a little bit more complicated so that people can understand how we can do this for like a complicated use case or like a little complicated. So the first let’s cover them like one portion at a time. The first portion up here is, like I said before, we don’t have this concept of global as object anymore. But you will have references to this variable everywhere in your custom code. Everybody who use analytics is used to seeing this stuff. S dot whatever. S dot events. So what I’m going to do is I’m going to create a local S variable just for my custom code for this universe in here. And I’m going to assign it to the data object. Right. So this content is sort of a dynamic variable that it can be XDM if the variable is of type XDM or it can be data if the variable is of type data. But this case, think of this as data that 51ºÚÁϲ»´òìÈ got analytics. And this way, you don’t have to change too much in your custom code. Like, notice, I did not touch any of this stuff. Everything still works because I already defined this missing piece. And I added one more thing to make it a little bit more complex. I know that a lot of customers use the analytics plugins. So for the Web SDK, we have those plugins. We have something we call common Web SDK plugins extension. But some of those plugins are not implemented. We decided that they might not be useful or something like that, or we didn’t implement them yet. So if some of the plugins, the legacy plugins that you’re using are not there, you can’t find them. You can always go to the documentation, find the plugin that you use, and you can always copy the code as is and put it at the top of your custom code. And this way, when you have something like this in here, like the append list, this should keep working as expected. So I guess my advice is use the top portion of the custom code to predefine things that might be undefined in the new world. Like the S object, like any plugin that’s not implemented. Okay, I’m going to stop. I know I went through a lot of stuff. So I’m going to stop here. I’m going to hit save. So now we have the custom code. We have the E-vars. We’re not doing target yet, so we’re just going to do analytics. Okay. There was a question. I am going to stop you real quick. We had a question. We have a lot of questions. I’m sorry, everybody, if I don’t get to them, but we have one that said, here it is. What if we only need to move 50 percent of our site? Like the easy part to WebSTK and leave most applications for the later stage or most portions of our site for later stage. Can we do only part of our site or part of our group of sites, etc.? We can. So we can. And if you’re a target customer, we do have an option, a configuration in the config pages of the extension. I can go back and show you in a second where you can flick a little checkbox to take care of going between page A using WebSTK target and page B using ATGS target. So we sort of handle that for you. But yeah, you can move one page at a time, one section at a time, however many resources you have to do that work. Okay. Thank you. Awesome. The first action that you showed there, you were just replacing the set variables. You didn’t send anything in, right? You just set it. Yeah, I did not send anything in yet. So we’re going to do that next. I’m going to add a replacement for send beacon. We call it send event. And we’re going to make it extremely simple. So you can optionally, you can choose a type. Let’s say it’s a page views type or whatever. It doesn’t really matter for analytics. And the only thing you have to do is you have to go and point the data portion of the send event to that data variable that we just generated together, the one with the E bar and everything. And for analytics, that’s really all you have to do. That was the new data element that you created, right? The new type of variable. Yeah. Oh, yes. Yes, exactly. Yeah, it’s a new one. Yeah. The page view variable. Yeah. Yeah. Now for this demo, Doug, I’m going to remove the legacy actions. You don’t have to. If you’re just migrating and you want to verify that things are working as expected, or you want to open the debugger and see like the app measurement hit, and then you want to see the Web SDK here, make sure that you can keep them both on the page. I choose just for the completion of this demo. I’m going to… Take out the legacy stuff now. You only have a Web SDK. You only have the Web SDK actions. One thing to note there, though, is that if you’re sending the data to the same report suite and you’re using the Web SDK to send that data as well as that measurement, there will be two hits. And so you could effectively double your traffic overnight. So that’s one thing to be aware of is that if you are doing this comparison, you need to be very careful about pushing these changes to production. Yeah. Right. In other words, create a report suite potentially in analytics specifically for development from the Web SDK so then it’s not going into your production report suite. Right. Exactly. Okay. Yeah. I’m going to… For the sake of time, I’m not going to build and demo that page view change and then do the same thing with the link. Let me just migrate the link click for you and then we’ll stop and demo and then we’ll do a target. Okay. So, again, we have a very simple link click and we have a send beacon and it’s a custom click, right? And then the link name is all truck. I’m going to copy that and I’m going to… Again, I’m going to follow my paradigm. You can do it however you want, right? However makes sense to you. But I’m going to create a variable just for the link clicks to keep it clean in my opinion. But we’re going to do this. We’re going to name it an analytics variable. And then now we’re ready to go back to this, to the link click rule. And we’re going to follow the same process. We’re going to update variable and this time we’re going to choose the link click variable. And if you go down to additional properties down here, we’re going to choose link name and I’m going to use the name I just copied, which is all truck. And then link type. And if you… As you know from analytics, as long as you have a link type and a link name, this hit should be considered a link click hit and not a page view hit. Okay. So now we set the data. All we have to do is send the hit. So back to Web SDK, send event, same thing. All we have to do is select the link click variable that we just populated. And we’re going to hit keep changes. Now I can get rid of send beacon. So the beauty about this is we’re reusing data elements. Maybe this is similar to or it relates to what Joseph was asking where if you have a bunch of data elements and they’re full of S dot products and S dot events and V bar one and whatever, you can reuse all that stuff. You don’t have to change your data elements or map them into XDM or do anything with them. Okay. So I think I’m going to stop here. Let’s build and let’s demo. We can cover some questions now. Maybe Doug while I’m building. Yeah. Gosh, there’s so many. Okay. Let me see. I’ve got one. So Michael Jansen, you asked if we can talk a little bit about the expected differences in the speed and size between the current app measurement set up. So we’ve done some testing, but it wasn’t just head to head Web SDK versus app measurement. What we did is we pulled in the audience manager library, we pulled in the the admin or excuse me, the the ECI library or visitor JS as well as target because because the Web SDK is able to interact with all of these solutions. We felt like that was the fairest head to head. And basically what we did is is we ran a number of tests where we where we put the Web SDK head to head against visitor target analytics and audience manager. What we found is that we were able. So first off, the libraries are about 73 percent smaller with Web SDK than it is with those four discrete libraries. The other thing is that as we were doing running our tests, they ran about 66 percent faster using the Web SDK than if you were to use those separate libraries and fire each one of those requests separately. So I don’t know if we can share this blog after after the fact. This is some of this outline, some of the testing that we did on our own. But the bottom line is that it’s significantly faster using the Web SDK versus the four discrete libraries that customers were using previously. Cool. Awesome. OK, so let’s go back to our Web page. Notice I had refresh. Nothing has changed. We’re still getting our target hit. And if we go back to the debugger, now we have a Web SDK extension showing up in the summary. And if we go to the network, notice how let me refresh because I went to another page. There’s no more analytics hit. Right. We can only see a Web SDK. And then if I click on this link, for example, it should show that now we have a link click. And then let me see. So if you go to the new solution in here, we made some little changes and added some stuff that are SDK specific. We do connect to assurance. I don’t know how many people use assurance on this call, but you can create an assurance session right straight from the debugger. And then you can go back to the home page, for example, this clear. And then you can click on a link and then you can dig into that link. So, for example, that link click shows you that it goes to we call it conductor, which is our edge network. And it shows you all the upstreams. This is the analytics option that we created together. And then if we select a specific upstream like the analytics hit, for example. So, Joe, before we dig into this, let me just let me just take a bit of a step back. So in terms of debugger in the past, as you have been as you’ve used debugger in the past, it’s basically been inspecting hits as they leave the device and before they’re sent to the edge network. What we’re looking at here is the communication between the edge network and the upstream solutions. And so if you’re not using this transaction view or the server side view within assurance, you’re missing out on a lot of the magic that’s happening in terms of how the edge network works. So there have been a lot of questions here specifically about using assurance in relation to the edge network. Like I said a moment ago, if you’re not using the edge transaction view or the server side logs, you’re going to miss out on how all of these values are mapped into their actual analytics. So let’s pop back over to the transaction view and show what we mean in terms of how that link click that you just sent in is actually being converted into the individual parameters that are then sent on to analytics. Yeah, let’s do it. So it shows you that. So like you said, Mitch, right, it shows the upstreams. So let’s say it shows you the mappings that took place because we do some automapping in analytics so we can understand how things work. And then it shows you the fields. So it shows you those bars that we sent out and then all these analytics constructs that you used to the page event equals zero, the page URL, like all the stuff that you are used to. See analytics. You can see them in this view. So, for example, maybe this might be the hit. Let’s see, PPPP. Yeah, so those were the custom code stuff that we set in our custom code. Yeah, we had a couple of questions about the debugger and, you know, will it be updated? And now you can see that it’s being updated. And Mitch, you said it’s kind of one of your things is making sure that the debugger is updated as needed and providing those things. And clearly, I mean, like you said, I mean, where we used to be just from client side only. And now it’s the server side stuff that it’s adding here so that you can see exactly what’s going on all the way through that architectural drawing that we saw at the beginning of this call. So because we’ve moved so much of the processing and decision making server side to this, I mean, you really can’t do data collection debugging without also looking at the server side logs. Yeah, yeah. I wanted to answer this question and it came through from Krishna. We configure data streams in Web SDK for prod, dev and staging. And if my company uses only analytics but not target or AAM, do you recommend even to even use XDM? So two great questions. First one. First one’s yes. Right. We we would configure a data stream for each of prod, dev and staging. Is that correct? Yeah. Because when you in the example that we’re looking at here, where we’re looking just in Linux, you would need to have a data stream that’s going to forward on those requests to a dev report suite, staging report suite in production. And so you would need to push between those. Right. And then and then in here, as Joe’s showing, you actually then in the configuration of Web SDK, you point to those three different environments. So, yeah, yeah, yeah. Thank you. Yeah. And XDM, if you’re only using I mean, that’s the gist of the story, right? If you’re only using analytics, you don’t need XDM. You notice I didn’t do anything XDM related today. Right. Yeah. However, however, I will say, if you’re just using analytics and you’re considering moving to customer journey analytics, then then you want to at least when you’re moving to Web SDK, now you have that option to set up a data stream that goes to platform, which where you would use XDM. And then that is your pathway to customer journey analytics. You know, one of your pathways where you could send that into platform and then pull that from platform right into customer journey analytics. So, so, you know, it’s using the using the Web SDK. Do you have to if you only have analytics? No, of course not. You don’t have to. But there’s a good way to do some future proofing, moving to some platform items as well. Is that is that fair? Mitch, you like that answer? Yeah, definitely. And, you know, to build on that, I mean, if if you’re not using target or audience manager and you don’t have any intention of moving to the platform solutions, there may not be a reason to migrate right away to the Web SDK. It really is going to depend on the solutions that are in play and what your future plans are and relate in relation to the 51ºÚÁϲ»´òìÈ solutions. Yeah, so let’s demo this. So we have six minutes and this is being recorded. I feel like it might provide a lot of value just to keep it in the recording. So, for example, we just added a very simple platform service. Yeah. And then you can go in and data stream and then I’m just going to choose. I have some JSON copy that mimics my data layer, basically. I’m just going to map a couple of simple data variables that I was sending today into XDM. So, for example, you can say I’m going to map, you know, let’s just pick a simple E-var one, for example, and I’m going to put it in a custom XDM field that we created just for the sake of this demo. So you can go in here and put E-var one and see it number. Now this E-var one will make it all the way down to platform. Same thing for if you’re using AGO, for example, and you’re migrating from target to AGO, you can do the same thing. You can grab cart total and you can pass that down to AGO. And we might not be able to see in the next five minutes, but this is how you would create your mappings. You would hit save and now your hits can make it to platform. So, I mean, we have four more minutes, Doug. Do you want me to migrate target? Let’s stick with what we got today. And we can have a follow up session and we can take this further if we want to. I know right here, Mark is asking, so this is all in place in the UI now? Yeah, none of this that we showed is still like beta, right? This has all been released. Everything is in there. So if I kind of jump back, I know we have a lot of other questions here. If I jump back to kind of say, you know, we titled this session, this is the way to migrate. I’m going to give my little 30 second spiel and then let you guys do yours as well. When I say this is the way, what I think of right now is the way to migrate is and I’m oversimplifying for sure. But going in and you’re going to migrate, for example, you’re going to have to create a new data element, at least one of the new variable type. And then and then you’re going to go into your rules and use those and use update variable, just like you used to do with set variable in analytics. And so you’re going to mirror the actions in your rules for the Web SDK that you were using for analytics. I hope that makes sense. And so you can keep your rules in most cases. I’m sure you can keep your rules and just inside those rules, add the Web SDK actions that will send that data to the Web SDK. And, you know, there’s a lot more to it. But that’s kind of the new the new way. And by using that data element, that that that new data, sorry, that data element and the object that’s called data, you don’t have to map analytics stuff, for example, from props and evars to XTM and back to props and evars. You can just put in the data element, do the mappings and you’re done. OK, sorry, that was 30 seconds. But is there is there more to that that you guys want to say this is the new way? This is the way that was the simplified it? Yeah, so I can see that Joe has been working on some stuff in the background. Let’s have him kind of finish out the demo and then I’d love to recap some of the some of the talking points that. OK, great. OK, great. Yeah, let’s do it. So I’m just going to use 10 seconds. So notice I disabled all the extensions. I only have the Web SDK. I have added a target data stream service in the data stream. And now we’re switched to using the Web SDK for target. And maybe the last thing I would I’m just going to stop here and let you mention because we’re running out of time. I’m going to let you give it. It’s OK, guys. Nobody’s with the lights aren’t shutting off in one minute. So we’re OK. We are going to, you know, people might have meetings. And so we are going to wrap up here in a second. But Joe, let’s let’s take a look at the network tab and see what we’ve got now. So now that we’ve disabled the analytics extension and the target extension, basically what we’re going to see at this point is that we’ve only got the requests that are being sent by the Web SDK. But we continue to send the data to analytics. We continue to get our target personalization and we’re doing it much faster than we were able to before. But I think more important than that, we open ourselves up to being able to send this data also to platform. And so if your customer or if your company is moving towards CJA or towards AJO, this really is the way for you to be able to start to set them up for success so that they can start to get value out of out of that that solution as quickly as possible. So that was that was one thing. Joe, sorry, Doug, do you mind going back to my screen for just a moment? Yes. Hold on here. You’re not sure. We reshare, Mitch. Oh, am I? Sorry, I turned off the share for you. Yeah. Well, he’s sharing the. Yeah. OK. Yeah. The final thing that I want people to come away from this understanding is that XDM really is for the experience platform solutions where the data object is for the experience cloud solutions. And we’ve tried to separate this data as much as possible. So one thing I didn’t get a chance to mention before is that when you have this data object, it does not inherently go to the experience platform solutions unless you map that data into the XDM format. And so this is a way for you to use the one SDK in order to be able to interact with all of your solutions, but also keep the data pretty separate. That’s something that that that we’ve heard from a lot of customers that they want that they want in the Web SDK. And so that’s what we’ve worked to deliver over the course of the past several months. So if there’s one takeaway from this whole thing, I want people to understand and know that XDM is for experience platform solutions, data is for the experience cloud solutions, and using this format is the way to keep that data separate. Yes. That’s great. That’s great. Thanks. I put you guys I put a couple of links in the chat. I put one link where I said continue the discussion here. There’s a link to the community discussion where we’ll answer these questions and you can add more questions if you want. And then I put another link to a session that’s coming up in a couple of weeks that is not in the weeds of technical stuff here, but it’s more strategic things that you need to think about when you are when you are migrating. So that’ll be a good session as well. And you can click over to register for that one as well. I hope that that link worked. Let me try to put it in there again. I’ll try that there anyway. So, yes. Try that final link that I put in there. Jose, maybe that’ll work. If those don’t work on there, I will put the links on the page so that you can get to those. But, yeah. Joe, any parting thoughts from you about about this process? No, I think this should make things we’re still trying to even make that process we demo today easier. But this will make migration a lot easier from what we’ve seen from customers, especially if you’re like an AAM customer, for example, and you have to go remap your traits and change them to match the new format. It was a pain. So this is the easiest way to migrate today. Yes. Yeah. And the WebSCC manages the third party cookies similar to ID service we call them. It works exactly the same way Visitor was working the best. Yeah. Great. You guys, I’m also creating a tutorial, a step by step tutorial that we’ll walk through. There is some good stuff in the documentation already that you can see there. If you just go again to go to experience.adobe.com and you can search for migrating to Web SDK and there’ll be some things there already. And like I said, I’m going to add it’s not quite finished yet, but I will add a step by step migration tutorial as well here, probably within the next few weeks. So thank you. We really appreciate everybody coming today. Really glad that you could share this time with us. We will get as much information to you as we can. We’ll take a look at this. Maybe we can have another session. You guys, where we can we can dig into some of the other topics that surround this and and we’ll take a look at that. But other than that, thank you everybody for coming. And again, special thanks to Mitch and Joe for sharing your awesome knowledge today and for all this great work that you guys have done to create this for us to to migrate. So appreciate you guys. Doug, thanks for having us. Yeah, man. Thank you so much. All right. We’ll see you guys next time. Thanks. Appreciate it. Thanks, everybody.