[Music] [Jamie Brighton] Okay, 8 o'clock. Wow. Thank you, everybody, for joining us. Appreciate you taking the time to come and listen to the session this morning. We have got a great session for you. We're going to go into mastering the CMS Maze, how adobe.com has standardized on Experience Manager. And my name is Jamie Brighton. I'm part of the global product marketing team. I'm joined today by Chris and Tory. And I'm going to let them introduce themselves as they come up and do their thing on stage. But I'm going to talk a little bit about product. Chris is going to talk about the implementation and make it kind of real. And then Tory is going to talk about the results that we've seen with the adoption of this technology on the various parts of adobe.com. I'd like to start with a few questions. So quick show of hands, if that's okay. Hopefully, nothing too taxing for 8 AM on Wednesday. Who in the room has a site built on Experience Manager sites already? Okay. Pretty good. You currently use more than one CMS for your digital experience.

How about more than two? Few hands. Three, four? Have you heard of Edge Delivery Services? You're not allowed to put your hand up.

You're biasing the sample. Okay. Of those of you who have heard about Edge Delivery Services, do you associate it with things like blogs and simple sites? It's a few hands. Okay. And what about do you think Edge Delivery Services means building sites in Word or Google Docs? Few hands. Okay.

You've fallen into my trap, those of you who kept your hands up all the way to the end. The point of this session, as well as talking about how there are many benefits for standardizing the technology that you use when it comes to content management. I also want to use it as an opportunity using the adobe.com example to try and break that connection between, in your minds between simplistic things like blogs and running sites in Word. Although Chris is going to talk a lot about how we do that and the power of managing documents and managing site experiences using things like Office documents and Google Docs. And just show you how this technology is incredibly powerful and incredibly performance efficient and going to enable you to really realize incredible benefits for your site visitors. Start with a question. How do you solve-- Sorry, I've already started with a question. But how do you solve a maze? I have a two-year-old and a four-year-old. And as I watch them, they kind of blindly stumble around in the maze banging into each of the kind of intersections. And, effectively, they end up kind of completing the maze by drawing over every, element of it. That is obviously incredibly inefficient. There are lots of ways to use algorithms and things to solve this kind of conundrum of a maze. But actually, one of the simplest ways is called the right-hand theory. And if you put your right hand on the wall as you enter the maze, if the maze walls are all connected, you will eventually find the solution and find the answer to the maze.

And if the walls are all connected, you can effectively condense the maze into a circle. And then it's basically just walking around the edge of the circle. In a very simplistic way, we want to show you how standardizing on, standardizing your CMS technologies is going to enable you to use Adobe to help you solve that challenge, to move beyond this kind of mess of technologies that can feel like you're in the middle of a maze, unable to get out there and serve your customers with the best experience. And it's important because we find through the surveys and research that we do that over 50% of our own customers are using multiple, different stacks, multiple different technologies to address their customer experience needs. And why the line that we're showing here is important is that-- I mean, you can almost choose your number. But certainly, in the research we've done recently, 70% of the end consumer, the end customer expects a seamless experience, expects to be able to engage with the brand in an intelligent joined up way across all of the different channels that you're trying to drive. And it's very difficult to do that if you don't have a standardized approach to your content. What are some of the advantages? By having a single platform that enables your authors, your content teams to manage content in a variety of different ways that make sense for them in their use cases. You can reuse content across brands and regions. And I know from some of the conversations I had already with people in the room this week that that is a key challenge. How do you localize content? How do you globalize it for various different markets that your brands are active in? And how do you keep that consistent experience across those different teams? You can use a modular approach to content in a centralized way to make sure that the offers that you're building, that your teams are building are represented correctly on all of the different channels and different sites that you have. From a practical and a regulatory perspective, you can make sure that key messages, things like your privacy policy, user manuals, brand logos, legal disclaimers, etcetera, are consistent across the different touchpoints that you have which is pretty critical. And finally, you can reuse and tailor content in various different variations to make sure that you're testing and finding the optimal experience for customers across different channels in different regions. So standardizing, if we come back to that kind of linear path. Standardizing on a single platform enables us to scale the content that we're producing and to deliver it across different touchpoints. But it has a lot of other benefits as well, which you're going to hear from my colleagues from the adobe.com team. You can get to market much more rapidly. You can do things like experiment and personalize built into the interface that your authors are comfortable in and are using on a regular basis. And critically you can then analyze and understand the impact of what you're doing across those different channels. So that sets the scene. We're talking about this idea of standardization, and all of these great benefits that we see on the slide here. So I'm going to welcome Chris to the stage to talk specifically about this at adobe.com.

[Chris Millar] All right. Thanks, Jamie.

Sorry. I got more questions for 8 o'clock. So here, who here is from marketing? Gosh, we're outnumbered. So who here is from engineering? Okay. So my name is Chris Millar. I'm the senior engineering manager of adobe.com, primarily responsible for the platform, the underlying platform that all of our marketing sites sit on.

We got a few more questions. Was anyone here for our 2019 discussion on Dexter? Tad? Okay. Great. Great. And it's important to frame it kind of like what has happened in the last five years since we gave that talk. Dexter, if you're not familiar, was our AEM sites implementation.

And then Jamie kind of touched on this a little bit, but it's obviously the elephant in the room even for us, but who all and I didn't turn around, but who all uses more than one CMS for their website? Right? Right tool for the right job, of course.

And the reason why I bring this up is because in 2019, we had a blend of on prem cloud service. We even had Wordpress. Blog was, of course, sitting on it, and then we had some homegrown for Adobe Stock, Experience League, Adobe Express. They're all homegrown. We have the world's best CMS at Adobe, and we had some homegrown stuff. I won't bury the lead. This is where we're at today. Experience League, of course, just launched using Universal Editor and Edge Delivery Services. What's kind of-- I'll do a few shout outs and a few callouts, but Adobe Stock is not even really in our org. They just kind of saw what we were doing with Edge Delivery and said, hey, we'd like to use the same tech that adobe.com uses. So we partnered with them. Firefly was in the same example. Some of the marketing parts of Firefly actually live on the same exact stack. And, of course, you can see everything that's document based and then Experience League decided to use Universal Editor and that's working really great for them. And this all started with a blog. The whole history of sort of, like, Edge Delivery. What basically happened was we were in a meeting with our CTO in 2019, and it was like, yeah, this stuff you're doing on the AEM sites is great, but why does the blog always go down? And, it was like, well, we're working on that. We're going to move it to the component-based stuff you just saw in AEM sites and not really feeling like the component, content model was really good for long form content of blog, kind of like, okay. And then a few weeks or months later, my friend David comes along to my desk and says, hey, that, research project Helix, we're now converting Google Docs into a site. And I said, you could get me out of a real bind if you could convert this to SharePoint and Word. And so that's how it all started. So basically, this is kind of the timeline is, we started with a traditional AEM sites in 2019, blocked out Adobe. We migrated that in 2020 during the pandemic. Adobe Express was in 2021. So what was really interesting about that is like a lot of you, there was this perception even back then that it was like, yeah, that's long form content, that's easy. That's blog stuff. And with Adobe Express, it really proved that you could have these, like, experiences that were really rich and of the gray that we typically ship on adobe.com. Adobe.com reviews, we have this PDF converter online and what you do is you can say, I want to convert this PowerPoint to PDF, or I want to convert this Word file to PDF, and we needed a way to capture reviews. And so we used Edge Delivery Services in 2021 to capture those reviews and I believe it was the first use of headless, Edge Delivery Services in a headless context. And then we really put our foot to the gas pedal. We kind of, we did all these sites, and we realized the kind of productivity gains that the Express team was getting, and the blog team was getting, everyone just living in the context of where they want. We didn't have to train anyone on take your Word document and then convert it to components. It was like, just use your document. So we did business.adobe.com, Tory's site, stock.adobe.com. Again, completely separate org, but they're using our technologies, and we even partnered with an internal intranet team. So it's like we've been able to span the gamut, and then and so that's fully locked down, of course. And then 2023, it was like, okay, we thought we were putting our foot on the gas pedal in 2022. Let's go 2023. Our homepage, our logged-out homepage is on, of course, Edge Delivery Services. We started our creative cloud migration, document cloud migration, and now in 2024, Experience League went live and then we're working on, gathering requirements for our HelpX. And in fact, some of our HelpX, internal HelpX content is actually already on Edge Delivery. So the question is how do we all do this? I mean, very, very diverse array of use cases, especially stock, which is primarily, sort of a headless use case. So the first thing we did is, like always, we started with the content. So if you're not familiar, Edge Delivery Services has an importer. So it will scan your existing site and it will convert it into your documents for you. And so we use this. Our first pilot was our customer stories on business.adobe.com, scanned our site, and out popped, like 500ish documents. And what I would say about this is this is fantastic if you have a lot of similar pages. If you have very bespoke pages, you may want to-- It may be faster just to look at the document, copy the text, throw it in Word because it's so easy. And as we started getting in, we started getting our hands on the content and, again, these, like, sort of, like, big kid contexts, we started to notice all the velocity that we were gaining on the developer side, on the engineering side. So things that we would catch kind of after the fact in production, we actually moved along much faster in the process. You can see our Jira on the left. So things that we would do after, I got to push it up to a server and then you can go check it out and all these things. Are you on VPN? Well, with Edge Delivery, you can just send them a branch. You just, you get their, they get their own personalized sort of domain that they can go check things out. So, doing UAT reviews and content reviews with our authors. Hey, do you-- Here's how we think we should structure this block for this carousel or this marquee hero. Do you like this? And accessibility review. Again, do we push it up to a server and we wait for approvals and then we catch it at the very end? No, let's throw it all into Jira. SEO, same thing. Hey, SEO, here's your URL. Go take a look. Analytics, is the data layer firing the way you expect? And then finally, code review. So you can do all those reviews much earlier in the lifecycle because everybody gets their own custom domains for that particular feature. And so you have great isolation. And then also with this sort of added capacity, we were able to invest in a lot of checks in the code review process as well. So you can see we've got end to end testing, we've got vulnerability testing, we've got license agreements, unit tests, linting to make sure everybody's writing code the same way because you have to onboard new engineers, and much more. And of course, the lighthouse check which we'll get into in the performance section.

But ultimately this is what it comes down to is getting your ideas out the door faster. And I love real world examples so I'm going to provide a couple. So, someone on, Tory's team named Porter, he said, I have this idea. So this was May 26, 2022. I want to link to competitors, and we thought we were like, why would you ever want to link to competitors? And it turns out if you want to make a blog post or some content about top 10 ecommerce platforms in the world, well, it's obviously Adobe Commerce, but you have to link to those competitors, but you don't want them to have the SEO indexing. So you can actually see 48 comments because we were all kind of like, what? Why would you want to do this? So we went from like, not even knowing what this was a thing that people would want, to the PR merging the next day. And of course, we solved it with a spreadsheet, right? This whole section is probably the subtext of this. It's amazing what you can solve with spreadsheets and documents. So here we just have what are the domains that you don't want to index for SEO reasons. We don't want to give them SEO credit. No follow, no opener my SEO friends probably know what all this means and open in a blank window.

And then on the content velocity side. Again, have any of you seen the holiday shopping report aside from my adobe.conference.

Again, what do we do? Do we write a custom CSV importer and serve lets and all that? And when the analysts are giving us their Excel files. And I was like, all right, we're going to, we literally take your Excel file, and it goes into SharePoint. In fact, it's already in SharePoint, and so we're able to build out these very rich experiences. The analysts get to use the tools they're familiar with, and we have to do a lot less coding all through the power of Edge Delivery Services. I'm not a salesperson. I just really like Edge Delivery Services.

And then the other one, this is another really fun story. With experimentation, if you've used like a traditional Target implementation, it's like, I'm going to go write some content in Target because I have some sort of test I want to run, going to write some content in Target or maybe I'm going to push an experience fragment up into AEM, and then I'm going to write some custom code in Target. Well, we put all of that in the CMS. And what's great about that is we actually have a testing and optimization engineer. Her name's Vivian. She's traditionally worked in Target, and now she's just part of the team. She's completely embedded all of the testing and everything that her team works on is right in our project. So what's great about this is that when we do have that challenger that wins, we just flight it out. You swap where the fragment is, and you're off to the races. And again, now we have this sort of much more cross functional engineering team member that we didn't have before.

And then localization. We knew that going into these larger sites, localization was going to be the biggest unknown, and we had some ideas of how we thought we could solve it. Do we have fragments. And with adobe.com, it is very high touch. I know there's, like, lots of AI tools that will maybe, translate your document on the fly that are probably not real great for performance. But the other thing is like we're still very pro human in the adobe.com world, and so it is very high touch. So how do we do this? Again, this was probably the biggest challenge. To level set a little bit, 40 languages, 80 plus locales. It's fully automated, or we have our regional authors that are actually in region. It's a blend of machine translate.

You can hear me? - [Man] Yeah. - Okay. I'll keep talking. I'm loud anyways.

So structured and unstructured. So documents and spreadsheets.

And when I said high touch, this is sort of the approach, and big shock to those [inaudible]. They're spreadsheets, right? So to get that, we'll work out now few languages. You say what projects you want and who want this return process.

- All right. - [Man] Thank you. Thank you. All right. So this is actually we did this for Summit. This is actually a real Summit project right here. So big shout out to Ricky's team who worked on this. So here's all their URLs because what's the handoff, right? It's an Excel file, right? Here's the URLs I want to, and here's the Jira. Do we go convert it into some custom thing and have to manage all of that? No, just start with the Excel file. Excel isn't great for everything. So we do have a localization dashboard to get status on things, set actually kick projects off. So you visit the localization dashboard. You can kind of see an exploded view here. So if I want to see, what's the status? Have I have published this page? Have I previewed this page? Can I get to this page? We have Langstore copies. I'll try to spare you that some of the localization notary. And then, of course, you send this off to the loc service. We have an internal loc service. Vendors will translate those documents. We didn't have to change this service at all. All the pages come back, and they say they're ready to roll out into their region. So, again, we'll localize, let's say, German, but German needs to go to Austria, it needs to go to Switzerland, it needs to go to Germany. So those will roll out into the locales. And then in region authors get to check the new content, and this is the sort of missing link. So who here uses MSM? Anyone? Okay.

So we needed to solve the MSM, right? Our in-region authors, how do we do this inheritance locking, inheritance breaking? And so what we've done is, we've used the native tools, right? Who here has used track changes in Word? So you are all now localization content experts because what happens is you get notified of the content changes. Hey, your Langstore has updated this content. Do you want to accept it or reject it? And it's just native. So again, if you know how to use Word, you can do this, and you say, yeah. The difference with MSM is if you if you break a lock, that's a snapshot in time. You'll never see the new content ever again. Here you sort of get that visibility, so it's sort of like win-win for us.

And then let's talk another one that's near and dear to me is performance.

So we primarily standardize on two metrics, so Core Web Vitals and Lighthouse. Core Web Vitals is going to be used for search rankings. So if you and your competitor have the same content but your site is faster, you're going to rank higher. It's averaged over 28 days, and it's real-world data. So what's nice about this is like if your visitors are primarily on fast connections, you may have better Core Web Vitals than maybe what Lighthouse may imply, but it's not actionable, right? So Core Web Vitals might say, hey, your largest contentful paint is really slow, but it won't tell you why, whereas Lighthouse will actually tell you why. Here's the things that you should probably do to fix your largest contentful paint or what we call LCP. It is synthetic data on the Lighthouse side, so it's very tactical, but it is synthetic. It's simulating a 4G connection. And, of course, through Edge Delivery, it's used for every single pull request. And you can see one here. So, some shady person sends a pull request in, and it's 100, and their LCP is 0.9, and they've got no blocking time, no layout shift. Okay. Let's ship it, right? Another thing, this is a little bit of a pet peeve. Like everybody has their different measuring tools, I use my desktop, or I use this sort of legacy tool internal to my company. We pretty much standardize. Everybody needs to be speaking the same language, and it's pagespeed.web.dev, and using real Google APIs, not self hosted or anything like that. Everybody uses this. Everybody is speaking the same language. And then also desktop doesn't exist. I say that kind of cheekily, but generally, if you have great mobile scores, a lot of times people will say, I have a 90. And I'm like, on desktop? And so I say it half jokingly, but typically, we only focus on mobile because that's really what matters most. And this is actually Tory's home page. You could go click on this link if you take a picture and go check it out. The thing to know, though, is, like, a good Lighthouse score does not necessarily guarantee good Core Web Vitals. We actually have this scenario where all of our Core Web Vitals were looking great, but then our Core Web Vitals 28 days later, it was like, we're not doing so good. And it turned out that our regional visitors, they were coming to our US site and they were getting what we call our geo routing model, and Google was flagging this as LCP, so we had to do something about that because we were like, hey, all of our recent merges look great, but our Core Web Vitals are not so great. What do we do? So there are times where those things mismatch. The other thing is, there are services, this is a reality, like, there are services that were built in a sort of pre-Edge Delivery, pre-Lighthouse world. And so like, when you're having those conversations with your business leaders, just be transparent. Like, say, hey, this service was built five years ago, and if we integrate it, we're going to drop 15 points, and let them make that decision. And if you are asked to ship that and we can't wait around to refactor that entire service, again, these are realities, give yourself the flags. We give ourselves the flags to say when somebody comes to us and says, hey, why is this page slow? We can say, well, you know what? We're integrating this service, and if we say service equals off, we're 100, so you may want to go check with that that other team.

But I'm trying to make this term happen, so bear with me, but the way I look at it is like performance is like a garden. So you're constantly getting, you're being asked to ship new features or doing bug fixes. And so we typically and, like, if you don't weed your garden, they kind of, the weeds kind of take over. And if you're not spending your time on performance, all of a sudden, the performance weeds will take over and you're kind of behind the ball. So we probably spend maybe 10 to 15, my team probably spends 10 to 15% of their time on performance because the last thing you want to do is you're in red and you just don't know how to dig yourself out. So, yeah. The last thing is real user monitoring. So this is maybe a little-known feature of Edge Delivery, is that you actually get real user monitoring for free. And what's great about this is it's sampled, it's privacy centric, it's extremely performant, so you're still going to get great performance on your site. It's consent-free. That's a huge piece of this, and it's also built in. Again, you get it for free. And so for the marketers, you can compare this against your page views. So a good example of this is let's say you have a consent banner, and you can't capture any analytics traffic data, because of the consent banner. Well, you don't necessarily have that visibility into who dropped out of the consent. So you can actually because RUM requires no consent because it's all privacy centric, there's no PII, you can compare it and you can say, maybe we need to reevaluate our consent management, so we can capture more of those visitors and get, sorry, but get more of their data. And then off also it will provide at a glance Core Web Vital information. If you're not a huge company or even if you are a huge company and you can't go talk to the SEO team to get, like, Google Search Console, you can go right to data.aem.live, and you can see all your Core Web Vitals by a page by page basis. And the Edge Delivery Services team is continuing to make new dashboards where you can, slice and dice the information in tons of different ways. For the nerds, you can use the API. So if you don't like the dashboards that Adobe gives you, you can reach out, and they'll give you API access. And then you can also use at a glance Core Web Vital information. Again, if you can't talk to Amanda in SEO to get Google Search Console access or maybe they don't want to give it to you, you can go look at this information, and it's using the same exact data as Google is. And also, I prefer our view into Core Web Vital data over Google Search Console, and I'm not biased at all.

And then so to get started with real user monitoring, you can reach out to the shared slack. If you're in the shared slack with the enterprise group, you can go reach out to AEM data desk for insights. They're really eager to get this data into the hands of people, so they're really curious about your use cases. So they'll work with you on custom designed dashboards, so if something's not working for you, they'll get you API access, and then you can also go to data.aem.live. And I was not allowed to show a screenshot, but it's really great. And with that, I'll leave it to Tory to see how we did with all that work.

[Tory Brunker] Great. Thanks, Chris.

All right. I get the fun part. I get to talk about our results. My name's Tory Brunker. I head up business.adobe.com. And we were the very fortunate recipients to be the first site fully migrated onto Edge Delivery Service and also using document-based authoring.

One of the things that I think people don't always talk about is, what does this mean for my operations? What do I need to do to get prepared to actually leverage these great new technologies that I now have at my fingertips? And there's a few things that we have done for business.adobe.com that I think are really important for all customers and businesses. The first is making sure that you're leveraging a common taxonomy and governance structure. And this is incredibly important because when you go to start analyzing your performance of your content, you need to all be talking the same language. You need to all understand what is a datasheet or what is a very specific content type that you might have. Maybe some of you have buyers' guides or other different individual content types that you want to be able to measure as a group. Having this common taxonomy structure and governance across all of the different marketing organizations is going to be critical for you to be able to do that. We also leverage a scrum team structure, not just for feature delivery, but also for all of our content delivery as well. This has been invaluable to us from a speed delivery perspective and from a continuity perspective with all of the teams. We have teams that understand the products that they work on on a regular basis, not just for content, but also to deliver the types of features and functionality that those products need within their sections of the site. Our content reuse has driven about 40% reduction in new copy written. That's not to say we aren't writing new copy because we are and actually right now, we're writing a substantial amount of incremental copy on purpose. But when we started this, we actually decreased our content production and leveraged a lot of the content that already existed. We repurposed it into other content types, and we repurposed it into individual fragments that we used in different places across the site.

From a people impact perspective, we've had about a 5% reduction in our engineering team members, but a 50% increase in features delivered. And that's certain teams. Obviously, that varies. Some teams haven't seen an increase in features delivered. Other teams, because of Edge Delivery Service, now have the capability to deliver those features faster. And they are, in fact, doing that with less people. We also have flat year over year product managers, but we have seen an increase of about 20% in the programs that we're delivering. And again, a lot of that is from driving that scrum team structure, leveraging this global process that really starts with every region planning, coming together collectively to define what is it that we're going to execute globally and what do the regions need to then continue to own in their own spaces.

We're also democratizing content creation. When I talk about this, people get really scared. We are not letting anyone who wants to author things for the website. We are letting them, however, create content that then we can use and leverage through the processes that we have in place to get content up on the web. That means more content authors are producing things in Microsoft Word. Those are going through our governance process. They're being reviewed and cultivated and leveraged across multiple sites and surfaces on a regular basis as a result. We're also using Adobe Learning Manager. I don't know how many of you have Adobe Learning Manager.

Highly recommend. We actually built training modules in Adobe Learning Manager. It was very quick and easy. And in that, we have given folks the opportunity to understand how to write for the web, basic SEO best practices so when they are writing their content, they understand how to leverage keywords. We've given them tools inside of Adobe Learning Manager to access the common keywords for their products, and also understand how using those within their content helps the site perform better, drives additional traffic and engagement, and then we deliver those outcomes back to them by teaching them how to use our analytics dashboards in one of the other training modules. We also have standardized our intake process through Workfront. How many of you have Adobe Workfront? Excellent. We actually use a single Workfront form. So it's a single front door, if you will, into the web. And based on the type of requests that people have, that gets routed through the right teams, it gets reviewed and approved through the right teams, And it makes it very easy for me to go in every morning, which I do, and pull up my Workfront dashboard and see where things are within the different pieces of the process. And you'll see that is actually this view that you see here is the content learning path. And then up top, you actually will see what one of our Word documents looks like. All of that content is actually the Adobe Experience Manager site's product overview page. So if you were to blow that up and read it, you would go to the website at business.adobe.com, and you would see that exact content on the site today.

We're also standardizing on reusable content blocks. This is really important. It's the foundation for our personalization, and it really helps drive improved execution, consistency across the pages. So as customers, when you come to our site and you're looking at AEM sites and then you go over to Workfront, the pages are similarly structured. It's easy for you to follow along with what we're trying to explain, and you know where things are intuitively through the UI, which is also a big bonus and means that you'll get more engaged with the site. And then finally, we leverage a robust test, learn, and execute plan. Chris talked a bit about experimentation earlier. We love to use experimentation on the site. It gives us a great way to test out some of my crazy ideas and see how is that working for us in real life, and then we can roll them out when it's time.

We have improved our speed of delivery. So last year, we were updating about 14,000 different updates across the site per quarter. In Q1 of this year, we had about 25,000 updates to the site. Our project SLAs so these are longer activities. Previously, it was about six weeks. So if you wanted an update, a major update to the site, that was about a six-week turnaround time. Now we do those in no more than three weeks. Our run the business SLA and you guys are going to really laugh at our before. But basic changes on the site were taking about two weeks on average. And when I say basic updates, that's like change out a banner, update this page copy. Now those things take two days or less. There are some things that I can literally use my bat phone and get done within minutes. The two days is to make sure that we have really good QA. We're doing full blown testing on those, and we're also checking for the regional differences that need to happen. And then we also send them through our localization process. We used to measure our publication time so that is like the after I've hit go button, in minutes, and now we are measuring that in seconds. I do have to toot the team's horn. Yesterday morning, hopefully all of you went to business.adobe.com, all of the content refresh that happened yesterday morning, which was 5800 pages globally, went live in under four minutes. That is phenomenally fast and absolutely an amazing feat for the team, and I couldn't be more proud of all the hard work that it's taken to get us here. But we do owe it all to not just the technology, but also the people and process changes that we've made.

Chris talked a bit about our Core Web Vitals and some of the improvements that we have seen there. We expected to see improvements with this change in our site speed and SEO rankings, and we did. We saw a 19% lift in SEO. Our Lighthouse scores went from, in some cases, 10 up to above 90. You can see the full Core Web Vital performance over there. On the right-hand side, that is for the full site. But we were really pleasantly surprised to see improvement in other key metrics. We saw 40% engagement lift, a 14% increase in repeat visitors, and we also saw a 25% decline in bounce rates. These were definitely unexpected results, but, of course, very welcome. And we're excited to see these continue to grow as we're starting to leverage the technology even better.

But wait, there's more.

- Cool. Thank you. - You bet. So we have talked a lot about business.adobe.com, and Chris showed you a lot of the other places where we're using Edge Delivery Services. We have a site, experienceleague.adobe.com. Everyone familiar with Experience League? Okay. Lots of.

In that case, I'll skip the video. But Experience League is we have hundreds of thousands of pages, all of the material about how to get the most out of your investment in the Adobe products. There's a really vibrant community of our customers there who are engaging with us on a regular basis. One of the things that we've heard from customers is Edge Delivery Services sounds incredible. I've invested a lot in my current authoring environment, authoring experience. I've got lots of people across the organization who are very comfortable with WYSIWYG, with page authoring. I'm not ready right now to go and sort of make them and force them to do things in a different way or to re-architect it. Also, there are lots of instances where content may be being pulled from various different repositories and different resources that you need to integrate. We've got you covered. So I don't want to labor this point too much. I started the presentation saying, asking a question about Edge Delivery Services and the association with Microsoft Word and with Google Docs and with Excel. You've seen how we're driving a sophisticated site using these capabilities, but you're not forced to do that. So with Experience League, a vast amount of the content that we have on there comes from GitHub markdown. And the team who have migrated to Edge Delivery Services have created everything that's necessary to make it completely transparent for the authors of that content, but still get all of the incredible performance benefits that Tory talked about. And no content migration, no change to the way in which the authors are very comfortable in authoring that that content, and all of the kind of performance benefits that we've talked about. For those of you who follow AEM, follow the news, you will hopefully have heard about some of the releases that we've made this week, or maybe been aware of the VIP program that we've had around something called Universal Editor, which is the next generation of the visual editing capabilities within AEM. And we also have content on the site that is built using the Universal Editor and this new concept that we have within Edge Delivery Services of blocks versus the components from existing AEM. Certain content on Experience League just makes sense to be managed in a different way from the markdown that's very useful for the technical documentation that's relevant for the products. We have a combination here. And I think the big thing to say is, as I've been talking through all of this today, we're not forcing your authors, you're not forcing your authors to use a particular sort of type of editing paradigm. You're able to give them the tools, the editing capabilities that make sense for them, that they're comfortable, and still get all of these incredible performance benefits.

So this is just a little bit of a look at how that looks within the browser, within the universal editing, universal authoring kind of experience. There's a Marchitecture. I owe a lot to Chris to tidying this up from the team who actually did a lot of the work. And a quick plug, I'm going to move into the kind of calls to action that I'd love you to take away from our session today. But just specifically at this point, many of the team who've been involved in the migration of this content are actually with us at the event. If you go to the community pavilion, we have a big Adobe booth. You hopefully can't miss it. There is an AEM site section of that booth. People like Nick from ACS, our consulting organization, who were instrumental in making this project happen, they're there. They would love to talk to you about some of the things that they've seen and experienced with this. So just wrapping this up. There were a few people who hadn't heard about Edge Delivery Services at the start. We hope that you're as excited now after this session as we are about the kind of the game changing capabilities that this offers to our customers. High impact experiences that directly enable you to understand performance, to deliver a better differentiated performance from the competition that ultimately your customers are going to, are going to love. It's going to have impact on SEO, as we've heard about. There are other Adobe customers here talking in sessions. And I'll show you a few of the sessions that I recommend you checking out later, talking about these same benefits that they're seeing in terms of SEO. Wonderful things where they were only ranking for specific brand terms plus, the generic term, and now they have incredible visibility of generic terms that are just simply driving a massive volume of additional content of traffic. Content velocity. You heard some of the-- You saw some of the rapid ways in which the team that that Chris manages were able to adapt and change things for Tory's team. And you heard about how Tory's team was able to handle a massive amount of content changes in a really rapid way. Rapid development, your development teams are going to appreciate because you can use the frameworks. They can use the environments that they're comfortable with, modern web frameworks. And I probably am laboring the point now, but this flexibility of authoring is kind of critically important. Enabling your authoring teams to build the experiences, to manage and maintain the content in the right kind of interface, the right environment for them. And just finally, we have had hundreds of websites go live with Edge Delivery Services. We're serving millions of customers with millions of pages. And experimentation is a critical part of this. So as a product marketer, I feel bound to say, Adobe Target does not go away. Adobe Target still has a very important part to play in your overall personalization strategy. But what we're representing here is experimentation capabilities right in the hands of your authors, giving them the ability to just run many more experiments and get the benefit of the learning that you can drive from experimentation across your sites. So I highly encourage you to check that out. Chris mentioned the AEM Live website. This is something that you can go to now. You can send your developer teams there. You should send your partners there if you're relying on partners for development. And they can get their hands directly on this technology. They can build a site. Anyone who has front end development skills can build a site in a very short period of time. And even I have managed to build a site on this. So I used to be a web developer like 24 years ago. So I had to dust off some of my skills. But it doesn't take long. And it's incredibly, incredibly rewarding experience to build a site so rapidly. So that brings us to the end of our session. I think we have a good amount of time for questions. Just a really quick plug. Please do take the time to fill out the survey. Hopefully, this is becoming second nature as you go to those breakout sessions. The rewards are great for you, but they're also, we really, really need to understand, are the sessions good for you? Are you getting good value from them? What can we do to improve them and enhance them? And just on that final note, I'll leave this slide up on screen. A lot of other great sessions, customers talking about how they've really seen value from Edge Delivery Services. There are labs on how to get hands on with the authoring capabilities. GenAI, massive topic. We've hardly, I think we almost damn, I wish I hadn't said it now. We almost got to the end of a presentation at Summit without saying GenAI. But GenAI is a big part of our roadmap and the current capabilities within Experience Manager. There are lots of sessions on these. I want to set some expectations now. You probably are not going to be able to get into the labs, unfortunately, because they are limited in terms of the number of seats, and they sell out really early. The content will be available afterwards. All of the sessions are recorded. I saw a lot of you taking photos of Chris and Tory's slides. You will get the slides available on the adobe.com site along with the recording of the session. [Music]