ÃÛ¶¹ÊÓƵ

Transcript

All right. Hello and welcome. This is our first partner webinar post-summit. So the dust has settled. For those of you who were able to join us in Las Vegas a couple weeks ago, we hope you enjoyed your time listening to some of the exciting announcements coming out of Summit. This is a unique partner event that we have. This is the first of a four-part series, and it’s something that we’re excited to share with all of you as a new way to interact with our partners as well as our product team. And this is the Partner Implementation Series. So as I mentioned, this is part one of a four-part series. And today we’re joined by several team members of both our product marketing and product management team as well as our ÃÛ¶¹ÊÓƵ Commerce architects. So today we’ll be joined by Russell Albin, one of our ÃÛ¶¹ÊÓƵ Commerce architects, Daniel Rios, who is on our ÃÛ¶¹ÊÓƵ Commerce product management team, and Surya Lamech as part of our product marketing team for ÃÛ¶¹ÊÓƵ Commerce. What’s unique about this implementation series is not only the number of events that we have in the series, but this was really generated through internal discussion through all the teams that I mentioned in addition to our ÃÛ¶¹ÊÓƵ customer success teams. Going through a number of ÃÛ¶¹ÊÓƵ Commerce customer implementations, we’ve curated this four-part series to showcase the best practices in planning, building, and maintaining the modern ÃÛ¶¹ÊÓƵ Commerce implementation and integration. So today, the session one is lowering that total cost of ownership for ÃÛ¶¹ÊÓƵ Commerce integrations. And the final point I’ll add before we hand over to Russell, what is unique about this as well is this is intended to be an interactive format between Russell, Daniel, and Surya as they’ll be guiding through a number of topics in a discussion format. So it’s a slight deviation from the usual presentation style you’re used to. We’re looking forward to your feedback. As you’ll see in the chat, we definitely encourage you to ask questions in chat. The team will be able to address toward the end of the session. But with that, I’m excited to turn the presentation over to Russell. Russell, take it away. Perfect. Thanks, everybody. So, yeah, we’re going to be… This is part one, and it doesn’t necessarily cascade one to another, but there are topics that we’re going to be covering for the next four weeks going over like edge delivery services and all sorts of really cool things. But today we’re going to focus strictly on the trying to do your best to lower the total cost of ownership using smart implementation patterns and things that we’ve learned. And that’s why we’ve invited Surya and Daniel because they have a breadth of knowledge in different areas. And we’re going to be able to help everybody understand some new best practices because ÃÛ¶¹ÊÓƵ Commerce has matured and it is definitely not the same product it was 10 years ago. So let’s kick things off with just a quick introduction. Like I said, my name is Russell Alban. I’ve been with ÃÛ¶¹ÊÓƵ for a couple of years, but I’ve been an architect for over a decade now. And I’ve been working with Surya. He’s fantastic. He helped me originally with some of the app builder things that we started last year. And then Daniel has been more than helpful. He actually came from I think Marketo, right? Was your previous role before you came over to Commerce, Daniel? Oh, check your mic. Yeah, no, no, no. It wasn’t Marketo actually. So we’ll start off with Magento. We’re back in the days before. Oh, wow. All right. That’s awesome. So let’s kick things off with like, Surya, can you explain like when you’re talking about like integrations with ÃÛ¶¹ÊÓƵ Commerce? You know, you’ve got a fairly good breadth of knowledge. Do you want to start off with like, what do you think? Talking about like… I didn’t get that again. Oops. By the way, if you have another question. Sorry, my Surya, my Siri decided to pick up and talk to me. That happens on pretty much every call I’m on. Somebody triggers Siri trying to say my name. So anyway, going back to the original. The original connection between Commerce and like a front end app, like you were bringing this up the other day that that was originally a little bit harder and complex. Let’s talk about like the new way to think about it, Edge delivery, if you want to bring that up. Anything you want to talk about. Let’s just get it started. Yeah. I thought, given the focus on today’s session, which is lowering the cost of ownership, I thought I’d go over a little bit about where does that cost arise from, right? Once we understand where those costs come in from, we can look at ways that we can reduce that cost and integrations tend to be probably something, at least in our experience and from talking to a lot of customers, integrations tend to be where you spend a lot of time initially integrating the system and then also maintaining them over time. And if you don’t mind, I have a couple of slides that I’d like to share. Not a structured presentation, but at least some just to guide the conversation a little bit. Sounds good. And let me know if you’re not able to see my screen. If you look at this change or the increase in cost comes from the fact that today, pretty much all commerce is digital commerce. So it’s no longer, okay, I have my website or a web store and that’s where that’s digital commerce and everything else is in store or physical or things like that. Today, every touch point, whether you’re in store or even at home, if you’re shopping using like an IoT device or from my smart fridge or something like that, every touch point is digital. And those touch points aren’t really discrete. It’s not like, okay, I have one customer who’s coming in and store and that’s completely different from the customer who might be shopping online. If you look at the way customers are interacting, we may discover something on a social channel. We may buy it on the web. We may get it delivered by a third party shipper, but it’s all connected because I can go into my retail store site and track where my shipment is, even though it’s being delivered by somebody else. I may be able to request support via an app. And then I might wonder if I do need to return that item, I may need to go into store. And a recent experience I had was I bought something from a retailer who only had an online presence, but they allowed me to return it at a store that was not even part of their chain. So I could just go into a local store. They had a list of partners locally and I could go and drop it off anywhere. And immediately the moment I drop it off over there within five minutes, I get a notification that the return has been received. So it’s all connected for the same buyer. And while that experience is great for the shopper, what that means is that there are a lot of integrations in the backend, right? I mean, there are so many different systems that merchants need to integrate on the backend as well as on the front end to be able to deliver those kinds of experiences. And what it starts to look like and what’s commonly known as composable commerce is really about having all of these different services that may be independent and very often are independent because it’s such a breadth of services. There’s no one solution that does everything for you from payments to search to reviews to ratings to content and assets. So merchants end up integrating across these different services. So this is what you envision. You have a number of services and then you have a number of touch points and this very clean system that allows you to provide that connected experience. But what we’re seeing is that while merchants are expecting to implement something like this, the actual implementation turns out to be a little bit more complicated. It’s a little bit more messy. All of us who have had some experience implementing an ad or a one of them, you know that those other architecture diagrams that are a little bit more marketing oriented, some of which I produced myself, I’m not sure the reality, right? You end up with a whole lot of point to point integrations between multiple systems. In order to do those, you end up with a bunch of services, maybe in addition to those original services like commerce content, you probably need storage somewhere, you need a runtime somewhere, you need a CDN somewhere, all these different systems. And that’s where we see the cost coming up because it takes a lot of time to implement this. You end up with data and I know Daniel is going to talk about that, about how we solve for that silo of data which resides because customers are reaching out, you know, the multiple touch points across their in-store devices or web store or social. And there are so many points we are capturing data about our customers and then it’s hard to leverage that to be able to provide that comprehensive journey. And then once you’ve built all of this, you know, I mean, we have some really smart architects working on ÃÛ¶¹ÊÓƵ Commerce. Once you’ve built all of this, what happens is you reach a point where the systems become so complex, you spend more time maintaining that system than you have available to actually innovate or build something new, right? If you are going with a particular search provider today and then six months later you decide you want to replace that, you now have six different systems that are probably deeply integrated into it. And replacing that search system will require to refactor gold on your storefront, on your, you know, maybe a content system or your commerce system and so on. So to go back to your initial question, this is why, this is where we see the most cost for our customers, which is building these integrations and then more importantly, maintaining them over time. So I’ll pause over there and ask you, you have experience with this, what do you think about it? I think what we are finding is that using the old logic of everything being individualized or siloed, as you put it, the QA process ended up taking like longer. So that’s usually where then you would sacrifice the timeline. You would say, well, let’s just not QA as much. And then that would just in turn lead to bugs down the road. So figuring out a way to get through this siloed data and all this, all these, I love your rat’s nest of lines, because that is actually exactly how it ends up looking. But I think that some of the things that we’ve figured out, at least on some of the keeping the seamless integration is when we introduced RCTDP about a year ago, that kind of helped solve some of those multiple integration points, right? Yeah. I mean, Daniel is on and I think that’s his baby. So we can certainly speak to that. Awesome. Yeah. And then, of course, and we start seeing really kind of these total cost of ownership and really between integrations between commerce and really other experience cloud products. We need to take the effect that we are one ÃÛ¶¹ÊÓƵ and we really need to have these native integrations between us because people were actually building these out on their own. They were taking the time and it would take them months to really build kind of these connectivity and these integrations between products. And what we’ve been able to do is really help in building that kind of this native implementation in which both you can send both, not only your data from a start from perspective, but I mean, really thinking it really taking also the time to do it from a back office perspective and really giving not only a total cost of ownership and lowering, really expanding that total cost of ownership, but really returning on investment and increasing in that aspect. Okay. So as far as the commerce piece goes, we have a new module that was created and it’s called the, sorry, what’s the proper name of it? Content? Oh, Siri, stop. Yeah. Yeah, I’m waiting for a slightly longer prompt Russell. The new module for? For commerce that helps do the integration from commerce to platform. It’s called, it used to be called the data connector. Data connector. Yeah. Yeah. So that’s been out for about a year now. Is that right? Daniel? Yeah. So our data sharing capabilities or data connection and our audience capabilities activation have been about, we started releasing them about a year ago and that was really to give us integrations between the native integration between commerce and experience platform, but not just the experience platform, the applications such as customer journey analytics, ÃÛ¶¹ÊÓƵ journey optimizer, and real time CDP, but also the ability to go to analytics and get to, and go to be able to go to target. But you know, when you start talking about data, you start talking about the flow of data and really being able to implement that with our data connection, we send data. And if you think of this as a round trip and a view of it, how do you get data back? To get really data back or really in this scenario, in our scenario, the way we viewed it was really to get audiences back. So by getting audiences back and bringing them back into commerce and net effect in the commerce experience, we had consistency across all types of, across all different types of communications or channels and being consistent in our channels. So let’s take for an example, you know, we’re really talking about the cost of ownership overall, really trying to, you know, lower the cost of ownership. What we’ve been able to do is actually lower by utilizing our data connection. We’re able to lower the time of implementation to be sending data over to the experience edge to be able to distribute it to all the ÃÛ¶¹ÊÓƵ DX products that you want to send it to in a day. Normally to set up the pipeline to utilize all the different technologies available, such as a web SDK, to set up a data layer, to be able to tag the page and then be able to set it all up within the experience platform. It could take up to three weeks or even longer depending on the type of implementation. We’ve been able to do it in a day or less for things such as a Lumen Storefront or if it’s a headless implementation, it may take a little bit longer because we have code snippets that you need to utilize. But really what we’re trying to utilize here is really lower the cost of being able to get that time to value in itself and being able to distribute that time to value and get a really a quicker return on investment in the product. True. Speaking of those integrations, Surya, you mentioned the other day, there’s, I think you listed off three types of common integrations. It was like back office and front end. Did you want to go over those and see where that leads us? Yeah. I mean, every integration is different, right? But if we were to try and kind of bucket them in these slightly broader buckets, we’d see typically customers are doing back office integrations with things like ERPs, CRMs, and PIMs. Then they have more of the personalization and data sharing integrations that Daniel was talking about, things like integrations with a CDP, analytics, journey optimization, and so on. Then you have the actual storefronts. So those would be like whether that’s your web storefront and a headless implementation or a native app or IoT or whatever that might be. So if we bucket it that way, we realize that there are different extension points a product might must need to support to be able to manage those different kinds of integrations. Now I would have asked this question, maybe some of you can share it in the chat, about how long have you worked with ÃÛ¶¹ÊÓƵ Commerce and maybe going back all the way to Magento, I’d be curious to know when your experience started with. But ÃÛ¶¹ÊÓƵ Commerce, we have evolved it tremendously, especially in the integration, how we integrate over the past few years. So if we look at, and I’ll pull up a slide again, if we look at, you may be wondering, if you have spent a lot of time, if you worked with Magento starting from when Magento 2 was launched and overall all the way up to now, you may feel that, well, it’s always been easy to customize or extend ÃÛ¶¹ÊÓƵ Commerce, right? And that is true. However, what happens is when you start, the traditional way of extending ÃÛ¶¹ÊÓƵ Commerce has been to go into the core product and maybe deploy a new module that does something like extend an existing module. And that gives you great power, but like I tend to say, with great power comes great responsibility. What happens is, right? I mean, you have these custom tables, custom extensions, modules, and all of that, and then that adds cost over time. It adds technical debt to your ability to upgrade the product and maintain it over time. So our goal and what we’ve done over the past, I guess, starting, and the data is etched in my mind because of the launch of the Jan 17th of last year, we introduced a number of different extension points that allow you a lot of flexibility at how you extend our product, but without customizing the core product at all. And that means giving you these well-defined points, starting with our API, right? I mean, we’ve added a lot of GraphQL API coverage for all of our previous capabilities. And of course, all of our new services, if you’re familiar with live search, product recommendations, our catalog service, all of these services are API first, right? And so we are designing them assuming they’ll be consumed by the API and UI second or so. So that gives you the ability to basically consume or create data in our system from any other third party system. And then we added UI extensibility and because that’s pretty common, right? You build an extension, but you want to give your merchants the ability to administer that new extension that you built or some additional capabilities, or maybe you have, say your auto grid and you want to add a new column to it or something like that. And with, right, I mean, Russell, we probably done that in your past implementation, right? And that means that you have to customize the admin console. Exactly. Now that’s an important part. I mean, merchant experience is very important, but that adds technical debt. So with UI extensibility, what we do is we allow you to build your single page app outside of ÃÛ¶¹ÊÓƵ Commerce. And then we give you these hooks where you can inject them in and say, you know, I need a new admin screen or I need a new column on my auto page or I need a new action on my product page. For example, you have an auto page and you want to add a bulk action to send all those orders for fraud detection, for example, that’s a common use case. So you can easily add those bulk actions, additional columns without actually customizing the core product. So that’s with UI extensibility. We added web hooks, I think around October of last year. And what that does is it allows you to extend native processes. By that, I mean, let’s say a new, let’s say somebody adds a product to cart. You might need to do a real time check for inventory or pricing before allowing them to add them into add the product into cart, probably a very common use case. So web hooks allows you that synchronous call that the moment you click add to cart, it actually makes a call outside somewhere, checks inventory and then allows you to add it to cart or as you go to the checkout page, it again, synchronously calls out, gets tax information or shipping information from a third party. And all of this is done through a simple configuration with, I think in December we added the web hooks configurations to the UI. So you don’t even need to do a XML configuration file for that. You just go to the UI and say, you know, call the service to get back shipping information or tax information. So that’s with web hooks. Again, no customization of the product. And then events allows you to tap into a bunch of events. I say over 700 here, I think it’s now close to a thousand events for pretty much anything that happens in the system. Maybe the most common of those are updates to customer accounts or to order data or product or stock data, things like that, where you can take, you can tap into these events and say, anytime an order gets created, send it over to my ERP or anytime a customer account gets updated, send it over to my CRM. So bringing that home, what we’re saying is that if you’re implementing ÃÛ¶¹ÊÓƵ Commerce, yes, you have all the power to customize the product to do whatever you want. However, our recommendation to lower the cost is to tap into these extension points. So don’t customize the core product because you know the challenges that come with that. All of you experienced developers with ÃÛ¶¹ÊÓƵ Commerce instead use these extension points that we’ve provided that are added to the product, which make it much simpler to maintain these over time, the extensions themselves, the apps that you build. So those customizations are easy to maintain and the core product as well, because now you have an un-customized product, which is very easy to patch for security patches or new releases and so on.

Andrew, did you want to follow up before I had a couple of questions I was going to ask Surya, but I felt like you might want to chime in.

You know, for, you know, Surya, I had a question actually for Surya myself. Hey, Surya, you’re giving examples of things that have been built out with App Builder in order to really help in this or with our flexibility? Absolutely. So I will drop a link in the chat. Some of you on the call may have attended ÃÛ¶¹ÊÓƵ Summit, but if you didn’t, all the sessions are online, so you can catch up on all the great content there. But we had a partner showcase. So there’s a session called ÃÛ¶¹ÊÓƵ Commerce Rockstar, where we had developers from partners and customers come in and showcase what they had, you know, some of the innovations that they had built. And I think one of the really cool use cases was a partner had built basically what they called a lean auto management system. And what they were doing is this is outside the US. And what they were doing is they were able to use instant messaging app to fulfill orders. And the way they were doing that is every time an event gets created for, say, an auto gets created in ÃÛ¶¹ÊÓƵ Commerce, those events, in their case, they used WhatsApp. And if you’re not familiar with it, it’s kind of like an instant messaging tool like iMessage or something like that, but it offers a few more capabilities like interactivity, polls, questions, answers and so on. And they were using events from ÃÛ¶¹ÊÓƵ Commerce to push out. The moment an order gets created, they determine which is the warehouse that needs to deliver it. They send a message to the warehouse manager, which goes on WhatsApp on the instant messaging, and saying, here’s the order, here’s the quantity. The moment it’s been packed in the warehouse, all the manager needs to do is click completed the task in the instant messaging app, which they already use. And that sends an event back to ÃÛ¶¹ÊÓƵ Commerce. So now that that’s been packed, then Commerce sends another event out because the order status has changed. It sends it to a delivery driver saying, you need to pick this up and deliver it to this address. And the delivery driver, it’s not like they’re texting back or anything. They get a bunch of options over there. Yes, we’ll do it. What time, when, which date and so on. And they go pick up the order and then they can click on the instant messaging app picked up. And once again, that status gets updated in ÃÛ¶¹ÊÓƵ Commerce. All of this is happening through events without customizing the core product at all. And a customer can log into ÃÛ¶¹ÊÓƵ Commerce to check the order status and they know that it’s been ready to ship in the warehouse. It’s been picked up by the delivery driver. It’s been out to deliver. All of this is done without customizing the core product at all. Almost real time updates to the status and tracking of the status of the delivery of it. So that was one really cool use case that we saw. The other one was Nestle. They had a session of their own and I was lucky enough to be on stage with their manager for the project. And so this was for Nestle’s brand, Purina, which focuses on pet wellbeing. And what they are building is they have a smart pet litter box. I didn’t know these things existed and I don’t have a pet, but I feel like I want to buy one of those. And this smart pet litter box, which is available to audit day, pet owners can use this litter box and when their pet gets in the litter box or anything, it measures their weight and how often they go to the litter box and all of that stuff. It sends that data back to ÃÛ¶¹ÊÓƵ Commerce. So everything it tracks about the pet, it sends it back to ÃÛ¶¹ÊÓƵ Commerce and then we use that data to make recommendations on products that that pet might need for their wellbeing and send those recommendations back to the owner’s mobile app. And then obviously right from there, from the app, the owner can choose to purchase those products. And so it’s completely connected from the smart device in home back to ÃÛ¶¹ÊÓƵ Commerce to the native app. And that’s providing those wellness recommendations, which then they can order and it gets shipped to them directly. And they are doing this using, they built out the first part, which is the API orchestration using API mesh. And we’ll talk a little bit about that shortly, but they’re also using events for that when that data comes in. So that part they are building out about sending out the recommendations to the pet owners. Did that rockstar, did they use App Builder for their integration or do you remember? Oh, they did. It was App Builder. So all the events were sent, were piped to App Builder. And for those who are not familiar with it, I will briefly give you an overview of that in a moment, but we’ll go over that. But yes, it was all built using App Builder. And that means it’s all orchestration rather than those point to point integrations and customizations. Cool. So the rockstars, so then he was, was he the winner or was he just one of the, he was one of the winners, right? There was. She was. So it was a lady Shikha who presented the integration with WhatsApp business and they were selected as the panel’s choice. Yes. That’s awesome. Yeah. That’s a great story. I love that one. Hey Russ. Hey Russ. I think this would be a great time. I think we have a kind of a little survey up and ready to feed that out and give really get some responses back from everyone to find out what they really know about kind of App Builder and kind of what really is their biggest pain points. Okay. Where’s that at? Ah. Oh yeah. So this was the poll that I had asked for. So I would, it would be helpful to know where you see the most cost in overall maintaining the platform. And it’s open so you can type in your responses. Ah, yeah. That’s frank and sad. That’s not uncommon. It looks like, you know, that seems to be, you know, okay.

I also would agree with your original statement while we’re waiting for things to come in that we used to spend most of our time either doing the data migration from, you know, your old platform to the new one or if you’re just upgrading or replatforming or replatforming or whatever. Integration piece with your backend systems, that was always number two. Like we always kicked off the data integrations first and then for the, you know, the old stores and old orders and stuff like that. But the other integrations with your inventory management or your payment processors or whatever, those always seem to take the longest. So it’s nice to see that some of the technology that’s been released in the last couple of years is going to definitely help with the overall time to get those things through the door and out to QA. Nope.

All right, we got about… I see the team. Yeah, I see the team. Right, so you want to go through what you see from the responses? Action points, ERPs, yep. Yeah, honestly, just from personal experience, knowing that we can divert some of the customizations that used to happen in the product and take some of the weight out of there is, I can tell you for a fact, that does help with the upgrade pain points because the less amount of customizations you have, obviously, the less amount of potential hang-ups you’ll have. So I think that’s a really good, easy takeaway. And then, like I said, the integrations, the fact that all of… you said almost a thousand events are now available. That’s going to… that’s… yeah. Yeah, it looks like if we look through this, it looks like third-party development, looks like we got some performance stuff, platform upgrade, all definitely things that we… really do affect it at the end of the day.

What’s funny, I don’t see anything in here, the cost of personnel. I would have assumed that that would have been like on there too, because having at least one experienced commerce expert is usually pretty expensive. So and sometimes you have a whole team. But it’s funny that everything was about the integrations and the software itself.

Well, yeah, I mean, it might have been the way I asked the question. Yeah, no, no, it’s… So, but I will say, I think, yeah, I think we can end the poll. The themes are pretty clear. Upgrades, integrations, adopting new features. And these are related to some extent, I would think. So let’s talk a little bit about… So first of all, we hear you, right? I mean, we understand. We talk to partners all the time between all of us here on the call and our customers as well, right? And we are hearing where those integrations, where those costs come in, what are the challenges are. So let’s talk a little bit about what we are doing to address those costs. And Daniel, I’m looking for your support over here. That’s where you feel appropriate. Please jump in, Russell, as well. Yeah, of course. So if we break it up into upgrades, custom feature development and adopting new features. So and I think there are a lot of other things over there, but let’s talk a little bit about that, about those three primarily. So we spoke a little bit about upgrades and why we are urging you to move to a out-of-process extensibility or rather extending outside the product versus inside. So let’s talk a little bit about adopting new features. So you, hopefully, because we’ve been beating the ground pretty hard about all of the new services we are launching, and over the past two and a half or three years, we limit new features within the core product. So by that, I mean the ÃÛ¶¹ÊÓƵ Carvers Foundation. We limit how many features we launch over there because we want to make it simpler for customers to choose the features they want rather than have a product that has a lot more features than they need in maybe consuming resources or adding complexity. And to that end, we’ve been adding, we’ve been delivering features at a faster pace than we did before, but they are not going into the core product. Instead, they are going into individual services like payments, product recommendations, live search, and those are all AI-powered services that allow you to do intelligent searching, browsing, merchandising, and all of that. And our goal is to deliver services in this way because they allow us to deliver those services faster. They allow our customers to adopt those services faster because they don’t need to upgrade the product. So that challenge you have with upgrade, if we release a new capability and product recommendations, a live search, you don’t necessarily need to update, upgrade your core product to get access to those features. And there’s scalability. So we are able to scale all of these services independently as needed. We are cognizant of the fact that sometimes adding new services can add, individual services can have performance penalties like latency. So we’re not one of the, we don’t intend to deliver to you 30 different services for every little component that you might have in the system. We ensure that when we deliver a new service, it’s not, you’re not going to suffer any kind of latency between the different services as they communicate with each other. But some of the important parts about these services, first of all, they all work together, meaning natively work together. So you don’t need to integrate live search with our catalog, with our commerce foundation, or you don’t need to integrate payment services with checkout processes, ÃÛ¶¹ÊÓƵ commerce, and so on. You can extend them, of course, and you will because your customers are always going to have unique or bespoke needs. But our goal is to make sure that adopting these services by delivering these as individual services, we are not shifting engineering complexity from us onto you or our customers. So you should be able to adopt these services seamlessly when you want to. However, if you choose not to adopt these services, we want to make that simpler for you, for our customers as well. So if you decide that instead of our search service, you want to use a third party search service or different payment service, it’s not our goal to simply say, well, we have an API go build or whatever you want because that ends up meaning you have to build everything you want. And we want to simplify how you build that. And to that end, we’ve launched capabilities. And Russell spoke to them. Daniel spoke to them as well, referring to app build and API mesh. I’m hoping you’re aware of them already, but if you’re not, the reason why we introduce these services is to avoid that first spaghetti picture that I showed you, which has a whole lot of point to point integrations. So we think rather than having to integrate each service independently and every service that is here, I’m talking to us about third party services, you need to integrate with our services work together already. The developers and each individual service should not have to know the inner working of all the other services they depend on. And for that, and I’ll explain what I mean by that. For that, we deployed API mesh or deliver API mesh, which helps you to orchestrate those communications between the services. What that means is that let’s say you have your storefront, which consumes product details and pricing from ÃÛ¶¹ÊÓƵ Commerce, but over time you decide that you want to replace pricing from ÃÛ¶¹ÊÓƵ Commerce with a third party CPQ or something like that. Now, our goal is you shouldn’t have to go and refactor your entire storefront or in some cases you might have multiple channels where that pricing is needed. Maybe you feed your product data to a marketplace. Maybe you have multiple storefronts, a web storefront, in-store, a native app and so on. What we can do with API mesh is you can configure in a third party service API for something like pricing. It could be anything. It could be digital assets. It could be search. It could be inventory, whatever it might be. Taking the pricing example, you can plug in the pricing API and then you can go and transform the response from the ÃÛ¶¹ÊÓƵ Commerce API to inject pricing from a third party service. All of this is done through configuration. You don’t need to customize the commerce product. You don’t need to customize your pricing product and you don’t need to refactor your storefront. All you do is in the API mesh layer, you can replace pricing coming from the ÃÛ¶¹ÊÓƵ Commerce API with pricing from a third party API. And that greatly, I mean, I don’t need to, I guess it’s obvious what the benefits of that are, which is that you’ve saved a lot of maintenance and avoided a lot of technical debt across your ecosystem, not just the ÃÛ¶¹ÊÓƵ Commerce product, but all of your other products that make up your ecosystem as well. So that’s the key way to do it. Russell, I know you had it. No, no, I was going to just expand because some of these people may not be like in the technical side of things, but like the benefit is, is that if that backend endpoint changes, your API mesh can also massage the data to make sure that the front end gets it as expected. So even if it comes now, if it comes in as a string, but now all of a sudden it’s JSON, you can fix it and then have the API mesh return the value back to the storefront in whatever format you were expecting it to be. So I think that’s the thing that a lot of people just don’t appreciate is that that API mesh does all the hard work and then you just massage the data there and then send it right back. And also back to those ERPs, because if your AP is expecting it as a JSON, but it’s coming as a string or whatever, you can reverse it and do the same thing, but just the other direction. So, yeah, and that brings up an important point because those source services, they don’t need to all be GraphQL. We started off with GraphQL and REST as source of API for API mesh, and then we added support for SOAP. That means for our customers who may not have GraphQL back-end systems for various things, ÃÛ¶¹ÊÓƵ Commerce and the services are primarily GraphQL, but for third party services that you might have had for a while, they could be REST or SOAP. And API mesh will transform that into GraphQL so that you get kind of a uniform API across all your services for you. That’s brilliant. I think this is a good time for that next poll. Did you want to go ahead? Because we’re running, we’re kind of, we’re actually going to run out of time. Sure, let’s go with it. Yeah. So this one is just in general, we were just talking about it. It just has everybody here, have they heard about App Builder and the new integration starter kit? And I can’t remember, Daniel or Surya, which one of you are more knowledgeable on the starter kit? I hope we can just explain it real quick. Yeah, I’ll talk about it shortly. And then I think Daniel will talk a little bit more about our data connector. So we’ll talk about it. It goes in a little more depth. Okay. In the meantime, let’s hopefully everyone responds to our poll here. So, you know, we can talk a little bit more about it depending upon everyone’s steps of this knowledge and really if they want to know more about this and why this is important to kind of the partner ecosystem overall.

Exactly. We can wait for some responses here. I mean, some important things. Hey, some important things. Hey, Surya, you know, just in general, API Mesh, App Builder, are those included with customer licenses? Are there extra costs here? You know, what is it that’s going on there? Right. So App Builder is our extensibility platform, includes API Mesh in it. Every cloud customer gets a certain amount of capacity available with their base license. They just need to talk to their account manager to turn it on. If you’re on-prem, you can still get it. However, there is a cost to it. If you’re a partner, you can actually request a sandbox for API Mesh or for App Builder, basically, and that will give you access to App Builder. So you can go to the solution partner portal and I’ll drop a link here in a moment. I just need to pull it up, but you can request access to App Builder and you’ll get a sandbox provision for you.

And then we do have, while we’re stalling a little bit for these answers to trickle in, we do have at least one sample app, right, that they can use. That would be the Amazon sales channel? OK. So there are a number of tutorials and sandboxes and sample apps, including one which is a fully built out sample app, which basically mirrors the original Amazon sales channel app. So that shows you UI extensibility, it shows you how to use events and all of that. I’ll drop a link in here for you to get access to all of that. That’s great.

So definitely looks like the majority of our.

Participants here, they don’t know, so we should probably spend at least five minutes talking about the App Builder integration and yeah, so. Let’s do that.

So. Oops. OK, so App Builder is our extensibility framework and it provides with it a number of tools that you need to extend or integrate ÃÛ¶¹ÊÓƵ solutions, including ÃÛ¶¹ÊÓƵ Commerce. So it’s unified in two different ways. First, it’s unified because you can use it to extend multiple ÃÛ¶¹ÊÓƵ products, not just ÃÛ¶¹ÊÓƵ Commerce. If you’re using App Builder, you can consume Creative Cloud API, Doc Cloud API. You can extend the AEM admin UI. You can work with ÃÛ¶¹ÊÓƵ experience platform and so on. And second, it’s unified because it provides you with everything you need. Now, you’re not forced to use everything that we provide, of course, but it provides you with API orchestration, provides you with event routing. So here up here I have, you know, how you would build event driven integrations and what that anytime. And I spoke about events a couple of times. So if you have events in ÃÛ¶¹ÊÓƵ Commerce Fire, they are routed through App Builder’s event pipeline. And there you can use a simple UI to determine what happens with that event. Does that go? Do we want to send it directly to a third party system that has a webhook? And, you know, without doing anything, just send the JSON data so events are basically, you know, JSON data so we can send them directly to a webhook sitting on a third party system. Or we can write a runtime action, which is really a serverless function. So you write a serverless function in App Builder that subscribes to an event. In this particular case, let’s talk about an order created event. So that order created event will go into that serverless function. You can transform that data if required, which will probably often be required because your third party system probably is expecting it in some format. So you transform that data and then send it there. And the third is we can send these events to Amazon EventBridge. And if you’re not familiar with Amazon EventBridge, that’s their no-code event management solution. So our events will, you can configure them to directly go into EventBridge by just providing your account information. And from there, you can consume those events in, I think, about 20 different services like Lambda, Step Functions and all of that on the AWS side. So it’s really a low-code way for you to orchestrate those events. So again, like our API and with our events, our goal is not to have those hard-coded, or I shouldn’t say hard-coded, those very rigid integrations point to point. We make our API available and events available to App Builder, and then App Builder decides how to orchestrate them using API Mesh or orchestrate the events using our IO events and determines what happens with those without you actually having deep knowledge of the product or with, when I say that, what I really mean is without you having to customize the ÃÛ¶¹ÊÓƵ Commerce product. So that’s why you don’t need that. Now that it’s a bad idea to have deep knowledge of the product, we just don’t, we just mean that you don’t need to customize the product at all to manage these events and to manage these API. And taking it a step further, what we’re doing is we’re providing you, and this is in beta right now, so I have a form. I’ll put that link in the chat as well. What we’re doing is we’re taking everything I spoke about, which is those events, those runtime actions, transform data, and we’re providing you with accelerators for them. So to start with, we’ll be working with six, or I should say five, object types, which are product, order, customer, stock, and shipment. And we think these are the most commonly used for integrations with order management systems and ERPs and so on. We’ll set up those events for you. We’ll set up those scripts to transform that data as well. And you will need to build out that last mile that your customer needs so that data and the actual transformation of the data and connection to the specific ERP, CRM, PIN, whatever that might be, and provide you with those best practices, the code accelerators and everything so that you can get started very, very fast. And the expectation is it should reduce 50 percent in development cost for you to build those integrations, which are critical and time-consuming for our customers. We ourselves will actually be shipping pre-built integrations with Dynamics and SAP S4HANA. That’s later in the year. However, the starter kit itself is in beta and there’s an interest form you can sign up for, and we’ll be onboarding partners and customers gradually. So it’s not open for everybody right up front. As you sign up, gradually we’ll start onboarding you onto the program so that you can start working with the starter kit and building out those integrations that you either are doing on a project basis or if you are interested in building a productized integration with any particular back office system, we’re happy to accept that back into our app store to provide you with the support you need. And the last part, and actually this is for Daniel, and he started talking about this and we didn’t quite cover it, is around using standards for those experienced data or visitor events and using that to provide that journey. So I’ll stop there because I’m a little out of my depth. Daniel’s the expert here. Daniel, do you want to cover this? That’s not a problem. That’s not a problem in the NSCANCS area. So really, when we talk about ÃÛ¶¹ÊÓƵ Commerce and really being able to send data and make sure that the data is consistently sent in a format that is readable by other ÃÛ¶¹ÊÓƵ products, what we’ve been able to do is we could call an extension called Data Connections. And Data Connections is really all about standardization and making it quick and easy to get a, I say get a head start in sending data or storefront data from any storefront that you want over to other ÃÛ¶¹ÊÓƵ products, whether it be into the profile with real-time CDP, whether it be into segmentation to build out segments in order to really capture those audiences and being able to then kind of utilize those audiences and marketing campaigns or really build out insights about those audiences or continue to change those audiences as they become more and more available via their segmentations. What we’ve done within this kind of this concept of there is really being able to take the data from the storefront, utilize the ÃÛ¶¹ÊÓƵ Client Data Layer for the listening from any type of implementation and then transforming those into a standard schema or what ÃÛ¶¹ÊÓƵ will call XDM and utilize the XDM and actually transform it into XDM for you.

What this does is instead of someone having to do this on their own, we give them that head start and the ability to utilize our pipeline and then in order to be able to send this data not only to other ÃÛ¶¹ÊÓƵ products and the Experience Cloud but also being able to send it to third-party services such as a business intelligence tool or maybe into a Facebook or into Meta in order to really be able to then do drive conversion. At the end of the day, as we all know, conversion is what we’re trying to do. We’re trying to make money here at the end of the day so we’re trying to get to a conversion as quickly and as possible as we can. And so really by utilizing kind of these standards and utilizing this data connection, we not only do storefront data but in a simplified way but we also can do kind of server-side data. And Siri, I’m going to just grab the screenshot real quick and share my screen really fast. Give me a quick second. When we talk about this, we’re talking really two types of extensions that we utilize in order to be able to do this. So the first one that we call and I’ve been talking about a lot is a data connection. And let’s see, data connection is all about sending data from commerce into whether it be the Experience platform or whether it be to the, excuse me, or whether it be to other ÃÛ¶¹ÊÓƵ products in itself. And when we talk about this, we’re not just talking about, let me get this into share so my computer’s going slow and I apologize. There we go. We’re not talking just about just the storefront and behavioral data and sending them to the edge and then to other ÃÛ¶¹ÊÓƵ products. We’re also talking about server-side data. And within this same extension, you’re able to send server-side data both in a real-time and in a batch format. Currently for back-office data, we heard Siri talk a little bit about the order statuses earlier and being able to send those order statuses. We can do the same thing here and being able to do when the order was placed, when the order was shipped, canceled, refunds, order created, order completed, and then being able to drive personalization based upon these style events that will really flow in the same way. So you can either send it directly into your real-time CDP or it will flow directly into ÃÛ¶¹ÊÓƵ Journey Optimizer so that you can send either personalized messages and really drive personalization one-to-one or utilize it within Customer Journey Analytics to build out insights based upon these. So having lifetime value of your customers or being able to measure other metrics that are really important to do this. We do this so that you can do this just by utilizing these two extensions and then being able to send this. But we’re not just keeping it so that you can just utilize what we’ve built. You can also add other custom attributes to these events that we’ve already built currently. But to keep it going and keep that data flowing back, I kind of talked about data going to these products, but you also can have data coming back and experience the commerce experience, whether it be in dynamic blocks or in related product rules or even in car price rules and being able to utilize those for car price. So if you send an email to a customer with a 20% discount, you want to make sure they receive that 20% discount seamlessly inside of commerce, inside of their software and their digital experience. So you can do this now in real time utilizing both of these extensions of the data connector and the audience activation extensions in order to be able to drive that and do that in real time coming back and give that seamless experience not only in commerce but in the marketing channels that you want to utilize outside of commerce itself. So really being able to do this quickly, being able to be able to completely control and customize these experiences, we’re here just to give you kind of the head start and help you deliver those, you know, that high return on investment, but really do it in a lower time to value at the end of the day for your customers in itself.

Yeah, that’s great. And I think one of the things I think this also handles like abandoned carts too, right? So if the orchestration through AGL can, that’s what I thought. So very powerful. Yeah, yeah. So I mean, abandoned cart is something that completely basically comes out of the box. And later on this year, we’ll be delivering what we call use case playbook specifically for commerce. And the first use cases that we’re going to be doing is re-engagement. So this is a one button kind of solution in which it does everything that I talked about, about implementing the web SDK, really being able to tag your page, but also being able to start the journey. And this is just like, same way that we have a starter kit for integrations. This is your starter kit for driving personalization and insights within ÃÛ¶¹ÊÓƵ itself. And just kind of look at it in that perspective. That’s fantastic, man. It sounds a little cliche and weird, but I am super psyched, man. This is the start of this new phase for ÃÛ¶¹ÊÓƵ and ÃÛ¶¹ÊÓƵ Commerce in particular, because obviously I like my ÃÛ¶¹ÊÓƵ Commerce. It’s just, it’s fascinating because we’re taking things and we’re still keeping speed and performance and upgradeability and stability. Everything is getting better and better, especially with the latency and the expectation between App Builder and Commerce. It’s so fast that it almost feels like it’s custom code sitting on your application. It’s not an external service that you’re using. So, I would, sorry, go ahead. No, no, no, go, go. I know we probably have maybe a couple of minutes for questions. That’s why I saw you. But I will say the one thing I would ask of all of you, look at if you are extending or implementing ÃÛ¶¹ÊÓƵ Commerce, using App Builder for that should be your primary way going forward versus the traditional, customize the core. I’ve dropped in two links. The first one is called the learning path. If you’re not familiar with ÃÛ¶¹ÊÓƵ Commerce, with App Builder, it has resources on what’s App Builder, what kind of use cases you can implement with it, sample code, sample tutorials with code that you can implement, and it also has instructions on how to get access to it. So, if you don’t have App Builder, if you’re a partner and don’t have App Builder today, it’s pretty simple. Just go into the solution partner portal. There is a link in there. You go in over there, request access to App Builder sandbox and you should get provisioned. Perfect. You stole my thunder. Oh, sorry. No, that’s fantastic. I think I was asking Chris, our moderator, he says that we’ve handled most of our questions. So, I think honestly, unless you guys have any closing remarks, I think we can wrap it up for the day.

Yeah, and I actually went ahead and just dropped a data connection on to our experience. We’re data connection and you can see all the overview guide of data connection and also audience activation both in that area. So, really if like, it’s serious said utilize App Builder to integrate for your third parties or other things or accessibility, utilize data connection in order to really start building your pipes between commerce and other ÃÛ¶¹ÊÓƵ experience platform products. Fantastic. And don’t forget about the services that we have for things like that. And don’t forget about the services that we have for things like catalog, payment, search, recommendations. Those are comprehensively featured and if you’re not aware of them, do take a look at those services. They’re included with commerce and for the most part. Absolutely.

Yeah. Thank you, Russell, Daniel, Surya. This was a fun session. I really appreciate the interaction, the content that you all shared. As Russell noted, I want to draw attention to the chat. A few moments ago, Amanda posted a link to our survey. I definitely encourage all the partners to click that. It’s a very brief survey, only five questions, two of which are just who you are, what your role is. But most importantly, as we noted at the top of this session, this is a new format. We want your feedback. Russell is going to be facilitating several additional sessions in the series. So we want your feedback. How can we improve them? What did you enjoy? What do we need to do differently in series two, three and four? As Surya noted, the Solution Partner Portal, the upcoming events are also advertised in there. We’ve got an exciting slate of events. As Russell noted, they’re not all required. We do hope that you register for each of them, but there is the intentional path of planning, building and maintaining the modern commerce implementation. And then that fourth event in the series where we deep dive on edge delivery services for ÃÛ¶¹ÊÓƵ Commerce storefronts. So we hope to see you at the subsequent events in this session. And just from the partner experience team, I want to express a thank you to all of our partners for the interaction you had in the chat, the polls. The response was fantastic. We look forward to diving into some of your answers and feedback shared on the survey. So I hope everyone has a great rest of your day. We look forward to seeing you actually next week on the series, next Wednesday, the four part series. Yeah. Beautiful. Thanks, everybody. All right.