ÃÛ¶¹ÊÓƵ

Transcript

Hello, everyone. Welcome. Can you guys hear me now? Awesome. Perfect. Hello and welcome, everyone. Thank you guys for joining today’s tech sessions. My name is Yodon and just a little housekeeping notes before we get started and let the presenter take it away. We encourage and hope you guys ask questions throughout this presentation in the Q&A chat available in the right corner of the presenter. And also rest assured that the last five minutes or so of the presentation are dedicated to answering any of your questions. However, feel free to ask questions throughout the presentation in the Q&A chat. Lastly, a link to this recording will be emailed to all of you in about 24 hours and will also be available on ÃÛ¶¹ÊÓƵ’s ExperianSeek website should you wish to view it again or share it with your colleagues.

All right. Perfect. I’m going to hand it off to Garrett now. Enjoy, everyone.

Okay. Thank you, Yodon. Get these slides up here. Just a second here.

Okay. Are you able to see the slides? It’s loading. Yeah. Okay. It’s your screen. You’re good. All right. Here we go. So today, welcome, everybody. Thank you much for joining. We’re, you know, pleased to see there’s a lot of interest in this topic. And I’m really hoping that we can cover a lot of good information for you today. I’m going to go over kind of two different this is going to be two parts. One where I’m sharing slides and talking, and then in the second part, we’re going to be doing a demo. In the first part, I hope to just, like, bring up topics and questions, things to be aware of that I would expect your team would We’re going to focus on the scenario where you’re currently collecting data to ÃÛ¶¹ÊÓƵ analytics using ÃÛ¶¹ÊÓƵ tags or formerly known as launch, and you’re looking to migrate to the Web SDK extension within tags. I’m going to share some resources as a follow-up in the follow-up email to the demo and the webinar today. And in there, I’ll have documentation for the potential migration paths, but the most common is going to be for going from tags to tags app measurement extension to a Web SDK extension. And we’re also going to touch on a very basic target implementation, but mostly to highlight a common pitfall that can happen with ÃÛ¶¹ÊÓƵ analytics and target migrations. My background is less than targeted, more so in ÃÛ¶¹ÊÓƵ analytics, but it’ll also be useful there. In the part one, I’m going to be talking about some of the topics are those paths. We’re going to be really hammering today the kind of two options where you can send data to ÃÛ¶¹ÊÓƵ analytics mapping from a data object or the XDM object. I’m going to talk about kind of the benefits of those two and when you would use one over the other. And in part two, we’re going to do this demo. The page toppers page bottom, that’s kind of this ÃÛ¶¹ÊÓƵ target, ÃÛ¶¹ÊÓƵ analytics pitfall that we see. When you migrate visitor ID service, there’s some consent management differences to be aware of. And then the meat and potatoes of the demo is going to be all of these different places that you likely are collecting and setting ÃÛ¶¹ÊÓƵ analytics data and data element custom code and extension custom code and do plugins, rule configurations or rule custom code. There’s tons of places that you may be setting data. We’re going to show the kind of most straightforward way to port those over to a web SDK implementation. So let’s jump into the part one here. All right, so there’s a lot of different paths here and different topics I’m going to kind of cover, but I’ve put an asterisk in each section by what is the preferred method and also what we’re going to be covering more in the tech session today. So first considerations when you’re migrating to web SDK are what are your downstream services? Are you a real-time CDP customer? Some people kind of make the big leap to platform, some businesses, and when you do that, you’re going to want to do a different migration with web SDK. If you’re not a CDP customer yet and you’re maybe just implementing, you’re just migrating web SDK for your ÃÛ¶¹ÊÓƵ analytics data collection, like you’re still sending to a report suite, then you’re going to implement very differently than if you were using real-time CDP or CJ. So the big takeaway there is if you’re using RT-CDP or CJ or some of these other downstream tools like AJO, etc., then you’re going to have a very different migration path with web SDK.

And it’s not mutually exclusive. You could be still using ÃÛ¶¹ÊÓƵ analytics and the migration that we’re going to show with the data object is going to still be useful to you, and you can use that also while you’re sending stuff through XDM. And this can become more clear as we talk through this.

Then there’s these different migration paths. There’s a little link in the slide, but we’re going to share that in the additional resources too. And this is talking about maybe today you’re not using tags, maybe you’re using Telium or some other third-party to ÃÛ¶¹ÊÓƵ Tag Manager. Maybe you’re using JavaScript for all of your app measurement implementation or a mix of those things.

This document is going to go through all the different ways you might be implemented and talk through the ideal migration paths for those. Today in the demo I’m going to show more all within tags. You’re using analytics extension, you’re going to web SDK extension. And then I touched on this, there’s these mapping paths. There’s the XDM schema mapping, and there’s a data object mapping. And for ÃÛ¶¹ÊÓƵ analytics data collection, the data object mapping is preferred.

For basically anything else, you’re going to want to use an XDM schema.

For target, target and campaign I believe will also use a data object mapping, and you could look into those. But basically it’s if you’re looking to use web SDK for your kind of non-platform solutions, you can do that. And if you’re doing that you want to stay away from using an XDM schema.

And this might sound like news to some people because the data object mapping is relatively new. It was kind of debuted last year in Summit. And so if you were an early SDK you may have already made a migration with XDM. But I hope to show today that it’s really easy to use the data object mapping, and maybe you decide to kind of do a hybrid or migrate some of what you’ve got implemented through XDM mapping through the data object. And yeah I think that covers this slide. So again I’ve mentioned I’m going to have a bunch of additional resources I do want to make a call out for this must watch video. If you’re going to migrate to CJA anytime in the future, I recommend watching the Summit presentation that was given by Dave McNamee in Summit this past year, or this summer. It’s available publicly, and I’m in the experience league that goes out. In this presentation Dave goes through all of the questions and maybe even business needs that you’re going to need to account for when you’re making a successful migration to CJA. And it’s a much bigger lift than just migrating ÃÛ¶¹ÊÓƵ Analytics to using the Web SDK. But then I’m going to have a document for that. The configure top and bottom page events, we’re going to go over that in the demo, and that’s a common pitfall. And then of course is object mapping that you’re probably going to get a little tired of hearing me talk about. So here we go, more on the mapping paths. So I’m going to swipe over to look at some documentation for the data object in the XDM map here, but well actually maybe it will be easier to kind of wrap our minds around what I’m talking about here. So when you go to the Web SDK you’re no longer sending data to a report suite. Your website is going to send data to what is called a data stream or the edge, and then from there, ÃÛ¶¹ÊÓƵ server side, it’s going to send data to all the upstream services configured on that data stream. So in the case of ÃÛ¶¹ÊÓƵ Analytics, your data is going to be sent to the data stream and then a hit will be constructed on the edge that would be sent to ÃÛ¶¹ÊÓƵ Analytics. Web SDK doesn’t use query string parameters like app measurement and Omniture ÃÛ¶¹ÊÓƵ Analytics has always done in the past. It’s going to use like JSON objects on the payload rather than query string parameters. So there’s got to be a mapping from these objects in the payload to query string parameters for the ÃÛ¶¹ÊÓƵ Analytics server to receive that and process it normally, and that’s what these mappings are. So you’ve got two options. There’s the data object mapping, so this is a, and we’ll show this more in the demo, you’ll see a data object, what it looks like, and this is showing the mapping from values on the data object to analytics. Now the ones you’re more common to seeing are like the EVARS and the PROPS, but link name, link URL, link type, these should all look pretty familiar. This is just ÃÛ¶¹ÊÓƵ Analytics data. The biggest one I want to call out is the product string.

I imagine most people on the call are familiar with the ÃÛ¶¹ÊÓƵ Analytics product string and all of the nuance to it. There’s a lot of commas, there’s a lot of semicolons, there’s a lot of values on a product string. When you map from a data object, it just asks for a product string. Just give it, just like you would s.products on app measurement, just give it the product string. But when you go to use the XDM object for mapping, it’s trying to, like, let me just go down to the products, it’ll, and you can just kind of visually see.

Yeah, so here you can see like the XDM schema is breaking out this product string into kind of all of its individual components on their own paths, and that is just kind of a logistic nightmare, honestly. There’s a lot of kind of like, your implementation today is configured to make a product string. If you then had to like break that product string into each individual piece and put it into each one of these fields, that’s going to be really complicated. And then also when it maps, you can construct that string again, and honestly in some cases it just doesn’t do it that well. So this is kind of the biggest moment when they released this data object option, was really just a sigh of relief around the product string, for me at least.

Now we can just, on the data object, we’re way more familiar with this kind of implementation, and it’s a lot easier to map your existing implementation to use this. And like I said earlier, if you’re already using XDM and this kind of logistical nightmare is familiar to you, it may feel like a step backward, but I think it’s like a really positive change that you can today just start passing your product string on the data object, and here you can see it says right here, the data object is going to, if you set both a data object field and the XDM field, the data object takes priority. So that’s a really big call out for like, maybe you have some scenario where it makes sense to use some XDM values, so you can use XDM with data on the same hit, and it’s going to prefer the data mapping. So I hope that conceptually this is making sense, when we’ve got to, just to kind of recap that, when you’re sending data to a data stream, it’s got to construct these hits that later go to ÃÛ¶¹ÊÓƵ Analytics, and you have two options. You can send that data to the data stream on a data object, which is only usable by ÃÛ¶¹ÊÓƵ Analytics. This path is only specific to ÃÛ¶¹ÊÓƵ Analytics. None of this data would make it to RTCDP or any other downstream service. Or you’ve got XDM, which is really designed and its use case is for RTCDP and CJA, AJO, these other kind of new experience platform products, and that’s where you’re going to want to use XDM. So the takeaway isn’t never use XDM, it’s just use XDM when it is the most applicable. And from my perspective, the data object is much easier when you’re trying to just do ÃÛ¶¹ÊÓƵ Analytics implementation through Web SDK. The other thing I wanted to touch on with XDM mapping and XDM in general is this kind of concept between a semantic XDM schema and just an XDM schema. When you’re designing your CJA and your RTCDP implementation, you want to make your XDM schema as semantic as possible, and what that means is the path in this schema, so xdmapplication.isclosed, this path should describe the field that it contains data for. Now if you come down here to your EVARs and your props, EVAR only has meaning within the context of ÃÛ¶¹ÊÓƵ Analytics. Even in CJA, there’s no reason to use the word EVAR. So that would be a non-semantic XDM path because we’re now using kind of nomenclature from the old analytics omniture implementations within our RTCDP and CJA implementations, and you really want to avoid that as much as possible because it’s only going to create tech debt further down the line and create confusion. So that’s the other main point I wanted to comment on XDM. So ask questions if any of that’s unclear, and we’d love to to straighten that up, and then also I’ve got the documentation that you can dig deeper into. All right, so now with that I think we are ready for our demo. I’m going to just swipe over here, and yeah, so first part of the demo I just want to show, like I’ve got a really simple ÃÛ¶¹ÊÓƵ Analytics with some, like the initial library loaded target rule implementation here. Now this isn’t going to be the size of your implementation, but what I’ve tried to do here is show as much information as will be representative of like a typical implementation. So let’s go look at our extension. So in a typical implementation on the ÃÛ¶¹ÊÓƵ Analytics extension, I’d expect maybe some variables to be set in this global variables section, or even down here in the custom code on the extension. So you’ve got these variables. This is very similar to being set in the global variables section. Do plugins is going to fire every time a hit is fired, and before that hit is sent it’ll set variables. So it’s very common to have some logic here where you’re setting variables. The global variables and variables set in custom code outside of do plugins on the extension are really more of an initial variables than they are global. They’re not going to be set on every hit, they’re just going to be set as the extension is loaded. Then we’ve got within, well let’s go to a data element. We got a data element that’s got custom code and it’s setting, you know, it’s returning a value. Then we’ve got a rule. I’ve just got my page load. I’ve got a set variable, send beacon, clear variables. And my set variables, I’m setting evars and props here. I’ve got one prop where I’m setting it using a data element, and then down here in my custom code I’ve got some props and evars. So really here I’m just trying to show all the different places where we typically see configurations for ÃÛ¶¹ÊÓƵ Analytics. And now let’s do a migration to WebSTK for these variables. First I’m just gonna, I’ve got my kind of silly demo site here. I’m gonna load the page. I’ve got the debugger running, so it looks like two, but one of them is just a redirect. And then here you just see your typical analytics hit with these props and evars, and I just put their values where they’re being set.

All right, so the first step in any WebSTK implementation is going to be to create a data stream, because this is where you’re sending your data. You need to be in your right, whichever sandbox you intend to be using. The data streams are specific to his sandbox. And then for this, let me refresh the page. I don’t think it updated there. For this I’m going to be using this Garrett demo data stream. If you’re making a new one, you just click new data stream. It’s gonna take you through, just give it a name, and then it’ll ask for a schema, but that’s only going to be relevant for configurations for our TCDP. But let’s go into my data stream. Here you can add services. So this is where you would say which downstream services do you want to send data to. For our demo, I’m going to do analytics and target, and I’ve got those here, and they’re enabled. Now when you do analytics, it’s going to ask you for the report suite. So this is how the WebSTK flow knows to go from the client-side WebSTK to a data stream, and then server-side the data stream is going to map values from XCM or data object to query stream parameters, create a hit, and send it to this report suite ID configured on the data stream.

Okay, once you’ve got your data stream, you’re going to copy the data stream ID, and then we need to configure that within our client-side implementation. So you would go to catalog, search for the WebSTK, and I’ve already got it installed, but it’s currently disabled. So I’m just going to come over to the WebSTK. In here, this is going to be filled out by default. This is a good callout. Edge domain is essentially your tracking server for ÃÛ¶¹ÊÓƵ Analytics, so if you’ve got a CNAME to name today, you can just immediately replace this edge domain with your CNAME. And then here you can see this is where you select your data stream. So it’s going to have you pick a CDP sandbox, and then whichever data stream. For my test example here, I’m just doing the same data stream for each environment. Consent is going to be in by default. The migrate ECID from Visitor API to WebSTK is going to be by default. If you’re familiar for when we migrated from like SVI cookies to ECID cookies, this is really similar in that it’s going to kind of force AMCV cookies to be created on every page, whereas if this is unchecked, then the WebSTK will just create its own cookie, the conductor cookie, and there won’t be an AMCV cookie. But to keep this unified across like your whole site where you may be rolling out partially, this will maintain the same cookies in every place. And then I’ve checked the migrate target from AT.JS to WebSTK, and also I’ve enabled this personalization storage.

Then the other thing to be… well one thing to notice here is that there’s no global variables here. There’s no like initial variable setup in the WebSTK extension. So we just note that, and we’ll see how we migrate those variables in the future, but it’s not going to be on the WebSTK extension. And then here this edit on before event send callback code, this is very similar to like your custom code on the analytics extension, but it’s not quite the same. It’s actually much more similar to just your do plugins from within the analytics extension code. And maybe you configure do plugins elsewhere, but this code is going to run. This is custom code that will run before every WebSTK call. So in here, this will be kind of where I start showing how you do some of the migration.

In here, it has this kind of like comment already by default here, and it’s talking about content.xdm. You can also modify content.data within here. So these first two lines are just like some gotchas I ran into. If the data object isn’t defined already, then you’ll want to define it, otherwise you’ll run into some JavaScript errors. And this is just also defining the analytics data if it hasn’t been defined yet. And then here I’m able to do just content.data, ÃÛ¶¹ÊÓƵ Analytics, evar10, and I set it to this value. And this is effectively replacing our do plugins code. You could have more in here like event list, product string manipulation, anything you would do on your S object in do plugins, you would do that in this custom code. So I’m going to save this, I’m going to save this, and then I’m going to enable the extension.

And throughout this demo, we’re going to kind of get to the point where we have ÃÛ¶¹ÊÓƵ Analytics implementation and we have Web SDK, and then we’re going to remove the ÃÛ¶¹ÊÓƵ Analytics stuff afterwards, but we’ll see both firing on the page. Okay now we’ll go to our rule, our page load rule. Here we’ve got set variables, send beacon, clear variables. What we’re going to do is add an action, we’re going to go to our AEP Web SDK extension, and we’re going to do a update variable action. And I’m actually going to come back to this because here I kind of skipped ahead here. Before you do that you need to make a data element, and this data element needs to be of the variable type. So you’re going to use Web SDK extension and you’re going to do a variable type. And for people with a background in ÃÛ¶¹ÊÓƵ Analytics, this is really going to function like your S object. This variable essentially represents the S object where you’re going to set variables on it, you’re going to clear those variables, or maybe you could even make multiple of these objects and have like one data element per each rule or event type. I don’t like that as much just because it doesn’t represent kind of what we were doing with the S object in ÃÛ¶¹ÊÓƵ Analytics as much, but I think thinking of this just as the S object and following that kind of typical ÃÛ¶¹ÊÓƵ launch implementation where you set variables, send the data, and then clear the variables, this is going to translate really really well for that. So I’ve selected, you can have it do XCM or data, I’m doing data, and I’ve selected ÃÛ¶¹ÊÓƵ Analytics and target. I’m going to save this and then I’m going to enable it. I mean when you go through this you’re not going to have these already made, but you can follow the same kind of path. So you make a new data element with this data object is what I’m calling it. Okay now we’ll go to the page load. We’re going to add an action. We’re going to add a web SDK and we’re going to do an update variable. Now this is going to look really familiar. So here you can see it’s selected my data element. If you had more variable elements they would show up in this drop down. So what we’re saying on this action is we’re going to update the data on this data object, and if you think of this data object as the S object, this is really essentially the same thing as a set variables action on the app measurement extension. So here we’ve got EVARS and we’ve even got custom code. So I’m actually going to duplicate this. I’m going to put this, if it’ll let me. Okay it doesn’t, I want to just put these side by side.

Oh my snap isn’t working. Okay, oh it’s because this is full screened. There we go.

Let’s put this here. Okay so when I’m doing this migration, what I’m going to do is on the up my set variables. And this is admittedly pretty manual at this point, but it’s also really really simple. So you just, I’m just going to set EVAR2. I’m going to set this.

For props I’m going to do prop2. I’m going to set it to this value.

For prop4 is going to be my data element.

And there we’ve migrated the set variables values. Then I’m going to go down to my custom code, look at what I’ve got in here. And here it’s just, this is on, I didn’t write this note. This is going to be on every update variable code to kind of show you what to do. But I’m going to have content dot, I’m just going to actually copy this, and change this to EVAR3.

And I’m going to do this for prop3 as well.

Okay so now we’ve kind of demonstrated how you would migrate those set variables values. The custom code on a set variables action and a data element, it’s essentially just the same thing. And in the data element you could also update these variables in there. So I’m going to this, and save this. So now we’ve made this new update variable action, and we need to send the data. So I’m going to go to web sck, action type, I’m going to do send event, and here in data you put your data object. So we’ve updated the data on this data object, data element, and then when we put that here it’s going to send on the hit this data JSON basically. Okay I’m going to keep those changes, and then this is where you kind of have some wiggle room, where you could, if you want to have a third action that’s clear variables, you could technically come in here, go to the web SDK, and if you do the update variable and you just check clear existing value, this checkbox is going to wipe this data object clear. So you could do that, you could kind of do that in its own action here, or I think what’s a little cleaner is just always when you do update variable, if this is your s object, just always whenever you configure this check that box and you’ll know that it’ll clear out the previous hit. So you have some choices there however you want to do that, but it’s kind of up to you. I’m just going to leave this for now. I’m going to save this, and at this point we are ready to see the send event for ÃÛ¶¹ÊÓƵ Analytics as well as the app measurement hit. So I’m going to come in here and just publish this, and once that loads we’ll come over look at the hit, and we might, I think we want to do a little bit more, like I want to do the do plugins and stuff more before we pull up assurance, but we’ll just let’s just see a little bit of this so far.

Should be a pretty small library.

I don’t think refreshing this publishing page does anything, but I do it out of habit. Okay, so now we’re ready to refresh this page. We obviously still have our analytics hit, but now we should see an interact call. Let’s look at a few things here. So notice the query string parameters don’t have anything, there’s no query string parameters here. Oh, that’s a lie, there’s two query string parameters. There’s a unique request id for every hit, and there’s the data stream id, which makes sense, that’s where this hit is going, let’s go to that data stream. Now we’re going to look at the payload, and that’s where all of our data is going to be. If we go into events, we see both an xdm object, these are default xdm values, and we have a data object, and within this data object we can see those evars and props that we set. So we’ve got the one in the, I feel like I’m missing, oh I put the event for, this was supposed to be prop for, but I put it in events. Okay, yeah, so this looks like what we expected. We’ve got the on before send event callback, so that happened in the plugins. We’ve got the page load rule, and we’ve got the, sorry, we got the page load rule set variables, and we’ve got the custom code set variables. Okay, so let’s come back to the rule, and we can fix that event thing if we want to.

We can also, so this is how you add another prop, but that also shows kind of, you know, how you do events. It’s really, really simple and very similar. And then in here we did the evar3, and I forgot to change this to prop3.

Okay, and that clears up those things. What we don’t have right now are the variables that were set in the extension for these global variables, and oh did I, I thought I had someone here. Actually, no, I got them in the custom code here. These evar1 and prop1. These, however, are going to be, you know, those functionally are the same as if I set them here, and this kind of this section of code doesn’t really exist in the web SDK extension, but what you do is just set that on your first hit, because that’s what those variables did in in the first place. They were only ever sent on the first hit, then they’d get cleared out at the first clear variables. So you just also want to migrate anything you have in that global variable section to your first analytics hit, and just in that same update variable. So we’d have a evar1, and we’ll put that there, and then we’ve got our prop1.

Okay, so now I think that covers all of the different kind of spots where you might set variables, and now let’s like, I’m gonna save this, I’m gonna push it, and then we’re gonna look at assurance, which is going to be a really helpful tool, and it’s also gonna kind of show you what’s going on under the hood here. So while that’s loading, I’m going to come back to my page, I’m going to open the experience platform debugger. Now that I’m on this page, it’s going to recognize that I have the web SDK on the page. I’ve got, still have app measurement, and I still have AT.js on the page at this point. Now we are going to come over to the platform web SDK tab here, and go to edge transactions, and connect. This is going to create a assurance session, and there’s this little icon here you can click, which is going to load that assurance session within data collection. What assurance does is it’s going to track everything that happens on that data stream, all the traffic that goes to that data stream, and server side on the adobe side, and show you what happened with your hits. So let’s come back to the page. That’s done. I’m going to refresh the page. We’re going to get our interact call, and now I’m just going to jump over to assurance, which boom, here it’s showing the hit received at the edge. I really like this event transactions view, because it shows, I think it’s a little hard to see on the screen share, usually there’s some like arrows pointing to each thing, but this really demonstrates how this works. So if we look at hit received, we’re going to see very much, you know, very similar to what was sent. Here we’ve got the event, we’ve got the data object, adobe, analytics, and then we’ve got all these values that we’re setting. Then we can look at the adobe analytics hit. This is what was sent to adobe analytics, and actually I like looking at this mapping one. Here you can see mapped query params, and boom, this looks way more similar to what we’re used to seeing on like a B slash SS call. And this is that mapping happening right now that we’ve been talking about. Okay, right now I’ve got duplicate hits going to my report suite. I’ve got the app measurement hits, and I’ve got the web SDK hits. But we can now, like now that we know this data is being collected, another thing you can check is you can see here this is the report suite, and that’s going to match what was on the data stream. And yeah, there we’ve successfully migrated my page load rule to the web SDK. So we can come back to our rule, and I’m just gonna delete these actions. Now we’ve got just our update variable and our send event. I’m gonna save that. All right, now I’m gonna kind of in the last like, I don’t know, five, ten minutes here. I’m going to do my best to demonstrate a target migration. Okay, so we are going to have a one. We’re gonna go just like acknowledge we’ve got this adobe target, and then remember that in the web SDK we’ve checked the migrate at.js and enable personalization storage. Also I wanted to point out on the assurance log, because we had those checked, the kind of initial target load request was actually tacked on on this first web SDK hit. So you can see here we’ve got the target trace, but that’s not typical. That’s atypical of a target implementation. Typically you’ve got target doing its kind of page load or doing its hit at the top of the page before your data layer and stuff is available. So we actually want this to fire as soon as possible, not on page bottom like we do adobe analytics. So we are going to create another rule, and we’re going to set this to page top, or sorry library loaded. Yeah, same thing. And we’re going to add an action. Go to web SDK, send event, and it’s very important to set the type to decisioning proposition fetch. This is going to flag this hit as a target library loaded hit, and therefore not track it to adobe analytics. This is the common pitfall where before this event flag was available, if you migrated target and adobe analytics, the data stream didn’t know what was a target hit, what was an analytics hit, and so every hit just goes to adobe analytics. But that would cause your bounces basically to drop because you’re getting two hits every page load. The target hit is going to analytics and your regular analytics hit. But here we’re going to flag that as decision proposition fetch, and then I’m going to check this render visual personalizations decisions, and I believe that is everything that I’m going to do for just this kind of like rudimentary target migration. But this is going to replace that target rule that is typically sent on the page load. So I’m going to call this…

Like in the typical target implementation you’ve got this library loaded, and this is replacing this one. So now I’m going to disable this, and I’ve got my target page top. I’m going to go to publishing flow. I’m going to… oh, also there is a different pre-hiding snippet, so I’m going to uncomment this and comment out my old AT.js snippet. And all of this target stuff is well documented for a migration, this is mostly just to kind of give you an idea for what you got to do.

All right, so now we’ve got that, and let’s go push this and send a hit. What we’re going to double check here is to make sure that the first hit has the target trace and it didn’t go to ÃÛ¶¹ÊÓƵ Analytics, and that the second hit goes to ÃÛ¶¹ÊÓƵ Analytics, and incidentally that hit also just doesn’t… it’s not going to have target stuff, so it’s not going to go to target the second hit. And we will, once this loads, we’ll show that, and I think that will conclude the demo, and we’ll just jump over to this kind of takeaway slide and take any questions. And definitely Marte, Mikhail, and I would love to answer any follow-up questions on support tickets too, if you make after. Okay I’m going to refresh this. So now we don’t have a analytics hit going out, we don’t have a tt.omtrdc delivery call going out, and we are going to look at our assurance log.

The second hit, so this is the second hit that happened on the page, this is the first hit that you can look at the timestamp here to see that, 0.5, 0.0, and on the… this should be the target hit, so let’s look at the analytics mapping, and you can see this dropped context true is saying that this is dropped, I thought it said dropped hit, but it’s saying dropped context. Here let me, I think actually if we look, yeah right here, dropped hit true. So this hit isn’t, to ÃÛ¶¹ÊÓƵ Analytics, this is going to be dropped from your report suite.

And then down here you can see the target trace, you can see like the campaigns it tried to qualify for and stuff here, and then on the second hit we’re going to make sure our ÃÛ¶¹ÊÓƵ Analytics hit is not dropped. So we’ll come up here, oh I changed it to the raw, I don’t know how to get that back, but right here you can see dropped hit is false, so this is going to go to ÃÛ¶¹ÊÓƵ Analytics, and target, it didn’t have any target data so it didn’t go to target on this second hit.

Yeah that concludes the demo, and let me get back over to my slides here, I think I exited the full screen, yeah.

All right so to kind of summarize all of that, first I’ll just say there’s a lot we covered, and definitely look for that additional resources page, it’s going to be a link in the follow-up email to the webinar that has like a link to an experience league additional resources. You want to use the the data object when you’re migrating ÃÛ¶¹ÊÓƵ Analytics implementation to Web SDK. I do not recommend using XDM because as you could see the XDM mapping is just a lot more complicated than the data object mapping. Also as you could see in these up with the data element update variable on those flows and tags it’s really easy to make this update, and the UI is much more familiar and consistent with the old experience. When you are ready to go to real-time CDP and CGA, definitely watch that summer presentation for designing your CGA XDM and you’re using a good semantic XDM design, that’s going to be really useful and help you down the line. And the big takeaway is that you don’t want to bring this ÃÛ¶¹ÊÓƵ Analytics nomenclature with you when you go to CGA. You want to have a semantic XDM that just describes what the path describes the variable. The data object also just are just some like little tidbits. The data object takes precedence over the XDM, so if you happen to be kind of like in the middle of a migration, or you’ve already done a lot of work with XDM and you don’t want to lose kind of some of that work that you have existing, the data object’s still available to you and you can migrate, you can have a kind of a hybrid. And then another big concept to wrap your mind around is just that the Web SDK isn’t sending to these downstream solutions directly, it’s going to the data stream and then it forwards those to all the enabled services. And the all is capitalized here because you got it there, you know, there are some scenarios where you want to hit just to go to target or you want to hit just to go to analytics, and for the analytics situation you can handle that. There’s also other means to do that with like configuration overrides and things like that, but those are less common scenarios. And yeah, we’ll just take any more questions. I know Michael and Marte have been helping in the chat, and I’ll take a look here as well.

We’re gonna, Shiva asked, can we get a link to the demo video about migrating to CGA? And yes, we will send that link in the follow-up. It is publicly available.

Okay, recommended to use XCM when sending data to both CGA and a how to tackle product nuances from XDM object. So actually for this I would say kind of think of them separately and use, just continue to use data for your ÃÛ¶¹ÊÓƵ Analytics stuff, and anything that is in the XDM object that’s going to CGA that would be mapped to analytics, it will map, and if your data object is doing it, the data object will map over that, so there’s no concern with getting like the wrong value there, just recognize that data will be the last say. And then also something interesting about data on the XDM object, that any data on the XDM object that isn’t mapped by these documented mapped paths in ÃÛ¶¹ÊÓƵ Analytics will be put on context data in ÃÛ¶¹ÊÓƵ Analytics and is then available through processing rules. So you can be kind of in a hybrid state where you’re sending data to ÃÛ¶¹ÊÓƵ Analytics or sending data to CGA on XDM, and you can still get value from that XDM in ÃÛ¶¹ÊÓƵ Analytics through processing rules, and also if you’re using the data object, there’s no concern that variables are being set that you don’t want to be. So I’m just going to type out a little response there.

Um, Rashil asked how many report suites can be configured per data stream, and you can you can do, I don’t know that there is an upper limit, but any amount that would have been reasonable for multi-suite tagging and at measurement can be put in the data stream. So okay, yeah, for web, Fernanda asked about the web SCK, can we use extensions as usual like in AA? And yes, like if you’ve got consulting plugins that you were putting in in Do Plugins, you would just configure those very similarly in the on before send event callback, and then like there’s extensions, like if you’re using like OneTrust for your consent management, that’s going to be a different flow with web SCK. So there’s some that don’t have like a one-to-one translation, but I will say there really shouldn’t be any problem that can’t be solved in the web SCK ecosystem. Some of it’s going to be a bit of a shift, some of it like the consulting plugins is really just you’re just kind of moving it like you are the variables. So let me let me respond to that.

So Juan asked is it better to use the data object over the XDM object? And the real answer is that in different scenarios you need to use one over the other. The data object is only useful when sending data to ÃÛ¶¹ÊÓƵ Analytics, but if your purpose is to send data to ÃÛ¶¹ÊÓƵ Analytics, it is much the preferred method over XDM. And XDM is the only way to get data into CDP and CJA, and so you’re gonna need to do XDM, but when you do design your XDM object, you want to ignore kind of that you don’t want to bring kind of the historical paths for ÃÛ¶¹ÊÓƵ Analytics along into that XDM. You want to design a new schema entirely.

Um okay there’s a question about client side and server side. So I think today it really stayed in the extensions, but if you’ve got data insertion API implementation, or you’ve got any other server-side flow, or even mobile SDK, there are migration paths for those, and we’ll put those in the documentation, but high level for like data insertion API for example, edge has a its equivalent API to send hits to, and this data object is also supported on those. So however your code is currently configured to set the creation parameters, you would just modify that to the data object values, and then that mapping will happen on the ÃÛ¶¹ÊÓƵ server side. And I’ll say that.

So I think implementations and app measurement going to be supported in the future, and uh I’m not project management or anything, I’m just kind of from support, but everything I’ve heard implies that those things are going to be around for a very long time. I mean there are still people with H-code implementations sending data to ÃÛ¶¹ÊÓƵ, so uh yeah there’s there’s no reason to believe that ÃÛ¶¹ÊÓƵ Target or ÃÛ¶¹ÊÓƵ Analytics are going anywhere. They’re gonna they’re gonna at least for now, but yeah there’s no there’s no way they could go away, there’s so many people still using them, and and uh um that isn’t to say that like you know people are sending H-code data but H-code hasn’t had an update in forever. But yeah I think new features you’re definitely gonna see coming out for Web SDK and less and less for like app measurement, but they’re they’re they’re not going away. They’re going to still work.

Okay there’s a question about uh migrating like okay so EVAR is traffic variables to to CJA.

Um Ganesh that’s a really good question, and uh and that that video about migrating to CJA is going I will just say that in general with the dimensions, the EVARs and the traffic variables, you really just need to think of those as you’re going to design a new schema. ÃÛ¶¹ÊÓƵ Analytics had a schema and that schema used EVARs and props, but that schema only makes sense in ÃÛ¶¹ÊÓƵ Analytics. So when you go to CJA you’re gonna you’re gonna change you’re gonna there’s no really click and done method except for CJA does have a way where you can import report suite data into CJA.

But that’s not really a migration that’s just kind of a really a proof of concept tool. I don’t think you would really want to rely on that. But then marketing channels and CJA you’re gonna implement those with derived fields, and I don’t think there’s like a a migration button for those, but you could reach out to CJA support for that. I don’t think there is. And then bot rules are actually more configured on the edge than they would be in these downstream solutions.

Yeah they’ll reply to that.

Okay there’s a question about data prep. I didn’t mention data prep, but data prep is actually like custom mapping tool where you can map from XDM or the data object to XDM. I don’t think that it’s supported right now to map to the data object, and I don’t know if that will be supported in the future. So typically you’re going to use data prep when you’re changing values on your XDM, not when you’re sending data to ÃÛ¶¹ÊÓƵ Analytics using a data object for example, but it could still be relevant there. As for when exactly to use it, I think the answer to that is really just when do you want the server to have the last word.

So there might be scenarios where you don’t trust device information. I don’t know, there’s a lot of different ways you might do it. I think the best one might be a lot of people like to, this is a good example, a lot of people like to track the ECID on a different variable. So there’s kind of the default path where you’re going to see the ECID, but if you want that on a different variable, doing that on data prep is going to be the most reliable thing, because sometimes client-side the ECID isn’t available yet, or you could run into timing issues. So in short though, it’s just when do you want the server to have the last word.

Okay, I lost where it was.

Any tips to optimize server calls? Really you just want to, as far as optimizing server calls, you just really want to consider just sending as few as possible, and just really wrapping your mind around how the edge is going to split these out into the downstream services can help with that. So anytime you can make a target call happen on the same hit as an analytics call, for example, just try to reduce the number of service calls made. But web SDK is going to be inherently optimized in that you are loading way fewer JavaScript libraries on your page, or even extensions in your mobile app.

Okay.

So there’s a question, Andy had also a question about the data prep for mapping, and you can’t map to the data object, so you can’t really rely on data prep for all of that. Now you can send XDM, and anything that isn’t default mapped will make it onto context data, and then you could use processing rules, but processing rules also has limitations for what can be set on it. Like product string can’t be set in the processing rule.

So yes, you can use data prep to map to XDM, but kind of one of the big takeaways from this demonstration is don’t use XDM if you’re sending to ÃÛ¶¹ÊÓƵ Analytics. Use the data object, it’s going to be a lot easier. But that isn’t to say you can’t do it, it just wouldn’t be the recommended approach.

Okay, I think we are a bit over here on time. I think we’ve addressed most of these questions, and definitely I see some in here like, I think Sumit, I think you’ve got a question here that actually I would say open up a ticket because this is kind of, I think this is a little bit more complicated. I guess you’re talking about maintaining the ECID values, so that’s gonna, like the append to URL, the web SDK has very similar, I’ll just answer this here, so these flows are essentially supported. You just need to double check the documentation for the API calls.

Oh, one data stream per environment in a tags property. Typically you’d see three data streams per property.

Derived fields, there’s a couple more here.

There will be the recording.

The web SDK extension update, really the like web SDK also, the ECID service, so in the future you should plan to migrate your ECID service off and replaced by but yeah nothing really for visitor migration.

To check the migration.

All right, I think we’re gonna call it there. If we didn’t get to your question, please reach out on a support ticket and we’ll be happy to have these discussions, and thank you so much for everyone for joining and for the support.

Awesome, thank you so much Garrett, the team, and thank you all for joining. This was a really informative session, and just a quick reminder before you all head out, a link to this recording will be emailed to all of you in 24 hours and will also be available on ÃÛ¶¹ÊÓƵ’s experience website should you wish to view it again or share it with your colleagues. Thank you all so much, please enjoy, and we look forward to seeing you guys next time. Bye.