Launch Server Side is Great, but What if it Could…

Transcript

Good morning, afternoon, evening, wherever you happen to be. Hope you’re having a good developers live conference. And welcome to launch server side is great, but what if it could do some other stuff? Today, we’re going to try to talk a little bit about the server side launch environment, how extensions are working there, if you’re unfamiliar with them, a little bit about how you go about developing extension and server side. And it’s kind of give you an overview. It’s hard to get super detailed in 30 minutes. So we’re going to try and also give you some good references to get to the parts that you might need. My name is Jim Bradley. I am a digital marketing tech architect at Ebalitics. Been involved with Adobe tools now for probably 10 years or so after a career in IT. And been involved closely with the launch process development team and everything since before it was actually a product. My co-compadre Brandon Martinez is going to be manning the chat and answering questions that you might ask as it comes up. Brandon is a senior manager on our analytics development team. And besides taking really good care of clients, he has also kind of been the main developer behind the various launch extensions that we released out into the catalog. Again, I’m going to let Brandon answer the questions because he’s the smart guy and I’m just the one with the radio voice. I said we both work for Ebalitics. We are a prime image everything to do with analytics and data consulting company. We’re based out of Kansas City. We’ve been around for 16 years now I guess, 50 some out of us now. And we just help brands compete with data and use it in ways to make a positive difference. So enough of that. I do want to talk though a little bit just to kind of set it up. We have put out three launch extensions into the catalog. First two are on the client side. We have what we call the channel source identifier. And what the CSI does is helps you kind of identify the marketing channel while you’re still there in the browser. Adobe Analytics has marketing channel rules, but those all happen on the server side. If you need to make a decision about it in the browser while you’re doing things, that’s where the CSI comes in. Our most popular one is the data element assistant. It’s been installed in several hundred properties and basically gives you some custom data element types. It provides some capability that would be nice to have in launch so you don’t have to actually write custom code. And our newest one, which we released not too long ago, is the runs on the server side. And it’s the cloud connector for Google Analytics. And it’s a server side extension that will send data to Google Analytics using their measurement protocol API. And we’re proud to say that that was the first third party extension that was out there on the server side. So what are we going to talk about today? I’m going to go kind of quickly over these first ones because I’m thinking if you’re here, maybe you know some of this. We’re going to talk a little bit about server side launch. We’re going to talk about extensions, how you would use those in the server side. And then really what I want to get into is like, why would you want to do this? Why would you want to create an extension? What are some of the opportunities there? Kind of go over the basic process of building one. I’m not going to write code live today, again, because I don’t think we have enough time to do it well. And then have a little bit of a product announcement to drop in at the end of the presentation. Again, as you go along, if you have questions, type them in there. Brandon will keep an eye on those. Answer them as best he can. And so what is server side launch? I think first we should get out. I think the official name for it now is Adobe Experience Platform Event Forwarding. And the UI is called Data Collection. But I’m not going to do that right now. I’m still going to call it server side. I figure if I have clients that still call Adobe Analytics Omniture, I can call this server side for just a little bit longer. So why would you want to send events and data and tags from the server instead of just like in regular client side launch like we’ve had? A couple of main reasons are that it decreases the weight of your page and your app because it takes all these things instead of firing them all from the browser and taking up bandwidth there and everything. It moves it to Adobe’s AEP Edge network. And these rules can take and transform data and send them to new destinations even without going around and touching the client. And a couple of big things you want to do, you can improve performance. And since it’s all being done in one place, you can get better data governance. So when you combine server side with the AEP web and mobile SDKs, that gives you the ability to make a single call from your page or your app containing a payload of well-structured data. And you can send that data to multiple destinations server side. Again, could reduce the amount of time it takes for your page to load. You get better transparency and control over what data type is being sent where because it’s all happening from one place. And then again, for those of us who have done client side tag management for years, being able to create a rule to send previously tracked data to a new definition without having to do anything that’s on the server is a big plus, especially if it’s on the app. So you don’t want to have to resubmit those. So there are some differences between client. If you haven’t messed with the server side, you haven’t used it yet. You have to use the web or mobile SDK, which a lot of people refer to as alloy. You can also use it to launch extensions and there’s alloy.js file you can use. And that sends the data up to the edge. You have to define XDM schemas, which is basically, again, a structured way of defining your data layer. XDM is a multi-hour session all itself. So I’m not going to dive into that. And then what are now called data streams, which kind of says, when I send this data up there, where does it go? And in the case of server side launch, it’s like which launch property when this data comes do I want it to go to? There are some kind of technical differences. A couple of key ones I think are interesting are that the data element tokenization has changed. Instead of the percent signs on either side of the data element name like we had in DTM and launch, now we’ve gone to the double curly braces, which I think is a big step in the right direction. And then if you do write custom JavaScript code to execute stuff, then while on the client it was ES5, it is ES6 JavaScript up on the server. Probably the biggest difference though is that server side, unlike the client, is a charged cost and it’s based on volume. While on the client, if you have an Adobe solution, you already have it. But again, I think the capabilities it provides means that the cost makes a whole lot of sense. So extensions are interesting. So you have these reusable components that extend launches capabilities. And when Adobe first made this out there, their thinking was instead of Adobe writing how to talk to all these different back ends and how to integrate all these different stuff, they’re going to open the architecture up and let the community build these pieces. So that if an ad company or a social media place has a, they want people to use their tool, they can write their own extension. And extensions can send data to external destinations. You can load to a media tag or things like that. Another analytics platform even. You can load and manage tools on the website, like say a session recorder or some kind of privacy bits. And you can also just give utilities to provide additional capabilities to make the implementation easier, more efficient. These extensions are developed by Adobe, by tool vendors, and by third parties like us at analytics. And you can either release these into the public catalog for everybody to see or you can keep them private to your particular organization. If it’s something only you use or it’s something you just want to have more, you don’t want to give away, maybe it’s one of your competitors. The launch extension ecosystem has been growing. The slide says it’s more than 100 client side extensions. I counted it Friday morning, I think we’re up to 120. So there’s a lot of capabilities you can add into. Now on the server side, it’s a much newer offering. So the extension ecosystem is not as developed. When I counted this morning, there were five. But privacy changes in the browsers have been made collecting your own data even more important. And it’s been around all that third party vendors are starting to develop data collection methods that can be implemented by an API from a server. They don’t require the headers and the cookies and things that we’ve traditionally had coming from the browser. And so that’s really opening up options and capabilities here on the server. And in my view, that means there’s a lot of opportunity for vendors, for agencies and for brands to add value to the launch process, to use the things that you know best. So using a server side extension, you will see that this probably looks kind of familiar to you in that it looks a whole lot like the client side. You go into the catalog, you install an extension, you know, I’m showing the one here, our cloud connector for Google Analytics. Once you do it, the configuration screen pops up and you enter some information in. You can see here, we created the tracking ID from a data element, because I wanted to be able to send it to a different account, whether I was in a pre-production or a production version of my library. So we used the data element, you see the little curly braces there. There’s more to it. Let’s just give you kind of the overview. And then again, like on the client, you’re gonna create a rule, and you’re going to then add an action in a rule. And in this case here, I’m gonna populate out the various variables that I need to send, that I wanna send to Adobe. Some of them are hard coded, some of them are data elements. And again, the UI and the general concepts are going to be extremely familiar to people who have experience doing client side launch properties. So Adobe has kept it very consistent and there are some differences, but if you know your way around client, you’ll pick up the server pretty quickly. A little quick word about credentials. I mean, a lot of APIs require some sort of authentication, to be able to use them, because you don’t want just anybody pumping data into your backend systems. I know it’s been the backlog for a while and nothing has been officially released yet, but Adobe is said to be developing a credential store for launch. The details and release dates are not available, but I’ve been told, hopefully that information will be out soon. And I think that on top of some of these other things will really make it easier for people like you and me to create these extensions to run on the server side. So this is all well and good, Jim, but why would I want to create an extension? In my view, like I said earlier, it is a great opportunity to add value. A vendor, if you’re a vendor, you can make it easier to adopt your products. If you’ve got a new API for collecting data, or you’ve got a new service or a new tool, you can provide an extension for server side launch and really make it easier for your customers to adopt your product. Agencies, you can either build custom solutions for your clients, or you can release utilities into the catalog, just to increase your name recognition, or just to in general, try and make the world a slightly better place. And finally, if you’re for the brand, you can build custom integrations to your own internal systems that’ll reduce the time it takes until that data is available. So instead of waiting for the overnight analytics, the data feed to come in and then ingest all that in, you can actually send the data in near real time as it happens directly into your system, if your architecture supports it. And you can keep that your own, you don’t have to make it out there and make it available to the rest of the world. So let’s do a for instance, right? Okay, you work for a brand and you want to send certain web events directly to your next best action system. And your data science people have gone through and worked on stuff, and found out that when a customer searches on certain terms that puts them at risk of leaving and the NBA system wants to know about it, right? So you’re sitting here on the website, and the visitor navigates to the help page and they enter cancel service in the search bar. Well, then you’re gonna make a web SDK call, it’s gonna send the data up to the edge to launch, nicely formatted in XDM. And then your launch rule is gonna trigger on this event that happened. You’ll add a condition that’ll look for the search text that you sent up and see if it matches any of these certain key terms that you’ve identified as something you want to know about. Then once the rule triggers, it’s gonna like call the action that is in your private extension that you’ve written. It’s pulling the customer information and search terms and other relevant data out of that event payload, transforming it, building the API request, and then sending the call to your next best action system. That call happens and then the NBA system is gonna pick it up, receive that information, add it to the customer’s record, recalculate what the next action to take is, whether it’s to send them an email, we put them up an offer, route them a specific way if they call into the call center or whatever. And again, this is happening more or less in real time, right? And it’s something you can build that is unique and custom to your environment and the way you do things. So let’s talk a little bit about the process of building an extension. It’s Adobe, again, there’s a lot to it, and I’m not gonna, I can’t build you one here in the time we have left, but Adobe has a number of really good resources on extension development. And the link here that’s in this deck is a really good place to start. It’ll kind of talk you through, what you need to do, what the different steps are, things to watch out for. And there’s other things floating around the web. But like everything else, it’s a good idea to think through, what do you want your extension to do? And on the server side, your extension can include the following components. You can do conditions, my rule should fire if or something happens or not, you can work that in there. You can create a data element, it’s gonna return a specific data or maybe manipulate data in a specific way that you need it. And then finally actions, which are probably the big one, cause that’s when you’re actually going to take that data that’s come in, transformed, worked on, and you’re going to send it to some other place or do something interesting with it, or even prepare it for the next step in the process. For each component that you’ve defined that you want to put into your extension, you will create a library module. And this is the code that does the work. This is the one that actually makes the calls, does the hard yards, does all that stuff. And then a view module, which is the UI where you can configure your component. Move on. So the basic steps to get this thing up and running so you can have it in your environment are pretty straightforward. There is a tool called reactor scaffold. You can pull that down. It’s linked in that document that I talked about earlier. And this tool provides, it’s a very simple question and answer interface to create the basic structure of your extension package. It’s going to ask, what do you want to call this thing? Who’s the author? What do you want to create conditions? If so, what do you want to call them? Same with data elements, same with actions. It’ll build out all of your basic JSON files. It’ll get everything set up. It’ll build out the stubs for all the other files that you need and create the package for you. And trust me, that is way better than trying to do it with just a blank empty text editor to get started. Once you have the scaffold has created that basic structure, then you’re going to go in and develop your extension. There’s a specific file, the configuration.html. And this is that first configuration screen that comes up. If you need information for, just generally get the extension to use. If you don’t need to, you can just basically say, there’s nothing here or like what we did with the data element assistant, is that’s where we actually put our help information. Like how to use it, what does this tool do, and how does it work? So again, with this HTML and any of the other HTMLs in launch, you have the ability to put in there whatever you need. They also create, there are also separate HTML files for each condition, data element or action that you set up while you’re running the scaffold tool. And that is where you’ll go in and do the configurations for those things. What I want, like on the one I showed earlier, mapping the different variables into the different parameters that are gonna go in that call to Google Analytics. When you’re writing the HTML, you can use kind of pretty much anything you want to. You can do just pure basic HTML, you can do React, you can do whatever. But the major advice I’ve always heard and been told is that try and make it fit in and look like the rest of the data collection UI so that it makes sense to somebody when they’re going to put it in the system and use it. Once you’ve kind of got your pieces written and everything, then you can test your extension by running the reactor sandbox. This is a really nice tool that’ll run. You don’t have to deploy it anyplace like that. It will bring up and allow you to test out your UI and make sure that it’s kind of working the way you think it is, and it’s a much faster, more iterative way to go through those pieces. Once you’ve kind of gone through that and I’m ready to actually try it out in a real property, use the reactor packager to package up your extension into a big zip file, and then you upload it with the reactor uploader, and that will put it into your own launch environment where you can include it into a property and test it. Some other considerations, just like on the client, you will need to create a property on the server side that is enabled for extension development. And if you’ve noticed this, maybe even on the client while you’ve been building something, but when you create a new property, if you open up the advanced options, there’s a checkbox that says you can configure this for extension development. And once you’ve done that, you can undo it, but you need to have one of those in your space so that you can upload it. And then if you’re going to release your extension into the public where everybody can work it and make it use, you need to create an exchange page that’s loaded up at Adobe Exchange and it describes your extension. It can be screenshots, you can have kind of like a beauty page that kind of talks what it is, how it ties into the rest of stuff that you do in your brand and your other offerings. This is where you can put in links to your documentation, to more detailed stuff on your website. Moving on down, you can even have ways people get in touch with you and everything. So this actually has to be in and kind of approved so you can get the final link before you can do the final build on your extension. And that’ll give you that little learn more length that you see on all the extensions and it takes you to this particular piece of information. So let’s see how we’re doing on time. We’re doing pretty good. And I did tease a little bit earlier at a product announcement so I do want to talk about that. Then we can kind of look and see what questions have come in. I mentioned earlier that we had the data element assistant and we’re getting ready to, we’re preparing a new release for that tool. Last year, there’ve been some requests that people wanted a way to generate like a unique user ID. So we added up a new data element type, creates UUIDs. And then we’ve had some requests come in this year and it really ties into what we’re talking about today. So we’re going to add a new data element type that will provide a SHA-256 hash of a value that you provided. We’re going to initially release this in the existing extension that will be on the client. And we’re kind of, I was hoping to have it, we’d have it done before this, but you got to do the paying client work first. And so we’re hoping to have that out probably like around the first week of November. It’ll be a new data element type. You can feed one in and you’ll get a hash value. What ties into this particular talk today is that we will be following up by releasing that extension on the server side as well. So as you begin to implement these various, the new kind of conversion APIs that vendors are starting to make available out there, you know, they’re going to, they ask for things like email, they ask for, you know, maybe phone numbers, names, other information like that, but it all needs to be hashed. And you can’t necessarily count on it coming hashed from the client side when it comes up into the server. So being able to be able to do this up there on the server, I think will be a big help that will, you know, make it easier for people to implement and get a lot of value out of this and provide value to your brands and to your customers. So don’t know for sure on that one, but I would really, really like to see that we get that done before the end of the year. So keep your fingers crossed. For, I want to thank you for your time today. I hope this has been interesting, or at least somewhat informative. Watch for extension announcements, especially on those two DEA updates. And we have one more that I would really like to tease, but we still got some legal I’s to dot and T’s to cross right and talk about it, but both on our website, devolix.com. And we will also push it out. Lots of stuff like LinkedIn and our other social. You can send questions and comments to us, adobe at evolytics.com. They’ve got several people to watch that account. We’ll answer. And I know you can definitely message me, maybe even Brandon also over on Measure. And that is what, you know, we’d love to help. You know, part of the fun part about launch is the great community. And, you know, we definitely like being a part of that. So Brandon, I can’t see the chat while I’m presenting. So I don’t know if there’s anything interesting up there that we want to talk about, or if everybody’s gotten bored and left. So we got about three minutes left. I think we just had one question about the Facebook pixel, but it sounds like that might have been answered. Okay. Other than that, I don’t think anyone else has any other questions. All right. Well, thanks, Brandon. I appreciate that. And everybody, again, thank you. I’ll give you three minutes left. I mean, back in your session time today. Again, appreciate your time and your attention and enjoy the rest of the developers conference.