ÃÛ¶¹ÊÓƵ

Transcript

Hello, everyone. Good morning. Good afternoon. Good evening, if it applies. Thank you all for joining.

Good morning. Hello. Hi. Today’s session, which we’ll be focused on, will be on Edge delivery. What is beyond the page? Fast, flexible, personalized experiences with AEM’s emerging technology. Hello, everyone. My name is Ledi McClure, and I’m a senior business strategist here at ÃÛ¶¹ÊÓƵ’s Ultimate Success team. I’m going to be your host today and moderator. So I want to note that this session is being recorded, and a link to the recording along with this presentation will be sent out to everyone after the session. This live webinar is a listen only format, but do feel free to share any questions into the chat and Q&A pod. Our team here will answer as many questions as possible during the session. And if there’s time after the session, after the presentation, we can open it to two questions again in the chat where Tommy and I can answer them live. Tommy, will you please next slide.

I just while we wait for attendees to filter in, I wanted to inform you that we do have several other sessions coming up this quarter that you can obviously you are welcome to attend. For those who are interested, the links and information will be included again as part of the deck, which will be shared afterwards. I believe there are a couple of slides on this. Yeah, this quarter. So you see, we have a few presentations in July that also extend to August. We have three in August. Let’s see, Tommy, will you go ahead and go to the next slide? Yeah, this slide is just really I wanted to highlight that they’re all online resources here on Experience League that you can leverage at any time. And this on demand library lists a few areas of opportunities for you to to dial in and click in, click into these sessions and listen to the recordings. And then lastly, I’d like to highlight our ultimate success program. The program offers a few accelerators that are rapid, impactful engagements with ÃÛ¶¹ÊÓƵ business and technical experts from our field engineering team. The program is chartered to inspire and empower customers to assist in driving that value realization through activating best practices, also planning new use cases with ÃÛ¶¹ÊÓƵ experience solutions and platforms. Again, this information is included in the deck for you to reference later. And now, without further ado, I will hand the microphone over to Tommy, who will take us through the presentation today. Welcome, Tommy. Hi everyone. Thank you, Lettie. I appreciate it. Let’s dive right in. So today we’re gonna talk about beyond the page, we’re gonna talk about some of the emerging tech with a deep focus on edge delivery. And we’ll dive into some of the authoring models and things like that. I’ll go over a full agenda here shortly. But really quick, I wanted to introduce myself. My name’s Tommy Miller. I’ve seen a few familiar faces join the call. So welcome. Good to see you again. I’m a customer success architect here at ÃÛ¶¹ÊÓƵ. My job that basically means I help teams figure out how to use AEM without losing their minds or in a lot of cases, their clients. I’ve been working on the platform for a little over 13 years now. And I am a certified AEM architect. And I’ve worked on a ton of different various roles over the course of my career. Everything from development, analysis to architecture, and even a little bit of project management. I’ve worn a lot of hats and I’ve worked a lot across a lot of different verticals. Just to get to know me a little bit, I put my happy place on here. My happy place is New England. Why do I love New England? Well, I have a thing for haunted forests, bad weather, fog, and books where something terrible happens to the dog at the end. So yeah, I’m a big Stephen King fan. As you saw, Lettie’s here helping me with moderation. She’s the responsible one. If I start spiraling into tech speak or get a little too sarcastic, she’s got an emergency break and she can pull it at any time. So let’s get into it. We’re going to talk about fast content, flexible delivery, personalization, and how to not tank your performance scores a little bit. And then finally, last thing I’d note is that I do have a LinkedIn QR code here at the bottom. Or if you want to type that URL in, you can, but feel free to connect with me on LinkedIn if you want to be friends.

All right. So here’s what we’re covering today. And I realized that no one woke up this morning thinking, yes, I hope I get to sit through 45 minutes of slides and product features on a Friday. So especially one that’s before a big US holiday. So I’m going to try to make this a little bit more fun. I’m going to tell a story. So the story, it’s a little story, but the reason I’m doing this is back in college a long, long time ago, I read this book called The Goal. It teaches business and manufacturing principles through a story. And yes, that sounds entirely terrible, but it actually worked. And I’ve kind of used that through my career to kind of guide conversations and explain technical detail and things like that as we go. And I figured, you know, if this works for making supply chain interesting, I’m hoping we can make content delivery a little less painful and not put anyone to sleep.

So in the spirit of shamelessly ripping that off, we’re going to follow a cast of characters, Jessica, James and Ravi. They’re going to go through some familiar challenges that you may have seen. The twist here is that they’re about to get a lot of really cool AEM-related technology. So as I was kind of mentioning, we’ll cover edge delivery and some of the new authoring models with it. We’ll talk headless a little bit and personalization, what it actually looks like, and then we’ll see some real world metrics towards the end so you can see how companies are using this in the wild.

There is a lot, so this is going to be kind of a high level conversation. I think my intent here is to kind of use this as a springboard for future discussions that we might have at a later date to really dive into more of the specific functionality. Alright, does that sound good? Oh yeah, you’re all on mute. So I’m just going to assume that you’re all sharing secretly. So let’s jump over and meet the team. I’m going to turn my camera off. There we go.

Alright, so here’s our heroes. And yes, they are entirely fictional, but they’re not imaginary. What I’ve done here is I’ve kind of combined a few different types of roles into three kind of specific roles that these characters kind of live day to day. Now with these characters, you’ve probably worked with them. You might be one of them. They’re not really personas and they’re not roles that you would see on a typical racy chart. They’re people trying to do their jobs while fighting against a system that’s supposed to help them. And the system that they’re working against is slow. It’s fragmented, it’s complicated, and it’s leaking into their lives outside of work. They’re carrying the stress home. They’re thinking about workflows when they’re trying to cook dinner or try to get their kids to bed.

So let’s start with Jessica. She’s the heartbeat of campaign work. She’s our lead. She lives in Google Docs, writing, rewriting, managing feedback, fixing it again and again. She’s coordinating reviews with her team and making sure that the brand team isn’t quietly panicking about the tone of the things that are being created. She’s not just creating content. She’s keeping six cross functional teams aligned and she’s pushing a deadline that’s moved again and again. She’s the one that’s refreshed a shared doc at 11 p.m. on a Tuesday, hoping no one overwrote her latest changes. She hasn’t had a clean handoff in three years. She’s fast, sharp and super creative. But she’s carrying an emotional burden directly influenced by this broken process that we’ll get into.

Then there’s James. He’s a developer, the architect, the self-proclaimed firefighter. And he might maybe just be partially inspired by me. He’s rebuilt the same component ten different ways. Not because he wants to, but because the CMS that they’re working with doesn’t support reusability the way that it says it does. And every time something needs to launch fast, he gets that 4.57 p.m. Slack message saying, hey, we’ve got a little padding issue on the front end. You think you can tweak that for us? And he knows overall he knows what looks good. And he’s very good at testing and performance, but he’s always switching context and it’s leading to burnout. And he’s struggling. And then we finally we have Ravi. He’s our governance translation compliance QA guy. He’s managing legal approvals in five different markets and reconciling last minute copy updates across three different time zones. And he’s trying to get campaign assets translated without breaking anything or offending anyone. He’s the one reminding everyone that publishing without review is very, very risky. He’s the quiet protector, the silent guardian of brand integrity. And yes, he’s also the one working through lunch because the system is kind of failing them. So that’s our team. They’re sharp. They care. They’re good at their jobs. And they actually embrace change. But they’re just trying to do good work in an environment that’s kind of working against them.

And so let’s explore what happens when we’re giving them some of these new tools. But first, let’s talk about a shift that kind of led to this situation.

So here’s the reality behind all of this. They’re doing things the way they’ve always done. Solving problems, pushing content and trying to stay sane. But the environment around them is a lot different than it was five, ten years ago. Let’s take 2013, for example.

A five second load time was fine. Pages were heavy. Timelines were generous. And maybe for our team that publishing, maybe for our team that meant that publishing, you know, like once a week might be kind of an ambitious task. But now, if you kind of take that same situation and apply it to now, you’ve got milliseconds to make an impression. Now, Google wants your web website to load in less than two and a half seconds. So performance just isn’t an ideal type of thing that you’re striving for. Google will literally downrank your site if you miss it. And they might put your competitor right in front of you. And they might, your customers might click there instead. So what your customers typically are trying to expect are fast, clean, personalized experiences. And they don’t really care about the tech stack or the approval process. If it’s slow or clunky, they’re going to bounce. They’re just going to go somewhere else. So my personal observation here, and this is just me, it might not be the official ÃÛ¶¹ÊÓƵ thing, but most teams are still trying to meet modern expectations with pre-pandemic tooling.

Or worse, they’re trying to do it with pre-mobile first tooling, which is something that goes back to when I started on the platform. 13 years ago. Anyway, a lot of these legacy CMS platforms weren’t built for speed. They weren’t built for multi-channel delivery and they definitely weren’t built for the kind of personalization we’re expecting to deliver today.

But it’s not a content problem and it’s not a people problem. It is entirely a delivery problem. And if you’re in a situation where you feel like things are harder lately and why your team might be burning more energy just to stay kind of afloat, it’s not just the volume of work, it’s kind of the shape that that work is coming in as and what it’s kind of turned into.

Which brings us to the bottleneck that’s really, really, really slowing down our heroes. So let’s go there and take a look at that.

So every story needs a very good antagonist. And I think it’s about time we meet ours. So here’s my narrative. It’s on a Wednesday, maybe 3 p.m. Jessica’s ready to launch her campaign. The copy’s done. The assets are approved. The campaign’s locked. She’s already thinking about performance metrics. And then she waits. She submits the request. It gets routed to James. But James is buried. He’s staring at a JIRA board that looks like a conspiracy wall. I’m thinking about that popular meme of Charlie from It’s Always Sunny in Philadelphia where he’s kind of pulling his hair out. He’s got all these Post-It notes up. I don’t know if you’ve seen that one, but I always think of that one.

And then, meanwhile, Robbie’s in the background. He’s pacing. Because today’s publish window depends on everything going right. And he has a gut feeling that it’s not going to. So what’s holding them back? Well, it’s this monolith. This giant immovable structure sitting at the center of this process. The only thing I think that would make this more terrifying is if it had tentacles.

It’s rigid and slow and it treats every single update like a four alarm fire. It doesn’t care that the campaign’s ready. It doesn’t care that the deadline’s tomorrow. It moves when it decides it wants to move. And this isn’t just about old code. It’s a design philosophy. Legacy architecture built in an era when content moved a little bit slower. Now every path, whether it’s content or development or governance, routes through the same bottleneck. One update could impact five different things. If you test in staging, you’re hoping that it behaves in production. This is what it feels like for a lot of different teams. They’re pushing against a wall and that wall doesn’t push back. So this picture I have of this monolith right here, that’s not a decoration. That’s what publishing can sometimes feel like for a lot of teams. It’s heavy, unpredictable, draining, and it’s sucking up all of the lights around you.

So let’s fast forward just a little bit. Our team’s frustrated. Launches are dragging. Everything feels harder than it should. So they do what a lot of smart teams do. They escalate. And I’m sure there were a lot of conversations with leadership and other folks that happened a little more behind the scenes that we’re not privy to. But ultimately they end up getting on call with ÃÛ¶¹ÊÓƵ and they walk through these pain points. Slow delivery, no preview, bottlenecks, lag.

So the suggestion that comes back isn’t really a patch to fix this. It’s kind of looking at the model in a different way entirely. And that’s where we enter edge delivery.

So let’s talk about what this actually is a little bit. Because edge delivery isn’t just a new name slapped kind of on an old idea. It’s kind of a modern architecture designed to meet a lot of today’s digital expectations.

With traditional AEM sites, you get great performance via the dispatcher cache and maybe a CDN tied to it. But high velocity campaigns, personalization, and rapid updates can create bottlenecks. Especially if you’re dealing with cache misses or new governance controls, edge delivery steps in by generating pre-rendered versioned HTML for every page and pushing it to a global CDN. Instantly your users get the right content served from the closest possible edge node. There’s no round trips, no guesswork, and you’re not limited to static experiences.

So edge delivery is built on a layer of dynamic personalization and experimentation thanks to a native target support or integration.

And then you have JavaScript sitting on the edge. Authors can create with familiar tools. And we’ll get into that a little bit more as we progress here. Developers build modern reusable rendering blocks. And blocks are kind of, if you’re not familiar with them, are basically like AEM components, but it’s the edge version. And the combination brings both content and code together. It keeps their workflows separated. So developers don’t need to worry about stepping on authors’ roles or vice versa. And best of all, it’s not a rip and replace. So you can use this along with your existing AEM sites implementation. And you can roll out faster web experiences where you need them the most. And that can be done on your schedule.

And then we have newer integrations like AEM content fragments powering omnichannel campaigns in AJO, for example. It’s easier than ever to keep every touchpoint connected, performant, and on-brand.

Okay, so we’re going to go back to performance just a little bit. And there’s going to be this kind of theme of that in the background as we continue talking.

So as I was kind of saying, performance really isn’t a tech spec anymore. It’s a requirement. And the nice thing about edge is it’s built as a performance first architecture, or in a performance first based architecture.

So let’s get into Google Core Web Vitals. So that’s where we’ve raised the bar. This is how Google kind of defines what’s going to end up when and where.

So they’ve raised the bar. Customers don’t wait for slow pages to finish loading. If they’re not fast, you’re kind of forgotten.

So we’ve spent, I mean, I’ve personally seen this, we’ve seen teams spending months chasing lighthouse squares. And you can trim milliseconds here and there only to get knocked back by a rogue widget or an external JavaScript library or something along those lines. And that really shouldn’t be the job. That really shouldn’t be your job at the end of the day. That should be solved upstream. And with edge delivery, the concept of speed is baked in. The architecture handles the heavy lifting so you really don’t have to. What used to take a performance task for, performance task force now takes something that’s done by default. Whether it’s a microsite, a landing page, or some type of content hub. So yes, the point of this slide is that performance is non-negotiable. But here it’s not a fight, it’s a feature, which is, I think, one of the really cool things about it.

Okay, so now that we’ve talked about performance, I’m going to shift gears just a tiny bit. Because the other half of these types of implementations is how the content actually gets created. So with edge delivery, ÃÛ¶¹ÊÓƵ, we’ve given you the flexibility and how your teams can author content. And these are the three main. And this isn’t a one size fits all solution. It’s a model that adapts to your teams. If you want structured content, ready for omni-channel reuse, you can use the Content Fragment Editor. This is built for headless delivery. It’s perfect for product descriptions, FAQs, or any content that needs to live in multiple places. It separates content from layout. It supports versioning and localization. And scales beautifully across channels. If you want in-context visual editing, that typical WYSIWYG type experience, but a little bit more modern, authors can edit content right on the page with this. The Universal Editor can be overlaid on top of your SPA to enable an authoring experience. And you can see live previewing with every change. And it works, like I said, it’s across both headless and it also works across traditional sites. It also supports workflows, approvals, and asset management for teams that need governance.

And then if you need the fastest possible authoring ramp up, well, that’s document based authoring, right? This is the one I think is the most popular out in the community that’s talked about.

This is where you can use Microsoft Word or Google Docs, tools that you already know, to create any update to your web content.

And with this, you don’t really need to learn AEM. There’s no development, dependency, and no friction. You’re just creating content. There’s some little caveats to that, but I’ll explain that here in a little bit. But for the most part, that’s what it is. And the best part about all of these, it’s kind of like I was hinting at, right? These are all compatible. You can mix and match and evolve your approach as your teams grow or your needs change. All within the same delivery platform.

So whether you’re structured or headless, you know, a visual person, or you need to create content really, really fast, there’s an option for each.

For Jessica and the team, this flexibility is game changing. She doesn’t have to wait on development just to get her copy live. If she’s more comfortable working in a Google Doc, fantastic. She can.

If she wants to use a live editor for tweaks in context, that’s also great. It’s her decision. For James, this means fewer one off requests clogging his backlog. He can help define scalable content in the content fragment editor while letting marketing own their day to day updates. They might not even talk.

And for Ravi, this model is a dream. Governance isn’t sacrificed for speed. He knows content is versioned, structured, and he can review it no matter how it was authored.

So while this flexibility sounds like a technical feature, it’s really kind of a people feature. I think the goal here is to bring people together in a way that hasn’t been done before. It gives everyone the space to do what they need to do without stepping on each other.

One thing I want to do is talk a little bit about each one of these authoring models a little bit before we continue back into the main discussion.

Content fragments are based off of a model, which is a template. It’s just a template of a dialogue at the end of the day from a content authoring perspective. And the content fragment editor is built so that it could be used for headless reuse. You could also use it in a traditional AEM kind of way. But you’re not designing pages. You’re using those models and you can use them pretty much anywhere. You can use them on your site, your mobile app, your kiosk, or even if you wanted to, load them into a chatbot. It’s all structured data, version controlled, and it can be translated.

And this is where JESSICA’s team stores things like product blurbs, FAQs, call to action text, maybe some legal documentation, that kind of thing.

And that’s stuff that might show up in multiple places and you only need to maintain it once.

And since content and layout are separated, dev teams can build a UI for this and once and then pull those fragments wherever they need to be used with the APIs. And if you look over here, you’ll see that I have a screenshot of what everything looks like.

So there’s in the background, you’ll see that there’s that dialogue. That’s what the dialogue to a content fragment would potentially look like. And then I have a sample of what a JSON response would look like if you’re requesting it from one of the APIs.

Okay. And jumping over to the universal editor. So this one’s fun.

So now a lot of the time, the teams don’t want to work in a purely headless setup. Sometimes you just want to see what you’re changing. And especially when you’re working on site pages or promotional content, you want to make sure you have that look and feel. Right. Do you want to do add a line break somewhere so the text flows a little bit nicer. This is the WYSIWYG. There’s no baggage with it. They can author content right on the page and you’ll see exactly how it’s going to appear.

And like I said, it’s compatible with both traditional and headless setups. And if you’re using edge delivery, it’s kind of just directly baked into the flow. The real magic is extensibility. So developers can build custom blocks, wire in external data, maybe a content fragment, or create governance logic to meet their exact project needs.

This means that teams don’t have to compromise between flexibility and control.

And this one’s the crowd pleaser, the most popular one. So document based authoring.

And this one just kind of goes back to what I was talking to you about before. Not every team wants to or frankly should work inside of CMS.

Sometimes the fastest way to create great content is let people use the tools they already know. With this, Jessica doesn’t need to log into anything. She opens Google Docs to remind herself where it writes up her content, drops in some images, and adds comments to review. I’m going to show a little demo. It’ll play in this window here in a second. But the rules are simple. Basically using a few structured guidelines, you’ll see that we use a table to insert these blocks. You’ll see that in a second. You can set this up without a developer having to touch layout. There’s no build pipeline, no merge conflicts. Just get the content to the site.

So this is perfect, again, for like things like campaign pages, policy updates, FAQs. I see it a lot of the time used for blogs or event promos.

Any scenario where speed and ease of use are more important than complex layouts.

And here’s a little live demo. I’ll kind of explain what happens here. So we’re going to go in, we’re going to load this up. They’re going to change the headline of the page. So they added some text there. Then they’re going to go in and add a block. And that’s our component. And it’s just a quote in this case. And you’ll see that gets inserted with a table. And they’re going to change this. There’s a little template of text. They’re going to change that text to what they want it to be. Then they’re going to go into assets and they’re going to pull an image directly from the dam. And then they’re going to insert it.

And then after that, they’re going to click on preview. And you’ll see it load in the web page.

And you’ll see the quote in the new image that they added.

Alright, so let’s talk about some other neat things. So we have the GenAI stuff. So generating variations in AEM sites.

This is where this all gets created from AEM sites itself. So Jessica doesn’t need a prompt engineer, for example, or doesn’t need to brainstorm a new copy that she might need to write. She can just select the content that she may have pre-written. It could be a headline or paragraph. And then she can ask AEM to generate intelligent variations of that in context. So that’s a pretty neat feature. The system knows the brand voice or at least can be configured to know the brand voice and will understand the page’s purpose. And that will produce multiple options that are tailored to what they’re looking for.

If Jessica sees one she likes, she can swap it in immediately or even mark a few for A-B testing through target.

So this isn’t like a disconnected AI experience kind of bolted on after the fact. It’s actually part of the authoring flow. And one of the neat things is you can also do this through content fragments, which I don’t have a visual for here. But if you have content fragments and you’re using the content fragment editor, you can generate variations specifically right in there as well.

Okay, so let’s go back to our story. This is where it all lands, everything we’ve been talking about. So Edge Delivery has flexible authoring, built in performance, and it’s coming together for Jessica’s campaign.

Alright, so in our example flow, this is our use case, right? Jessica starts in Google Docs. She’s just going to write up her copy. There’s no training, no ticket queue. She writes the copy, drops in her images, just like we saw in this last slide. And she can collaborate with her team in a tool she’s already using daily. As long as she just follows a few lightweight formatting cues like inserting that table, she’s good.

James, meanwhile, isn’t in the weeds. He’s already setting up any styling or associated with the blocks or any other logic.

And then any other last minute things that might come up while completely staying out of Jessica’s way. Her content just kind of fits right in. For Jessica, there’s no custom layout, no deployment process, and James is literally just giving a quick format check. Then there’s Ravi, who’s going to have a little bit of a bigger role, but he reviews everything live in the browser on multiple devices. He’s looking at accessibility. He’s looking at the layout all in real time. If something’s off, they can tweak the doc or just adjust the block on James’ end.

There’s no rebuilds and hopefully no fire drills. This is the shift we’ve been working toward from reactive to rigid to fast and fluid.

So what used to take weeks could actually just take days or even less. You could theoretically have this up in a day.

And the best of all, the experience users see is the one that Jessica actually wrote and not a watered down version lost somewhere between the design process and the development process.

Okay, so as I mentioned, Ravi gets to do a little bit more fun. So Ravi, I decided, is also going to be our personalization guy. So Ravi gets to flex. Personalization isn’t a layer bolted on after launch. It’s embedded in the delivery itself. So the edge side logic runs before the page even renders using headers or cookies or geolocation and session data to decide which experience is best to serve.

And that’s done right at the request level. This means there is no waiting for the browser to kind of figure it out. It’s fast and invisible and consistent.

ÃÛ¶¹ÊÓƵ Target brings the brains and some of the A B testing, the audience segmentation, delivery rules, and then AJL adds real time muscle.

If a user, let’s say for example, gets an email and in that email they have the decision to click on a product. That’s great. They do it and then we can show them a related offer on the site like two seconds later.

And so quick example. So I put some metrics here. One customer used this to spin up five homepage variants tailored to region and loyalty tier.

We saw an engagement jump of 41% and a 20% higher conversion rate. And because the personalization happens at the edge layer, performance didn’t really dip. It improved. So they scored a perfect 100 on their Lighthouse score.

All right. Now we’re going to pause our fun story for one minute and focus on what actually happens when organizations move to edge delivery and modern authoring.

So these aren’t hypothetical numbers. These are real results reported by real teams across a variety of industries and based on different needs.

All right. So let’s take Meritive for example. You’ll see that we have these stats from a few different companies on this slide. After adopting edge delivery, their web speed scores jumped by 85%. For them that translated into faster access for healthcare professionals and clients. They had smoother experiences and a measurable boost in both user satisfaction and SEO.

It’s the kind of step you feel not just in the metrics but also kind of in the day to day experience for every visitor. And then we have Made in Form. They had a pretty dramatic transformation. Their Lighthouse performance scores, that crazy set of metrics Google uses, tripled by 194%.

They had a very, very slow site before. What does that mean for the business? They saw bounce rates drop by 12%. So fewer shoppers were leaving before the sites even loaded. Instead, more of those visitors stayed, browsed and ultimately converted. Even more impressive for them was that organic visits jumped by 19%.

Because Google now rewards you, as I was talking about, for having a more fast and reliable performance. So this is all real measurable growth just from delivering a better experience.

And then you have organizations like Sunstar and Danaher who managed to completely overhaul their digital operations. They cut their time to launch brand new sites by 80%. And projects that used to drag on for weeks could now be completed in a single day. And it didn’t stop at site launches. The time their marketing teams needed to create or revise site pages dropped by 50%. And that was a massive win for efficiency.

This gave them more time to free up their team to work on new campaigns or pivot to something completely different. Or simply just give them a time to relax.

And let’s not overlook the software impacts. So IT support channels and Slack threads got a little quieter because people, not because people weren’t disengaged, but because they were finally free from some of that daily firefighting type stuff that we’ve been talking about. Teams spent less time wrestling with slow builds or deployment snafus. And far more time actually building, experimenting, and creating new value for their business.

The big takeaway here is with Edge delivery and these modern content tools, you’re not just getting something faster. And I really hope at the end of the day, the big takeaway is that you’re kind of unlocking new levels of agility. Improving the customer journey and creating that, and to me, it’s the most important and much happier, more productive team.

Alright, a couple more metrics. This will give a little bit more visual into some of this. So let’s talk about Largest Contentful Paint or LCP. This is one of the metrics that Google uses in their Lighthouse scores to measure how fast the main content of your page loads and becomes visible to users. So a fast LCP keeps people engaged and improves your search rankings. A slow one leads to frustration and lost traffic.

So what you’ll see here on these graphs, you’ll see in kind of the red area or the orange, what their Lighthouse, their LCP was before they implemented Edge delivery. So Made in Form, if we look at this, their LCP scores were lagging. They were very slow to load. After going live, Made in Form saw the LCP time drop well under the recommended score that Google has of 2.5 down to 1.2 seconds. And this contributed to a dramatic surge in organic traffic and a 12% decrease in bounce rate.

Sunstar, so if we switch over to this one, their homepage LCP went from several seconds, well above the industry standard, down to 0.8.

And that was, I mean, that’s less than one second after their migration. Along with this, their Lighthouse performance score hit a perfect 100 and they had an organic search jump of 30%.

And this also reduced their bounce rate by 20. And then Danaher had probably one of the more dramatic shifts. Their mobile pages had LCP scores that lagged far behind most industry benchmarks, making mobile visits especially painful. Their LCP dropped close to one second and their Lighthouse mobile score rocketed from six to 100. This speed enabled them to publish 150 new pages in three weeks, a pace that was unthinkable before.

Okay, so let’s go back to our story. We’ll wrap this up. So we’ve reached the conclusion of the story. And what happened to our merry band of heroes? Well, Jessica’s campaign worked. Happy ending, yay. James didn’t quit in a rage. And Ravi went home on time. There wasn’t any deployment anxiety. The whole thing shipped a little bit faster than expected.

And the metrics were just awesome. More importantly, what we saw wasn’t really a fluke. Because once you have this kind of workflow in place, it doesn’t punish you for moving fast. And you wouldn’t ultimately want to go back. You’ve kind of started setting up the foundation to something that could be really awesome.

So after all this, Jessica, you know, she’s already getting ready to start off the next launch. James now has a library of reusable blocks, aka components in AEM lingo. And he has his fragments ready to go. And Ravi, he’s fine tuning any region specific rules. He has a full cup of coffee that he can actually sit down and enjoy. And they’re not reacting anymore.

The end. Wait a minute. No, this isn’t the end. All right. So, there is one more slide. It’s a little outside of what I wanted to talk about today.

But I would be doing you a disservice if I didn’t mention what kind of comes next. So, here we go. So, this is one of the cooler features of AEM that’s come out. So, let’s assume we’re with our team. So, even when Jessica, James and Ravi, you know, nailed their launch, there’s kind of this ongoing challenge of keeping the site fast, accessible and always up to date. As you introduce new things, you know, you have to continuously kind of optimize. And that’s where this newer tool, the AEM Sites Optimizer comes in. So, one of the latest additions to this, I think it was announced at Summit this year or released. What’s exciting here is that it works seamlessly across classic AEM sites as well as latest edge delivery sites. Think of it as an always on site intelligence. It’s an optimizer that’s continued continuously scanning your site in the background and running automated health performance, SEO, accessibility type things across every page, and not just the homepage.

So, instead of having to hunt down problems or wait for users to flag issues, you can get this a little bit more prioritized and you’ll get actionable recommendations and it will prioritize those right inside of your AEM dashboard.

So, while they’re planning their next campaign, the optimizer is kind of sitting there working quietly in the background doing its thing and making sure that things are getting flagged effectively for the team.

Okay, so we have now reached the Q&A portion of our discussion.

I think I’m going to hand it back over to Letty.

Thank you, Tommy. That was great information. Great presentation. I believe we’ve answered most of the questions in the pod. But let me see. I believe we have a poll set up if anyone is available still here and has a few seconds.

We can launch this poll. There we go. Let’s see. So, Tommy, I wanted to ask a question myself. What happens to existing workflows and permissions if we move to Edge Delivery and Universal Editor? And I’m speaking like existing AEM workflows and permissions. Okay. So, I will answer this with a caveat. So, if you’re using AEM workflows and you have permission model already set up in AEM, the only way that model will continue to work is if the content itself is stored in AEM. So, this would be a scenario where instead of everything living in Google Docs or in SharePoint, slash Word, or Excel or Google Sheets, basically, you can just continue to use those models.

It’s based on the same technology that powers AEM. So, that will continue to work. Now, the one thing, since I brought up the caveat, if you’re using Google Docs or SharePoint, those tools have built in workflows potentially and a permissioning model. So, it’s kind of just making use of what’s there and what’s available to kind of manage that content. Does that make sense? Yeah. That’s great. Thank you. I was also wondering, these tools, are they only good, like should smaller customers or teams, can they use and leverage Edge Delivery for their content or is this just for large enterprises? It’s totally available for both. So, they’re good for small agile teams and large enterprises. The general goal with this tool is to reduce technical barriers and speed up any content delivery needs that you might have. So, yeah, it’s for everybody.

Great. Tommy, I want to go back to our audience. If anybody here has additional questions or maybe wants further explanation to the question you posted, feel free to add it to the chat right now and see if we can address it live.

And if not, that’s okay. What I was going to recommend is if you think of other questions or you have further, you want further understanding on your question, please feel free to reach out to your account with that information, with that question, and they will route it to us and we can definitely provide information there.

John, I see John posted a question. Let’s see. Is Site Optimizer built in or add on module to ask as a cloud service? And secondly, is that also available in AMS version of AMS? Sorry. Let me know if you need me to repeat that, Tommy. I actually am not sure. What I would suggest we do with that one is filter that over to the account team. I’m not sure off the top of my head. It’s definitely built in as part of cloud service, but I’m not sure off the top of my head if it’s available for the AMS version or not. But I would suggest just checking with the account team.

Okay, great. Thank you.

Okay, I think I think that’s all for questions.

I don’t see any more coming in, but yeah, so I just want to go say, yeah, go ahead and reach out to your CMS. Thank you. If there are no further questions or comments, I’ll go ahead and close it out and want to thank everyone for joining on a Friday, midday, mid morning, mid afternoon. And again, any questions, please reach out to your CSM or account team. And thank you all for joining us. You will receive a copy of the deck and the recording link to the recording after the session.

Thank you all and have a great weekend. Thanks, everybody. Take care.