Data Drip: Benefits of Migrating from an Old System to Web SDK

Transcript

So hello everyone and welcome to Data Drip. Today we are going to be talking about all the benefits of migration to a web SDK. So we do design our webinars to be interactive and we encourage you to ask questions in the questions box throughout the presentation. It’s gonna pop up on your next screen. You can type them in there and we’ve set aside the last 10 minutes or so for Q&A. And we’re gonna do our best answer as many of those as we can for you. So I’m gonna quickly mention a couple of housekeeping items before we get started. We are presenting in Adobe Connect today and we are live but not to worry. The session is being recorded and will be able to be viewed on demand and shared with other members of your team at a later time. So you’re gonna get the recording of the event in an email from us tomorrow afternoon, depending where you are, in about 24 hours from now.

I’d also like to point out at the top of your screen, there’s a black bar with a smiley face icon on it and there you can find different actions that you can utilize throughout the presentation. So if you like what you see, feel free to like, applaud, laugh, so on. But we’d love to see your engagement throughout the event. Yep, oh, I see them coming in now.

And as we are closing out the webinar, we’re gonna have a few survey questions at the bottom of your screen. If you can take an extra minute to answer those, we’d greatly appreciate it. So with that, I’d like to introduce myself. My name is Alana Cohen and I’m a Senior Digital Events Manager here for our Customer Success team at Adobe. I’ve been with Adobe for a little bit over six years now and I’ve spent a majority of those years organizing and hosting these events for you guys, our customers. Prior to my time on this team, I spent about two years working with Adobe’s Advertising Cloud customers and then before coming to Adobe, I spent many years at different advertising and media agencies around New York, but I’m excited to be here now hosting events like this for you guys, our customers. If you have any questions or comments about today’s event or any of our customer exclusive events, please do reach out. So with that, I’d like to hand it over to Arindam to introduce himself and then get us started on today’s presentation. Arindam? Hold on, you’re on mute.

Arindam, you’re on mute. Hang on a second.

I hope I’m not there now. Hey everyone. Thank you, Alana, for that.

Hey everyone, my name is Arindam Agarwal. I’m almost a year old at Adobe now. I’ve been a partner with Adobe. I’ve been a customer for Adobe, so I’ve been in all possible shoes that you can imagine. I’ve worked with hundreds of customers to help them in their digital transformation process. I’ve worked on all products ranging from analytics target to AP, CJ, AJO and so on. So the entire DXV.

And yeah, happy to walk you all through Web SDK and some of its capabilities and how you can migrate. So yeah. Awesome, great. Let’s get started.

All right, so I hope the slides are visible now and let’s get started. So the main agenda for today is to go over the Web SDK in a nutshell, what it is, some of the key features that we have, what are benefits of migrating to the Web SDK, and then a quick walkthrough of how you do implement, how do you proceed with maybe thinking about moving from the legacy implementation to the Web SDK, and then talk about some… I’ll quickly also demo an implementation of Web SDK, how it looks before, how it looks after and so on. And then we’ll move to the some resources in Q&A.

Hope that sounds good. So moving on.

We’re gonna pause here for a poll at red button. Yeah. Before we get started, let us know which tag management approach are you currently using for your Adobe products? So are you using Adobe Launch or data collection tags, other tag managers, no tag manager at all, you’re hard coded, or maybe you’re not sure.

Let us know. Right now, majority of you are using Adobe Launch or data collection tags, so that’s good.

It’s a little bit of a mix between the first two responses here. So we’ll leave it open for another five seconds, let everyone answer, and then we will move along. All right, seems like we got mostly the first response there. Okay, cool. I’m gonna switch us back over.

It’s interesting to see though that we don’t have folks using the library directly, which is a good thing, of course, we’re not using hard coded libraries. That’s amazing to know. So let’s just go through what the Web SDK is for a minute. So in the past, if you wanted to use Adobe Analytics, Adobe Target, and maybe Audience Manager together, you had to load separate JavaScript libraries. So for instance, appmeasurement.js for analytics, at.js for target, and so on. Now, each one of them sends its own request, which means extra page weight, multiple network calls, and a lot more maintenance headaches. Now, the Adobe Web SDK changes that completely. Instead of juggling multiple libraries, you load one unified SDK, the alloy.js library, which sends all your data in one single call to the edge network. Now, we’ll take a quick look at as to what the edge network is. The edge network basically is a middleware, it’s a collection of distributed servers managed by Adobe. Now, every bit of data from the Web SDK and other libraries, maybe through APIs, through network calls, can be sent to the edge network, and then the edge network handles where this data goes. Now, the edge network can send this data to other Adobe platforms like Adobe Analytics and so on, and can also send that data to third party. We’ll come to all these benefits later, but just to understand, the edge network is the heart of this entire ecosystem now.

So moving on, so basically the edge network routes your data to all configured Adobe solutions, and this is some configuration that is easy to do, manageable, and quick to move on.

Moving on, let’s talk about why Web SDK, right? All right, I’m gonna pause you again. We have one more poll question. Actually, we have another poll question.

It should be up on everybody’s screens. So before we get into why Web SDK, let us know what your primary reason for considering or using Web SDK is. Is that faster performance, server-side data forwarding, easier governance and compliance, consolidating Adobe implementations, or maybe another reason other than these ones up on screen.

Okay, I’m just gonna leave this open for another couple of seconds. It seems like a total mixed bag here. Everybody has a different answer, so love to see that.

I do see a lot of others though, and we would love to know what these other factors are. And we did make this to be a single choice because we wanted to know the top priority. However, we understand that it could be all of the above or a combination of these. But yeah, I see answers coming in, so all of the above. So maybe that’s what others stand for.

Great, all right. And this one, we’ll get back to the slides.

So let’s talk about why Web SDK, right? And there’s a couple of key features that I wanna walk you through. Now, as you see on the screen, major features are like single unified library, which is, as I mentioned before, the alloy.js. Now, this library replaces multiple Adobe libraries like App Measurement, ATE, Audience Manager, Board visitor or JS, for instance. It’s an extremely lightweight script, which basically reduces a lot of overhead and page weight. And it manages data collection plus personalization delivery in a single call. What that means is that you don’t have to first hit, let’s say, Adobe target to get personalization and then send this information back to analytics for maybe reporting on these target activities or personalization instances. However, this can be handled all within one single call. So you just have one call to the edge network, which handles both data collection as well as personalization. Now, the edge network integration is another key feature, basically, which means that the data is sent to edge network. The edge network handles the routing to multiple different platforms. And then we just avoid multiple calls from the client side. Now, one of the key features is event forwarding. Now, as I said before, the edge network can forward events to non-Adobe destinations. And this is extremely crucial and we’ll just come to this in a minute, but it reduces client side tracking complexity. So let’s say you have multiple different pixels and you want to send data to Facebook and Google and so on, right? Or maybe even just track it for monitoring purposes. Maybe you send some events to Splunk for logging and so on. So this is all something that can be handled by the Web SDK and the edge network now.

Let’s talk about the built-in consent management. So one of the key features is the built-in consent managers, which basically allows you to follow or align your data collection strategy with GDPR, CCPA, and your CMP requirements. You have commands like set consent, which allows you to easily handle how and when data is collected. Events can also be held until consent is granted. Now, I know this is a common pain point where, hey, how do we get data for events which have happened before they gave us consent? Now you can actually hold the events in the client side or in the front end till the consent is granted and then send it all at once. Now this is an amazing feature by Web SDK. And then the Web SDK being a very new design is a privacy first designed by choice. Now, identity management also supports the Adobe’s ECID and other custom IDs. So let’s say you have a different authentication process. You get to decide what custom IDs are being used to identify unique visitors, which then enables cross-section identity stitching and customer journey continuity. So let’s say you have multiple domains or multiple channels where users interact, you have that entire customer journey continuity where a user moving from, let’s say the app to the web to maybe some, to brick and mortar store, it can all be stitched together based on some of the other custom ID.

The last bit is the data collection where I do want to emphasis on the experience data model standardization. Now the XGM model is the Adobe standard schema which stands for experience data model and it provides consistency across all Adobe platforms. So basically analytics, personalization, activation and that’s something that’s standard across all Adobe tools and products. And then it makes governance and scaling much more easier. We’ll come to the benefits just in a second.

So moving on to some of the benefits that we have.

The implementation is simplified to a large extent because you have one common library instead of having multiple different or handling multiple different libraries.

It’s much simpler to maintain because it’s just one code base rather than three, four libraries. It has fewer updates where Adobe manages improvements essentially by the edge network and then standardized data as I said before, the XGM standardizes data between different platforms. So it’s easier to collaborate for your different teams to collaborate. Now the other thing is performance.

One optimized request versus multiple bulky calls to Adobe products leads to much faster websites and other platforms then better core web vitals because it has a much lower impact on the largest contentful pane and the first input delay. So basically it makes the overhead on your websites much lower. Now it also has a reduced JavaScript size. One point of consideration here is that I’m talking about JavaScript libraries a lot because the primary content here is the JavaScript library but I do want to put a lot of emphasis on Java that the Web SDK is a complete package and it’s basically a software development kit which is available on NPM and other platforms as well. So you don’t have to restrict yourself to a JavaScript library.

Now let’s talk about future proofing. So basically event forwarding as I said, unlocks modern server-side integrations without extra development cycles and an integration with the AP ecosystem. Now a lot of us might not have journey optimizer as of now we might not be using the RT-CDP but that’s the Web SDK and the XGM model is something which is a core requirement for these products. The integration with the AP ecosystem make sure that when we move to the Web SDK, we are ready for the future.

Now I’ve spoken about compliance and governance where since it’s privacy first, there’s a built-in consent enforcement, it’s cookie-less ready. So what I mean by that is you can easily move to server-side data flows and you have a flexible identity management in terms of maybe using the Adobe EC ID or your customer identification matrix that you use on your end. Now there’s a lot of centralized control as well because it reduces a lot of uncontrolled client-side data which might leak in the process. The last point that I want to talk about is business value because having one team working on one library makes sure that there’s faster time to live processes. So basically you are able to extract business value much faster, you are able to save a lot of cost because there’s less engineering required, there’s less duplication and much simpler QA.

So in short, the Web SDK ensures that we have faster websites, cleaner data, stronger compliances and a future proof market.

Now let’s move on. I want to move on to some implementation details and how we can begin to implement.

So we are, before we get into implementation, we have one last poll question. I promise this is the last one.

Should be up on your screen now. Have you implemented Adobe Web SDK in your organization yet? Yes, fully in production. Yes, we’re in testing phase. No, but we’re planning to implement or no, we have not planned yet.

So let us know what phase you’re at. This is also a mixed bag.

Most are in testing, a majority is in testing phase. So that’s great. But a real mix here, or I’m seeing a lot, we’re almost at 25% each across the board here.

So that’s a good healthy distribution, but I’m happy to see that folks are in production as well as folks being in testing phase, which is always good to see. Definitely. All right, I’m going to hand it back to you to move on to implementation.

Perfect. And before I go forward with the implementation, I do want to call out that with any of your licenses, let’s say we have analytics or maybe target, the Web SDK library is an additional free, like it’s a free of cost library that you get within data collection tags. So you would have the Adobe data collection platforms and you can use the Web SDK out of the box. The only thing that, the only caveat here is that event forwarding capabilities to third party destinations, that is something which is part of the RT-CDP connections queue. Now, there’ll be more information about this particular queue, but it’s an add on that you can get in touch with your SAMs with or your AEs to get more information.

So having called that out, let’s move forward and look at the implementation bit. Now, migrating can sound a bit intimidating, but it’s manageable if you follow like a clear roadmap. Now here’s how I would recommend approaching it. Let’s look at the life cycle. So the first bit is planning, right? Assess your current setup. Identify the Adobe solutions that you are currently using, and then list, then define the objective and the integration scope, and then list every variable event, personalization activity that you track today, so that you have a clear understanding of what we need to move to the SDK. Then the next bit is, let’s get into the development side of it. So you have to first define your XTM schema, which basically means that in the AP screen or in the data collection screen, you have to build a schema that represents your data. Now schema is just like a data model that you have to build out, where you can include what data needs to be tracked and how, and then go from there. Then install the Web SDK extension in Adobe Launch, define your extreme schemas as I discovered, and then map your existing data layer variables to the schema fields.

The last bit is to handle consent, as I spoke about before, and we’d be good to go. That’s it. So now let’s get into the validation bit. So the data collection, test your data collection in proper dev and staging environments, validate the data accuracy and compliance settings and privacy settings. So make sure that you are following the compliance policies in your area. And then we recommend using the Adobe Experience Platform debugger to inspect payloads and confirm routing. We’ll come to this in a bit as well when I start sharing my screen. I wanna show you how easy it is all to do, but we typically recommend using the Adobe Experience Platform debugger to inspect the payloads and then make sure that the data is routed as intended. The last bit is to compare your old and your new setups before switching fully. So one last bit of recommendation is that we should compare the sort of data that we are collecting, the sort of position that we are offering with the old setup and the new setup before we actually go out to production. And that’s it. We just roll it out and monitor performance and make adjustments as needed. Now, let me quickly show you what a basic implementation looks like inside of Adobe tags.

And let me start by sharing my screen.

All right, one second.

Loading, one moment.

Let me know once when you’re in the system. You are done. Oh, perfect. So for example, like I’ve just taken one sample AEM website that we have, where I’ve deployed two different set of libraries. One is property, I don’t know, and then the Web SDK version. And I wanna quickly show you the differences between the two. Now, if I go into the legacy property, and I know that a lot of folks here might have worked long enough with Adobe this was called DTM and then launch. And then now it’s called Data Collection Platform. And it’s, but yeah, heavier. So if you come into the extensions screen, you can see that I’ve installed different libraries as of now. So you would see Adobe Analytics Library, you would see an Adobe Target Library, the Experience Cloud ID service, which basically represent different JavaScript libraries on the website. So the app measurement, the Adobe Analytics the app measurement, this installed C80.js and this is the visitor.js library. Now, if I go into my website, and let me quickly open the debugger. So let’s just clear everything out. Let’s make sure that everything is fresh.

Let’s just remove this. Make sure that we have a fresh implementation. And now if I go on to the debugger, you’ll be able to see that I have different libraries on my screen. So I hope everyone is familiar with this debugger. This is an excellent tool for debugging and seeing what all happens on your website. You’ll not only be able to see what products are installed, for example, if you have an analytics target and what libraries are present, it also lets you see all the events that are flowing. So you can see, hey, these are different events, these are different timelines for events and so on. So if I move to something, if I wait at the loser, as I do something on the website, it will keep tracking these different networks on. So now one thing I wanna pull your attention to is you see that you have an analytics request and a target request that goes, and this is an audience manager as well. So this is true for all products that you install on a website.

So that’s one thing that I wanna call out. Now let’s go on to the data collection tag and see how it works. So I just have one simple rule as of now for the purpose of showcasing this, where we just wanna load target and have a page load call. And we just sent like a couple of variables. I only said that send page name in one of the E-vars and send one of the events. So just send event one and set E-var four as the page name, which is a data element in my tags.

Now, moving on from this sort of a setup, which you might be familiar with, this is a very typical legacy setup. You would have seen the screen multiple hundreds of time. Let’s look at what the WebSgK then looks like. So if I go back to my data collection tags, let’s give it a second to load and let’s open the WebSgK property. If you now look at the extensions, all you see is just one extension, which is the WebSgK. It’s capable enough to handle everything on its own. You don’t have to have different platforms running on your website simultaneously. And this is what a simple rule might look like, right? So I have just one rule, which has page load and then say, hey, just send an event. And this is, I’m just using this for requesting personalization.

You can also do both of them together. So you can request a personalization and collect analytics together. But for the ease of this, like I’m sending different events, one request for personalization, you update the variable. So let me quickly show how it looks like. So I again do the same setup, which I did before, but this time I’m mapping my XTM field. So this is an XTM object.

Which shows different data to be tracked. I have mapped the similar fields. So I’d say, either for store the page name, track event one and so on. And then I send this basically in a send event function. Straightforward enough, it’s similar to what we have. It’s just a different way of doing it. And now if I, let’s say go onto the website with this. So let me just take my development code.

And again, if you have any questions on what I’m doing, keep putting them in the chat. And I hope you are familiar with this sort of an experience. So if I go into the tags now, let me just clear everything up for a second.

And if I go into tags, let me configure this. Let me change my script to the WebSGK version. So as soon as I change that, I come on to the same summary and you see, hey, it’ll be analytics not found. It’ll be target not found. So there’s nothing now apart from the WebSGK. You see that here the alloy library has been deployed. You see the library version. And now if I go into events, you just see one event, which is the experience, the WebSGK events. So if I go into networks, you don’t see analytics. You don’t see target. You just see the WebSG sending events. And you can look at the extreme schemas here. So if I, this is a payload that is being sent. And if you look at it, you’ll be able to see, hey, what is the, it’s the E-word has the page name. We want to track the event and so on, right? So this is the event type. This is the typical XTM format, which I spoke about.

One quick other thing is that, so this sends all of this to the edge network and you have an assurance screen here. So if I go on to events, actually, let’s just go into logs and let me open an assurance session. And what this does is basically show you what data is coming to the edge network and how it’s being handled. So it will show you every, like each and every event that comes through, what, how it’s processed and so on. Let me try and clear these for a second, clear session.

And if I now reload the page, you’ll be able to see things moving here. You’ll be, you’ll see here a lot of data coming in, a lot of rules have been evaluated. We consider what all propositions might be shown here and so on, and then track analytics as well. So this is all happening on the edge side, but it’s good for you to basically see what’s happening. Now, the last bit that I wanted to cover was the event forwarding bit. Now, I know a lot of you folks might not be seeing event forwarding as an option here, because that’s something which is part of the RTCDP connections queue. But what it does is basically allow you to send a lot of data to third party applications. Now, this could be either in the form of pixel data being sent to Facebook, Google, DoubleClick, whatever. And the other option is basically for monitoring purposes, for enabling a lot of internal complicated use cases, where you want some event to trigger a set of actions on your back end. So if someone maybe purchases something more than $1,000, just for a hypothetical use case, you might want to trigger something on your back end, allowing them to be eligible for a promo code or for a email or something like that. So you can trigger a whole lot of third party and internal use cases or workflows through this. And if I open this, it’s pretty simple. I just go to rules, I say, for this use case, I just want to forward this to a webhook. I open this, I have a condition saying that, hey, if the data that comes on to the edge network, if it’s the event type is page views, send, then just run this particular rule, if not, then not.

And what I want to do out of this is basically my action is to make a fetch call that just makes a get call to this particular webhook site, which I have there. So if I go to my webhook site, I have it present here. Now, what it does is if I, let’s say I just keep going on to different pages, right? Let’s say I go to FAQ.

Let’s say I go to this article page.

I’ve just been roaming around on the website and you see all these page views are being sent to my webhook. Now you will be able to see that, hey, the page name was so and so, and it can keep on changing. So it was magazine once, it was again, the homepage, and then Western Australia, which was one of the blogs. So just a quick example of what this enables, you can send whatever data you want to here, but it just unlocks a whole lot of possibilities on your end.

Now, for debugging purposes, I said I’ll just walk you through how we validate stuff. If I then again, go to the debugger, if I open events, or rather let’s just look at the network page, getting all these requests happening, right? The basic purpose or the basic validation that you would want to do is make sure that the events being sent to the Edge network matches what the requirements are. I would come into events and see, hey, the XGM data should be what we intend to collect, how we want to collect that data. So the event type for page views, the out of the box event type is web.webpage. Details or page views, and this is different from different events. So for example, if it’s related to target, it could be decisioning propositions or fetching propositions and so on, right? So if I, let’s say I open one related target, sorry, you will be able to now see that, hey, this is a proposition fetch call, which allows Adobe target to then send a routed data through the Edge network and send what all needs to be configured. Now this will have information about what all, what all activities needs to be triggered for this particular user or this particular session.

Now, there’s a lot on the screen, like you can go through the events, you have like a typical implementation, you would have a set of rules that you would want to validate here, but that’s how you can typically do that. Within Assurance’s screen, you can also write scripts. So basically you can write validation scripts where, and this is a very high level use case where if you have, let’s say, you wanna make sure that every event, every page load event must have a page name. You can write a script, but if the event type is page view, make sure that it has a page name. If not, then we might wanna discard it. So something like that, you can write validation scripts here, making sure that your implementation works well. I’ll take a quick pause here and I’ll stop sharing my screen.

All right.

So one thing that I wanted to ensure was that I showed you that the entire payload being sent is the XTM based, and once the call goes on the Edge network, that is where the entirety of routing is handled. So the Edge network decides through data streams what all services need to be enabled. And Elana, do you mind, can I share my screen once again? Sure, no problem, one second.

One thing that completely skipped my mind before is to show you how the routing works, right? So, hey, I have data coming onto the Edge network, what do I do then? That is where data streams come into play, where we define what data coming into the Edge network goes where. So let’s say if I open data streams, let’s give it a second to load. And now if I open any of these, let’s say I just wanna see one particular data.

Data streams basically allow you to configure where that data is being sent to. Now, it allows you to maintain that, hey, data coming in from this particular property should land into different services. These services, as you saw on the Assurance screen, trigger a set of different functions in the backend on the Edge network, which then lead the data to be routed to different places. Now, for instance, I have enabled in this one data stream, I have enabled that, hey, forward my data to Adobe Target, Adobe Analytics, do the event forwarding, which I just spoke of, and Experience Platform as well. Now, the primary purpose for today’s session was to talk about how we migrate from a legacy system to a newer Web SDK system. And that is why a lot of the focus has been on Adobe Analytics and Adobe Target. But one point of clarification is that, let’s say we start moving into the complete Experience Cloud ecosystem, we start moving to products like the Experience Platform, we set up RT CDPs, we set up the Adobe Journeys Optimizer. The XGM format becomes the core of our implementation, and that is where you have to use Web SDK for any tracking or personalization use cases.

All right, so having said all that, let’s just, I just wanted to showcase this. Let me stop sharing my screen again.

And let’s go back to the slides.

Now, moving on, again, quickly highlighting the differences that you see here, removing all these multiple libraries and just consolidating everything into one much lighter package, ensures that is a lot less overhead.

All right, so I just wanted to, so let’s just open it up, right? So I wanted to save a lot of time for Q&A. I was hoping, actually, I was assuming there will be a lot of questions around this sort of implementation. So.

We did get a bunch of questions in. I’m gonna turn our cameras on. We’ll get to answering as many as we can.

Let’s kick off with this first question, that we have.

We already have Adobe Analytics implemented via app measurement. Do we need to rebuild everything from scratch for Web SDK? Perfect, perfect question. So basically, no, you don’t have to start from zero. The only key word that we have here is to sort of map the data that we were tracking before to the XTM relevant schemas. But once we map that, we reuse most of our logic. So we can use the same rules that we had. We can use the same conditions that we had. Most of the logic remains the same. All we have to do is map the existing data elements and the data being tracked to the new XTM compatible format, and we are good to go. So that’s it.

Perfect.

Okay, you might have touched upon this, but can Web SDK send data to Adobe Analytics target and audience manager in one request? Yes, so as I mentioned before, that’s one of the biggest advantages. It just sends one single payload to the edge network and then your data streams handle the routing of the data on the backend. So it alleviates all of the pressure from the client side or your applications. Let Adobe handle the heavy work. Okay, great.

You mentioned a lot about event forwarding. So why would I use event forwarding with Web SDK? Sorry, what’s that? I didn’t catch the last question. Why would I use event forwarding with Web SDK? Oh, so basically, if the primary purpose of using Web SDK is to just send data to Adobe Analytics or interact with Adobe target, you might not need the event forwarding capabilities, but where event forwarding comes in, it basically unlocks a whole skew of capabilities or use cases where you wanna send data to maybe pixels. You wanna get into the cookie list world. You don’t wanna have pixels on your client side. You handle all of this data being sent to different platforms like Facebook, Google from the server side. So that’s where event forwarding comes in. And as I said before, you unlock a lot of workflows where you can trigger an email maybe, or you can trigger an entire complicated workflow from the backend using event forwarding. So extremely capable.

Great, thank you. All right, a couple more here. Do we need to rebuild our data layer for Web SDK? Good question. So I assume that data layer is something that most of us would have spent enormous amounts of time on, right? We preparing our data layers, making sure that they collect everything in the right format. So no, we don’t have to get rid of our data layers. The it’s very similar to the first question that we answered. We just have to make sure that we map the existing data layer to the new extreme relevant data elements. We have multiple different ways of doing it. We can do it through the rules, maybe create a data element out of it, or write a small JavaScript code, but there’s multiple ways of doing it, but we don’t need to get rid of it. We just need to map it to the relevant XGM variables and we are good to go. Okay, great.

Excuse me, what’s the easiest way to debug Web SDK requests? Oh, I would again call back to the debugger that I just showcased. It’s in Chrome extension. It’s called the Adobe Experience Platform Debugger. It’s available for everyone, any to everyone on a Chromium based browser. It lets you inspect payload. So basically it intercepts anything that goes out of your website in terms of Adobe capabilities and it intercepts the payloads, check the XGM mappings, and then confirm that the events are reaching the edge network. And then you can also get into the assurance screen where you have the edge network. You can see data coming in. And then it’s being processed and then being sent out. So it’s an amazing end-to-end validation capabilities that we have there.

Great.

Those were all ones that I saw. There’s a couple more in the chat. Arindam, I’m gonna give you a second to- Yeah, so- Perfect, so I see a question from around the relationship between the Adobe Web SDK and the Adobe launch and tags, right? So the Adobe tags is basically a tag management solution. Now what it allows you to do is basically have a library on your website so that if and when you require changes on your front end, you don’t have to go through the entire development cycle, maybe ask your website developers to make a new release and so on. So you have a tag management solution, which is capable enough of handling multiple libraries, handling different events and actions and so on. And then the Web SDK is just one JavaScript library or maybe some other, if you want to deploy it to the server side, if you want to deploy it to your backend, it could be like a node library or a NPM package and so on. But in our use case, the Web SDK is a JavaScript library, which can be deployed using the Adobe launch and Adobe tags. So it’s similar how you would have the app measurement library for analytics, and then you would deploy it through Adobe launch.

Similarly, the Web SDK is a alloyed or just library, which is deployed through Adobe tags. Does that make sense? I hope it does.

All right, I see how a lot of questions around validation and there’s one question around, let me just make, fine. So there’s one question around, would you recommend using assurance for testing debugging too as opposed to AP debugger? So like I would say no, unless and until you have extremely advanced test cases that you might want to write and maybe you see that everything is okay on the front end, that it is reaching the edge network correctly and you still see some discrepancy, that is when I would recommend going into assurance, but the AP debugger is the first sort of stage. So I would recommend everyone getting started with the AP debugger, get onto the debugger, see if the payload is okay, if the data matches our specs and then go from there.

There’s tons of questions.

Let me just make this public. Will switching to the Web SDK change the raw data schema since it’s in a…

So no, I mean, technically speaking, we don’t need to have a lot of restructuring of our schemas.

It’s the capabilities within the Adobe data collection and tags allows you to easily map even the nested JSON structures. You can map each field to any particular data element that you might have. So you can go into the next nested structure. You can go to one field and then map it to, let’s say, page name, what I just showed you, and you don’t have to then restructure it in a way which is easier to manage. These all capabilities are present in the Adobe Tag Management and you should be able to leverage that.

I see more questions around, hey, can I migrate Adobe Web SDK for Adobe Analytics without migrating? You can do that. So for example, you can use the Adobe Web SDK for Adobe Analytics without migrating Adobe target. So let’s say you just have the 80.js library still present and you have Adobe Web SDK for Adobe Analytics and you can do this in phases. Move Adobe Analytics, see if everything works fine, then maybe move it Adobe target. But the goal, as I said, is to improve latency, improve your overhead on your website and reduce or make our website much lighter. So the end goal is to remove all separate individual libraries and just have one unified library on your web pages. So you can do that, but the end goal is to remove all such libraries and then just have one.

Makes sense. All right, there’s tons of more questions flowing through.

So does this work on mobile apps? Excellent question. So even though I just covered one instance where we spoke about the JavaScript library called alloy.js, however, the Web SDK is not just the Web SDK. We have a mobile SDK version that you can deploy in mobile apps. You have a node version, you have this particular library almost available in all development formats. You can have the data packages for Java, you have that for any other backend services. You can even deploy this on your POS, your kiosk, your mobile apps. So let’s say you have an ATM machine somewhere, you can deploy it there as well. So it’s available on all platforms and you can leverage the same functionality. It’s just different, written in different formats. And I just use the JavaScript version as an example.

So I see on the similar questions, can we migrate different Adobe integrations separately? As I said, so you can just take one by one and then go from there.

Does the debugger work with the… So I see does the debugger work with Web SDK? Correct, so the debugger works with all Adobe services. So even if you are on the legacy implementation, you’ll be able to see those events flowing. When you move to the Web SDK, it becomes even more important because then you can easily see the extreme formats, the JSON structure that you see there. It’s much more easier to see or read in the debugger. So it does work with the Web SDK as I just showed you.

I see questions around event forwarding. Let’s take one of those. So we are migrating the event forwarding from Fresh Paint. Just wanted to know what are key things to be considered here.

So like if I put it very directly, it’s just a way for you to hit third party endpoints, right? It’s just you making net HTTP calls. It could be a post call, get call and whatnot. You are in this hand, this basically happens in a API sort of format or an HTTP interaction format. Now, the only considerations that I would want you to have is make sure that the payload that we are sending. So if it’s a GET request, make sure that the query strings parameters and the authorization and stuff are okay. You assign them carefully. And similarly, if it’s a post call or some other event, let’s say you trigger something on your back end, just make sure that the payload is structured well, but that’s pretty much it. The other thing to notice here is that you will have, to use event forwarding, we need to understand how the data is handled on the edge network, because data comes onto the edge network and then gets rerouted. So we might want to read up a little bit around how data is handled or accepted on the edge network. How do you access those data points? So I showed you, you can actually call it like arc.data.stuff like that. So not getting into the technical details here, but you’ll be able to, you have documentation around it, how you, around this, that how you access that data on the edge network, how you can read that data, how, and so on. So that’s one consideration that I would want you to keep in mind. But apart from that, it’s straightforward.

The other consideration, I’m assuming that you would already know if you’re, if you’re planning to migrate to event forwarding, is that we need the RT-CDP connections skew. So I would highly recommend everyone who is interested in RT-CDP, the event forwarding capabilities that get in touch with your SAMs or AEs or whoever you work with at Adobe to get more information about the RT-CDP skew and how you get, how you can get that enabled for your particular sandboxes. Yeah, we had that form on a previous screen and it will be on the next screen as well. So if you fill out that form, we will route you to the correct person to get you in touch on that connection. So thanks, Miranda.

Perfect. So I see one, let’s take, we have time for one or two more questions. So I see a question around not using launch, which is an amazing question, right? So we don’t want to limit ourselves to just the Adobe platforms or the Adobe tag management solutions. Let me just make this public. So if we are using TLM tag management or let’s say Google tag management, the Web SDK is quite a large, like it’s a set of lines, which is compiled into one JavaScript library, which is alloy.js. Now, similar to how you would deploy analytics or target through TLM tag management or Google GTM, you can place this JavaScript library on your page and then start using the functions available. So you can start using the set content function, send event functions and so on. You might have to tinker with the JSON formats, some data that how you formatted, how you send it to the edge network. But at the end of the day, it’s a simple JavaScript library that you can put on your website through any tag management, or even if you want to hard code it, not that I recommend that, but if you want to do it, you could, it’s straightforward.

Yeah, I see a lot of more questions around similar lines, but I think we, do you see any other questions, Elana, that I might have missed? No, I think you got most of them. Some of them were just the same questions raised in a different way. So I think we got pretty much all of them. If there was one that slipped through that we were not able to answer, definitely reach out to your success account manager and we can put you in touch. If you don’t know who that is, we are happy to help.

I’m gonna go ahead and wrap us up.

Thank you so much, Arindam, for such an informative presentation and answering all the questions.

Don’t forget to fill out that form here up on the bottom right corner of your screen. If you’d like more information on RTCDP connections, again, if you have a question we weren’t able to get to, please reach out to your solution account manager, or if you don’t know who that is, you can reach out to me and I will put you in touch with the correct person. As a reminder, you will receive a recording of these events in email from us in 24 hours from now. So that’s all that we have for you. If you have a moment to fill out the survey questions below, we’d really appreciate it. Thank you guys for attending today. Thank you, Arindam, for a fabulous presentation and we hope everybody has a great day. Look forward to seeing you at one of our upcoming events. Thanks, everyone.