Data Collection for digital experiences - Client Performance and the power of server-side integrations

Transcript

Thank you all for joining this session, Adobe Experience Platform Collection. I know there’s a lot of sessions to choose from and me and the team are thankful that you’ve chosen to carve out some time with us today. My name is Jon Verai. I’m a product manager on the AEP collection team. And I’d like to start our time together by going through a few slides that talk about the four trends that are really changing our world as technologists, and then how the old school architecture that many of our joint customers have landed on is really vulnerable to these four big trends that are going on in the market today. And then lastly, we’ll end the slide where by looking at the new school architecture that Adobe has brought to market to help thrive in this new landscape that we’re in. And then we’re going to spend the vast majority of our time in two demos. The first part is going to focus on the user experience. And the second part is going to focus on the developer experience. On the AEP collection team, we have created a platform in the true sense of the word that connects you as a developer to the world’s biggest brands who have selected Adobe as their data collection network. Now if there’s a single sentence to take away from this entire presentation today, it’s this one. That AEP collection gives you two ways to access real time events from one of the world’s largest data collection networks and then transform and send that data anywhere you need it to go. We allow you as a developer to run jobs on Adobe infrastructure and take advantage of the massive amount of data that’s flowing through that infrastructure. So what are the four trends that are really changing the world that we work in? First and foremost on my mind is of course, performance. Never in the life of the entire internet has performance been more important than it is today. Whether it’s the technical marketing team or the SEO team or your boss or product management, we are constantly being asked to make the native mobile applications and websites significantly faster. I mean, I meet with companies who have attributed a dollar lost amount for every 100 milliseconds in additional latency. And I see this happening over and over again. Now if performance was the only requirement that we had, we could probably meet those requirements. But that’s not the only thing that we were being asked to do. I mean the business is also asking us while at the same time speeding up performance, add new functions to the page, add new features, make more immersive experiences and send data to more places. So when we take the complexity of the technologies that we’re working with and we combine that with the performance needs, the complication really compounds over and over again and makes the world that we work in really difficult. And layered on top of that is the need for better controls around consumer data. We as a marketer are listening to what consumers want. They want more transparency into the data that we have on them and they want more control over that data, which are great things, things that I want for myself. But the responsibility to execute on those requirements falls upon our shoulders. And lastly, technology is evolving so quickly. Whether it’s ITP or every single browser eventually agreeing to deprecate third party cookies, the way that we drive business today is not the way that we must drive business in the future or the way that we need to help our clients drive business. So when we think about these four trends, let’s now shelf that in the corner of our mind and look at the ecosystem or the architecture that we’re working in and how this architecture is very vulnerable to these four trends. This is what it looks like at Adobe and it’s been like this for many years. Adobe is a compilation of many, many acquisitions and you kind of see that in the old school data collection architecture that you see here. If you buy four Adobe products on the old school data collection architecture, then the traditional IT administrator will get four separate emails for those products. They will get four sets of code and documentation on how to deploy those products. And then they have to deploy five separate JavaScript libraries or mobile SDKs onto the app or the website to send possibly five separate events for a single user interaction. And then those five events are sent to various edge networks within the Adobe ecosystem. I mean, when we look at this, we realize that data is fractured from the very first millisecond. And this isn’t only reflective of customers or accounts that use Adobe technology. This method of data collection, of one off data collection is pervasive and ubiquitous across the market. We see companies doing this whether or not they use Adobe technology or not. And so as a engineering and a product team, we’ve seen this problem and we’ve tried to come up with a few principles to help us design and to really reinvent data collection for the future. And these are the principles that we came up with. First is a single Adobe library. That means instead of juggling multiple SDKs or JavaScript libraries, we give you one. And when you install Adobe one time and you buy additional products a year or two later, you don’t have to touch a client side. We have delivered on that. This also leads to a single Adobe beacon, which leads to one stream of data flowing to a single globally distributed SOC 2 compliant, really, really fast edge network. And that of course, we offer end to end control over the data that our joint customers are sending through our platform. And as we thought about this, we realized we shouldn’t just solve this problem for Adobe because data collection is really a problem across the market. So we need to make the system a true platform and allow partners like yourselves, developers, to really tap into the massive amount of data that’s flowing through our architecture to transform and deliver that data where you define. And so now this is the new school architecture. One email invitation to the person implementing our products, a single web or mobile SDK that takes data in a generic form, any key value pairs that sends that to a single edge network. And then from that point on our edge network, then we propagate that data to Adobe products. But like I mentioned before, are we only going to focus on Adobe or should we really become a platform and be a data collection solution for the entire market? Of course, we’re not only focusing on Adobe. This is a data collection architecture built for everyone. So whether or not data is being stored on a server or on a website or a native mobile application, we have a streamlined method to get that data from any device connected to the internet to our edge network. And then from that single point on the edge network, we will propagate those events to Adobe products and non-Adobe products and do that with extremely low latency. We have customers sending us thousands of events per second and we’re getting data to their end destinations with lightning fast speed. So let me just kind of talk to the demo portion now. So what you see on the screen, everything, if you can see my cursor from these three circles in the middle to the left, this is available to all Adobe customers and so is the edge network and of course sending data to Adobe products. We’ve released a new product earlier this year called Launch Server Side, also known as Event Forwarding. And this is where I’m going to focus most of the demo, not all of the demo, but most of the demo here on this section. I’m going to show you how you can develop on Launch Server Side or Edge Forwarding in two different ways so that you can run jobs on our infrastructure. Here is the first part of the demo that we’re going to be focusing on. The initial part of the demo section is going to be focused on the user experience. So I’ll show you the AEP web SDK. I’ll show you two websites that have equal functionality, but of course the new school architecture performs leaps and bounds faster. Then I’ll go into Launch Server Side and show you how we can transform a single stream of data and propagate that from our edge network to multiple destinations, really giving our joint customer scale. So when they send data to your product, they don’t need to touch a client side. They can send that data from our edge to your service. I’ll show you custom code and extensions. Extensions are apps that we allow you to write to add new functionality to Launch Server Side. And then I’ll talk about the debugger, how we give full and complete transparency into the server-side experience that we’re giving to customers. I’m going to hop out of PowerPoint and jump over to a few screens I set up here. So what you’re seeing is alloyio.com. And I have our engineer, Joe Corey, built this for us. And we have the same feature set on two sites, but one is using the old school implementation or architecture, and then one is using the modernized infrastructure. So when I refresh this page, I have the network tab opened up. Oops, excuse me. The network tab is opened here. And there are multiple libraries being loaded. So I mean, there are six server calls, a handful of these JavaScript libraries totaling 121 kilobytes of slow wait. Now I’m going to jump over it. And these are the libraries that we have deployed here, some Adobe technology, GA, and also Segment to send data to a third party. I’m going to hop over to the AP Web SDK. And you’ll notice here that instead of having six requests, we have a single request. And the library size now is only 20.8 kilobytes. I mean, this is huge value. We have taken the various Adobe SDKs, and we have collapsed and compressed those into a new SDK that’s generic enough and flexible enough to capture data requisite for not just Adobe products, but non-Adobe products also. This is the AP Web SDK. It provides blazing fast performance to all Adobe customers. Now I’m going to go into event forwarding or launch server side. The basic construct of launch server side is we have a notion of rules. And so a rule consists of two portions, conditions. So when certain conditions are met, then take certain actions. Now where do we give you as a developer access to tap into this event flow? We allow you to go into the conditions here. And you can add custom code. So we allow you to run JavaScript ES6 on our edge network. We do that securely and once again with extreme low latency. So this is one place where you can develop. But there’s also another place, and that’s in the form of extensions. So this action is going to hit an endpoint, listen for the response, hand it off to my data warehouse, to Google Analytics, Snapchat, and Facebook using their new conversions API. And I do all of this without adding any of this code to the client side. So once again, maintaining that performance and maintaining that simplicity on the client side. So if I open up one of these actions, you’ll notice here in this dropdown that I can select an extension. Once again, this is something that you could build and I’ll go through the developer experience in a moment. But when I select any of these extensions, then you as a developer have complete control over what’s happening on the right side of the screen. So when I select the Facebook extension, which was built by Facebook engineers, not Adobe engineers, they defined what this whole side of the screen looks like. And this is the power and flexibility that we’re giving to you as a developer. You can add whatever you think is valuable to our joint customers here in this screen, and our customers are loving this functionality. So this is what the setup looks like. I would just publish this and then it would deploy to our edge network. I’m going to move this window out of the way and I know that this screen looks very busy. But on the right hand side, excuse me, on the left, this is my locally deployed website. I have this webhook that represents my own data warehouse. I have Google Analytics here. And at the bottom, I have Facebook. So I’m going to refresh this page. And you’ll notice that data has already made it here to my webhook. And it’s also made it here to Google Analytics. You see that little spike in the graph. To trigger Facebook, I need to hover over some buttons. Now Facebook has had, there’s been a little bit of latency, so we’ll see how this works out. But if I hover over that button a few times, you see this data making it to this webhook very, very fast. And also same with Google Analytics. You see those multiple bars, so we’re capturing that data. And let’s see, sometimes Facebook takes a moment, oh, we actually got those data points. So right here, here’s a timestamp, successfully received by Facebook. This is hugely valuable, once again, because I’ll go to my developer tools and look at the network calls. When I come here, I don’t see any Facebook code. I don’t see any, actually, let me refresh the page to get those calls. I don’t see Facebook code here. I don’t see any Google code. And I don’t see any webhook code. So the customer has modernized their data collection architecture to the new school architecture. And we have taken those events that I loaded up on this page, sent that to our edge, and sent it to the webhook, to Google Analytics, to Facebook, and to Snapchat, even though I didn’t show you that, but it’s here in my developer tools. We’ve propagated that one event to multiple destinations, and we’ve done that in a way that’s scalable and very, very fast. So now I’m going to jump out of this view and show you the developer view. So let me go back to PowerPoint real quick, and let me just share what I’m going to show you right now. I’m going to show you a scaffolding tool. The value of this is it helps you to really start developing quickly, because it is a command line that has a few questions that when you answer it, we construct the extension library for you. Then I’m going to show you the extension sandbox. This allows you to deploy locally in your own development environment to test extensions that you build and to actually send an event through that extension to see how it works. And then I’ll show you the Hello World repo, which is an extension that’s on the public GitHub repo right now that you can dive into and start learning how to develop on AEP collection. So without further ado, let me bring over a few windows to show you the developer tools that we have. So on the left-hand side, I am in, I know I’m a product manager, so I am using a Windows machine. Please forgive me. I am in command line here, and you’ll notice that the directory that I’m in is Magento live extension, and I’ve navigated to that directory here. So once I navigate to this directory, this is a NPM package that I pulled down, and I execute this command, then that turns on the scaffolding tool. And so I’m going to go through this scaffolding tool just really quickly. It asks me to name the extension, so I’ll name it. I select the type of extension, so we offer development for web, mobile, and edge. I’ll select edge. I want to start off with version 1.0.0, short description here, and then the author I’ll say is Adobe, or this would be, you know, your partner name. And then here, just ask me a few questions. Maybe like I showed you on the demo, maybe I want to add an action type, and maybe that action type is I want to make a fetch call. So I named that action here, and it asked me, do I want to show this to the end user? I say yes, I do. And then I could add in new conditions or other elements. I won’t dive into the details here. But let’s say that I’ve completed this, and I select I’m done, and watch the explorer window on the right. When I hit I’m done, you’ll see that these two folders were just created. And so this scaffolding tool is hugely valuable because it allows you to create the file structure of an extension and get coding quickly. I’m now going to pull this off the screen and bring over some other development tools that we have. This is a sandbox tool. This is also an NPM package that I pulled down, and I’ll show you how this works. So in this extension, in this sandbox rather, I also connected the hello world extension. So that’s what’s running here. I’m going to pull up my webhook window, and I’ll show you how we can also use this same webhook. I’m using this local sandbox to test this extension. So I’ll make this a little bit smaller so that you can see. And there’s a few parts of sandbox I want to go through. And this is just really high level, but in an extension, there’s two components. There’s the view, and this is essentially what the end user can see in the UI. And this extension has two views. It has the action view and the extension configuration. So here, the field that is required is a URL. So in this URL, I actually put this URL here to the webhook. And once again, this is just the view of the extension. It’s not actually configuring it. I’ll show you how the user configures it in the library sandbox in just a moment. So this is the extension configuration, and this is what the action looks like. And notice that we have added the functionality to save the response from an endpoint into a certain key. So this is really helpful because it can help you understand what your extension will look like to the end user to make sure that it’s what you expect as a developer. So once you’re comfortable with the views, then you would go ahead and go to the library editor. Inside of Edge Forwarding or Launch Server side, or even Launch Client side, it’s the same, you know, if you’re developing for web or mobile also, we have this notion of a library. A library is a set of extensions, a set of data elements and rules. Data elements are just variables, and rules are what I discussed before. If certain conditions happen, then it executes a set of one or many actions. And so in this library view, you get to see how your extension interacts with the other parts of the library, namely the data elements and the rules here. So here’s the extension configuration. So here’s that view that we looked at before, except this time because I’m configuring, or I’m using a sandbox to configure the extension as if I were an end user, I can put in the webhook URL. So once I’ve done that, then I can go to data elements and create globally accessible variables. And then I can also go to rules. So in this one rule, I have two actions. I haven’t created any conditions just for the sake of demoing. I just want this to trigger on any on hover or page load event. So I have these two actions and they’re being powered by the same rule. So when I edit these, you’ll notice here that I’ve saved the response from this server, this webhook is, you know, we’ll pretend like this is my own first-party data warehouse. I’m saving the response from that server in this first action, and then in the second action, I’m going to take that response and then send it back to the same webhook. Of course, in real life, we would probably send this to a separate endpoint, but just to make this simple, I’m sending it to the same webhook. And I haven’t hardcoded the value of the server, right? I’m using this data element, this variable, to send that data on. So I’m going to go to my webpage. Sorry, I’m going to go to the library sandbox here. And this is the last step. So you’ll notice I have a payload, and I’m going to send this payload through this library, which means that it will also flow through the extension that I just created and that I’m testing. And let’s see if it makes it to this webhook. Let me make this… I’ll kind of scoot this over a little bit. I’ll hit Send Event. And there we go. We just got two events to line up to those two actions that I created. And what you see on the left-hand side, this is our logs that you would see as if this event ran through our servers, but this is all happening locally on your machine to make it as easy as possible to develop on our platform. We have very specific logging here to tell you exactly what’s going on. And let me show you the events that were received by the webhook. Remember, I didn’t add a payload here, but if it worked properly, this second event should have… Yes, it has hello from server. And I didn’t hardcode that. And just to show the response body, here it is. So for this server is responding with hello from server, and you’ll see that that data made it all the way from the sandbox back to this webhook. And that was done very, very, very quickly. I’m going to jump back to the PowerPoint presentation and just give a quick summary of what I just showed you. So to summarize, I showed you the scaffolding tool, which is an NPM package, and how that enables you to really start development very quickly. I showed you the sandbox that allows you to take the extension that you’re building and to test it locally on your device and to see exactly how it will function as if you published it to our own catalog. And then let me end by showing you the repo that we set up for the Hello World extension. I got so many tabs opened up. Let me find that one. Here it is. So this is a Hello World extension. And I think one of our moderators will paste the link of that in the chat box. And we also have a lot of very detailed documentation to help you start developing on our platform. So thank you all for joining. I think we have a few minutes to take any questions if you have any. But if you want more documentation and links to the resources that we have, you can go to this form here and fill this out. And I will send you, I promise, just one email that will send you all of the links to our various developer tools. And once again, if there’s one thing that you take away from this session, it’s that we give you two methods to run jobs on Adobe infrastructure. We give you custom code, and we also give you extensions so that you can tap into the massive amount of events that are flowing through Adobe’s data collection infrastructure so that you can deliver value to our joint customers, whether it be transforming data or sending that data to a given endpoint. We have tried our best to really make this experience as friendly as possible for developers, and we’re only just getting started. So with that, I have been rambling for 24 minutes and 50 seconds. Let’s go to any Q&A that any of you have. And if there aren’t any, then maybe we can give you some time back in your busy day. Joe, Sherabon, anybody, are there any questions that we should answer here? We’ll give it a couple more minutes. I’ll keep this screen up. But maybe… There was one question about whether you need event forwarding license to get started with this repo. This repo, you can go download it, and you can play with it, and you can even test it locally without needing a license. So no license required to get started. Thanks. Awesome. Thank you, Brandon. Were there any other questions? I don’t see them in the chat pod for some reason. Okay. Going once, going twice. If there aren’t any questions, once again, I invite you to please go to this form and fill it out. We’d love to send you the additional developer tools that we have and partner with you to deliver joint value to our customers and to give you access to, literally, I mean, the massive amount of events going through our ecosystem. So once again, I know that all of you are busy, and we on the AAP Collection team are thankful for you carving out time to meet with us today, and we hope that you enjoy the rest of the conference. Thank you very much.