[Music] [Joan Smith] So welcome, everybody. And thank you for joining us on Wednesday afternoon. We're standing between you and the Bash, I'm sure. So we have a very exciting session for you today. So welcome to learning about Edge and REVOLT TV's journey with Edge Delivery Services.

Before I get started, so let me introduce myself. I'm going to be your host for this panel and this discussion. My name is Joan Smith. I lead Protiviti Digital. And we are very, very lucky and honored to have our clients REVOLT TV with us, as well as our engineers from the Protiviti Digital team to chat with you today about how to actually implement Edge.

Before we get started, though, I want to just ask, has anybody implemented Edge on any of your sites? So we got a nod. Okay. Okay. The panel, that's good. This is good. Anybody thinking of it? Anybody? Okay. We got some folks thinking about it. Okay. Great. We're going to have some room and time for questions, after as well. So we'll go through a conversation, and we're going to keep this pretty light, but we'll have definitely time for questions. So I'm going to ask my panel to introduce themselves. So, Rishi, if you want to jump in. [Rishi Kumar] Sure. Hi, everyone. My name is Rishi Kumar. I'm the Director of Product at REVOLT. I oversee the product management...

SEO, editorial, and design team at REVOLT. And I work on our revolt.tv website, which is the one we will be talking about today, as well as I oversee our mobile apps and our TV apps.

[Stephen Dyer] Hi. I'm Steve Dyer. I'm the VP of Engineering for REVOLT. I'm responsible for IT infrastructure, our media distribution platform, then the development and support of the apps and the websites we have.

[Stephen Pfaff] I'm Stephen Pfaff, Enterprise Architect at Protiviti Digital. I help our customers integrate across Adobe products and any other products that they might have within their ecosystem.

[Dan Hixson] Thanks. Dan Hixson. Director of Experience Platforms at Protiviti Digital. I work with Stephen Design Solutions and then, make sure that we actually got it right and deliver them for clients like REVOLT.

And not sure how many of you are familiar with REVOLT, but just to, kind of, set the stage, content creators. And let's get a little energized. So we're going to share a little bit about the brand with you. [Music] # I think we found ourselves # # A sacred place... # Salute to this platform. Y'all killing it. This guy's really a legend. He's really an icon. Icon. I know that's right.

Welcome aboard REVOLT Airlines. Bro...

I'm going to be the first black woman entrepreneur of my generation to be a billionaire. I will never do anything that doesn't speak to my spirit. As of now, there are still no arrests. Ball game!

The only podcast that got wild Puerto Ricans were... Yay! Take one, marker. I'm here to try to help you get to a back. Make some noise!

Can't take no more. [inaudible] Let's be real. Put the blow the doors off this. What are we talking about? - Good job, REVOLT. - Thank you. The revolution will be live. The revolution will be live.

Sign the greatest shit.

Hopefully, that gives you a flavor of the amazing amount of content and energy that REVOLTs brings to their customers and people who are interested, and all the hip-hop lovers like all of the rest of us.

Okay, so, Rishi and Stephen, let's talk a little bit about your program journey, and what were you trying to achieve, and what were the challenges you were facing when you thought about having to replatform your site? - Yeah. - Great question. So as you can tell REVOLT is a publisher in the hip-hop media space. We use the revolt.tv platform to publish our articles, our videos, and our podcasts. We are primarily an advertising-driven company. So things like ad impressions and site engagement are very important for us. And today is going to really be a real-life case study. We're going to talk about how we went from our CMS to Edge, and really talk about the journey, how we ended up selecting our partners, all the way through our implementation, as well as the results that we have seen post-launch. And so just to set the scene, as I mentioned, we were on a different CMS, we were on WordPress, and we really were looking for a CMS where we could migrate our 50,000 plus articles, hundreds of video shows and podcast shows, and we really needed to bring several key integrations together, such as our advertising integration, and most importantly, give our editorial team the best publishing experience we could give them. So Steve, do you want to talk about some of our pain points? Yeah, as Rishi said, we had the WordPress site for a number of years and there were problems with it which I'm sure everyone's experienced. You know, firstly, for the technology team, it was difficult to make changes to the website. We had the normal WordPress problems around maintaining plugins and keeping up with security upgrades. Secondly, for our editorial team, the publishing workflow was very cumbersome, so it was slow to add and refresh content on the website. And thirdly, for our and most importantly for our consumers, the website was very slow. We didn't pass any of the core web vitals and this had a major impact on our SEO rankings and, of course, for the usability of accessing and reading our content.

So let me ask you, why Edge? Why did we end up there? - What was that choice? - Yeah. So to be honest, when we were going through the process, we had no idea what Edge Delivery Services was. You know, we had just signed our deal with Adobe, and it was for AEM Sites, right? So we were thinking about, "Okay, how do we do AEM sites? Do we do a traditional head full integration? Do we do headless? What do we go about doing it?" And really, we talked to a bunch of different partners, and we met Protiviti and really, they listened to our use cases, and they were like, hey, have you guys considered Edge? I mean, at that time, I think it was called, you know... - Helix, Franklin. - Helix, Franklin... Next-gen composability... They might change the name during this session. Yeah. But I'm very glad that they introduced us to Edge, like, hey, there's this new thing. So we decided, okay, let's use this and really the back and forth, we were thinking, okay, this is clearly going to meet our use cases and we were thinking about the pros and cons, should we do sites, should we do edge, and we were really concerned about, like I said, performance, the best publishing experience and what's going to be the quickest site to implement, right, like how do we get from start to finish the fastest? Yeah. And the way that Rishi said start to finish the fastest now is very different than how he put it to us, and it kept us up late at night. It's going to shiver up our spines, but the timeline was a challenge that we needed to meet, and we needed a technology that would get us there. So we were aligned on that. I think for us as implementers of the tools as Adobe partners, we want to add value for clients with new features that come out, with new advanced solutions that are coming out, as well as contribute to the ecosystem. So I mean, for us, that's where it came from was, I think we said, hey, wherever you go, whoever you end up going with, you should really think about this because there's some places where it really matches, what you guys are trying to achieve. And then the places where it was it seemed askew, it seemed like we might have had a delta, we didn't try to prove that it would work 'cause we were joking about this earlier. I think the most dangerous thing on a software project is a combination of optimism and nearly being good enough to get it done. And we've seen many projects go straight that way. We tried to prove that it couldn't work. We tried to, in essence, pressure test edge. We had a punch list, all of the integrations, and Stephen's going to go over some of those in a minute, that needed to be there and set up the conditions, okay? We don't think it can work for this reason. Well, maybe it can, right? Then how do we engineer through that? And when we ran out of things on our list where we thought, "Hey, this can't work." Then we felt, we had a conviction where we said, "Yeah, this is going to work with great partnership from Darren, Jillian, and the VIP team as well." But we have strong conviction there. Yeah, and then when I sat down with our internal teams, really, and gave them the choice, they all selected Edge, right? And I think it's just because of some of the performance and speed reasons and, yeah. And to be clear, it's the document-based version of Edge Delivery Services. So you were telling us that they were already working in Word documents to begin with... Right, I mean, they were writing articles in Word Docs and Google Docs and copy and pasting them into WordPress, so why don't we just stay in Word Docs, right? So for us it was a very natural use case to go with Edge.

- And you, Dan, you mentioned timeline. - Yeah. What was... Let's talk a little bit about the timeline 'cause if I understand correctly, this was a very large WordPress site that was maybe breaking WordPress a bit. Yeah. Yeah. 50,000 pages. If anybody's done a content migration of 50,000 pages, you know that we would still be migrating pages right now if we had tried to do that manually or do a delta scripted migration. But we tried what we've got shown here, we've tried to show the compression that we experienced in the schedule. And basically from a setting aside the content migration piece, which again, that was somebody on Darren's team that was gracious enough to run the ingestion script over a few weekends for us.

In terms of development, in terms of getting up to speed, in terms of author training, they're in a tool they already know. And you get the acceleration from the content migration capabilities of Edge Delivery Services. You know, we're doing this project in roughly half the time, that we thought we'd have to do it in AEM classic, if you will. And so when we were talking with Rishi and Stephen, it wasn't, you need to do this, you need to do that. It was... Here's what we're looking at. You've given us a challenge, right? We love a challenge. Here's some options and here's how we would make the decision if we were you. But ultimately, they had to make that call. But from a timeline perspective, hands down, this was the fastest we've gotten to site up. And again, there's no way that we would be up and live and a month out and being able to show those results, right now if it wasn't for Edge.

So let's talk a little bit about integrations, right? I'm going to guess, and I think the team shared with me, this is a content-driven business with lots of content creators and I have to imagine that there was complex ecosystem full of a whole bunch of integrations and some things we had to customize. Yeah, yeah, absolutely. And I'll turn it over to Stephen in a minute. But maybe you've heard this or maybe you have clients that are saying this, but it seems like out of the box, there's a lot of pieces that need to get plugged in. And some of these items were like the heart of that punch list I was talking about where we had to try to figure out whether or not we could actually, achieve what we needed to for REVOLT and work with Darren's team. Hey, can we extend the platform this way? Can we not? But it was really encouraging for us to be able to extend Edge Delivery Services to do what we needed it to do. It was certainly sufficiently flexible enough. And I don't think there's really a better example of that than, the Megaphone integration that we built. Stephen maybe you want to talk about that. Yeah. Thank you, Dan. So on the next slide is a few screenshots of that Megaphone Integration. I will get into a diagram of this, but at a high level, what is Megaphone? So Megaphone is how REVOLT has is really giving power to creators. So REVOLT's website has 49 podcasts and growing. Each of those podcasts has up to 1,000 episodes. All of that content is created by third-party content creators, so they are not REVOLT employees. We also needed to have a way so that these podcasts and podcast episodes could make it into the site, and we used a bit of magic on the Edge Delivery System called folder mapping to make this happen. But the screenshots you see here, kind of, illustrate from soup to nuts how we got that content, what the content looks like when we bring it in. So the way this is working, if we jump to forward one slide, is we have this diagram here that illustrates the podcast creation process and automation. So at the very start you have Megaphone, and you have your content creators creating all of your podcasts and podcast episodes inside of Spotify's Megaphone Platform. This includes not only the episodes and podcasts and its metadata but also any podcast cover art. So we built a service that lives within AEM Cloud Service, that's the middle blue square here on this diagram. And that service calls out to the Megaphone APIs. The reason we needed this solution was that Megaphone's API had rate limits so we could only make one request a second. So it's not a good enough API limit that we could dynamically pull this content directly from the API. So what we did was we persisted that content into the AEM system as you see here again in the middle on blue into content fragments. So we synced that content down from Megaphone into AEM Cloud Service content fragments. We also grabbed any of the podcast cover art associated with the podcast or Lentepisodes and automatically married that relationship up between the DAM and the content fragment. Once we have that, we're able to do a couple of things. So we have page requests coming into the website. Any of those podcasts that you land on are dynamically being called to a GraphQL endpoint to provide all of the content that you need to render that page out. The second challenge we had was, well, what about all of the listings? We have, again, there's 49 podcasts in growing, there's some of them have 1,000 episodes and on the podcast page, we need to list all of those episodes in a performant way that's not going to slow down the site and take away the benefits that you get with Edge Service. So the way we achieve this is on the side of page requests for any listings that we have for podcasts, we are also running a GitHub workflow which synchronizes the content from the GraphQL API into OpenSearch. So then we're able to take advantage of the capability within OpenSearch to quickly provide fast response times that are filtered and faceted based on the needs of each of those podcast pages.

And just to chime in here from the business and product side, like, it was just not practical for us to manually publish these podcasts, right? Our editorial teams and our content creators would upload it into Megaphone, right? And using the stuff that you guys built, it was dynamically populated. It was automatically on our site as soon as they hit Publish on Megaphone. We didn't need to do any lifting, right? So that's the beauty of having these dynamic pages that auto-publish. Yep, this solution here is fully automated, so you can make a change in Megaphone, and you'll see that change probably within 5 to 10 minutes on the actual REVOLT website. So that includes not just new content but any updates to content. We're able to find those during the sync process and delta any of those content changes into the content fragment which is again then persisted within AEM Content Fragments in Serv 2, both OpenSearch and Edge side. Right. Yep. So if we jump forward, there's a couple other use cases we had. So in addition to publishing to the website, REVOLT also needed to publish to Apple News at the same time. So the way this worked was, based on the article that was being published, we'd look at the categories that were applied to the actual article page and we built a mapping using the document-based authoring approach of spreadsheets to say if this category exists on this page, map it to this Apple News category. They have their own categories within the system. So we had to create a mapping. Once we had that mapping, we were able to determine which of the articles that were being published should go to Apple News. So we have that, sort of, control, built as a mapping within a basically, a spreadsheet. It's kind of the power and simplicity of document-based authoring in Edge. So once we do that mapping, we see the article's published, that publish event kicks off and work as a GitHub action, we're able to then fetch that publish event request, pull the page, get all of the information that Apple News needs, and immediately at the time of publish, we are publishing all of that content to Apple News via API call.

So the other solution here is Getty Images. This is a quality-of-life improvement we wanted to make for the editorial team. So they heavily used Getty Images across the whole website. And previously they would go into Getty, they'd find their images, they would download them and then maybe make changes and then put them into their WordPress site. Nowadays we've automated that so that as they go through and curate any of the images they want to use on their website, they don't even have to download them. All they do is favorite them as in adding them to a board as you see here in Getty. And we have a service within AEM Cloud Service that pulls those assets that the team curated back into the DAM. And once it's in the DAM, you can make it take advantage of the asset selector within the Sidekick of Edge.

And you had a few other customizations, right, regarding quality of life for the editorial team? Yes. Thank you. So up at the top, we're just looking to make sure I'm in the right order. We have our SEO tool. So it's more than just an SEO tool, but at the basis the real need was we needed a pre-publishing checkpoint so that when authors curate the content and they go to preview the content, before they publish it, they needed a way to quickly analyze the page and make sure it's meeting all of the SEO recommendations. This is one of those gaps that we were trying to cover coming from over from the WordPress platform as they had Yoast SEO implemented and we wanted something similar to that 'cause when you're authoring an article in WordPress they could immediately see, "Hey, this title's too long, this description's too short, keyword density is not great." So the way we did that is we built the tool into the Sidekick, which is extremely extensible 'cause it's just a Chrome extension. We're able to, at publish time, an author would open up the SEO tool and be able to quickly analyze and get as you see in the very top right there, a page status that says, pass, warning, or failure. So based on that page status, the author can quickly immediately know, "Hey, this thing passes I'm good to publish." Or if there's warnings, they can scroll through there's a lot more than what you see here. As you go down, as I called out, there's more than just SEO. It was critical because we're using document-based authoring that we solve some of the challenges of not having an object-oriented system. So one of those challenges is, again, all of these pages have categories, tags, and authors being applied to them. Now those things don't exist as objects like they would in classic AEM, so we need a way to standardize and simplify the process. And I'll get to a bit on how that happens but essentially the SEO tool is verifying that the categories tags that were authored in the page by authors are actual categories and tags that exist within the taxonomy. And for REVOLT, we set that taxonomy up as a spreadsheet. So you have the same hierarchy you would have in other taxonomies within your CMS platforms. So that takes us into the editor assist tool. This is at a point of editing. Before you preview or publish your page, the authors can have this tool to open up in the Sidekick that gives them quick access to copy and paste specific data points that are needed within the page. Those include a post ID, a publishing date which has a specific syntax. We didn't want to make it hard for authors. Again, this is a quality-of-life improvement. So we included a date picker so that they could choose the date. It allows them to quickly copy and paste that into the Word document, into the syntax or the date format that we needed. And further down, what you don't see here, you see the selected categories and tags. There's actually a full tag selector built within this that is powered by, again, that taxonomy spreadsheet. So there's categories, tags, internal tags, and authors that are all managed within a spreadsheet. And once those exist within that spreadsheet, we quickly publish it, and this tool will update. And again, as I said, if you were to scroll down here, there's a fully searchable and filterable tag selector. And when you select the tags, we populate the selected category and tag in internal tag sections which allow them to quickly paste that content into the metadata of the page, thus providing a tremendous amount of power to the website 'cause now we can find pages that are flagged with specific categories and tags and create specific article listing, so it was now like business critical that they had a way to simply author it, but actually author it consistently. That's where the taxonomy came in. And it just gives us our team a lot of confidence, right? Like, we can make sure that what we are publishing is accurate and we are optimizing our SEO and data is valid a lot of those issues have been resolved because of these custom integrations. Yeah, and I think from what we've heard from people as we're talking about Edge Delivery Services, they go, "Well, where is that? I expect that. It's been in AEM for 10 years." And so our goal wasn't to try to reinvent the wheel, but we said, "Well, let's take the best parts of AEM that content authors know have established workflows around, and then let's bring it into Edge Delivery Services and try to get that DNA into the implementation here at REVOLT." And I mentioned earlier bringing value to the ecosystem. This is now something that anybody extensively could use.

So the last one on here is our page publishing scheduler. So Edge Delivery Services including the document-based authoring has a way to schedule pages for publishing, but we, again, needed a way to simplify that for the editorial team. We didn't want them to have to worry about, "Hey, did I author the format of this date properly so that it correctly flows into things like OpenSearch and all of the other things that we use across the website that are date powered or filtered by and ordered by date." So the way we did that is we built another Sidekick extension that is giving them a simple date time selector. And when you select the date time, it's going to copy that date format, convert it into the format that we want. And it looks very simple. On the back-end, it's extremely complicated. We built a Microsoft Graph API integration within Cloud Service. This tool calls to that with the modified date, and then it commits that date that was scheduled into the out of the box Crontab Spreadsheet that powers scheduling your pages within Edge Delivery. So again, looks very simple. It is simple for authors to use. Make sure that we keep consistency is the end goal with this, again, authoring quality of life. And yeah, I think it works great. And it's kind of backing into some of the features that you're lacking when you move to a document-based authoring when you're giving those things up with a move from a CMS into this platform. They're very easily solved by creating solutions similar to this. And this was just very important for us given the freelance nature of our writers. You know, we needed something easy for them just to drop into, something they were familiar with, but something where they couldn't go wrong, where they couldn't lose an article. And so the site quality of life was not quality of life, it was vitally important or else we wouldn't be able to work site the way we would use it.

So let's talk a little bit about results. So you've been live for what a month now about that? Yep. Did Rishi, Stephen, did you have any expectations of what, kind of, results you were going to get right after you went live? Well, I think with any, kind of, website migration, right? Because the CMS migration is apretty extensive thing that you're doing, you go live, your page is going to get reindexed, right? We don't know what's going to happen with Google. Are your numbers going to go down? So I think we were just very we were holding our breath. We were taking a wait and see approach, like, what's actually going to happen. We've done a lot of other migrations in the past and our numbers didn't perform to our expectations, so we were holding our breath.

Yeah, and Rishi and Stephen have my cell phone number, so I was expecting that call, like, "Hey, Hix, where are my metrics at? How long am I going to wait?" So yeah, what I was expecting. We were a little nervous.

So can... If I show the results to everybody, can I assume you're happy? Yeah, so I mean, obviously, we were looking at our pre-to post-launch metrics and very, very happy to say that our page performance has improved by 86%. We've doubled our average visit length. We've improved our programmatic ad viewability by 41% and most importantly, we've increased our ad impressions by 61%, right? And we're absolutely delighted by the results and it's just really validating that we've made the right decision to go with Edge and also right decision in terms of our implementation partners. So just want to give a very quick shout out and thank you to Darren and Jillian at the VIP team. Really want to thank the Protiviti folks here, Dan and Stephen Pfaff, and also to our REVOLT team, right? Just done a fantastic job all around. It was a team effort. Like I said, CMS migrations are not easy. And we're very happy with the results. Yeah, and I mean, this is why as Protiviti we're bullish on Edge Delivery Services.

You know, obviously, the warmth and affection they have for the site so far and the work that's been done, but also just the results. We had a hypothesis as we were proposing that you should consider Edge Delivery Services, which is if the page loads faster than the ads load faster. And on our team, we consider ourselves stewards of our client's business. And so to be able to come to the end of it and say within a month, we've seen that hypothesis be proven true, and it's having a real meaningful impact, on the business it's having a meaningful impact for the editorial teams and the visitors ultimately, that are coming to the site and engaging with REVOLT. So it's why we're so excited about the technology.

Yeah. I mean, these results were great. I mean, you look at the performance graphs and there's, like, a line and then it just goes up and then there's a new line. And that's just so exciting to for us to be able to see and to be able to show the executive team at REVOLT who kind of didn't know what we were doing and, kind of, signed off a lot of money. But to be able to show these numbers was a great result for us. And it does take a special type of company to be able to go and pioneer with folks like us and Adobe on this to have the belief in engineering, the belief in ingenuity to say, we don't necessarily see how we're going to get through it. It's not that I don't know. It's that I don't know yet. And then we'll go, and we'll figure it out together, so credit to REVOLT and you guys and Shantanu and everybody over there. Thank you.

So I have to imagine you've got more things on your roadmap, more things you want to accomplish. - What's next? - Yeah. So we're finishing up some of our, integrations with, like, Adobe Target and personalization there and we are looking forward to doing some AI integrations, - Steve, you want to talk about that? - Yeah. I mean, I don't think it would be a talk at Summit 2024 if we didn't mention generative AI at least once. So we were looking at that.

One of the things we're very cautious of is that we value the distinctive voice our writers bring to the site. So that's something that is very important throughout REVOLT for the creators. And so we want to be cautious how we use generative AI, but we think it can bring a lot of value, as part of the assist tool. So around optimizing our content for SEO, improving keyword tagging, just improving discoverability and things like that.

And what's next for Protiviti on thinking about Edge? - Anything? - We're going to take a nap. Okay. No. No. No. We're so emboldened by the results that we've seen that we're talking to all of our clients about it and saying, "Look, you need to consider this." You need to look at if you're on-site classic and you've been using it for 5, 10 years, let's identify the parts of your digital properties where it makes sense to apply it. Let's run the test. We have data now that says that this works for real business cases. And we've got a point of view on how do you make certain types of trade-offs along the way. What decisions do you need to make to make it successful and for us I think we went end-to-end on this may be like it was four-month complete cycle and our message to the market right now is that that's only going to get compressed further, right? We don't have to re-figure out page publishing scheduling again, right? We've got that one in the bag. So it's really about evangelizing with Adobe about the benefits for clients. And I think demystifying it a little bit and hearing from us as practitioners that have built and implemented and wrestled with the solution a little bit, and being able to share that with folks.

- Awesome. - Yeah. I think that's an interesting point in, hopefully, we can be a case study now for how this is. You know, when we first pitched this to our bosses, they were like, "Who else is running this?" And we kind of said, "There's a few sites out there." And they kind of nodded and went along with it. But now, we've proved you can do a big site, 60,000 pages and counting. So and it works. And taking a site with a lot of custom integrations and building that, right, into the Edge Platform. So I think it is absolutely doable.

Awesome. I want to thank you all for sharing so much. And thank you so much for joining us. We appreciate it and going on the journey with us. And thank you to our panel, and thank you to Stephen and Rishi. We appreciate you joining us.

- Thank you. - Thank you.

[Music]