Ask the experts: The basics of Web SDK

Transcript

Hey everybody, welcome to Experience League Live. Got my shirt here. Experience League Live, welcome. Glad to have you with us today. We’ve got a great show prepared for you today. We’ve got some experts. We’re going to talk about some great stuff today. Before we do, just want to give you the rundown here for Brought to You by Experience League. For all of your self-help materials, you’ve got documentation, tutorials, free courses. You’ve got the community, talk to your peers. Hopefully, you’ll come on over to experienceleague.adobe.com and join us there. Let us know if there’s anything missing. If there’s anything that you want us to have there available for you, then just let us know. With no further ado, let’s bring in our guests. Today, we’re going to talk about the basics of the Web SDK. We’re going to have an Ask the Experts. We have corralled our resident experts on the Web SDK so you can learn everything you ever wanted to know about it. And maybe then some more after that. First, we are going to bring in Rudy Schumpert. And here he is. Rudy, where are you? There you are. Hey, Rudy. How are you doing? Thanks, Doug. I should have asked you ahead of time. Is it Schumpert or Schumpert? Did I get it right the first time? Schumpert. It was close. Oh, son of a… OK. I was going with the German pronunciation. So there you go. I don’t know. That works. OK. And Rudy, you are a senior evangelist for the platform and for the cloud as well. Is that right? That’s correct. OK. All right. In 20 seconds, what does that mean you do every day as an evangelist? So I really worked with our customers and internal folks to help educate them on how to get the most out of our products. OK. Well, in case you missed anything in that explanation, we’re also going to bring in our very next evangelist as well. And welcome to Jeff. Jeff Chase and welcome to the show. So Jeff, you are also a senior evangelist for the platform and cloud. And what did Rudy miss that you guys do in your day to day? I’m just a sidekick. I’m just being a sidekick. Got it. Well, we try to help customers as much as we can. You know, we use the materials on Experience League and contribute as much as we can. But try to maximize the value they get out of the time they spend with our stuff. OK. Awesome. Yeah, I was going to say that if you’re the Ed McMahon to Johnny Carson, but I figure that probably half of our viewers don’t know who those guys are. So they will have to say, they’ll have to choose some different sidekicks. Yeah. All right. Last but not least, we bring in Eric Matusoff. Eric, how are you doing? Hey, hey, hey. And Eric is not a senior evangelist. He’s the principal evangelist. That’s right. Principal evangelist for analytics and data science. Is that correct? You got it. Yes, sir. He’s a scientist. We’ve got to have, we always try to have at least one scientist on the show just to keep us honest. I did bring some beakers and test tubes with me. OK. OK, good. OK, sounds good. All right. Well, you guys, thanks for being on the show today. Glad to have you here with us. And we’re going to talk about the basics of Web SDK. I just want to spend a minute and let everybody get to know you guys a little bit better. So I just want to run through maybe your fun facts a little bit. And Rudy, we’ll start with you because this is maybe, this is one of my favorite fun facts we’ve had on the show. You’re like, I don’t know, I don’t really have anything. And, you know, it’s nothing, it’s no biggie. I just have 14,000 Christmas trees that we pull out in our house every year. OK, that’s a exaggeration. It’s a little high, but we don’t have quite the collection of artificial trees. There is enough to have a tree in every room in the house, at least two. And sadly, some of them, most of them are themed. So. Oh, they’re themed. OK, OK. Of course they’re themed. Yes, yes. OK, OK. Do you have, this is what I want to know then, if you have themed Christmas trees. I’m only counting on you here, Rudy. I need to know if you have one for Heat Miser and Cold Miser. And if you know who I’m talking about from the year without a sanitize. No, we don’t have any of those. No things for that. OK, well. It’s OK, Doug. It won’t be the last time I disappoint you, Doug. This year, this year, this year. OK, which one is your favorite? You have a favorite? We have a tree that’s all just small photo picture frames with family photos. That’s probably my favorite. Ah, very nice. You’re going to be really endearing yourself to the audience right now. It’s a good move. OK, Jeff. Jeff, you are an avid scuba diver, which is awesome. And over 500 dives. I’m glad that you’re still with us, having gone under the water that many times. So, what was your favorite dive out of all of those? I don’t know if this is a favorite dive or favorite place, but. It’s hard to pick a favorite place or dive, but most interesting, I guess, was taking my two kids diving in a river on a shark dive where they fed the sharks. That was pretty cool. A little nerve wracking as a parent and probably not my finest parenting moment. We needed to do that, but it was fun and we looked at all about it. Yeah. Hey, you guys called DCFS. That’s awesome. That’s awesome. I’ve been once, I think, in my life. It was fun. Awesome. OK, Eric. How are you doing? Yeah, so as also the evangelist, we didn’t get really to your what you do all day kind of thing. But is it is a lot of working with customers a lot like these guys do, but mostly with analytics and data science? Yeah. Yeah. Working with customers, working with products, working with sales, working with prospects, working with consulting, working with technical marketing, really just trying to find ways to take our products and share out the best ways to use them. Best opportunities, latest and greatest capabilities, writing books about them and whatever it takes, whatever it takes to share the Adobe Gospel. Nice. That’s right. Sharing the Adobe Gospel. The evangelist. Nice. I like it. Cool. Cool. And you’re a soccer player, even at your ripe old age of twenty nine and a half. Still playing some soccer. That’s nice. In a league. Yeah. Tuesday nights, Tuesday night pick up, Sunday morning, Sunday morning, forty five minute halves, eleven v eleven. I don’t get a lot done on Sunday afternoons. I know that. Nice. Awesome. Well, thanks guys. Thanks for being here. We win twelve nothing on Sunday. Oh, OK. They were nice. They were not good. OK. Well, congratulations on stomping those guys and hope you feel good about it. To you as well. All right, guys, I’m pretty sure that they are now interested in hearing the actual topic that we came together to talk about today. So anyway, so, Rudy, do you want to kind of you want to kind of get us pushed off in the right direction here? We’re going to, you know, we’ve kind of teased this that we’re going to talk about the basics of SDK. And then I will kind of say to everybody, you know, please do please do come into the in the chat room and and, you know, give us your questions that you have. We have some, too, that we’ve kind of, you know, gotten over there over the last, you know, however long. Rudy, you’ve got you’ve got a list of questions for us, right? In case people are slow to bring them in. Absolutely. But but please do go ahead and you guys put your questions that you have for these guys into the chat pod and we’ll have we’ll have them address them here on our live show. So I appreciate that. And Rudy, what is you know, what is probably the start you go here? What is the main basic question? Is it is it what in the world is Web SDK or or what is it? Yeah. So yeah, I’m sharing my screen here, Doug. OK. The question we get kind of the kind of start off and give us some framing is, you know, what exactly is the experience platform Web SDK and how does it fit into Adobe’s data collection strategy going forward? And so I think this is a good starting point for most of the conversations I have with customers. So here on the left side, we basically the experience platform Web SDK is a consolidated tracking library for all of the tracking. So in the past, for legacy data collection, you would have measurement. You’d have the 80 dot JS file for Target. You’d have the deal file for audience manager. You’d have the visitor ID code for the visitor ID service. And you’d have to maintain multiple libraries. And this was true whether you used our own tag management software now called tags or whether you use any other vendor as well. You had to maintain multiple Adobe libraries to accomplish the data collection for Adobe. And not only do you have to have multiple libraries, you had to make sure that as you upgraded one that the other versions would work with the new the newer version of that library. So keeping them in sync. I often thought of it as the carnival sideshow where you’d see the spinning plates or on Johnny Carson, like you mentioned earlier. They have the entertainer there. They’d have to keep all the plates spinning at the same time and then fast enough so they wouldn’t drop. And that was a lot of how I always thought about keeping the Adobe implementation going is you had to keep all the versions in sync so that you’d get the most benefit from the tools. So when we introduced the Adobe Experience Platform Web SDK, we gave our customers for the first time the option of a unified collection library. And so now whether they deploy that through tags, which is our recommended solution, or they deploy it through some other tag manager or just natively on the site. They only have one library, one set of code to deploy that will they can then turn on analytics. They can turn on target. They can turn on sending data directly to the platform all from this one code base. So the long term data governance becomes easier because you’re only having to worry about when there’s an upgrade to the SDK. You don’t have to worry about whether it’s compatible with all the other versions of the Adobe code that you’re leveraging because it’s all self-contained. The great thing is, is that the same approach that we’ve done with the Web SDK also applies to our mobile SDK as well. So the new mobile SDK also now has a unified set of code and then also just came online a couple of weeks ago. Pardon me. You have the ability to actually connect the server to server deployment as well for data collection. So whether you’re trying to do data collection from like set-top boxes or mobile devices or traditional web applications, you’ve got a single code base now that you can deploy. And then once you’ve deployed it and you set up the rules and you’ve set down all the configuration, what happens is the data gets sent to our edge network, which is right there in the center of that Illuminati looking triangle. And right there where there’s the edge, you can think of it like a really fast traffic circle where based on the rules and the conditions and the configurations that you’ve set up in other parts of our data collection system, it’ll send that data directly to platform. It’ll send it to analytics. It’ll let you interact with target and offer personalization, you know, back on your web application. Now, and as you can see from that bottom part of the triangle there, you can also start sending that data out to non-Adobe destinations as well. So event forwarding or RT-CDP connections, basically you can take that single call or that same call that we sent to the edge, it feeds data into the Adobe stack, can be used to syndicate data out to non-Adobe destinations as well. So it’s pretty exciting that we’ve after 15 years plus of multiple JavaScript files that we now have a single combined code base. Yeah, that is awesome. That is awesome. And we’ve had a question that’s been answered also, asked and answered in the chat there. But you know, like what’s the difference between tags and launch? And as people said, yeah, it’s just a new name. The greasiness of sadness among the folks that used to call it satellite. So it’s just brandy. It’s just brandy. Yeah. Yeah. And it will, it is, I totally get it’s confusing. You know, we’re trying, you know, we’re not intentionally changing the names to try and confuse people. There is a plan behind there to try and align things so that it makes sense as we add more pieces and add more functionality. So I get it. But yeah, right now, so if you think of Adobe launch, really that’s now tags. So tags contains everything that’s done on the client side that launches to handle. And it’s kind of important to have the new name differential because within the same interface, there’s additional functionality that’s been added. It was never part of the original charter for launch itself. So the building out of the data streams, which allows you to basically control the rules there in the center of this chart, the edge network, where that data is going is now managed in that same data collection interface. So it’s not a launch capability. It’s a separate piece of functionality. So that’s why, you know, part of the reasoning behind why there’s tags, data streams and event forwarding broken out as separate features and functionality within our data collection offering. Okay, cool. Thank you. Thank you. Appreciate that. We are having some, you know, some questions come in. So I’m going to throw this one up on the screen. So this might be for later, but, you know, there’s no time like the present. So I’m going to bring this one up here. Pam asks us, would you recommend going ahead and setting up Web SDK while still sending data directly to analytics so you can verify your data is the same? So, you know, that plan of as you kind of move over from app measurement to Web SDK is the method, you know, maybe a little bit of overlap time as people move over to that. Thanks for your question, Pam. Sure. And that’s a great question. And I’m going to, I’ll give you my opinion on it. And then I’d love to hear what Jeff and Eric have to think on it, because I think every person you ask it a bit is probably going to have a slightly different inclination in this. And so I’ll start off by saying there’s, I think it’s a great method to do for as a short term or as a trial period to put the Web SDK up in parallel with your existing implementation. Don’t touch anything with your existing implementation to start with. You can add this in side by side. It’s really easy to do that in tags. And then maybe spin up a test report suite where you can send some of that data off and get more comfortable using the Web SDK. You know, a lot of the approaches to data collection and the way you think about data elements and building out the data object that you’re going to send along with the Web SDK to the edge is fundamentally different than how we used to think about implementation using the legacy methods. So I definitely think it’s a great, great opportunity to get some experience with it right out of the gate before actually changing over a whole bunch of things within your existing implementation. If you’re also able to start leveraging RT-CDP connections, which it is, there is a cost associated with using RT-CDP connections, event forwarding, unless you’re a new actual RT-CDP customer, which I believe that’s bundled in. But don’t hold me to that. But that’s another great way because you can really start building out rules and give it real production level testing, again, without touching or altering your existing analytics implementation. So I’m a big believer of getting comfortable with it before you do a rip and rip close. Yeah. Yeah, yeah, yeah. So, yeah, and just kind of a little add on here, kind of a teaser, I suppose, that next month around the same time here, kind of in four weeks, we’re going to do another one of these with these same great guys here to talk, to do a deep dive into RT-CDP connections into the event forwarding. So we will on that one, if we kind of don’t go too deep into that one here, everybody, then know that we’re going to come circle around next month and really hit that one hard for you as well and answer your questions. But it’s good to know that that’s there as part of this, as part of the Web SDK, you know, stack here or feature set. So cool. Jeff, what are your tips about as you move, for example, in this case, we’re kind of talking about analytics specifically. So maybe talk about that. But is that also kind of the same, I don’t know, the same paradigm that you would use for whether it’s target or even audience manager or whatever else, but maybe kind of focusing for a second on analytics since that was a question. You know, as they move over to Web SDK, what are your thoughts there? I would just emphasize Rudy’s opportunistic approach where you sort of, you know, ease into it. Because, you know, one thing with these new data collection technologies is it’s one thing to look at the technology and the use cases that you come to support and implement. But it’s also, as everyone who does this knows that you have to operationalize it, right? You have to make it part of a day to day. And some things are different. And so, as Rudy suggested, I think it’s a pretty common recommendation from the Adobe side that you absolutely do not have to do any kind of a gigantic project where you’ve ripped out something that’s old, you know, replace it with the new. You can do it step by step. So I would definitely echo his comments. I know there’s a whole bunch of comments now flowing in and questions. I’m not sure which ones you want to take on next. But I think in terms of a migration, definitely doing it one small step at a time is the way I would recommend. Yeah. Yes. And we do have a lot of questions coming in. You guys, thank you for those. Appreciate that. I don’t know if you guys have seen any there that you want to address specifically. But there seems there’s a couple that are talking about, you know, when you’re moving from one data collection strategy or technology to another. How do you verify the data is going to be the same? So Pam asked, you know, if you’re moving, sending data directly to Adobe Analytics and you want to check out Web SDK and some other questions related to that as well. How do you compare the data? How do you observe the data? So the good news is that with Web SDK and with all of our data collection tools, if anyone watching has not seen the Chrome debugger, the Adobe Experience Platform Debugger extension, that’s a nice utility to use for data validation. And it does work with event forwarding data from the edge. I know someone had popped a question there about validating that data. And it’s also part of the debugger extension is what is called Project Perfum. I know there were several questions about mobile. So that’s also available to validate and troubleshoot and document your data collection so that it flows through the system. So from your site or your app, just like the diagram that’s on the screen, from the left to the edge and then out whether it’s to a non-Awarebbe endpoint or to one of the Adobe solutions like analytics, etc. You can validate that the data you expect is the data you’re receiving in the variable format that you want. So we have a really expanding the observability of these things at the same time that we add to flexibility. Yeah. Yeah. Thanks. Eric, did you want to add anything to this conversation before I kind of move on? And Rudy in the background before… Sorry, Eric, before I catch you off here, I’m going to catch up. Rudy, I don’t know if you wanted to bring up something like that and be able to show anybody, show them kind of how that debugging might look. But let me move back to this while you kind of get that ready, maybe. And so you kind of show them the debugger, what that will look like as they debug the data coming through the Web SDK. Eric, what are your thoughts though, regarding this topic of moving over? In terms of migration, I think Jeff and Rudy covered it. I don’t have anything to add. We got enough questions to come in. The one that I thought was most interesting, Doug, was perhaps like around licensing for the Edge network and using it and using Web SDK and server calls and all that kind of stuff. There are maybe two or three or four questions that covered all of those. So maybe we’ll just like wipe those clean so that we can wipe them clean. We’ll take care of those all now and go from there. Rudy, I don’t know if you want to take that first or I can. I’m happy to. So I was trying to pull up the… Go ahead, Eric. Yeah. Yeah. So there were some questions around like who gets access to what and all of that kind of fun stuff. So first and foremost, if you have any Adobe Experience Cloud product today, you can start using the Web SDK, the mobile SDK, the server to server edge API in coordination with the Edge network and data streams. There’s no additional SKU required to utilize data streams and the experience platform edge network in correlation with the Web SDK, the mobile SDK for edge network and the server to server edge API. You don’t need to buy real time CDP. You don’t need to buy anything experience platform related. If you have analytics, if you have target, if you have audience manager, if you have customer journey analytics, if you have AJO, whatever, you’ve got access to send data into Adobe applications using that Illuminati slide that Rudy was sharing earlier. And where you need to add licensing is if you want to also use event forwarding to send that data to non Adobe destinations. If you want to utilize the Facebook conversions API, if you want to send data to a backend data lake or data warehouse that you’re hosting and stream it in real time, then you would utilize event forwarding for that. And therefore you would the SKU to actually purchase that standalone is called real time CDP connections. Or if you already have a current SKU of real time CDP prime or ultimate, then you actually automatically get access to event forwarding as well. So hopefully that’s a little bit helpful. But in terms of server side tagging, that’s the only time that there’s an additional fee for using the product. Now, in terms of like server calls, server calls going into analytics are the same that they are with your contract for Adobe analytics, regardless of how they come in. If they come in from the data insertion API, if they come in from using Adobe tags to the analytics extension or using, I don’t know, some other tag management system that I can’t even come up with a name for into the web SDK or. Alloy into analytics, a server call is a server call is a server call. Hopefully that’s helpful. Yeah, no, that’s great. That answers some of the questions up there. So I appreciate that. Hopefully it was enough. It was enough blathering that Rudy is now able to pull up the debugger as well. While he does, while he does, and while you share that, I’m just going to throw one more about mobile. And I know that we could probably go, you know, we could go deep into mobile and spend the rest of the time. But I just want maybe, maybe even a quick answer for mobile. Right now, this is, you know, Rajeev says we directly add mobile SDK into our web, into our mobile source code at the moment. Is that going to change with web SDK? Will there be as they move to web SDK with mobile, the mobile SDK? Is that going to be a big, a big change in paradigm shift there, I guess, and what they’ll have to do? So the, sorry, you go ahead, Jeff. No, no, feel free. So there shouldn’t be any change. The mobile SDK is a separate SDK that’s designed specifically for those mobile interactions. So the new, the latest mobile SDK is what enables being able to send stuff to the edge and also leverage the event forwarding and the other features that the web SDK also enable. So I think you still have to deploy it through, get it into the app using the same method. But once it’s in the app and you’ve got that configured, it’s the, what you can do to the data when it hits the edge, which becomes very different than previous iterations of the SDK. Yeah. Perfect. Thank you. And maybe we’ll… Think it’s done right, Jeff? Yeah. I mean, yeah, I don’t think it’s, that’s very funny because we both know it’s not really a question of right or wrong. It’s just, you know, the particular use case that the customer has. But I think for the person asking, one thing that I think helps people coming from maybe a mobile background or a few specialists who spend a lot of time implementing in mobile apps, it’s sort of the paradigm, if you will, or the way I think about it is that with the web SDK and specifically with the web SDK and launch or some other tag management system, it’s a rules engine, right? If the visitor does this, then we want to capture some data or do some stuff or send some data to some system and that executes in the browser when it’s running. And so it’s really rules management or tags management, if you will, down to a real granular level. But on the mobile side of things, when you’re working with the mobile SDKs and launch, it’s really SDK management because the actual actions that you track and the state of your app that you track, you’re going to place those calls in your Swift files or, you know, whatever your technology is that you’re using to actually create your app. Those are embedded in the actual source files of the mobile app. So it’s a little bit different way of thinking about it. So once the embed code is installed on your website, then you can manipulate things and control things through your tag management system using the web SDK. On the mobile SDK side of things, you’re in a tags property and a mobile property and you’re managing the SDKs that you’ve installed and importing into your application file. So it’s just a little bit different way of thinking about it and a little bit way of instrumenting the mobile app versus instrumenting your website. Maybe what we can do is kind of plan one of these for going deeper on mobile since we’re kind of trying to focus on the web SDK today. And it’s fine because obviously they’re related, you know, it’s just a different SDK and platform there. But we can maybe go a little bit deeper in another one of these shows too, to the mobile SDK as well. Before you cut over to the debugger, there was a question from Ryan, I’m not sure if he addressed it, on how do you run in parallel when you’re using the ECID, the audience manager and target. So because one of the migration ways that we have approached was like running them side by side. So the good news is that you have to, you need to think of them as completely separate, you know, rolled off implementations, even though they’re running side by side. So the visitor API code, the visitor ID service code, and the stuff that legacy collections like target, AT.js and audience manager is looking for, they’re looking for that ECID that’s created by that visitor ID library. So when you do the web SDK, there would be a second, if you had the visitor ID service implemented and the web SDK, you’d actually have two different IDs generated. But legacy target and legacy audience manager would not be looking for the one that was set by the original visitor API. So it should run completely separate. So Ghostbusters of old, you don’t cross the streams. If you’re doing stuff in the web SDK, you need to be, think of that as completely separate and firewall it off. And everything you do in there is self-contained and not have any expectation of reaching in and looking into that to pull stuff out for your existing legacy implementation. So, yeah, maybe follow up to that. And I don’t know, I haven’t, I don’t know if somebody asked this yet, but I will. And that is, tell me about, if you have those two IDs, and you’re cutting over, I mean, tell me about, you know, visitors and being able to, is it a cut off and we’re starting with visitors and there’s a, you know, a clipping or what do we do about visitor identification as you move over? As you move over to web SDK? Yeah, I can take this one. So, so the web SDK kind of manages all of that for you. So there’s a checkbox to basically say migrate from EC ID over to web SDK as you’re setting up the extension. And it’s, it’s a pretty painless process. So it just simply extracts the EC ID value from wherever it lives within the cookie and places it into the web SDK for use going forward. There’s none of that like grace period stuff that we had when customers went from analytics to EC ID or anything like that to worry about. Cool. Thank you. Rudy, are you ready to show stuff? Yep. I’ve got the debugger pulled up. So just let me know. All right. Yeah, we’re ready for you. Debug away. Fantastic. So we’ve got one of our lovely Luma athletic apparel sites up in the morning that we all know and love. And I’ve opened up the experience platform debugger. This is a Chrome extension. You can find it in the Chrome store. Just search for it and install it. And what you really need is you have to authenticate in. And it’s important that to do this because without having actual access, you won’t be able to without having access to that particular property. An account won’t be able to see all of the edge trace information. So I’ve got this page pulled up here. It’s showing me that I do indeed have the Web SDK deployed. It also sees the tags is running. And if I start going into away from the summary and into more of these solutions here on the left, we start getting more information. So this will show me the network requests. It will actually show all of the different. This is pulling in the EC ID here. It’s going exactly from the configuration IDs. And if you move over towards the edge transaction and after you actually enable it, you can actually see kind of a nice visual flow of how those calls are being processed. So right here, this was the Web SDK on the client side. It gathered up all the necessary information. The data was sent to the edge network. Over here, the hit was received based on the rules and everything that we have set up. This data was then forwarded over to Event Forwarding. And this is evaluating all the different rules in Event Forwarding. Some of that data was automatically mapped to analytics, automatically mapped into target and audience manager. And so that’s a really cool kind of visual representation. But there’s another little more detail. You can go to the logs. Excuse me. And kind of like the developer console, just being able to see the different stuff running from tags on the client side. You can also flip over to edge. You’ll have to start a session if you haven’t already started one. And then it will show you basically the same information. You can say, OK, the request was received on the edge. And you can actually dig in and see everything that was sent over in that particular XDM object. And then I’ll actually go through and show you that we sent data off to directly to analytics. The left was mapped. This page view rules, this Event Forwarding rules was set up. Data was sent out to a webhook site that apparently was not found. And you can see that we sent data off to other systems as well. So you get that same level of granular access to the debugging information that we all know and love from the developer console in our browsers. But with this authenticated debugger, you’re able to actually see everything that’s going on on the edge as well. So if you haven’t downloaded the Experience Platform Debugger, I highly recommend you do it. It’s really the only reliable way to view and kind of debug and troubleshoot your Event Forwarding implementation or what’s going to the edge. Even if you’re not using Event Forwarding, that stuff is automatically, you’re trying to automatically send analytics and target and such. Any questions with that before I kind of stop sharing on this part? Thanks for doing that. Thanks for showing us that. Let me go back to the gang here. Yeah, no, that’s good. I think one of the questions that comes about here, and I think it has, you know, it’s at least related to this. I know, Eric, that you kind of teed it up here in the chat as well for Krista. And that is maybe the simplicity of understanding tags that the Web SDK and XAMPP bring to developers. And is it harder? Is it easier as they move from, you know, kind of the old world to the new world here? Is it going to be, you know, is the level of effort, you know, going to go up or down or the same as people start working with Web SDK? Sure. So there’s always a learning curve when you start leveraging new technology. And the way that the SDK approaches data collection and the way that you bundle up the data into a data object, whether you use the XDM object, you know, the Adobe XDM object in our schemas, or whether you have your own data layer. The kind of the whole approach of assembling a data object instead of just grabbing this little data point, this little data point and appending it to a query sharing parameter, sending off a pixel request. It’s a different method. And so absolutely, there’ll be a little more work in the beginning, just as you get familiar with the platform or familiar with the framework and familiar with how you know, how you construct data elements, how that changes, the way you build rules, the way you think about, you know, assembling the data layers on the page. So it is a shift in how data collection is done. I do think that, you know, eventually the juice is worth the squeeze. I do think that once you are able to move away from the legacy implementations, when you’re comfortable enough with what the new method can provide to you, being able to have all of your tracking code consolidated. The downstream benefits of being able to start moving a bunch of these third party tags off of the client side and move them over to event forwarding is a huge benefit. I know that’s not what we’re talking about today. We’re going to do RT-CDP connections in depth, but that’s a huge benefit because, you know, what tags will work and whatnot. You know, there’s, you know, a lot of customers are dealing with when you load up a page, even you, adobe.com is no different here. There’s tons and tons of third party tags that are running. Well, then that takes time and bandwidth and has an impact on customer experience. So anything you can do to streamline your implementation, to consolidate those rules, to consolidate the tags and to move things off will be a boon to customer experience. But yes, there, you know, when we moved from Adobe Tag Manager to satellite, there was a learning curve, DTM. And then we moved from DTM to launch. It was complicated and there was a learning curve. This is another one of those evolutionary cycles where we’ve changed at a pretty deep level how we’re looking at data collection. The great thing is all the stuff that you’re building from the edge, being able to, you know, that traffic cop in the middle of the Illuminati slide that I showed you, you know, that starts to become even more powerful when you start leveraging the web SDK and the mobile SDK and the service API. Because the edge doesn’t care where the data came from, doesn’t care if it came from a web app or a mobile app or a laptop device. You’re really starting to simplify what you’re doing with that data after you send it to Adobe. And so, yes, there’s going to be more work to start with, but I do think that the benefits that you will achieve down the line will start to make it all worthwhile. But, you know, there’s always going to be. That’s good. And I want to just, I want to kind of back up for a second because I want to skip over this. And the kind of, this question, this question from Jason here, that actually kind of triggered this in my brain here for a second. And it’s this, to use all these things, you do have to first be provisioned, right? I mean, like how does it enabled? And so, I guess my question, I’m going to add on to your question a little bit, Jason, and that is like, let’s say that, you know, I don’t have platform or RTCDP. I have analytics and I want to kind of go towards this new, maybe I have analytics and target, or I want to go to the new world here. Yeah. How do I get provisioned or how do I get this interface where I can actually go in and, you know, and set things up? And, you know, obviously I’ve got to be able to get into data collection tags, you know, aka launch and be able to set that up. And maybe I already have, or I don’t have access to that interface. Anyway, what are the steps that are needed to kind of be able to get to all of these things in order to start really using it? So the great thing is, Jason, that, you know, my Venmo is just my name. You can just start sending me money right now. There is a provisioning process for some of this stuff. So there’s no additional cost to use the Web SDK to consolidate and streamline all of your Adobe tracking. So like Eric said earlier in the call, the server call to the edge is the same as the server call from the legacy implementation. So we’re very indifferent on that. So you can, the Web SDK extension is in tags right now. Everybody should have access to that where they could go in and set that up and start using that to consolidate their data over to, to send over the edge. You may still have to be technically provisioned to see this, the part in the interface to build the schemas. If you don’t have, I’m going to share my, I’ll share my screen right here. So if you don’t, can you see my web browser now? Yeah. Awesome. So if you don’t see the schemas set up here and you want to use the kind of the XDM format to, to, you know, to build that data object I’ve talked about a bunch to have the SDK send that over, just email your account team. They can get this turned on for you. I believe I heard that sometime later this summer, the schema stuff will be turned on for everybody, but I know that’s a process of just instead of requesting it, they’ll have that activated automatically. And then once the schemas are turned on, you should also see data streams up here so that you can configure in data streams. You know, whether you’re sending that data, you can add the services here, whether you’re going to send data to analytics, target, audience manager, event forwarding. And of course, if you don’t have an event forwarding or have a contract for that, that won’t be an option for you to select and you won’t see event forwarding over here on the left-grained as well. So some of this stuff does have to be provisioned, but there’s not always a fee associated with a certain set of these features. So hopefully that makes sense. Yeah, thank you. Thank you. I will also add, you know, give my mid-roll here. We’re actually doing good here. We answered a lot of questions, but I will kind of give my spiel here for the fact that there are some tutorials and there’s the documentation. And again, if you come to experience.elig.adobe.com, we do also have a page by page tutorial to walk you through the implementation of the Web SDK. We’re currently building out of some things that are a little more closer to the migration path, but that will be available also on experience.elig.adobe.com. And there are some just, you know, standalone training videos to kind of address specific topics. And of course that’s where the documentation is too. So that’s my plug again for coming over to experience.elig after the call here. Great. Hey, Doug, if we have time for it, I think there is a really good question from Olivia. Olivia or Oliver. I’m awful with other country names. You murdered that. For the first three years that I met Rudy, I called him Rowdy. So, you know, you just can’t trust me. So, I don’t know if you can post that question on there. I also wanted to point out that I charge my phone with experience.elig. Oh, yes. Nice. I recommend it. How did you get one of those? I don’t know. I don’t even have that. This thing is ancient. I’m surprised my phone hasn’t exploded. Okay. Let’s move this up so it wasn’t in front of anybody’s face. Okay. Yes. Is this what you’re talking about? For clients that are not licensing. Yeah. I’ll just hold it up for you. Oh, yeah. Thank you. That would be… What would be the main benefits to migrate them to AP Web SDK for now? Yeah. Yes, sir. I’ll take an initial stab at this and then, Rudy, Jeff, if you guys want to add to it, that would be great because I’m certain I’ll miss something. So, probably the reason that we built the Web SDK is to consolidate libraries. It’s all about a smaller library in terms of the number of… the amount of JavaScript that’s being delivered to the page. What that brings with it is it’s also less JavaScript files that are being delivered to the page. And so, from that perspective, it’s very much about faster delivery of your code from the client to analytics, from the client to target, from the client to audience manager. Because that also means it’s just simply a single tag from Adobe tags that is sent into the Adobe ecosphere. Now, another really big thing that comes with that, and I linked to it a little while ago, was there was a question around like ITP and cookie deletion and those kind of things. One of the really big differentiators that the Web SDK brings to customers is the ability to essentially set your own ECID value. And we call it the first party device ID. So, what you’re doing is you’re taking a unique ID that you set in a server side cookie and since it’s a server side HTTP response cookie, and Jeff will do a much better job describing what that actually means than I would, then it is not as limited in terms of how the expiration by ITP. And that means on Apple devices or iOS devices and iPadOS devices as well as in Safari on Macs, it can persist longer than two weeks. That ID that you’re defining as your first party device ID gets passed in and generates an ECID associated with that user. And even if the ECID cookie that’s set by JavaScript is deleted, then the Web SDK will look for that ITP solved, I don’t know, that’s a terrible word, first party device ID that you’re setting in order to persist that visitor for a longer period of time. So that’s the second big differentiator. Then the third that I happen to like is since it’s a single hit that’s going to both Analytics and Target, if you have both of those applications, two kind of cool things happen there. First of all, the data is even tighter than ever because we don’t have to worry about any kind of SDID or any, or like using ECID to link and map the two applications together. So the data is just simply better and stronger, faster and more, I don’t know, rowdy to mention rowdy’s name earlier. But the other big piece around A4T is that your real time reports within Adobe Analytics come in faster. So if you have A4T and you’re using legacy libraries, i.e. you’re not using the Web SDK, there can be a longer period of time between data getting sent and it showing up in your real time reports. Whereas I’ve seen it like 80% faster when you’re using the Web SDK in terms of real time reports. And to answer JF’s question there about what is an example of an experience platform native application, we’re talking real time CDP, Adobe Journey Optimizer and Customer Journey Analytics. Those are the three. So if you don’t have one of those three, then this conversation that I’ve been having with myself will be of interest to you. Jeff and Rudy, tell me what I missed. I don’t think you missed anything there. I think the example you gave of being able to set your own ID is an important one because for those of us old enough to remember when there was the move from S code to app measurement, there were new features and functionality that were enabled because of leaving the S code behind and moving over to app measurement. I think marketing channels might have been the big driver at the time. Don’t quote me on that. The newer features and functionality, the new benefits, the new hotness that will be coming out as part of data collection will be added to the Web SDK. The legacy libraries, they will continue to function. We are not in the business of turning off your ability to send us server calls. We will collect those server calls as long as you want to send them to us. But the newer features, the things like bring your own ID and things like that, those are really going to be more focused in the Web SDK. So if you want to be able to have access to those new developments as they come online over the next however many years, then that’s a big draw. Even if you’re not leveraging some of the other platform specific applications, just having the latest and greatest of our collection code is a pretty big draw in and of itself. Yeah, what do you think, Jeff? What do you want to add? I don’t think anything to add there. I know we had some other, I think there were some other questions maybe we didn’t get to. Yeah, if you saw one, I’m just going to add this too. I know that I’m just the host and so I should just be quiet. But I’m going to add the fact that, look, even if, let’s say you’re just analytics only right now. As you know, if you’ve been doing analytics for a long time or for however long, to me, it’s always been a little bit difficult. I know we had some tools, what we’re calling data sources and things like that to get other non web data in and merge it with your web based behavioral data. And that’s hard, at least harder in Adobe Analytics. And so that’s the beauty of like customer journey analytics is just this whole ability. And it’s fine. Look, if it’s down the road, it’s fine. I just wanted to kind of throw this out there because I know that was always kind of a stumbling point of thought for some of my customers that they wanted to bring in other kinds of data, whether it’s call center data or whether it’s point of sale data. Or whatever other kind of data you have and merge it with your analytics data. And that is made more possible, easier, streamlined, great with customer journey analytics. So I’m not trying to sell you on this today, but I’m just saying that if that’s the direction you want to go, then this is the bridge. This is that gate that’s going to, I don’t know, I’m the gatekeeper or the keymaster. Anyway, but that’s maybe the direction you want to go. I mean, does that make sense? Would you guys concur with my rambling? Except for you almost did reference Back to the Future for Ghostbusters, but you know. Oh, gosh, cool. Well, I know we’re running out of time. We’ll try to keep this to an hour. We’re going to answer one more question and then we’re going to end it off. But let’s put Carly’s up there here and does the web SDK capture any, there you go. Thank you. Move it up a little bit, if you would, Eric. Does SDK capture any out of the box data or events without building custom rules? Is everything going to have to be custom done or is there kind of a, you know, you’ve given anything out of the box? So I’ll take the first stab at this one. I shared a link that kind of walks you through like all the automatically covered fields that basically if you just simply have a single rule at your global page top that is triggering a single web SDK event, all those XDM fields will automatically get pulled in by default. But the fun caveat there is like, we’re talking like custom rules. And there’s some fun ways that the web SDK is kind of changed a little bit around how data is collected and how XDM data objects are defined. So it’s worth kind of digging into those. But the cool thing that I want to point out is in that link, that’s a list of all the automatically captured items that you won’t have to capture in a custom XDM data element. I feel like that’s like the more complete way to describe that. Yeah. Thanks. Yeah. Rudy or Jeff, do you guys want to add anything to that about, you know, automatically captured stuff? No, I think he summed it up nicely. Okay. Okay, cool. Great. Well, thank you. Thank you. Appreciate those questions. In our last minute or two, we’re just going to end this with our favorite feature here at the end. And that is… Unrelated cool tip. So, Rudy, I believe you have our unrelated cool tip today. And I’m really excited to hear this. And also a little scared. I think the cool level is very, very low. Okay. Unrelated tip. Unrelated tip. So I’ve had a bit of a brain fog this week. Getting over a little bug here. But one of the things that I thought of when I was, you know, racking my brain of what kind of cool tip we could show. I went back to when, you know, in the before times where it was traveling to a lot of different hotels. You know, one of the things I struggled with was trying to get the room dark enough so I could actually get to sleep because I like to sleep in the pitch black room. So, and I don’t have one of the lovely hotel hangers that they have, but almost every hotel has a wooden hanger that’s got the little funny fun clips on the bottom. So I have found that you could take the curtains in the hotel, take their hangers and close them up. And I’ve had to use as many as three hangers on one set of curtains before. But it does a good job of making the room dark enough when you can get some sleep. So especially for those New York hotels where Times Square just wants to come in the window. Exactly. Well, thank you, Rudy, for that for that cool tip. I love it. Just before we sign off here. Yeah. Is there a link, Eric? Can you throw that link that you had potentially back into the chat? Yeah, it’s weird. Like all of my links in YouTube. I don’t know. Yes, we can we can put this on experience like so I will I will put a link underneath this and you’ll be able to click over to it. And so if you want to come back later to this, then I will I’ll put that link down below in the comments and make sure that you guys can get the link and we’ll get whatever links we can. I think would be helpful, helpful there as well. So anyway, just want to say thank you to my my experts here. I’m excited to have these guys come back also in a month. So we’re going to talk, like you said, about real time CDP connections. Event forwarding in a month will go deeper into that. And just a super teaser for the next month. We’ll go more into some additional data collection topics as well. So we’ll have these guys over the next couple of months as well. Thank you to everybody who joined us today. Thank you for your time. We know it’s valuable and we hope that this was helpful. And please let us know if there’s anything you can put in the comments here, if you want anything that you’d like to see in experience league. It’s not there. But again, go to experience league dot Adobe dot com. And then hopefully you can find all the documentation, tutorials and everything else you’re looking for there. And other than that, thanks for coming. And we will see you next time, everybody. And appreciate you. We’ll talk to you next time. See you all.