ÃÛ¶¹ÊÓƵ

Transcript

Good morning. Welcome and thanks for joining today’s session focused on foundational architecture needed to enable the CGA vision. My name is Julie Egbert and I work in ÃÛ¶¹ÊÓƵ’s field engineering group as a principal solution architect where we focus on helping customers get as much value as possible from their ÃÛ¶¹ÊÓƵ solutions. I’m going to go ahead and kick off our session today. First and foremost, thank you for your time and attendance. Just to note that this session is being recorded and the link to the recording will be sent out to everyone who registered after the meeting has concluded. This live webinar is a listen only format, but do feel free to share any questions into the chat in our QA pod. Our team will try to answer as many as possible there. In addition, we have reserved time at the very end for you guys to, for us to go through and answer any questions. Also at the end of the session, we have a poll and it’s really helpful. We’d love to have you fill that out because it helps us get good feedback about the value of presenting these things. So without further delay, today we’re joined by Steve Pelhan. He’s a senior customer success architect at ÃÛ¶¹ÊÓƵ. Steve brings deep expertise in digital experience strategy and has spent over 13 years helping organizations transform their customer journeys using ÃÛ¶¹ÊÓƵ solutions. So take it away, Steve. Yeah, thanks Julie. Like Julie said, my name is Steve Pelhan. We’re going to be talking about the foundational architecture needed to enable a CJA vision today. Before we do that though, I want to give us a little bit of context into why we’re having this session in the first place and really why we’re doing this series of webinars. A few years ago here at ÃÛ¶¹ÊÓƵ, we interviewed 100 execs with the goal of identifying some of the most common barriers to realizing value, particularly with the ÃÛ¶¹ÊÓƵ Experience platform.

Then we took those insights and they really became the foundation for this value realization framework that we use today, right? So this is a cross-functional programmatic approach to help guide customers on the path to value, really trying to ensure strategic planning occurs. It’s activated and it’s measured across all of these five pillars because these are the pillars that we realize sort of represent a critical theme tied to delivering value. And we found that the absence of strategic planning within any one of these pillars is often the root cause for failure. So each session in this mini series is going to highlight one of these pillars from the framework and share key artifacts to support strategic planning and accelerate value realization within your organization. So for today’s session, we’re focusing on the technology pillar and the key artifact related to this pillar is the North Star architecture. So this artifact is really the best way that we’ve found to ensure that strategic planning occurs, is activated and is measured in this technology pillar. And this context is going to be super important to help us frame this whole discussion today. Yes, we’re going to be talking about foundational architecture needed to unlock the CJA vision, but we’re doing that through the lens of this value realization framework and talking about the North Star architecture artifact as a tool for ensuring that we realize value from our technology through strategic plan.

So with that context in mind, what are we actually going to talk about today? So we’re going to start with just talking about making sure we’re all on the same page when I say foundational architecture, right? What does that even mean in this context? From there, we’ll talk about the key artifact for the technology pillar again, which is the North Star architecture. What is it? Why is it valuable? How do I create one? How do I use it? And then we’ll do all this through the lens of CJA, customer journey analytics. So let’s talk about foundational architecture for the CJA vision. What does that even mean? Maybe you’re coming from ÃÛ¶¹ÊÓƵ Analytics and you’re thinking about architecture in that lens, right? From ÃÛ¶¹ÊÓƵ Analytics, architecture was a fairly simple and straightforward process. We had a few sources of data, right? We had maybe our web data, mobile data, maybe classifications if you’re using that. And then I’m sure there were a few small percentage of people who were successful in using things like transaction IDs and data sources within ÃÛ¶¹ÊÓƵ Analytics. But a lot of that architecture was pretty strictly defined. You could or couldn’t use how you could get that in. And it was largely baked around that idea of data and how that was contributing to some of those digital efforts that we were doing. So with ÃÛ¶¹ÊÓƵ Analytics, when you think about architecture again, you might be thinking about an SDR, right? What EVARs and events are we even tracking? How do they match to that web behavior? Where’s that data even coming from? Maybe you’re thinking about your data layer. What data is actually present on the page? How are we leveraging that? How are we populating that? Or you might be thinking about ÃÛ¶¹ÊÓƵ tags, right? How are we actually connecting the data that’s on the page into the Analytics platform? So is this what we mean when we’re talking about foundational architecture for CJA? Well, maybe you have a little bit of familiarity with platform, ÃÛ¶¹ÊÓƵ Experience platform. And then you probably know the answer that we’re talking about a little more when we’re talking about CJA. So maybe when I talk about the foundational architecture, it’s summoning visions of XDM schemas for you. What specific fields you’ll be mapping your data to. Maybe you’re thinking about the Analytics Source Connector versus Web SDK. Or maybe you’re familiar with one of the promises of CJA, which is connecting different data sources. And you know that that requires a consistent personality to really stitch those data sources together. So maybe that’s what you’re envisioning when we’re talking about architecture. Or maybe you’re even thinking about in CJA, what specific data views you’re going to create and how you’re going to curate that to actually realize that value and do that analysis with CJA.

Maybe you’re thinking about data sources. Where is our data actually coming from? Remember, we’re talking about CJA now. So that answer is going to be a lot broader than it was when we’re thinking about ÃÛ¶¹ÊÓƵ Analytics. Where Analytics was really strict with the data that you can bring in, CJA is absolutely not. So maybe you have your web data, but how are you actually tracking that? Are you using Web SDK? Are you using some third-party tool to get that data in? Are you using App Measurement? Or are you thinking about the Source Connector? Maybe you’re leveraging mobile analytics. Then what about non-web data? CJA is really, really set up to stitch these disparate data sources together to give us this view into data previously. We couldn’t really do this analysis on. So CRM data, maybe you have brick and mortar retail sales. The list really goes on and on, call center data, whatever it is. Maybe that’s what we mean when we’re talking about foundational architecture, right? But foundational architecture actually can also mean something very different based on what vertical you’re in. The sources, schemas, views, etc. that an e-comm-only retail company needs, it’s going to be really different than a company with a full set of dedicated sales reps, B2B, and 12-month sales cycle, right? So the foundational architecture needed to enable the CJA vision. Whose vision are you even talking about? So the answer to that, of course, is your vision, right? You, the person listening to me talk right now, your company’s vision. But how do you actually quantify that? How do you document that? How do you understand what that vision actually means in terms of our technology? How do you plan for it? How do you execute it? How do you measure it? What’s foundational to you isn’t necessarily foundational to somebody else. And we’re sort of past the analytics, ÃÛ¶¹ÊÓƵ analytics world. It’s past the time when that sort of view was enough. When only having insight into that online behavior was enough for us to really get the insights that we need to stay competitive. That is obviously still a foundational piece of this architecture. But some of our companies have their goal of actually reducing call center volume. Or they don’t have a huge online presence, but they have a robust sales center. And so the main goal is when you’re thinking about reducing call volume, you’re going to have to have a rich behavioral data. Sure, you’re going to have to know what those visitors are doing before they actually call in. But you’re also going to need to sit to that data with the call data to actually do that analysis. And then you’re going to need to discover that intent and identify sort of what happened that pushed them into that call. And you’re in that sales B2B style of business, your needs are going to be really different. So you’re going to need that robust CRM system. You’re likely you’re going to want to be pushing data out of platform to your sales reps so that they have access to it. And so when ÃÛ¶¹ÊÓƵ is talking about this technology pillar, the value framework, right? Remember our context here. When we’re talking about strategic planning, execution, and measurement, our answer to this really custom question is the North Star architecture. So what’s foundational to you and your company? It might look something like this, right? We have our web data shown on the left. We have our content creation process shown here. This is generic, so I haven’t put in specific vendors or non-ÃÛ¶¹ÊÓƵ solutions in here, but we can see the data coming in. We can see it getting populated into analytics, moving into platform, getting pushed out target, AJO, and Marketo in this particular example, and then finally getting pushed out to some of our other platforms as well. So that’s one example of a North Star architecture, but really what is a North Star architecture? Remember we’re thinking about this as a tool to answer that question of what is foundational to us? Where do we need to start? And then where are we going? So here’s one example of a North Star architecture. We can see that this one’s really focused on CJA. It’s zoomed in really on this CJA lens. So we’ve actually gone through and we’ve labeled a few of the different most important connections. We’ve put a few additional descriptions and details around each of them, and we can see where the data is being brought in. We’re showing how it’s being enriched, and then how we’re actually planning on using it within reporting and analysis. So this is one version of a North Star architecture that achieves its goals for a particular customer.

And here’s another version, right? So we can see that this one we haven’t specifically called out any specific arrows or connections in this piece. We haven’t detailed necessarily steps to showcase one specific use case in this one, but we’ve added a few additional platform products into this few. We have some explicit call outs on timing. We can see call outs for streaming versus batch data, for example. And this is another North Star architecture that’s working and trying to achieve some different goals than the previous one for a different customer with different requirements and use cases. And then finally, here’s one more that I wanted to show, right? Right off the bat, we can tell that this one is much less generic. We have specific companies here showing data coming in, and it’s not even just data going into the ÃÛ¶¹ÊÓƵ platform, right? We can see some information coming into Salesforce over on the left before it even makes its way into platform.

And so what’s the point of showing these different architectures? Well, which one of these is the right architecture? Which one of these is actually a North Star architecture? And the answer is that they all are. Like with so much of what we do, the answer for what you need and which one is right is going to depend on you and your company, your audience, and your specific use cases. Do you have any architecture already in place? Have you built a North Star or do you have just current state? What is your current level of detail with this and experience with this? Because that’s going to dictate what makes the most sense for you to create and leverage and use in your, maybe not day-to-day, but semi-regular basis and cadence. So taking a step back, what is a North Star architecture really? At its core, all we’re talking about is a high-level architecture diagram showing your marketing technology solutions and how they connect, right? How is data moving from one to the other? How are you actually using it? How does this help you achieve your use cases? So when ÃÛ¶¹ÊÓƵ specifically is talking about it, we’re talking about it in this terms of this technology pillar of the value framework. I think I’m going to say that phrase four or five times in this webinar. So we’re talking about North Star architecture at a strategic high level and a use case driven lens. We’re really talking about this as a way to help align and connect the business and the technical teams. We want to think of the North Star architecture as a strategic framework for translating our business goals, our KBOs, and our use cases into concrete technical requirements, but we want to do it in a way that’s accessible to both our business and our technical teams. So a few things that we like to think about when we’re helping our customers with the strategic planning around their technology, right? And that’s why we’re doing this. That’s why we build the North Star architecture. So when we’re doing our strategic planning, we like to use these NSAs, and we say NSAs should be a future state. This is about where we are going and what we’re trying to accomplish. So this does not mean that there’s no point, that it’s not worthwhile at all to draw up on the architecture based on our current state. You have to know where you are to know where we’re going. You can’t identify a gap if you don’t know what you have today. And this doesn’t mean that you need to design your North Star architecture with every possible future use case in mind, right? I have seen so many people trying to design with every possible use case in mind, and it paralyzes them. So NSAs need to be limited in scope. And when I say this again, I don’t mean, what I mean is don’t plan for every edge case, don’t plan for every eventuality. We have to start at a place where we can actually do something, right? Obviously, we don’t want to design ourselves into a corner. I’ve seen clients when they were first getting started with platform, bringing everything they possibly could and promoting it to the profile in a platform. And that has serious licensing implications for profile richness or total data volume in your profile. So there are some things that you need to think about and consider when you’re building out your North Star architecture that are truly future state long-off considerations. We don’t want to wall ourselves in or make it so that we’re stuck in this sort of local maximum line. We can’t back out where we have to redo a substantial piece of our work, but we do need to do this in a way that it is still actionable and that we’re not trying to overdesign our architecture, overdesign sort of our technology in general. We want to focus on the highest value in those most urgent and pressing use cases because, and I can’t stress this enough, the NSA is intended to be a living document. I can’t tell you again the number of times I’ve talked to clients and asked if they have an architecture already and come to find that it’s two years old. It was created when they initially bought the product based on the use cases that they had at that time, which two plus years old at this point. And that is not serving you in the way that we intend this tool to be used. And it’s not going to serve you and your business with that strategic planning. It’s not going to help you execute on that. These are intended to be updated regularly and really we recommend sort of reevaluating every time you’re reprioritizing your use cases. So whatever cadence you’re using, whatever process you’re using, really try to integrate reviewing your architecture as part of that. And then this is also going to prevent your implementation from getting stale. It’s going to give you additional capabilities to sort of be working toward and use cases to be working toward and unlocking.

So with that in mind, when I think of Northstar architectures, generally this is the level of detail that I picture. I wanted to call this out because there’s all sorts of different depths that you can create a Northstar architecture app. And from those examples, I wanted to make it clear that there isn’t one of these that’s right and one of these that’s wrong. It is like so much of what we do, context dependent. When we’re talking about using a Northstar architecture as a tool to help align a business on a technical team, likely this level of detail is what’s needed. There may be some technically minded people on the call who are noticing that some of these arrows are kind of a lot of heavy lifting. Number one, for example, just collect your behavioral data from your website. Obviously there’s a lot going on in that one arrow. But at the end of the day, when we’re using this as a strategic framework to prioritize and align our business and our technical teams, that arrow is often all we need. We need to implement Web SDK and it unlocks these things for us. Likely your business team doesn’t need much more detail than that. We are working on implementing Web SDK and once we do, it unlocks these things. And I say often, so that’s often all we need. But again, I showed those three examples to show that there is time when going deeper into the weeds, the technical weeds or the technical architecture can be really valuable.

If you’re technically minded, you know that number one is not an easy thing to do. There’s way more to it than just drawing one arrow on a diagram. And there are times where building that out and adding more detail and zooming in on just that one particular piece or even all of this as a whole, zooming in on all of this and showing that level of data latency, order of operations, any sort of customizations, calls that need to be applied, third-party APIs that may need to be created to show sort of the level of effort or to just make it clear when we’re working on that alignment exactly sort of the lift that’s being requested. So and sometimes just going through and building that deeper technical architecture helps the technical team translate that specific use case into hard and fast technical requirements. So I really like these visualizations on a lot of different levels. And then it’s really about keeping in mind our context and the strategic planning and value realization lines we’re talking about today is going to focus more on this high level. But diving deeper is totally appropriate in certain settings. I’ll leave that up to sort of the listener to determine when and where it makes the most sense to have that additional level of detail. So that’s what a North Star architecture is. I’ve alluded a little bit to some of the value of a North Star architecture, but let’s just call it out explicitly. Before we go into the next slide, I just want to take one step back to the survey that we did in the first place that led to the value realization framework and NSA specifically. What we were hearing from the executives that we talked to were blockers and what were sort of some of those blockers to them realizing value, right? What happens if you don’t have a strategic plan for your technology? Well, there’s a misalignment. The technical and business teams can be working across purposes, right? I’ve seen business teams creating use cases that aren’t viable, ending up wasting time sort of designing an analysis in CJA or a journey in AJO that just isn’t feasible with the technology in the state that it’s in right now. And then I’ve also seen the counter of that. I’ve seen tech teams creating really burdensome limitations, some somewhat arbitrary restrictions on what data you bring into the data lake or what data you’re allowed to promote into the profile or things like that. And that sort of misalignment and that sort of misunderstanding about what is trying to be solved for with this technology can create that challenge. Understanding the value that we’re creating by unlocking a specific use case or the value that we’re trying to create by implementing a new solution capability is the root of what we’re doing with this technology. Why we’re using these tools in the first place is trying to create value. And how we measure that value, what that specific value is, is going to be unique to every person on this call.

But having no strategic planning around this technology pillar is going to make that much harder for the teams to see and much harder to work in a line. The next one we heard about was sort of mis-prioritization. That same thing about value, right? If you know the value, you can look at the highest value, highest priority use cases. I can’t, again, the number of times that I’ve heard a person or a team who’s working to implement a feature sort of just because one person asked for it or because we have the technology, the technological capabilities to do it, so we’re going to do it. But what if the business team isn’t even planning on using that feature? You know, we don’t have the resources on our team to actually stand up a campaign like that, so there’s no point to actually implementing that yet. So getting that prioritization piece in place is huge. And then the last big refrain that we sort of heard is my implementation is stale and it’s outdated. You know, the speed at which we are iterating and making improvements on these products, it’s really impressive to me and it feels wildly different than what it felt like when ÃÛ¶¹ÊÓƵ Analytics was sort of the primary driver of this. So we get people really easy to get comfortable on what you have, just keep using the features that you have and not pushing forward. The problem with that is your competitors aren’t doing that. Somebody out there is pushing us to the edge of what you do and if you’re not moving forward, you’re going to be falling behind.

So from the other lens, how does the strategic, how does the NSA specifically help with this? Right, so first it’s going to give us this holistic view of the technology and our implementation. You know, from the business team, this can help us clearly show what data sources are being adjusted, what integrations are in place, what destinations exist. You know, can either implicitly or explicitly, depending on your level of detail in these diagrams, they can answer questions about time. In the specifically in the CJA realm, that’s maybe a little bit less important. A lot of our analysis is not necessarily needed to be done in real time, but there are certainly some use cases to get some faster analysis in place. But when we’re looking at some of the other AP apps like CDP, obviously batch streaming and edge is a constant consideration.

And then for our technical teams, it can really help us identify gaps in the implementation. You know, what piece is missing? You know, this is where we’re going, this is what we need for this specific use case and we haven’t done this yet. It can also help us with prioritization, right? It can help us quickly answer that really important question of, can we do this today or not? And if not, what’s the level of effort together? What value are you actually going to unlock by implementing this feature? And then it can also help us group specific use cases to solution capabilities that you need to unlock. So in other words, right, we might be able to identify situations where we kind of kill two birds or more with one stone. You know, by implementing this one solution capability, by onboarding this one specific data source, by tagging this one piece of online content, we can actually implement two or three or four different use cases that we’re looking to prioritize. And again, all of that in this value lens, right? So the planning piece around this, the NSA piece on this, is the NSA can help you show your current, what you’ve unlocked so far, what remains to be unlocked, and what you want to focus on next, and all with that lens actual value.

And then if that’s not enough, right, we talked a little bit about alignment already, but the NSA is really designed to help with that alignment. So first, I want to talk about this as a use case led piece, right? We really want you to be asking the question, why are we doing this? I know we had the use case session already a few weeks ago, I think, in this series. And there’s a reason that we do this first is because the NSA’s are intended to be use case driven. So how does implementing piece of technology actually tie into our use cases, our KBOs, and our value? I’ve said it before, probably say it again, maybe even on this call, but we want to avoid implementing things just because, just because it’s the next thing on our list. We should always have a clear value driven reason for committing hours and hours of development time to the future. And then how else is it up the line? You know, it shows clearly exactly what the company is working toward. You know, has your CRM data been onboarded yet in AAP? Check the architecture, right? And then finally, it promotes this transparency, right? The teams can look at this one thing, they can look at the architect diagram and discuss and talk about it from a high level planning prioritization lens. Your business team should be able to look at the architecture and have a clear view of what use cases they can actually implement based on what exists or based on this future state that we’re looking at with the North Star architecture.

So hopefully at this point, we know what sort of the problem is. We know what the solution is. And hopefully you even sort of buy in the value of the North Star architecture as a tool to solve that challenge. So now what? How do we actually make a North Star architecture? Well, remember, it’s just a technical diagram, but there is a lot that goes into getting that correct. And so like where we always start, we’re going to do discovery. We have to know what we have and where we’re going in order to create the North Star architecture. So we’re going to ask a lot of questions. I always like to kick this off by asking, do you have anything already? What you have, if you do have an architecture already, is it current state? Is it future state? Is it outdated? Is it no longer something that we’re aspiring toward? When was the last time it was updated? And then what, if anything, has been implemented? Does the architecture that exists support our current use case priorities or not? Do we need to reprioritize, reframe, and rebuild, redesign that architecture? And then I alluded to this before, right? But we had that use case session first because our North Star architectures are always intended to be use case driven. That’s the answer to why are we implementing this? Well, we have a specific use case we are trying to achieve. So as part of discovery, if you haven’t been involved in this before, we need to know what the use cases are. What are the KBOs? And then we want to prioritize and limit the initial creation of a North Star architecture to some specific use cases, our highest priority use cases. We can build out what we have today, and then we can build out based on use cases we’re trying to achieve what the North Star actually looks like. So what products and capabilities are needed to support those use cases? What data sources, if we don’t already have them, do we need to add? All of that sort of information. What different data sets? What are the connecting pieces between those? And then we want to try to capture the appropriate depth. We’ve got a lot of data that we need to be able to capture. And so the journey is going to dictate a little bit how much depth you need to go into and even who you’re trying to build the NSA for.

It’s possible that the NSA is somewhat superfluous for a technical team with a lot of experience who knows exactly what they need to do in order to build these things out. And all they really need is that prioritization piece from the strategic business team or the high level executives to help with that. If that’s the case, then a high level of depth, just getting that alignment from the business teams is what we need for this. If instead we need to understand and have that explicit technical detail in there, you can go deeper with your NSA’s. And additionally, just building one North Star architecture. You can have a high level North Star architecture. You can have a zoomed in North Star architecture based on a specific use case or based on a specific connection that you’re trying to work on. There’s no limit to these architecture diagrams that you can build. Just as we’re talking about the North Star specifically, we want to keep in mind, again, the value realization framework, technology pillar, and what we’re trying to achieve with this particular artifact. And that is the strategic planning, the executing, and the measurement of that strategy. And so for this, typically, the depth that we want to start at is that high level so that we can get that alignment between the different teams. As we’re doing our discovery, I wanted to put in some pieces specific to CJA. When we were setting the stage for what foundational architecture even means, we were asking a bunch of these questions with these different lenses. And the point isn’t that those questions don’t matter. It’s just that they need the appropriate context. So now that we’re doing our discovery, we’re building our NSA, it’s time to revisit some of those questions. So for more specific CJA discovery, we got to dig into what data do we currently have? Do we have a CRM system, call center, offline sales, online data? Do we have an existing ÃÛ¶¹ÊÓƵ Analytics implementation? And this is a great time to call out how easy it is to bring an existing implementation into CJA right now, an existing ÃÛ¶¹ÊÓƵ Analytics implementation. I will admit that this was not always the case. But at this point, with new features that have been released, new, I believe a year old at this point, if not more, it can be pretty easy to bring your existing analytics implementation in to CJA. And it’s worth calling out that there, even if you bring no other data into CJA, there is still value in moving from ÃÛ¶¹ÊÓƵ Analytics to CJA. That’s sort of another webinar. It’s probably been given already. I think we’re going to find some information on experience. But there are a lot of feature enhancements with CJA that provide a compelling reason to make the update. But we’re talking about getting our online data sources, doing the discovery with CJA. So where is your existing online data being recorded? Is it ÃÛ¶¹ÊÓƵ Analytics? Is it App Measurement? Web SDK? What does that look like? Because that’s going to inform exactly sort of the speed at which we can do our analysis, the speed at which that online behavioral data can be used as a trigger in AJO or for audience qualification in real-time CDP. The next is talking about some of those person IDs, right? If we’re bringing in different data sets, can we actually sync those together? Do we have a consistent person ID that’s available in a way that we can do that stitching? And then what sort of integrations, right? Are we going to be exporting our segments out of CJA? If we define a new audience from a good piece of analysis in CJA, can we actually activate on that? Can we push it to CDP and out to our destinations so that we can actually start doing some marketing toward that? And then what about target reporting, right? Are we going to be doing our ÃÛ¶¹ÊÓƵ target reporting in CJA? Are we using AJO? What sort of integrations exist? What sort of third-party non-ÃÛ¶¹ÊÓƵ solutions exist? And how does that data move from CJA into those other systems? So there’s lots and lots of questions. These conversations, they can last a long time to get this initial picture of what exists. And this is sort of why we talk about limiting our scope, making incremental improvements, and starting somewhere, building something and not getting paralyzed by this sort of overwhelming amount of choices and data that we have available in the cloud. Once we have all of those questions, how do we actually make the diagram? I’m not going to go into a demo of using diagramming software on this. There’s a ton of online tools to support this. We tend to use Lucidchart here at ÃÛ¶¹ÊÓƵ. So that’s kind of the one that I can speak to, but there’s tons of other ones out there. They all work fine. Use whatever you have, use what you’re happy with. We also have a set of blueprints that are sort of available online on Experience League. There’s a link here. I’ve got a link section at the end of the deck. We’ll be sharing this out afterwards as well. But those can be a good jumping off point for the ÃÛ¶¹ÊÓƵ architecture. And you can bring in some of your other non-ÃÛ¶¹ÊÓƵ pieces into that architecture as well. And then finally, you can work with us here at ÃÛ¶¹ÊÓƵ. I can’t speak to every person’s individual settings, so reach out to your account team and they will help put you in contact with the right people to help with this. Finally, after you’ve built your NSA, how do we actually use the NSA? And so I wanted to just take a few minutes to talk about some different ways that we can do this. We’ve created the NSA. Now what do we do with it? We’ve talked about using them as part of the strategic planning and ensuring alignment across team. We’ve talked about prioritization, identifying gaps, sort of even what we can execute today. What else can we do? And I don’t want to undersell those other pieces. I think those are really the most compelling reasons to build and use an NSA on an ongoing basis and integrating it as part of your process. However, from our discovery, we should really have a very robust understanding of our current capabilities and what we need to implement to activate our use cases. So we can use that NSA to translate those gaps into actual technical requirements. So we identify those gaps and then we can translate that into actual requirements. We were talking about how some of those arrows on those high sort of low-depth diagrams are doing a lot of heavy lifting. Well, you can translate that into concrete Xsteps for the technical team. We can build up project plans and timelines and we can do that through the lens of actual value that we expect to unlock because we’re doing this through the lens of specific use cases. And then you can also go deeper on those specific use cases. You can use that high-level NSA to zoom in on a specific use case and detail the steps needed to activate that use case. Data comes in, data gets refined, manipulated, enriched, and data goes out.

So I just wanted to give an example of a full-state NSA here. This is a generic retail example, but you can imagine customizing this with specific partners and vendors to make it your own. But we can use this to identify some gaps, like, oh look, we need RT-CDP in order to activate our audiences, but we haven’t stood that up yet. Or we really need the apparel inventory for this restock notification use case that we have. Or we need that information to identify when our site is actually putting in the incorrect information or when our visitors are unable to actually complete their purchase that they want to. And we can use that notification to drive our analysis in CJA of which products are consistently understocked, for example.

And so understanding those technical requirements and implementation work necessary for specific use cases that can come from looking at this NSA. And then it can also help us see which use cases can be activated immediately, especially if you’re working with a current state architecture and a full state aspirational North-Start architecture.

I wanted to talk about a specific CJA use case as well. So here we have an example of enriching your behavioral data with additional CRM data. We can see sort of the flow is diagrammed out how this data is coming in. We have our expectation here with this specific use case is that current state already has our online behavioral data, and now we’re trying to enrich it with the CRM data. So first we’re connecting Salesforce to pull that CRM data in. We’re using platform to get that in usable form and CJA to connect that data with our online behavioral data. And then we’re using Workspace to actually build and do our analysis. And then finally from there, we can export that audience to CDP and then activate it and use that enhanced audience in our marketer view to trigger nurturing or personalization or even add suppression logic.

And then finally, today we’ve been largely focused on CJA, but I just wanted to loop back to this diagram from the beginning and show a reminder that your North-Start architecture can include all of your marketing technology. Here we have sort of an ÃÛ¶¹ÊÓƵ centric view, but we have a content creation management flow added into this. You can see how AEM is going to be used into target and AJO for use in personalization campaigns. And you can get this sort of this whole picture of what your marketing stack looks like. And you can use this to identify and manage the use cases that you have, you want to prioritize and to get alignment between those key businesses, or those key stakeholders. So finally, if I can leave you with anything from today’s call, I hope really simply that it’s just that you will use a North-Start architecture, that you will start creating if you do not have them already, some architecture diagrams as a tool to help with that strategic planning on this technology piece and for alignment across your teams. I know that I’ve seen these issues a lot. I imagine that everyone on this call has experienced some of these issues within their career at least once, but we really want this NSA to be a guiding light for your technology and that pillar of the value realization framework. So if you as well, we really think you can help address these challenges. So next steps, again, if you do not already have those lists of use cases, we really strongly suggest doing all of this through the lens of use cases, having a why for why you’re doing this and building these specific things that makes it all make sense. It just keeps that alignment in place from there, build and start leveraging the NSA. And then if you have trouble, if you need any help, contact your ÃÛ¶¹ÊÓƵ account team and we’ll be happy to help. So I’m just going to leave a few links here. We’ll pass this as we share the deck and the content after the call. And then now I think we can turn it over to Q&A and I think Julie’s got a little questionnaire.

Yeah, before you guys drop off, I did start a poll. So we’d love to have responses for that if you guys do. And I also included the links to the future events in the chat that you can grab and use to register. And if we have any questions, if you guys want to get them in the Q&A or chat, we’ll do our best to try to answer them in our last few minutes. Good job, Steve.

All right, everybody, I think we have one question around future, the future sessions. I only know about these that are scheduled. So I’ll try to, I guess we can try to find out and answer them. All right. Well, I’m not seeing anything else. Thank you, everybody, for attending and hope you have a really nice rest of your day.