[MUSIC] [Surya Lamech] Welcome to day two of Adobe Summit. For those of you who might have been here for pre-conference trainings, it's probably day three. So, to have you here at 8:00 a.m. in Las Vegas, speaking on behalf of both of us, we really appreciate you taking the time to be here bright and early.

I'm Surya Lamech. I'm a Product Marketing Manager with Adobe Commerce. With me is Ben from Nestle, and we will be hearing from him shortly. We're going to be talking today about building composable commerce applications with Adobe Commerce.

If you look at the digital commerce landscape today, really all commerce is digital commerce. Whether you look at traditionally what you consider digital, which is web and social, or even in store, at home using IOT devices, all of them today are digital channels. They are not discrete channels. A customer is not visiting one or the other channel. A buyer journey may span across all of those and they expect a connected journey. Meaning I may discover something on social, but buy it on the web. I may get support over the phone. I may get it delivered, through a third-party shipper, of course. Then I might have to return it in store.

Businesses need to provide a connected journey across all of those touch points.

In order to do that, businesses are essentially needing to stitch together multiple services to support all those different capabilities, whether that's managing your content, your commerce processes like your product catalog, transactions for adding to cart, checkout, and so on, your payment methods, things like shipping, digital assets, and search, and all of those services. There are a number of different services that you need to deliver those experiences. Those experiences need to be delivered across a number of different channels. Those could be things like I mentioned, in store, IOT devices, web, and so on. This approach of stitching together all of these services to build those commerce applications is what's commonly called composable commerce. However, as businesses start on that journey of stitching together those services they find that not all composable applications are the same. In the sense it's not so much about a particular service. or how many services make up your commerce application What matters is how those services interact together. You may end up with a system where the goal might have been agility and flexibility to start with, but as you build out those point-to-point integrations across all those different services, you find you need to incorporate third-party systems for compute, for storage, for integration, and so on. Managing that can become challenging. So, those complex integrations, changing one service and system might require you to refactor a number of different applications in order to make them work together. You might end up with siloed data across different services. So, every time a customer interacts with one service or another, that data becomes siloed, making it difficult for you to act on that data, and provide the journey that your customers require. And then there's the technical data that builds up over time, making these applications more and more difficult to manage, and more expensive.

Our approach at Adobe is to simplify how those applications are built. As I mentioned, it's not just about the underlying services, but how those services work together. The goal is to, number one, help our customers adopt and launch capabilities must faster. Those could be new features that you need to launch. It could be rolling out to new markets, new brands, and so on. Second is simplify how you share data across those systems, and that's a big part of what we do.

The third is lower the cost of integration. As you integrate your systems together, make the data available across them, how do you lower the cost to maintain those systems over time so that your developers spend more time innovating, and less time managing the system that they've already built.

How do we achieve these? Or what's our strategy to help you across those three goals? To start with, we provide flexibility through extensibility. If you have been working with us, and I know I've met a number of you who have been working with Adobe Commerce for years, or even Magento, before Adobe Commerce, you're probably thinking, well, Commerce, or Magento, was always very extensible. I could build whatever I wanted with it. The change in our approach has been rather than have you customize the product, provide you with these extension points that give you the same level of flexibility, but don't require you to customize the core product. The obvious benefit of that is if you don't customize the product, then you end up with a system that is easy to maintain over time. That includes things like API coverage. So, GraphQL and Rest API across all of our capabilities. All of our new development, all of the new services you hear us announcing, and you've probably heard about them in other sessions, they are all developed as API First services. The second is UI extensibility. What that means is you can customize or enhance the admin console very simply. You can build single page apps that run outside our system, and inject them into Adobe Commerce to build new pages, new merchant experiences, or even enhance existing pages within Commerce. For example, you might have auto grid, and you need to add a new column to it, a new action to it. You don't need to customize the product. Just simply build a single page, inject it in there securely. Third is Webhooks, which allows you to customize native process within Adobe Commerce. As an example, a customer adds a product to cart, we provide you with a hook that you can add on a service call to a third-party system to do an inventory check. Or a customer goes to the check-out page, there's a hook over there that you can use to call to a shipping service to get the shipping total. Webhooks helps you customize all of those processes. Finally, there's Events. Events help you build large-scale, resilient event-driven applications or integrations with third-party systems, like ERPs, order managements, etc. We provide over 700 events that cover pretty much anything that's happening within the Commerce system. For example, an order gets created in Adobe Commerce. That can trigger an event that notifies your fulfillment system. Or a customer updates their account information, we can trigger an event to notify your CRM about those updates.

Next is orchestration. Orchestration helps you be more agile in the platform. What I mean by agile is it allows you to modify different pieces of your application very easily without incurring technical debt. We do that through API Mesh, which is our API orchestration layer. That combines API from Adobe Commerce and other third-party systems into a unified graph. All those underlying services, they can be REST API, they can be GraphQL API or SOAP AI. However, we combine them, and provide a unified GraphQL response from that. That means you can apply this layer to existing applications, then your developers only have to work with GraphQL, and not have to understand and authentic all those underlying services with us. The primary benefit of this, aside from the fact that you can standardize your API, and decide the exact API you want to expose to your organization, is the agility it provides. Meaning you can replace a service that sits within your application with minimal impact to the rest of your ecosystem. Let's say that you currently get pricing from Adobe Commerce. You have your product detail page and it gets pricing that resides in Adobe Commerce. If you decide you want to replace pricing from a third-party service or a CPQ or something like that, you can easily plug that API into API Mesh and then stitch that API, or the response from that, into the Adobe Commerce API without customizing either Adobe Commerce, your third-party pricing engine, or even those store front applications that rely on the pricing. You do all of that in the Mesh layer. We provide the security, the extensibility, and everything over there. That means when you replace services, you don't have a lot of refactoring to do across other applications.

Next is choice.

Adobe provides a number of different services that help you build those composable commerce applications. Starting with core commerce, so your cart, catalog, check-out, payments, and all of that. There are also other services we provide, like Edge Delivery services for managing your experience layer. We provide Live Search and recommendations for intelligent merchandising. All of these services work natively together with Adobe Commerce. This means that you can choose when you want to adopt them, and when you choose to adopt them, the cost of implementing them is very low. You don't have to do any custom development to make use of, say, Live Search or Catalog service, and so on. They work together natively. You don't have to use all these services. Most of our customers probably have one, two, or three of these services that they have already invested in, or maybe they're planning on investing on something to meets their needs better. That's fine, because when you replace one of our services with a third-party service, we actually provide you with all of the tools and services you need to integrate them together. We simplify how you integrate not just how our services work together, but also how third-party services can be integrated into our application.

Finally — well, actually, there's two more slides here. So, not finally — semi-finally, we have data through standards. I mentioned one of the challenges that our customers face is when you have all these different services, you have a customer interacting with you in store, you have them interacting with you on the web, or multiple, or in the native app. Each of those points is somewhere you can collect data, get signals from your users about their intent, and provide them with a customized journey. That becomes difficult because you're capturing them in different formats and then you have to figure out how to get those across to different services. We provide you with a standards based data layer. This data layer can be deployed into a storefront of your choice. That could be an Adobe storefront, third-party storefront, native app, whatever that might be. You can deploy that data layer, which will then capture those experience events, or those user events. Things like a shopper adding something to cart, or visiting a page, or searching for something. All of those things are signals that are then captured and exchanged using a standards based data exchange mechanism, which is experienced data models. When you capture those events, and the data that goes with those events, we use that to enrich the customer profile. Then you can use those enriched customer profiles to segment those users, and then act on those segments. You can act on them within Adobe Commerce. So, bring that full circle back to Adobe Commerce and how you interact with your customers. Or you can act on it through other applications. For example, Adobe Journey Optimizer. So, if a user adds something to cart and abandons that cart, that's okay because those signals are sent back to Journey Optimizer, which you can use to then re-target those users.

The benefit of this is that you save a lot of time in deploying those data layers. You build them once. That integration is built once, and you can deploy it across all the different touch points that your shoppers interact with you on.

Finally, we provide you with a better developer experience. When you work across multiple platforms, a typical commerce system may have eight, 10, 12 different services that serve various purposes, ratings, reviews, content, catalog, and so on. What ends up happening is your developers have to work across multiple development tools, development frameworks, potentially manage logging, monitoring across all those different services, which makes it difficult to troubleshoot because there's so many different systems. With App Builder for Adobe Commerce, which is our extensibility framework, we provide you with a unified extensibility layer across Adobe solutions and third-party solutions. Whether it's managing your API orchestration, that I spoke about, event routing, single page app development, all of that can be done with the tools we provide you for not just our services, also your third-party services. We manage the provisioning and scaling of things like compute, scale, storage, CDN, authentication, authorization, logging, etc. We do all of that for you so your developers can focus just on building apps using a unified tool set, and not have to worry about all the underlying infrastructure that we are distributing for you globally. We are scaling for you and managing for you. That really improves your developer efficiency with not having to jump through hoops to get all of those other resources they need provisioned and then managed.

In a moment, Ben will talk to you about Nestle's journey with Adobe Commerce. But if you want to hear more about composable commerce and Adobe, or how our customers and partners are using our solutions, tomorrow we have Adobe Commerce Rockstar Showcase, where we'll have some of our most experienced developers highlight some of their innovations. You can join us there at 10:30 tomorrow. There's also the AWS booth at 471 in the Community Pavilion. You can hear from AWS how events from Adobe Commerce are natively available within Amazon EventBridge so that they can be routed easily in a local environment to over 20 different services, including Lamda. With that, I'll have Ben Robie come on stage. He will talk to you about some of the really cool stuff that Nestle Purina is doing with App Builder and Adobe Commerce. Thank you.

[Ben Robie] Good morning, everybody. My name is Ben Robie. I'm here today to talk to you about how Purina is using Adobe Commerce to bring a bunch of different consumer experiences to life, in a bunch of different ways. My background is in software development as an old-school Magento developer, then into architecture, and now I lead the D2C technical team at the greatest pet care company in the world, which is Nestle Purina. Nestle Purina produces a bunch of different pet care products, wet and dry dog food, cat food, supplements, treats, cat litter. And we're getting into some cool products like IOT devices and other smart devices, that we'll talk about a little in this session. First, everyone in the room, how many of you either use Adobe Commerce as your platform, or you support Adobe Commerce? A show of hands. Okay. About 80 percent of you. Regardless of whether or not you use Adobe Commerce, how many of you either support or use a headless implementation for your e-commerce platform? Okay. How many of you don't know whether or not you use a headless? All right. Lastly, how many of you are here because either you or your leadership is asking you to build a more composable platform? Okay. About 50 percent of you. All right. Great. The two takeaways I'm hoping you get from this session are, one, why Purina chose Adobe Commerce as our platform for growth moving forward. And secondarily, how we're using it to bring all of these customer experiences to life in different ways with different architectural options and implementations. Throughout the presentation, you'll see these light bulbs pop up. One, for me to remember to talk about. Two, lessons learned as we moved through the journey of selecting Adobe Commerce and building out this new architecture. Purina goes to market in a lot of different ways, B2B, B2C, B2B2C, but specifically with our own e-commerce sites that we manage ourselves. We use two different e-commerce platforms. We use Adobe Commerce. We have about five sites on Adobe Commerce right now. I think we're looking to launch four new ones this year. We have three sites on Shopify.

A little background on the Shopify piece, about three years ago, we had decided that we were going to use Shopify as our way to launch test and learns, and pilots, and ways to spin up sites quickly. Then as they reached scale, or become successful, we would then migrate them into the Adobe Commerce platform. That was our decision at the time. We've actually found that to be kind of a bad decision. [speaker and audience laughter] It's not because Shopify isn't good at standing up these experiences quickly. The problem is as they do reach scale, we're finding we're left with two difficult situations. One, we now need to actually do a platform migration for a site, which takes cost, time, all that. Secondarily, as it scales, contrary to maybe some beliefs, there is infrastructure that's needed to support Shopify if you have custom apps. So, we're needing to scale that infrastructure while we're thinking about platform migration, and things like that.

Moving forward, and I'll talk about it soon, we built a way to spin up sites quickly on Adobe Commerce so we're not needing to go through the pain later on.

Like a lot of you probably, during the pandemic your D2C business grew.

Even into late 2022, at Purina, we were still seeing that growth. So, we decided to do an evaluation to make sure that we have a platform that can not only handle our growth in the businesses that we currently have, but also that we can extend into different business endeavors, or customer experiences that our business owners want to bring to market.

We started by building the criteria. The first thing we did was create a huge spreadsheet of all the feature and functionalities that we needed, our functional specifications. This included things we are currently doing on Adobe Commerce and Shopify, and what the business wanted over the next five years or so. We that by must have, nice to have, all that stuff. Then we moved into non-functional specifications, which, for me as a technical leader, is probably even more important than some of our functional specifications. Things like security and privacy, which are paramount to think about, and really important at Nestle Purina. Things like cost of the licenses, support of the vendor. Can the platform be customized? How is it customized? How difficult is it? How many developers there are globally? How easy is it to spin them up? How many plug-ins, or extensions, or whatever the platform called that are pre-packaged pieces of functionality that you can purchase and add on? Lastly, the non-functional spec, we separated it because of its importance. What are the different architectural options that we can deploy to accomplish our needs? Is the platform deployed as monolith, with a front-end and back-end, or a part of the same technology and every time you change the front-end, you need to deploy the back-end with it? Does it have a suite of APIs that we can enable headless with? Or can we build a composable architecture? At Purina, there's a lot of different definitions for composability. But the way we think of it is we have the core e-commerce platform, and if we want to add functionality to that platform, do we have to change the core code? Or can we take existing services or create new services and stitch them together to bring that functionality, but lessen the complexity on upgrades, and things like that.

There's a lessons learned here.

As we were looking into whether we wanted a composable platform, there is complexity that comes with it. As Surya had the slide earlier with all of the different lines connecting. You really have to make sure that what you want to do is worth the cost of composability. Then we moved on to evaluating platforms.

We actually evaluated four different platforms — Adobe Commerce, a cloud SaaS platform that's very popular, and a platform that's only APIs, so, a complete micro service architecture, with no front-end. We also evaluated a German PHP based platform that boasted its micro service architecture.

That didn't really pan out.

We didn't choose to evaluate Shopify because we knew it wasn't a platform that we were going to go with.

The way we did it was — and I'll pull this up here before I start — we had our D2C solutions architect lead an evaluation internally. We talked to each one of the vendors. We looked through the documentation, We put that up against all of our functional specifications. We did proof of concepts to make sure that the vendors were telling the truth, and maybe not fibbing a little bit in their marketing material, and stuff like that. We talked to solutions architects, technical architects, customers of the platform to make sure they were satisfied, and understand the true cost of ownership. We were able to lay all that over our functional and non-functional specs grading system. At the same time, which I think is the most important part of this evaluation, we also hired a partner that had experience with all four of these platforms. They did the same thing in their lane. They used their experience to evaluate our feature and functionality set. We were able to put those two together find deviations of where we thought one thing, and they thought another, and dive deeper to get to the real truth of what the platforms offered. We were able to move forward with 100 percent confidence, and not thinking did we miss something, or not being able to quite trust the partner. We were able to move forward with the decision, which, of course, was Adobe Commerce, or I wouldn't be here talking in this session today. [audience laughter] But the real reason that we chose Adobe Commerce was not really because of the features and functionality that they offer. A lot of the platforms that we evaluated probably could have done the job, mostly because a lot of our D2C, our e-commerce experiences are B2C, not B2B. I think if we were evaluating the B2B piece, Adobe Commerce would have won out on the feature functionality. But really the reason that Adobe Commerce stood out above the rest was the different options that we could use in our architecture to go to market to accomplish what the business wants. Our technical team at Purina, we really value standardization. We understand that standardizing on software lessens complexity, it lessens risk, lowers cost. We also firmly believe that one way of building an architecture does not necessarily allow us to satisfy what the business wants. Different business needs might require different ways of implementing a solution. With Adobe Commerce, it allowed us to do things like spinning up a site really quickly. We use Adobe Commerce templated inheritance structure for sites. We use Hoover as our front-end. We're able to spin up new sites, within six to eight weeks, if it wasn't for all of our back-end stuff that takes forever to spin up.

We can also go deep and build deep customizations. Things like connecting our commerce platform to veterinary clinics or shelters. Or really caring a little too much about the consistency of your dog's poop, and capturing that. These customizations that are very specific to Purina, we can customize deeply. If we wanted to bring D2C, or bring commerce to our non-commerce properties, which I'll get to more in a couple of minutes, we can use things like API Mesh to expose all of the Adobe Commerce APIs.

The benefit for us, by using API Mesh we can have one central point for all of our digital properties to connect to, to use our D2C technical team's commerce services, and also really for protecting backwards compatibility. When we make incompatible changes on the commerce side, or we're switching services behind the scenes, we can use API Mesh and the API Mesh configuration to allow all of our service consumers on the front-end to not have to change anything, which was really important to us.

As we were doing the evaluation, a lesson learned here is that as you're doing the evaluation, the platforms really can never do everything that you want them to do. It's really important to set the expectation with the business that either they have to think a little bit differently, or you have to be willing to make customizations and support those long-term. Everybody probably knows that, but it's important to lay that groundwork early on.

Purina's composable platform consists of a lot of different services. At Purina we don't want commerce to be at the center of the universe. We have a lot of different ways that we can bring value to our consumers, and we want the interaction for that value to be at the center. Sometimes it's commerce, and sometimes it's not. We have different services internally, like our single sign-on and universal profile that can expand across all of our different sites, whether they're commerce or not. Pet profiles, so if you add a pet on one, you can see it on the other. We have recommendation engines that aren't the simple you bought Product A, so we're going to recommend Product B. We take in attributes about your pet, whether you're entering them, or potentially from smart devices, and we can make smart recommendations to increase the well-being of your pet. We have loyalty services, product data services to ensure we have consistent product data across all of our sites. Last, but not least, we have the commerce service.

It's our goal in D2C to provide a commerce experience where it brings value to our consumer. That could be in many different places. We have a lot of different digital properties. Some of them are listed here. We have native mobile apps, like the Petivity mobile app, which I'll dive into. Petivity is our IOT smart device brand where we can track activity about your pet and bring insights to you that are valuable on a mobile app. We have the MyPurina app. The MyPurina app is the one-stop place where you can manage your loyalty, you can get feeding recommendations. You can do online training. We have a bunch of different partners that are bringing experiences into the app.

A final app, called Cat Fishing, where a cat tries to use their paws to get fish that swim across the screen. We have purina.com, which is our flagship .com site. You can learn anything about our products there. You can get feeding guides. We have petfinder.com, which is where you can go to figure out which new cat or dog you would like to adopt. We have a ton of different partner sites that want to sell our products. We have IOT Devices, like FoodFinity, which can measure the volume of your container, and reorder for you without you having to do anything. Then we have a whole bunch of Adobe Commerce stand-alone sites. We had to think, where in all of this, and more, can we bring value? We settled on four different use cases. One, is we think that we could bring value by adding a shopping experience inside of our Petivity app which makes helpful recommendations based on the activity of your pet. We also have a micro biome analysis kit, where you can send in samples of your cat or dog's poop, and we can analyze it and give recommendations based off of their micro biome. We figured we'd allow them to check out, right in the app, once we've made that recommendation. Secondly, on purina.com, as you're discovering new products and you think this is the one I want to use for my pet, why not allow you to buy from your favorite retailer, or buy directly from us right there in the experience. Lastly, on the MyPurina app, there's two different experiences that we want to bring to life. One, when you're on the MyPurina app and you're asking what food should I feed my dog or cat, and you're entering all this information. we say you should feed them x. Why not allow you to buy right there from your favorite retailer or check out in the app experience. Lastly, as you're looking at or managing your loyalty points, why not allow you to use those loyalty points, and check out right in the experience. We've chosen the platform Adobe Commerce. We have all these business cases that we want to bring to life. The next step is for us to enable an enterprise-wide commerce service.

We had to define what our service was going to be. We named it Purina Commerce Services. What these services are is almost as important as what they're not, right? Because Adobe Commerce offers hundreds, if not a thousand different APIs across their Adobe Commerce platform, and we knew that we did not want to support all those. We only wanted to support a specific subset to bring the experiences that we needed to bring to life. So, we chose product APIS, customer APIs, cart, check out, some stuff about order history, and our subscription auto-ship APIs that we built.

Lastly, we knew we wanted to integrate our single sign-on service because most of our digital properties have single sign-on. We didn't want you to jump into the e-commerce experience, and then have to re-register, or check out as a guest, where we lose who you are. We knew we needed to integrate our own enterprise services there. Some lessons learned here. Again, focusing on the things that are really critical and deciding what's not important, was just as important as knowing what we needed. Also, we decided as a team that we wanted to provide a service to the rest of our organization that was as good as the ones that we wanted to use as a technology team. We wanted to provide good documentation. The technical people in the room have all experienced trying to implement APIs with bad documentation, or testing environments that weren't quite the same as production, pre-production or staging. We wanted to make sure as we were building out this service for the organization, that we were providing a good quality environment. After defining what we wanted the service to be, we needed to build our team. We pulled team members from three different buckets. First, from Purina itself. We have a Technical Product Lead who is responsible for the roadmap of this service. They are responsible for integrating all of our service consumers to Purina Commerce Services. We have a Technical Team Lead who is responsible for the actual technical work being done, implementing Mesh, making sure CICD works, integrating it to Commerce. Then our partner, Merkle, who has been supporting us building out our Adobe Commerce sites for over 10 years now. They provide us with extra commerce expertise around architecture, extra developers, business analysis, and quality assurance. Then lastly from Adobe. Adobe was really critical for us standing this up. We didn't have any developers, or anything like that, but giving us advice on how we bring SSO into this whole mix, how we can better deploy to Mesh in the way that we wanted to use Mesh, and especially around security. With Nestle Purina, security is a big deal. We have to go through a whole compliance process. Adobe was great in providing us all evidence we needed that it was secure. A lesson learned here is defining the team up front is really important because supporting a service based architecture is really different than supporting stand alone e-commerce sites. You have to think through that. Secondly, an important lesson here was that many of us probably use Agile or Scrum, or some way to go through sprints, and work out our deployments. And there's a product owner there who's deciding what the roadmap is. It's just as important to have a technical product owner on the services side that's responsible for the roadmap. Lastly, lean on your partners if you have questions. There was a lot of times we asked the partners, and they might not have known the answer, whether it was Adobe or Merkle, but their vast experience allows them to go and find the answer, which is really critical for us. The next step was to build the proof of concept. We had the team. We know what service we want, but we needed to make sure that what we were intending to do was doable. So, we went through this process of making sure CICD was able to work, that we were able to deploy our Mesh configurations and things in the same way we were deploying our application, making sure that the integration from Mesh to Adobe Commerce really was fast and easy to do. We looked into how are we going to report on this? We knew that we wanted to report who is using the APIs, which APIs were they using, what was the speed of those APIs, and we needed a dashboard to see all that to be able to make decisions. Security and compliance, I already talked about that. Lastly, we needed to make sure our SSO service could actually be integrated into this whole architecture. What we found out, that is obvious, probably, to most of you, but there's a cost to cross-team alignment.

Managing a composable architecture is not always about the technology. It's making sure that every team that's responsible for all of the different services are aligned, right? As we're building out this proof of concept, we had to make sure that the SSO team was available, that they're planning this in their roadmap, and there's a cost to that.

It stretches timelines a little bit, and you have to be aware of that.

So, we went through the proof of concept, and we determined that this was viable. Then we started to build out the actual production service. We decided we were going to use the Adobe Commerce instance that we were using for all of our stand-alone sites. We use one instance of Adobe Commerce. That was going to be the backing of this service as well. The reason is because we wanted to reuse all of the feature functionality, the integrations, the downstream processes to our financial and fulfilments systems. That was going to be the first decision. We built out a new environment. We currently have integration, pre-production, and production. We also built a new environment called Production Sandbox. It's a production level environment that had the production code on it. We were sure that as all of our service consumers were using it, that it was going to be stable and production ready code. The last thing that we discovered through our proof of concept as we were starting to implement this, is that payments can be hard. We were intending for all of our front-ends to be building the payment capture mechanism. Many of you know, probably, that credit card capture happens on the front-end, and that front-end is responsible for being PCI compliant, and transacting those credit cards or sending that credit card data directly to the payment gateway. So, that was our stance. You guys are responsible for that. You can share our payment gateway credentials, so that once we get the order we can capture it. But we quickly found out that the team that was responsible for the Petivity mobile app, they didn't have commerce experience. They didn't have PCI experience, right? All of a sudden, we were saying, the most important, critical part of this transaction, you have to learn and be responsible for. And not only that, but we were going to do that on all of the different front-ends, and we realized this is going to be an issue. So, not only are we providing this suite of services, we're also providing one very small front-end component which is really crucial We're providing the credit card number expiration date, and things like that, so that it can be injected via iFrame or WebView into the experience. All of the subject matter expertise and the risk is handled by our D2C technical team, rather than having different agencies, and different teams be responsible for knowing that. That was a big takeaway for us. Again, the lesson learned here is that there is a lot more to think about in a service than just its functionality. How is it going to be used? How is it actually going to be implemented? Also, testing a service is very different than testing a stand-alone website. The QA that goes into it now has to do QA automation with Postman, or manual testing with Postman against APIs, rather than the team that has acceptance criteria, and experts in browsers and clicking through a scenario. Petivity is our first implementation that we're working through. I'll give you a little about what value Petivity adds right now. First up, acquire a Litterbox Monitor. This goes underneath your litterbox. As your cat uses the litterbox over time, you can track the cat's weight over time, you can track its activity to determine whether it has a potential urinary tract infection, or it's losing weight because it's not eating. We can bring insights and value to you that you might not have known otherwise. We take all that data, we send it to the cloud, our cloud, where all the meowgic happens. We take that data and create insights that we give to you, and now you have the value from this proposition. To bring D2C into the mix we decided that we have our app, we have all this information, we're going to use our own recommendation engine that will bring a recommendation inside the app. We would then be able to connect to our Commerce environment using API Mesh App Builder to allow you to get the pricing, add to cart, check out, all within the app experience.

Right now, our integration to our SSO service is directly with Commerce. The next step is twofold. It's to actually integrate using App Builder to our SSO service so that we can move that functionality outside of Commerce, and we can do all the validation, and everything we need to do way upfront to know that the customer is already validated before the service is called. Also, mesh in our inventory service which we have 5to show inventory availability across all of our distribution centers. That way, as you're looking at a product detail page, you can understand if you, as a consumer that is shipping to this specific address, has stock quantity in your distribution center with one call through Mesh. Some of the things we learned here that are really critical to our journey, is just because you make it easy to do D2C, or to sell on a property, it doesn't make it easy to do D2C there. Things that we have to thing about are we want to sell product on Petivity. but is that product available in our distribution centers? We have to think about our customer service, right? Now, our customer service team needs to understand how are people ordering. Before, it was just on these websites. Now they have to become experts on all of these apps, on all of these different other experiences on purina.com, and things like that. So, doing D2C, there's a lot to think about there.

One of those things to think about is that putting commerce into a non-commerce experience takes a lot of intentionality because we don't want to diminish the value that already existed there. We want to bring D2C there and blend it in to what was already happening. Also, as we add D2C experiences across all of our properties, we want there to be a consistency across the entire Purina brand. And there is a real reliance on other teams. The D2C technical team, we've been doing Adobe Commerce work for many years, and we know how to put the customer at the center of everything we're doing, but now we have to rely on all of these other external teams inside of Purina to make sure that same mindset remains there as we move forward. In summary, Purina chose Adobe Commerce because of the options that it had for architectural go to markets. Lastly, we're using Adobe Mesh and Commerce to build out an enterprise service to be able to bring D2C to all of our different platforms and enable what the business wants us to enable.

If you guys want to reach out and ask any questions, our information's right here. Nnamdi, who is sitting in the back over there, and Tia, who is over there, are happy to talk to you about how we've implemented these things from a technical perspective, or from a product lens.

[applause] [Surya Lamech] Thanks, Ben. [applause] [music]