Adobe Experience Platform Launch Demo

Transcript

Hello, everybody. Welcome to the session. This is the next session for Adobe Developers Live, Adobe Experience Platform Launch. We’re going to do a quick demo and we’ll get into a little bit of information for those folks looking to extend or customize the platform using Launch Extensions. My name is Jeff Chason. I’m a senior evangelist for Adobe Experience Platform and Experience Cloud. I have a few slides to go over, not too many, just a quick introduction to where Launch fits in to the overall Experience Cloud, how it works with Adobe Commerce or Magento and your stores, and then we’ll do a quick introduction to extension development.

So Adobe, as you know, Magento, Adobe Commerce, as you know, that is powered by Magento, is part of the overall objective and the overall goal of the Digital Experience Cloud to change the world through digital experiences. It’s not just the digital experience part of Adobe, but it also includes the Creative Cloud and the Document Cloud. You may have heard of a little application called Photoshop, InDesign, Premiere Pro. Those are the parts that are commonly thought of when we talk about Creative Cloud. Document Cloud, you may have heard of PDF before, but there are other things as well with Adobe Sign for electronic documents signing and workflow management with managing electronic documents, and of course the Experience Cloud. Experience Cloud is where Magento or Adobe Commerce fits into the overall sort of architecture of the technology stack for Adobe solutions. Experience Cloud is pretty robust. It’s pretty industrial strength. It powers a significant portion of the largest sites on the internet, handles kind of a mind-boggling number of transactions every day, and these numbers have been increasing very steadily over the last couple years. Of course, with last year and the acceleration of the digitization of many businesses that were on a gradual path, it’s condensed that down to a very short time frame, and so these transactions obviously are accelerating. The number of transactions that we handle are accelerating rapidly. Focusing on experience or the experience that the customer has when they come to your store, obviously they talk about is good for your business. They talk about performance and how increasing performance and the load time and decreasing the load time of your pages and decreasing the amount of time that a product first appears on a mobile device or on any device obviously increases conversion and improves your numbers. Focusing on the overall customer experience and managing that experience yields huge returns for the investment. There’s a lot to manage though that goes into that. Obviously, the traditional customer life cycle that you see on the left of a customer discovering a product category, exploring different options, and then buying and then engaging with a brand, it doesn’t really look like that anymore. It’s much more disjointed. It hasn’t really looked like that for a while. There’s a lot more that goes into it obviously with multiple devices and multiple channels and more brands than ever competing in various spaces for consumers attention.

And because of that, there’s a lot to manage. In order to manage a customer experience and make the technology transparent and give them a seamless experience across devices, you’re stitching together for some of our customers literally trillions of data points when you’re managing profiles at scale. You’re bridging on-premise solutions software that you run maybe in your own network behind a firewall versus together with SaaS software that you run. And you’re doing this across geographies, across regions, and for some of our larger customers all over the globe. It’s a lot. There’s a lot of moving parts and a lot of pieces to this. There are a lot of teams involved, a lot of specialties and practice areas. And coordinating all these things for a real successful customer experience management program overall across all of your digital properties. There are a lot of moving parts. Adobe’s products obviously can help you handle these challenges more efficiently, more effectively, and more profitably. Data and insights is something that we’re going to focus on a little bit today. How do you collect the correct data? How do you get insights from that data? And of course obviously content and commerce where your Magento store, your Adobe Commerce solution comes into play along with the other pillars of customer experience management that Adobe touches. Adobe Commerce fits into the overall experience cloud as part of our application stack. And you see here in the gray section of this so-called layer cake diagram, we have data and insights, we have content and commerce, and we have customer journey management in this particular sort of slice of the overall Adobe technology stack. And the applications you’ll see here in this gray area sit on top of our services, some of which are intelligence services and which in turn sit on top of the platform, which at a very basic level talk about data collection, the intelligence that you gather from that, and how you activate it across different devices and channels and profiles and segments. And we’re going to focus again Adobe Launch as a tag management system as a tool to help you be more efficient with your data collection and activation allows you to get to the value of your intelligence more quickly.

Specifically we’re going to be looking at these areas at a base level when we’re talking about Adobe Launch and where it fits into the overall overall structure. Launch is not just a tag management system. When you talk about Adobe Experience Platform Launch you’re talking about several components or pieces of the overall solution. We talk about we’re going to look at the Adobe Experience Platform Web SDK, which is the current and future direction for data collection for the digital experience products including Adobe Commerce, your Magento store, the Edge network, which allows you to send data up in a very efficient effective performant way. It’s currently one of the world’s largest real-time globally distributed networks for data collection and then Launch Server-side will give a sneak peek into what that looks like, which is now generally available to our customers. And it basically unlocks the power of Server-side data distribution and management. This is sort of a picture of the data flow at a very high level for modern data collection and again where Launch fits in. And these things over here on the left, the Web SDK, the Mobile SDK is where Launch helps you manage those technologies for your data collection. You see on the left-hand side here in the light blue where the data collection is two ways, meaning to illustrate that you send data from our Web SDK data collection library up to our Edge network for distribution both to Adobe and non-Adobe products. You also see this dotted line which leads directly from the client from the Web SDK out directly to your non-Adobe destinations. So you have the flexibility to send data to non-Adobe solution endpoints directly from the client or from our Edge in a server-to-server configuration.

So that’s it for the slides. Let’s jump into the product. First, for those that are not familiar with tag management, we’ll do just a real quick very basic level introduction. So this is a test website that I have set up. This is our Luma Yoga and Fitness retail brand selling various products, both clothing and gear for fitness enthusiasts. And if I look at the code of the page underneath this actual webpage and I see the source of the page, you’ll see this line of code here. You can see line 41 which is highlighted in blue. That is the JavaScript embed code or the link to the launch JavaScript library. The way to install launch on your website depending on your configuration, depending on which Adobe products you’re using or non-Adobe products you’re using, in this case in a Magento store I’ve simply added it to my main default store in the content section and I’ve added it in the HTML head section. This little includes for a script tag and that is a real easy and simple way to deploy the launch embed code to your site across all the pages. So this embed code links to a launch property which I’ll show you in a minute and it manages the data collection and distribution for this website.

Now obviously we don’t want to look at this when we’re managing tags and we’re going about our day to day and we’re trying to do things as fast as possible because we know that in today’s environment and today’s economy everybody is doing at least one or two or three jobs. We’re trying to move as quickly as we can and so looking at this is not efficient for most folks that are not developers. When you sign in to launch through the Experience Cloud login, this is the main screen that you’ll see in a company account and this is my example or demo company and I have several properties. You can see this list of links down here in the middle is a list of properties. Property and launch is simply just a way to collect your digital assets, your domains, your subdomains, your websites, your applications, etc. And also notice up here we have different types of properties. You can set up a client side property, a server side property, and in order to take advantage of launch server you can set up an edge configuration which we’ll talk about a little bit in a minute. But for now we’re going to deal with the client side data collection and data that we care about that’s relevant to visitors who hit our store and are looking at our products and hopefully shopping. So if I click into this property, this is set up just very simply as a quick demo property that does some basic data collection for demo purposes for today’s session. It’s a way to manage data collection in your site without having to engage a front-end development team to implement code or tracking based on specific events or specific visitor actions. Because those visitor actions are what we care about. Are visitors that are coming to our site finding what they need? Are they struggling when they run a search? Are they finding the products that they’re interested in? Which products are selling well and which products aren’t selling so well? Which customers arrived from the campaigns that we’re spending money on and investing in across different social platforms and other paid or earned media? And so the answers to these questions can be obtained much more efficiently and effectively when you’re collecting your data through a tag management system like launch. This interface, this property manages just this one website but a customer could if you chose to, if you had multiple stores, multiple properties, multiple domains, you could manage them together in one launch property if you wanted to. It’s a very flexible system and you can change your mind at any time if you set it up so that your websites are in separate properties. You can later on combine them or later on split them out as you wish. The main navigation over here on the left hand side of the screen, there are just a few main areas that folks that are working in launch to manage their data collection and distribution where they spend most of their time. The first thing I’d like to talk about is data elements and a data element is basically a variable or a mapping, it’s a pointer if you will, that points to a specific value in your web page. And so for example if I look at this page there might be information about this particular image that you see with this woman sort of sitting and meditating and she’s obviously modeling a top and some pants that we have for sale and so maybe there’s some metadata associated with that image. For example this image shows a woman and on our men’s wear page we might show a male model, we might show just a picture of gear, we might test which image is more effective for a given segment or for a given product category. And so the way we collect that data typically is that there’s usually a data layer and in this case there is a data layer with a storefront context, it gives you the store URL, it gives you the website ID, the environment ID, etc. In this case it gives you page information, a default page type, and an action of a page view and there are various pieces of metadata that we can embed in our data layer.

And so the data elements are a way to map from launch to those variables or those values that exist in our page when a visitor is on your site doing a particular thing. In this case here is a page name data element and it’s already been set up for us and we see that the page name is furnished by the core extension and we’ll talk about extensions in a minute. It has a type of JavaScript variable but there’s a wide variety of different source data types that we can use just with this drop down to point to different values whether it’s a cookie value, a custom code value, information about the page like the title of every page, query string parameters, etc. And so in this case we’re pointing to a JavaScript variable and that variable is called digdata or digitaldata.page.name and so somewhere on our site is a data layer, an object called digdata, and it has a page attribute with a name value. So for marketers and folks that are not technical, not developers, they don’t have to worry about any of this dot stuff or this name stuff and they don’t have to look under the hood at the code. All they need to do is to reference a data element called page name when they need it. So it’s a great way to simplify data collection for folks that are less technical or non-technical users. Then you can reference those data elements elsewhere in our system, specifically in the rules which is where most folks spend most of their time. Now we saw a minute ago that that data element was furnished by an extension to the system. So what’s an extension? If I click on the extensions we see there are three here on this screen. We see that we’re looking at the installed tab up here if you can see above the search box. And so these are the three extensions we have installed in our launch property. We see the Adobe Experience Platform web SDK, the core extension, and a Facebook extension. Now the core extension is pretty simple to understand. All of the tag management functionality that you would expect from a tag management system is supplied to launch by the core extension. And that may seem weird that we have an extension that represents the core functionality or the basic functionality of our product. But it makes sense when you think that launch is entirely API driven. And so everything you see me doing in the user interface on the screen during this session is actually an API call under the hood in the code. So our engineering team as they say we like to eat our own dog food or eat our own cooking if you will. So the tag management functionality of launch itself is built as an extension in the system. And if there’s anything that happens on the screen or a workflow that you don’t particularly, doesn’t particularly match your way of working or for whatever reason you don’t like it, you can change it by accessing our API and using your own little interface or your own programmatic interaction with launch. That also means that there are tremendous opportunities to automate a lot of your interactions with our system. The web SDK extension is the current way that Adobe Solutions receive data from our Edge Experience, Edge Network. And we’ll see what that looks like in a demo in just a minute. The Facebook pixel obviously an extension that we want to use to send data to Facebook based on certain campaigns that we’re running.

There’s also a catalog of other extensions from Adobe and non-Adobe products. It’s a pretty wide variety of additional functionality that’s added to launch by way of these extensions. And so instead of dealing with custom code and curly braces and semi-colons and getting a developer to help you, we can simply click on one of these buttons, install the extension, and take advantage of the functionality that those extensions provide to our users. The rules is the other major area of the system that people generally will spend most of their time when they’re working day-to-day in launch because they’re adjusting their data collection as their campaign results come in and as their tracking needs change and as their visitors and their sites change. Of course, we all need to adjust what we’re doing online and that’s one of the reasons Tag Management Systems became a product category in the first place because we needed a way to make it easier and more efficient to alter the data we’re collecting and the marketing campaigns that we’re running. We need to adjust as we go as the results come in. And so here I have three rules set up as it’s quick test. We have one on the load of every page it sends an experience event. On the hover of a button or some other element it sends an event. And up here we have a test of the Facebook pixel when we look at the women’s gear page. And so what does that really mean? Well let’s look at the onload. So for folks that don’t know onload is just an event that the browser says okay the page is fully loaded and everything that the page needs to load for the visitor to interact with that page that experience is now ready. All the images, all the JavaScript, everything’s been processed and everything’s ready. And so when that happens and a visitor is on our site and they’re looking at our products in our store, Launch is looking for certain events. Again, Launch is hooked into our site through that embed code that I showed you at the beginning. And so when a particular event occurs there may be some conditions attached to that but if those conditions pass then we want to take an action. We want to do something. And typically that means we want to collect some data or send some data to either Adobe or some non-Adobe endpoint like Facebook for example. And in this role what we’re doing is when the window loads, so let’s open up this event, we see that there’s an extension that we choose from. We could choose events from the Web SDK but in this case we’re working with the core extension. And what we’re doing is we’re looking for an event, whoops sorry, let me get rid of those changes and come back to our event. What we’re looking for is the window loaded event which is basically any time a page loads on our website. That’s what we want. And so that’s the event that will trigger this rule. So whenever a page loads on our website this rule will be triggered. And since we have no conditions this rule will be triggered on every page of our site. We could add a condition that says only in a certain site section or only within a certain time period or in response to some certain query string parameter on our pages or a variety of different ways to set conditions for our rules. And you can make them as broad or as restrictive as you like.

Excuse me.

And then finally after the event occurs and the conditions pass we have an action that the rule takes. And in this case what we’re doing is sending an experience event. So what’s an experience event? Well an experience event is an action, a type of action, we have a send event action that’s supplied to launch by this AEP web SDK. And again that’s the extension that allows us to send collect data and send it to Adobe’s Experience Edge network in the format that our network expects. And that format is called XDM. XDM data uses a recipe or a schema which is our extensible data model. XDM is an open source format for data that simply tells our products what to expect and where and what it’s going to look like. So for example if our page name is a string of characters then our XDM data will tell the Edge that our page name data point or if you will our data property is a string. It may also be a boolean value true or false. It could be a variety of other data types. It’s a very flexible and extensible system and it’s also open source and we do accept contributions from the community of course. And so what we’re doing is we’re sending an event and we’re referencing that data element, a data element that we built earlier. And if I click here this little icon you see a list of data elements that we can select from. We’ve already selected the XDM data element. So let’s back out of here and see what that gives us. If I go to the data element and I go to XDM we see a variety of data that we could send to our Edge network and in this case we’re simply sending a subset of web data. We’re sending this on hover string which we’ve created. It’s a custom XDM property and we’ve created it because we need it for this demo. We also have the web page name and the site section. Now we could obviously include a wide variety of other data but just to keep it simple we are just selecting a small subset of the data. And so when we reference this data element this is the information that will go to our Edge network. So let me cancel out of this. So our rules execute and they reference the data elements and those data elements are generally supplied by one of the extensions. Now this library that we showed you on the page has a workflow in order to get that library, make those changes and push those library out to the different environments that we have. And so there is a publishing flow where we have any number of development environments. So if you have dev, test, uat, dev1, dev2, qa, whatever it is you can have as many of those as you like. And those development libraries are basically projects that group together different work that different teams are doing and it goes into a library and that library will be migrated up to submitted for approval and then approved status generally in a staging environment and then out published to production. And you can have various libraries in various states depending on which teams are working and those are mapped to your different environments. And you can set this up to match the workflow that you currently have. So if you have a very simple workflow with dev and stage and prod, then you can do that. If you have 27 different development environments, you can do that too. It’s pretty flexible. So if I go back to my web page and I take a look at I’ve got the browser console open over here on the right and the site over here on the left. And so let’s go over to the network tab and I’m going to filter for interact, which is the call that is made, the destination for a call that’s made when our web SDK extension is loaded in launch and it executes or rule executes and calls that library to send David to the edge. So if you remember, we’re going to send that web page name and some other information. So I’m going to reload this page, clear the cache and reload. And then if we look over here on the right in our browser console, if I hover over this and go down to the payload and I open up all the events and I go down in here, I’m not going to go through everything, but if we look at the XDM, here’s that web. And this looks just like the information that we said before. We currently have this a tag value on hover of off. And if you remember in here, we had a data element that was called button hover and it points to this JavaScript variable, this dig data page button hover. And so if I’m in the console and I go type in the name of that value, see that it’s an object that exists on the page with some properties. We have a button hover value and we have a name value. And the name of this page obviously is the home page and button hover is called button hover. And if we go down page and button hover is currently off, and that’s what was sent just a minute ago to our edge network when we saw this event. Now we also have a rule that if we hover over a specific button, that that will change to on. And so if I hover over here, if you look here in the name section of our console right here, you’ll see another call in a second when I hover over this button. There’s our second call that shows the hover. And if I come down here and I expand that XDM object that I showed you just a minute ago, and now we have the button hover on. And so now when I hover over, that’s what my rule does. It simply changes off to on and it sends that data up to the experience edge. Now we also have a Facebook rule that we have set up to show you a non Adobe endpoint. And if I go back to our rules, and I go back to this Facebook women’s gear rule, anytime they page loads, and the path is equal to the women’s section, we are going to send a Facebook pixel because we have a campaign and that represents to us that represents a lead every time someone looks at the women’s section. So if I come back to my website, and I put a filter in here for Facebook, and I clear this out, and I go to the women’s section, now we see this event, it loads the Facebook event JavaScript, it connects to Facebook for the signal, and it sends the data that we wanted it to send here in the pixel request or the execution of that code. And it sends our event with the type of lead. And this is all the query string parameters that we sent. And if you see down here, highlighted in the blue, the event type is a lead event type. And that was all done in launch in our rule. If you see here, if I click on this action, the Facebook pixel extension supplies an action type of send lead event, which we can send to Facebook.

And we have a value of $10. And we value this lead at $10 of US dollars. And obviously you can put whatever’s appropriate there. You can also reference other data elements if you’re sending a value and a currency to Facebook for this particular event.

And that’s sort of an overall demo of the data collection flow of how we set up rules and data elements and extensions in launch. Now what we’ve seen here with these extensions is that extension developers like Facebook or Adobe or other vendors that we see here in the catalog, they can supply different pieces of a rule or what we call rule components. So if I go into a rule and I go to this Facebook rule, which we just saw a fire to send the lead event, the event that we’re doing, that we’re taking advantage of to trigger this rule is a page load event. And that page load event is furnished to us by the core extension. Now everything you see here over in the white rectangle over here on the right side of the screen where it says no configuration necessary, that’s the extension view. So that is the user interface that the extension developer created for this particular action. So this event type of window loaded for the core extension, it doesn’t require any input from the user. It basically just says, okay, when the window loaded event happens, then we’re going to trigger this event. And there’s no configuration required.

But if I change the view and I get rid of this change and I go back to my extensions and I click on this Facebook pixel extension, I’m in the configuration screen to configure this extension. So any information that the extension needs to operate like a customer ID or an API key, or in this case, the Facebook pixel ID, and of course we’re using a fake one for our demonstration session here. I’ve just used a random number, but the pixel ID is input that the user of launch, the person who’s running launch and installing this extension, we have to input this into the extension and save it for use by the code. And so everything you see here over in this white rectangle to the right, where this basically very simple web form is with a label and an input field, it was created by the developer of the Facebook pixel. Over here in the gray on the left and along the top is launch. So when someone is building an extension to add functionality to launch, what they have the opportunity to do is create any user interface components that they need to accept any user data that their extension needs to function, like a pixel ID or an API key or other data. And so in this configuration screen, we have this view. And now the other parts of an extension that are relevant to an extension developer, not only is there the view, but when we’re in a rule and we’re taking an action, in this case, we’re sending a lead event, this is the action view. And so there is also a view created by the extension developer to allow anyone who wants to send a lead event to Facebook, that’s the action that we’re taking, allow the users to add a value and a currency for this action. And so these input fields, this very simple web form, this is the extension view for this action, which is the lead event. Now the other actions may or may not have views that they require. So that’s a little bit of an introduction to the extension views. Now what about the other part of an extension, which is how does the extension actually work? Well, when we’re sending an action, when we’re executing an action, excuse me, like a lead event, which we saw here in the console and we sent this lead event and we gave it a value of $10 in USD, launch had to know what do we send to Facebook when we execute this lead event and we send that data to Facebook. And so that happens in a library module. And the library module is what executes on our website when the visitor takes the action that we care about. And that library module is part of the code that gets emitted to the browser through this embed code. So we have the launch embed code, launch itself is installed on this website like we mentioned at the beginning through this line of code and also through this line of code, all of our actions and rules and anything else that we need is allowed to operate on this website when the visitor is taking the action that we care about. And so we see that a library module is what actually takes the action on the website at the time, which is send the lead event to Facebook and give it a value and a currency and tell Facebook that it’s actually a lead event. That happens through the library module. And the view is the other main part of an extension that a developer can create, which gives us the opportunity to accept input from the users of launch. So leaving the launch UI here in the few minutes we have left, we’ll talk a little bit about what happens when we build an extension. So the first thing we generally use is something called a scaffold tool. And this is for folks who have worked with other frameworks and other frontend development projects, typically there’s a generator, if you will, that you can use on the command line. In this case, I’m in visual studio code. And if you see here down at the bottom, I have a terminal open and up at the top. I don’t have any files open yet, but we’re going to go ahead and create some real quick. So I’m going to make a directory called, let’s see what we call it, dev live. And I’m going to, let’s see, make, yeah, and I’m going to CD into dev live. And now we’re in there. And now that I’m in my development directory to start my project, I’m going to run this scaffolding tool, which gives me an opportunity to interact with the first developer toolkit that our engineers have offered to folks to make it easier to build these extensions. And so if I run NPX at Adobe reactor scaffold, this will run the scaffold tool for my system. I don’t have to do the whole NPM install thing and set up dependencies, et cetera. NPX is the package runner from NPM that allows me to just run it right from the command line. If you’re not familiar, this is what it does. And so what this does is set up a question and answer to establish the parameters and the functionality of my site. Pretty simple things. So what’s the display name going to be? Let’s just make it dev live for example. And you see here now we have a choice of platforms. So extensions can be created for the web, which is what I was just demoing for you on the screen during our session. We also have mobile platform that you can choose if you’re building an extension to operate on mobile devices. And we also have edge, which is launch server, launch server side solutions, which we’ll look at just in the closing minutes, we’ll give a sneak peek to that. But for this, let’s keep it simple and we’ll go with a web extension version. We’re just going to stick with one. And then we give a short description. So this is a demo. And who is the author? Me. And now we have a variety. Let’s make this a little bit bigger. So make sure we can see it up from the bottom. So now it asks, what would you like to do? What would you like really, what would you like to create for this extension? And this is the, if you’ll look at this list, you’ll notice that some of these things should be familiar from our demo session that we just finished. So you can set up an extension configuration view where you can input things like the Facebook pixel ID that we saw. You can add an event type. So instead of window loaded, you can have, or button hover, you can have your own event that you would like to make available to users of launch to trigger a rule to fire. You can add a condition, you can add an action type. And again, the condition can be something like as simple as path name or some local storage object equals some value, or it could be as simple as complicated as needed for your extension to operate. An action type is generally like sending the data or collecting the data or firing a beacon, if you will. And when we saw that Facebook lead event fire, that was the action that we looked at. You can also create your own data element types. And then you have a variety of other options. So I’m just going to add an extension configuration view. And I’m going to add an action type. And we’ll name this action demo action. And does it need a view? Let’s say yes. And I’m going to say that I’m done. And the scaffolding is now complete. And so let’s open that up in VS code.

Take a look at what that looks like. And we have our terminal. And here we see up here in the file viewer the files that were just created for us by this scaffolding tool. And so you see a variety of HTML files and you see one JavaScript file and a JSON file. So pretty simple setup. The extension JSON is what we call the extension manifest. It’s a JSON structure of properties that explain basically the what and the where of your extension. So display name and platform and version, description, author, et cetera. But then we have some things that are necessary for the extension to function. The base path of your view and some other metadata about the actual extension itself. You can specify specific properties according to a schema standard.

And then we have a similar set of actions. And so any views or events or data elements or other components of your extension that you create either manually or with the scaffolding tool, you’ll have a section for those here in the extension JSON. And this is what tells our system what to expect from your extension. The configuration view, which we see here, is a simple HTML page. As you might expect, it’s pretty basic. We saw that other extension configuration view for the Facebook pixel, which was this. And all we had was a simple web form that looked for the pixel ID where we had the 123456 value. And so that’s what this page here is for. It allows you to set up a simple web form to accept that input. And it gives you some functions built in to allow you to both save and access that value while a launch user is working with your extension. But also while the visitor is on the site and your action, which in this case, in the Facebook case, is the send lead event action. And in our case is this demo action. And so when that action is executed, we will need access to that pixel ID because part of the beacon that goes to Facebook requires that the pixel ID be sent. And so your action has access to this data. And so these functions allow you to save and access both set and get and manipulate, of course, any values that your extension needs to operate. And so this is just the basic scaffolding of an extension. All of the documentation that we have in the user documentation, there’s a section for developers specifically for extension development, goes into each one of these things in great detail. We have our action, which is simply a module that gets exported that runtime by the launch library and allows it to operate. So this is where in the Facebook pixel extension, this is where that lead event would be triggered and where it would operate with any settings that were set. And you see here, this settings object is passed into the function and exported by this library module. And so that settings parameter obviously would have the access to the pixel ID and any other data that you need from your other views.

So that’s a little bit of a peek into what happens with an extension when you’re developing. The other utility that just to quickly highlight is our sandbox. So if I NPX at Adobe slash reactor sandbox, that will run the sandbox utility from the same project folder and will start a local development instance that I can use to test and troubleshoot and debug and develop my extension locally before I upload it into the actual launch system for use on the site. And so the sandbox, what it does is allows you to do your testing. We have a view sandbox and a library sandbox. So you can test either your views or your library. And so in this case, we have an extension configuration view and I believe we had an action view, but we didn’t set up a form yet in our extension project. And so we don’t have any values here to test, but just wanted to highlight this sandbox utility as a way to test your extension locally before you upload it to our system.

So for extension development, again, for the details, check out our documentation on experience league and in the launch user documentation, there’s a section for developers with access and links to all of this tooling and detailed information, reference docs about all of the different components of a rule that we talked about, the actions, the events, the conditions, data elements, and the other parts of the system. And also links to the sandbox and all the other packages on NPM that are available for your testing.

Now, just with a few minutes we have left, I just real quick wanted to the server side information. If we jump over to the server side of things, once we send that XDM data from the web SDK in launch, once we send that to our experience edge, we can manipulate that data and send it to other endpoints. And if you remember our slide where we talked about data distribution, down here in the gray at the bottom, we talked about sending from our edge network, not only do we send from the client to non Adobe endpoints, but we can send from the edge network to non Adobe endpoints. And that’s where we set things up in the launch server side extension. And so we can send information in this case, we’re sending it to a web hook. In another rule, we have an example of enriching the data and sending it to a web hook. And by enriching the data, what we’re doing is calling a backend system like a CRM system, or if you use a lookup vendor like Dun & Bradstreet or Demandbase, and you’re looking up information about the visitor who is coming to your store and looking at products, you can enrich that data and then send it, for example, to a backend CRM system, or you can send it to Snapchat or Facebook or any vendor of your choice. And so I know we’re almost at the top of the hour. And so I just wanted to say thank you for attending this session. Hope you took away at least a brief introduction of what launch client side and server side have to offer, a little bit about extension development. And we would love for you to get involved in our community. Also in the docs, there’s information about a Slack community that we have for developers. It’s a community resource, not an Adobe resource, but still very valuable. There’s about a thousand extension developers, launch developers who are active in there. So we welcome you to join there as well. And there’s a discussion forum linked in our session description. So if you’d like to continue the conversation or you have follow-up questions from anything we discussed today or you want more information, feel free to leave a comment on that page. Thanks very much. And I hope you found the session valuable. Appreciate your time.