Leveraging a NorthStar Architecture to Enable the Adobe Journey Optimizer Vision

Transcript

And Jas, I’ll let you introduce yourself and talk about your Bonafides, and then I guess take it from here. Sound good? Great, thank you, Jon. Hello everybody and happy Monday. And I’ll just quickly introduce myself. And again, thanks again for joining today’s session. We’ll be focused on leveraging North architecture as a foundational architecture or foundational piece as needed to enable your AGO or Adobe journey optimization vision.

And myself, I’m Jasmedhir Singh, I go by Jas. I’m a principal customer success architect here based out of San Jose, California, the headquarters for Adobe. I’ve been at Adobe for a collective of about 10 plus years, and I’m a cross-solution integration SME.

So with that, let’s get started. And today we’re here to talk about that foundational architecture that’s needed to enable that AGO vision, right? So before we even do that, I want to set some context in why we’re having this session in the first place and why we’re doing this series of webinar, just so you understand the whole VRA concept, right? So few years ago, we’re here at Adobe, we interviewed about a hundred executives with the goal of identifying the most common barriers for realizing the value, right? Particularly around AP or Adobe Experience Platform as a solution. And then we took these insights and they became the foundation of the value realization framework that we’re going to talk about today. It’s basically a cross-functional programmatic approach to guide our customers on the path to value. At the same time, we’re also ensuring the strategic planning, it actually not just occurs, but it also is activated and measured across all these different pillars. So let’s quickly talk about these pillars.

These pillars are the roadmap to value, technology, resource investment, sponsorship, and org readiness. We’re going to have other sessions on some of the other pillars as well, and each of these pillars in this framework, it represents that critically theme to tie to that delivered value and what we found that in the absence of strategic planning with any of them is often the root cause of the failures. So each session in this mini series, it’ll highlight one pillar from that framework, and we’ll share some key artifacts to support that strategic planning and accelerate your value realization within your org. But for today’s session, we’ll focus on the technology pillar, right? And the key artifact that’s related to this pillar, which is Northstar architecture.

Now, this artifact, the Northstar architecture artifact is the best way that we have found to ensure the strategic planning is occurring, activated, and is measured across the technology pillar. And this context is super important for us to help us frame this whole discussion today. So we’re going to be talking about foundational architecture that’s needed to unlock that Agio vision, but we’re also going to be doing that through the lens of the value realization framework. So it’s two things. We’re talking value realization, foundational architecture for Agio. So it’s going to be a combined back and forth discussion. And we’re talking about the Northstar architecture artifact as a tool for ensuring that we realize the value from our technology through that strategic planning.

So with that context in mind, our agenda today is starting with making sure that we’re all on the same page when I say this foundational architecture, right? What does that even mean? So from there, we’ll talk about the artifact, the key artifact from the technology pillar, value realization framework, the Northstar architecture, what it is, why is it valuable? What’s the value you’re getting out of it? And how do you create one and how do you use one? And we’ll get through this, all of this through the lens of Agio as well. So it’ll be Agio focused.

So first things first, I know you heard me talk about foundational architecture a couple of times already now. So let’s see what is foundational architecture for that Agio vision and what does that even mean? Now, well, if you have some familiarity with AP and you probably know the answer to this, but let us say, let us lay that on a slide, this slide that we’re going to talk about. So you’re maybe thinking about, well, what sort of XDM schema will I use or what specific fields I’ll be mapping to for the data? Maybe you’re also debating on using a source connector or the frequency in which that data might be sent like batch or streaming.

While thinking the foundational architecture, also thinking about the identities, the profile merge policies, how they’ll be emerging together, right? To create that unified profile. Perhaps you’re also familiar with one of the promises in sending that one-to-one personalization messaging, but you know that for that, you need to have some unified customer profile already. And it has to be created by tying those desperate sources of data that we generally send towards AP. And you might be even thinking, well, I have all that now, what channels we’d like to use within Agio, email, SMS, in-app, web, code base, right? Excuse me.

So is this what we’re talking about? Is this what a foundational architecture is? Well, maybe to you, yes, architecture could be this, or it could mean different things like different data sources, like where’s the data coming from? So when we are talking data to be sent to a customer platform, of course, it’s web data, right? You always have that. But are you porting that data from an existing Adobe Analytics implementation? Are you using web SDK? Are you also leveraging mobile SDK at the same time to send that data? What about some non-web data, like from CRM, or any brick-and-mortar stores, any loyalty data? So there’s a whole lot, right? The list goes on and on, and we will talk a little bit more about that.

So foundational architecture could also mean something very different based on which vertical you’re in. So the sources, the schemas, et cetera, right, for an e-commerce website or a customer will only have like a retail company needs. And they’re going to be very different from a company with a full set of dedicated sales reps who support a B2B over a longer period of time. Like sometimes those sales are like 12 months, and not to forget multiple buying groups, slower sales cycles, high-stakes transactions, et cetera. So, well, the whole North Star architecture won’t change, but at least some of the things like the schemas or the foundational architecture will be different for these different companies based on the industry vertical you’re part of.

So the foundational architecture needed to enable Asia vision, right? Whose vision are we even talking about? Because we’re talking so many different things on, be it on industry, based on solution. So the answer to that, of course, is it’s yours, your company’s vision, right? Now, but how do you quantify that? How do you document what exactly that means to you? How do you plan for that? How do you educate it? How do you measure it? So what’s foundational to you isn’t foundational to someone else. So we are far past that time and that was enough. It’s like a common boilerplate thing that serves everybody. That’s not the case anymore. Online behavioral data is probably the only piece of foundation architecture that is common through like a lot of different companies, because obviously there’s a lot of online footprint for all these companies. So that’s probably the only common piece, but other things might differ. For example, in travel industry, getting a flight status notification, right? We’ll need to create event-based journeys, streaming ingestion, and that way, a real-time flight delay event gets ingested into AP, but we’ll also need the passenger’s info from a CRM system for that AGO to be able to trigger a personalized push or SMS to that affected group of passengers. Now, while we do that, what’s the value delivered? When you do that, you have engaged customer with the real-time communication, because this is sort of like in real time, you have reduced your call center load and overall improve your customer’s experience.

Well, that was travel industry. Let’s talk about banking, for example. Credit card activation journey. Now, we’ll need to unlock multi-channel orchestration plus decision management. It’s a little bit of an advanced use case, but I just want to throw it out as an example. Now, when a new card is shipped, the journey starts automatically, right? And if this card is not activated within five days, let’s say, we send an email reminder on, oh, activate now and start earning rewards. And if it’s still unopened, the email’s still unopened, you send a follow-up SMS with the activation link. Now, once these things get activated, AGO triggers an onboarding email series past that as well about your overall new features on the app that you have downloaded. So we did all these different things for different industry with different data sources, right? And, but value delivered is still very similar based on your industry, of course. In this case, we have the activation rate that has increased. We have more product information or education being delivered to your customers. And because of all this engagement, we have overall reduced churn. So just some examples that I just threw it out there. Now, when Adobe is talking about the technology pillar of this framework, right? Remember our context here. We’re talking about strategic planning, execution, measurement, and our answer to all that is incredibly custom, bespoke question. And the answer is North Star Architecture. We’ll get a little bit more deeper into that to help you understand what that is. So perfect segue into what is a North Star Architecture.

Now, before we even start looking into real examples, let us quickly talk about the different components of a North Star Architecture, right? And we’ll talk a little bit about, well, what NSA is and things like that. So if you look at this slide, these grayed out sections or blocks are potential components of North Star Architecture. And in the top left, you’ll see about content. So when we talk content supply chain, where’s your content coming from to be delivered for personalization? What are your different data sources, right? And streaming, batch, real time, things like that based on the frequency, what are those data sources being ingested? Then comes the data management and, excuse me, reporting parts. The data management is when all that data gets ingested, how are you creating those audiences, right? That could be also batch segmentation, streaming segmentation, edge segmentation.

We won’t get too deep into that, but just to show you like that is one component of your North Star Architecture. Next one is activation. Once you have all these audiences, you need to start activating on these. That’s the activation part. And then finally comes the destination, which are your different channels, like email, SMS, web, things like that. So I just want you to talk about what are these different components of a North Star Architecture.

Now, here’s an example of North Star Architecture. Now this is AJO focused because that’s what we were talking about in this webinar. And it labels a few and most important connection and provide you some additional details around them. It shows where the data is being brought in from. It shows where it’s being enriched. It shows how we’re actually using it in the journey as campaigns to send those messages through the different channels of AJO. So if you look at step one, it’s collecting all that behavioral data from the website. This is the one we talked about in the foundational architecture part that might be a common data source or architectural component throughout a lot of our Adobe customers because everybody has an online footprint. Next one comes the behavioral data from step one. It gets saved into the data lake. This data lake is Adobe AP’s data lake. Third, the profile data loads from the CRM or the data warehouse store. It gets loaded into profile. And then four, you start pulling audience segments into campaigns and journey that is part of that data management we talked about as a component. Once you have that, you start executing these journeys or campaigns in AJO. And then finally, number six, the messages start getting delivered to your respective endpoints or channels. So this is just one version, right? As a, if you’re a focus example, and here’s another one. Now we don’t specifically call out arrows anymore, but you can see that we have added a few other AP products on top of AJO, right? UCCJ, RD-CDP, right? So we have some call outs on timings as well, like streaming versus a batch, for example. But this is just one other version of NOS architecture.

Now here’s another one. This is more real world example, actually. One I did for one of our customers and it’s much less generic. It’s much less generic in a way that it calls out to specific non-Adobe solutions. Now, every customer is not like, honestly, any customer is never married just to Adobe. So you’re going to have Adobe solutions, non-Adobe solutions, right? So these connections to some of your non-Adobe solutions, even outside your AP stack, it needs to be called out. Now, what’s the point? Which one of these are right? I just showed you three different examples of Northstar architecture, right? Well, all of them are right and all of them are fine. Like with so much of what we do, the answer depends on you. Your company, your org, your audience. So do you have any sort of Northstar architecture already? What level of detail do you have? So that is something like food for thought to go back and see which version do we have today and if it’s a Pfizer leap.

Now let’s get into what is a Northstar architecture? Well, at its core, it’s just an architectural diagram showing you, of course, your marketing technology solutions and how they’re connecting. How that data is moving from one source to another, one solution to another and how you’re actually using it. That being said, when Adobe is talking about Northstar architecture, we’re talking them as a part of the technology pillar of that value framework that we talked about initially. Now, when we’re talking Northstar architecture at a strategic high level and use case driven lens, we’re talking about this as a way to align and connect our business and technical teams. Now, what does that mean? That means that when you are defining goals for an organization, we need to make sure both the business and technical teams are aligned and this tool, Northstar architecture, is going to help with that. We’ll talk a little bit more about that, how that works, but I just wanted to call that out that that’s one of the main reasons why we create Northstar architecture through the value framework.

Now, when we think about NSA as a strategic framework for translating your business goals, for example, your KBOs, your use cases, to concrete technical requirements, but in a way that is accessible to both your business and technical teams. Excuse me.

So, when we say that, a few things that we like to talk about is when we’re helping our customers with strategic planning and on their technology.

Northstar architecture are about future state, where we’re going to be, what are we trying to accomplish, right? So, this doesn’t mean that it isn’t worthwhile to drop an architecture based on your current state, but you have to know that you have to get to a future state and that is the only way you’ll be able to identify the gaps you might have. So, unless you have a current state, you won’t be able to really call out those gaps on what am I missing to get to that future state. But that doesn’t mean that you need to design your current state architecture with every possible future case in mind. Like I’ve seen so many people, they try and design every possible use case in mind and it basically paralyzes them because it’s just too many things at the same time and you end up losing momentum or vision and you’re too much into the lead. So, don’t try to boil the ocean at once is basically what I’m saying.

And that actually brings us to the next point. Northstar architecture, it should be limited in their scope. Now, what I mean is we don’t recommend trying to architect and design every possible use case you might ever want to implement. Well, yes, try not to design yourself into a corner, of course, like when you have to redo something down the road, but then you feel, then you don’t let the fear stop you from doing anything because nothing is future proof. We all know that, like being in industry for so long. So, focus on that highest value and then most urgent and pressing use case.

And the last thing, I can’t stress enough that the Northstar architecture, they’re intended to be living, breathing documents. They’re not one and done, they’re not set in stone. I can tell you a number of times that I walked into a client and it hasn’t updated their architectures since they initially bought their tools.

That’s even if they have an architecture at all. There are some examples that you walk in and we ask for architecture, like, we don’t have it. So, yeah. Now, they’re intended to be updated regularly. They being the Northstar architectures. Now, we recommend you reevaluating every time you reprioritize your use case or you evaluate your use case or you evolve in your use case. So, that’s the time you want to reevaluate your Northstar architecture. And the needs for Northstar architecture can be reviewed and refined to reflect your shifts and from current state, evolving business goals, new emerging challenges, new opportunities, new product features, for example. Technology also changes. And then the progress made towards those milestones that you called out in the previous version. And this flexibility will ensure that the Northstar architecture, it remains relevant, actionable throughout your engagement. Now, whatever cadence you’re using, whatever process you use, make sure you’re viewing your Northstar architecture as a part of that. Now, how it will help? Well, it’ll help preventing your implementation from becoming stale, but also gives you a chance or gives you a cadence for evaluating new features.

Now, with that in mind, when I think of a Northstar architecture, this is generally the level of detail I feature when I’m creating Northstar architectures. Now, technically minded people on this call may notice that some of these errors are doing, excuse me, a lot of heavy lifting. For example, just collect the behavioral data from your website, right? Well, is that it, Chas? Obviously, there’s a lot going on in that one arrow, but at the end of the day, when you’re using the strategic framework to prioritize and align your business and technical teams, that arrow often is all you need.

There’s great level of detail you can put in Northstar architecture, right? But don’t forget what the goal for Northstar architecture is. It’s not a super technical diagram, but let’s say all the different sources calling the different primary IDs, how are they going to be mapped? You can certainly go in that level, but that is not the purpose of Northstar architecture. All we need is, yes, this one arrow going from your web data AP, that’s what you need to understand to make sure, yes, business asked for it, technical feasibility allowed it. That’s the purpose of Northstar architecture. And I often say here that not every team is the same, right? Every team works in a different way. And I’ve showed you previously three other examples earlier in this presentation, and none of them are wrong. They’re just different version of it. And I say, see what fits best for your scenario. I’ve also seen diagrams that go super deep, right? In that technical specifications about data latency, order of operations, different custom API calls, and more so on and so forth, right? Now, these could be appropriate in a lot of different settings, right? Maybe as a technical lead, you need to prove out why one of these arrows for data flows is more than it appears in diving deeper into that topic can help you make your point. So different case will have different scenarios, but it can help with the alignment is what I’m saying.

Now, maybe just the act of diving deeper helps you and your team translate a specific use case into hard technical requirements, right? And now these visualizations basically will be helpful on so many different levels.

Now, keeping that in mind, our context is strategic planning, value realization lens, and this is where we want to start.

So we’ve talked about different examples of version of North Star architecture, but it’s the foundational architecture needed towards North Star AGO lens vision. We talked about what a North Star architecture is, but why are we doing this? What’s the value of North Star architecture? We have alluded to this a little bit, but let’s talk about this directly.

So first, let’s take a step back to the survey we did in the first place that we mentioned, like how this all started with the value framework, right? So the value realization framework and NSA specifically, what we’re hearing from executives that we talked to, what are their blockers, right, for realizing their value. So one of the main things they talked about was misalignment. So the technical teams and business teams, they’re working at cross purposes, right? I’ve seen business teams creating use cases that aren’t viable, wasting time time designing a specific journey in AGO or a campaign in AGO that isn’t feasible technically. And I’ve also seen tech teams creating burdensome limitations, right? Arbitrary restrictions on what data can be brought into data lake or the profile.

We also heard in the survey that the teams, they’re prioritizing the wrong things. I can’t count the number of times I’ve heard a variation of, oh, well, we need to implement this feature or integration or data source. And then when I ask why, there’s a sort of a struggle, like, well, because we have the entitlement, we have it available. Well, just because it’s available, doesn’t mean you should use it. If it really adds some value to your use case or certainly, but don’t think about using a new feature just because it’s there without looking into why you should use it. So what, right? If the business team isn’t planning to use that feature, the technical work to unlock is wasted. There’s no point of doing it if there’s no value.

And the last thing is the big refrain that we heard, well, my implementation is stale or outdated, right? So it’s not really easy to get comfortable with what you have.

Oh, sorry, it’s really easy to get comfortable with what you have and just keep running new campaigns or new journeys based on your existing features and capabilities that you’re used to. But if you really want to move the needle, we need to keep moving forward. So there’s a reason Adobe keeps releasing all these new features. And it’s not just to keep our engineers busy basically. These are actually useful features. And if you’re not keeping up, you’re going to fall behind.

So you’ll lose that edge over your competition is basically what I’m saying. So this is what we’re talking about. It’s like, why are we doing this? Because of value, value, value. This is how you get the most value out of your North Star architecture.

Now let’s talk about strategic planning. We talked about the strategic planning word a lot. So how does a North Star architecture specifically help with this? First, it gives that holistic view of technology and implementation. So for example, for the business team, this is clearly to show what data sources are being ingested, what integrations are in place, what are the different destinations that exist. If you’re using the North Star architecture, using them or not using them, that also depends on the NSA, its current state or future state. And then it can either implicitly or explicitly answer all your questions about timing, depending on which version you’re talking about. And it’s a little less important in the AJO world, but let’s say for CDP example, batch versus streaming versus edge is a constant consideration. So that matters there a lot more than it would in the world of AJO. And for technical teams, it can help identify those gaps in implementation. For example, if your business has asked about a use case, but you don’t really see that, oh, well, it’s not really connected. So that’s where you’re like, okay, let’s work on this out of the box integration for customer integration first, depending on what the ask is. It can also help you with the prioritization. Now it can help you answer quickly and accurately of all the important questions that we can do this today. And if not, what’s the level of effort you’ll need to get there if something doesn’t exist today. What value are we going to get by implementing this new feature that we’re talking about? And if it unlocks any use case that we need the value for.

It can also serve you to help you group some specific use cases to solution capability that you need to unlock in order to execute. In other words, we can get two or more words with single stone.

Now, all that helps point our focus on value. So what value have you unlocked so far, what remains to be unlocked, and what do we want to focus on unlocking next? So that’s the strategic plan piece of this North Shore architecture.

Next is alignment, right? Because if that’s not enough, North Shore architecture can also help with alignment between different teams. We have talked about this a little bit, but let’s talk a little bit more detail in that how this alignment works.

So the North Shore architecture, it should be use case led first and foremost, right? So I really want to ask you the question, why are we doing this? How does implementing this piece of technology ties to our use case for the business, our KBOs and our value, right? And I’ve said it before, and I’ll say it again, avoid implementing something just because it’s there, right? So when everyone understands the why behind the strategy, it creates confidence.

A clearly defined North Shore architecture show customers that we’re in it for the long haul. We’re with a stable or customer centric, customer first led approach, and that builds trust between different teams. So you should have that clear value driven reason for committing hours of development time or to a new feature. We need to make sure we all understand the why behind it. Now, how else does it align the teams? Well, it shows clearly and exactly what company’s working towards. Has your CRM data been onboarding AP yet? Well, check the architecture, you can just quickly go into further, right? Now, it also finally promotes transparency. Transparency in the sense that you can host your current and future architecture for the entire company or org to see. This isn’t just about quick wins, right? Because North Shore architecture, NSA, it lays that foundation for long-term strategic partnership. And once you have those aligned shared goals, we’re able to support you with the kind of advisory or growth focus engagement that will last.

Now, we talked about what North Shore architecture is, what’s the value, what are the different examples or versions of North Shore architecture value and through the AGO lens. Now, let’s talk about how do we create, right? So, you know what the problem is, you know what the solution is, even buy into the value of North Shore architecture, well, now what? Well, how do we actually make one? So, let’s talk about that a little bit.

First, it’s always discovery. So, we have to know what we have, where we’re going, right? From there in order to create that North Shore architecture we have to ask a lot of questions. That’s the discovery part. And I generally like to kick this off by asking if you have anything at all already, like if there’s a current state diagram and if it’s current or more of a future state that you’re trying to go to, right? When was the last time it was updated? What, if anything, it has been implemented since then, not just because this exists, like was it also implemented? Does the architecture that exists supports your current state use case priority? Now, one reason we led this series off with the use case session is because your NSA should always be use case driven. So, start off by ensuring that you know what use cases you’re trying to architect for. Understand what product and capabilities are needed for those use cases, which data sources, which destinations, right? You have to be able to communicate with channels when it comes to AGO. So you have to keep that in mind and all of this gets discovered during these discovery sessions. And you’ll have to try and capture an appropriate amount of depth in this North Shore architecture.

You have to understand where your company is currently in this journey. So all this gets discussed in a discovery phase.

Now, when we’re setting the stage for that foundational architecture, what does that even mean, right? I was asking a bunch of questions from different lenses. The point wasn’t that the questions didn’t matter, just that we needed that appropriate context. Now, when we’re doing our discovery and building our North Shore architecture, it’s time to revisit some of those questions. So for something more specific like AGO discovery, right? You need to make sure you dig into things like, which data do we have currently? Does it come from CRM system? Does it come from call centers, offline, sales data, other online data, right? Event data, I mean. What about if it’s online, is it coming from Web SDK? Do you need Web SDK for use cases? Things like that, you’ll have to see if a typical source connector will suffice. Can we actually do something with that data? So these are the kind of discovery questions just specific to AGO that you’ll want to ask.

Next thing you want to think about is, do you have the IDs that you have to stitch your data with, your data system together to create that unified profile and audience for AGO? What other sorts of integrations you’ll be leveraging with AGO? Will you be exploring any newly discovered audience? Will you be leveraging AGO for any real-time messaging, right? And if you have, let’s say, CJA, customer journey analytics, you know that you can bring your journey data into CJA for analysis. So these are the kind of AGO discovery-specific questions that you want to ask. This is not exhaustive list, of course.

Excuse me, just some of the examples.

So, okay, great. Now we have done, excuse me, all our discovery, and now we need to make sure that we actually have a diagram. Well, how do I do a JAS? How do I start creating a diagram? We don’t even know where to start. So in this slide, I’ve put this link here for digital experience blueprints. It’s nothing but some sample blueprints that Adobe already provides, right? I’ll share this link with you, and this could be a really good starting point for you. Now, well, there’s tons of tools online to help, of course, but we here at Adobe, we tend to use Lucidchart, and that’s the really one that I’m going to speak to, but there’s tons of other ones, and they work just fine.

All of these tools, Luciddraw, MirrorBoard, they’re all great. Use what you’re happy with, use what your company provides. Now, we also have a set of blueprints available online that I just showed you, right? And some of them are also product-specific. So there is one for AGO-specific as well, and it can help you get that good jumping-off point built from there. And finally, you can work with Adobe. That’s us, right? There’s a different number of groups here at Adobe that can help you with not-so-architectures. If you have ultimate success, you can work with your account team, right? And we can work with you to make an not-so-architecture with you.

Now, we talked about what it is, value, building, types. Now, how do you actually use it, right? So we have created the not-so-architecture. How do we use it? We talked about using them as a part of the strategic planning and ensuring alignment across teams, right? We talked about prioritization, identifying gaps between that current and north star state, and even understanding what we can execute today, right? But what else? Well, from our discovery, we should have a good understanding of what capabilities we need and activate our use cases. Now that we have that, we can use the north star architecture to translate those gaps into actual technical requirements. Now, remember how we were talking about a few of those arrows doing a lot of heavy lifting? Well, now we can translate that, right, into concrete next step for technical teams. So if there was not an arrow existing, let’s say, between that web data coming into AP, now we know we need to talk to technical teams about implementation of a source connector or a web SDK, right, that’s just one example, but there could be other scenarios like that. So we can build out project plans and timelines, excuse me, and do it all through that lens of actual value we need to, or we expect to get out of this, right? Now, we can also go deeper into specific use cases. We can detail out which specific flows are required, which specific use case, for which specific use case, and we can further drive that alignment with business and technical team. Now, what happens after sending out those messaging out of HEO? Like you have talked about bringing in the data, creating the audience, and sending the messaging out. Well, we also need to think about existing, if there’s an existing closed loop reporting on any of those source of attribution that’s needed once the messages leave HEO. So things like that, we got to keep in mind.

So here’s another example of a full state North Star architecture. Yeah, it’s very generic, but you can imagine the customizing with your specific partners or vendors and make it your own, right? But we can use this to identify the gaps, right? Oh, wait, look, we need RDCDP to activate those audience. We don’t have that today, but we have stood that up yet, or we’re looking to really need the parallel inventory available to restock, we need to send notifications out of HEO for that. We’re understanding the technical requirements and the implementation work necessary for that specific use case. And better understanding of which use case can be activated immediately versus later. So that’s the prioritization that can also happen looking at a North Star architecture.

So here’s a specific example, right? That the North Star architecture that was built around AJO, and this one is promoting personalization for customer journeys. So let’s talk about the data form, what’s happening, just because it’s actually a real world example. Number one, the data hub integration for near real-time data ingestion. So it’s sending near real-time data into AEP. Second, it’s activating journeys and messaging via AJOs new WhatsApp channel by utilizing that near real-time event data. And then we’re using target for real-time activation via Edge, right? And RDCDP activation via hub using the destination connector for target. Fourth, the AJO decisioning. This is a little bit advanced one, right? The decisioning part for real-time offers and aspects action that goes through AJO.

But this is a specific use case is what I’m going to call out like this is for personalizing the customer journeys.

And you can have a different one, but for the same work for a different use case.

All right, so today we have largely been focused on AJO, but what I wanted to loop back to this diagram and show you a reminder that you can and often should include other components and solutions for that big picture, right? And you can have multiple versions on our architecture of course, depending on your audience, your teams, what, how much depth you want to go to, but you would want to include as many components as possible that are available Now, we’re going towards the end of this session. So some of the key takeaways that I expect I’m leaving you with from anything from today’s call. And I hope it’s simply that you’ll start using North Shore architecture for one. And then we’d also discussed a lot of challenges that arise when you don’t have it as a guiding light for your own technology. Like I imagine many of you have seen those or similar issues yourself in your work or years. The NSA, when it’s used well, it can truly be a tool that can address all those different challenges.

So as we wrap up, we want to emphasize again on having that plan.

It’s only the beginning, right? The consistent follow through of is very essential to your success. So as next step, we recommend the following.

Identify the list of your initial use case for prioritization, right? Number two, you design and execute your tactical action plan. Number three, you contact your Adobe team for any support during your use case planning, development or execution or journey. So this is the next steps I would also like to leave you with I also left some of the good resources that will be helpful when you come into North Shore architecture and building up from there. And we’ll share this recording and content as well with you.

With that, I think we can save some time for some question and answers.

Definitely. Thank you, Jas, that was really great.

Let me see here, I do have a few questions. I’m also going to launch a poll that will show up in the chat.

And basically it’s just three questions, multiple choice, and then any feedback from you all. So we can, for the next session, have your feedback and use that. I will launch that right now, hopefully. Let me see if I can do this or this, this, and… All right, I’m going to launch it there.

And Katie, if you can just verify that, that worked.

Yep, looks good. Okay, cool. All right, so we do have a few questions here, Jas.

I’ll ask them. The first one here is, what maturity milestones should we aim for before enabling AJO journeys? That’s a really good question. It’s something that will pop up first thing in your mind when you’re trying to build that foundational architecture to kick off your AJO journeys. So yeah, great question. Now, first thing you want to do is you want to make sure that we have that unified customer’s identity framework established. Like what are your different data that is being enabled in AP? If it’s streaming, your content and governance model is there being implemented. If your first party data is being activated to come into AJO, right? You also want to think about automated monitoring and reporting. If it’s existing, if it’s operationalized or not for AJO. You can obviously do pull some easy reports like AJO itself, like typical sends, clicks, opens and things, but you can also bring that data into CJA if you have for closed reporting, closed reporting or sometimes in some cases, even attribution.

Very cool. Yeah. Okay, and I’m watching chat. If anybody has follow-up questions in here.

I have another one here. Let’s see. How do we phase implementation from MVP to advanced orchestration? That’s another great question actually. Okay, yeah, we got started with some sort of MVP model, but how do we use it to get to the advanced or mature state? So crawl, walk, run. I tell this to everybody. I know it sounds cliche, but you phase it out. Phase one, two, three, and so on. So phase one will start with your foundational journeys, depending on the industry, of course, like typical welcome messages, newsletter, things like that, very basic stuff. You start with that, and then from there on, when you move to the next phase of behaviorally trigger cross-channel journeys, right? That’s going to be a little bit more mature use case. Once you have achieved that, you move to the next stage, which is more AI or decision-based orchestration and even personalization at scale. So start with basic stuff, welcome, not typically your batch stint, like generally we used to leverage your typical campaign orchestration tools for, but something basic, simple journeys, then trigger-based, cross-channel, and then finally your decision-based orchestration.

Then another one just popped up here.

Tatar Vaidi, I want to understand more about the pause feature.

What changes can we make? And the use case is, I want to update the audience in the live journey, so when I update the evaluation, it will take some time.

Let’s see here. I guess this is pausing a journey, correct? Yeah, I think that’s what they asked me. If you pause the journey, how do you update the audience? Yes.

So I think I’ve heard this one before, and the product functionality is there because if you don’t do that, your journey, because it’s live, it cannot do that, basically. The functionality can happen because your audience gets streaming and you pause your journey, then there’s like a mismatch in the middle. So that’s why the functionality is there for you to not to be able to do that. The best way to, or workaround to achieve that is, I will say, just create your batch audience first, and instead of using that as a live journey, send a campaign to that instead.

That sounds great. There could be more nuances based on the situation, but for whatever information I just learned so far, that could be one possible workaround. But like I said, could be more layers to this question as well. That might change the answer is what I’m saying. Exactly. Okay, cool. We have more people typing. Here’s another one. What are some quick win AJA use cases that validate the Northstar Foundation? Great, and this almost ties back to our previous question that was about how we move from that MVP to advanced orchestration stage, right? So we start off with your welcome onboarding journeys. From there, the basic stuff, then you move on. If you’re a retail client, for example, you move on to the abandoned cart or ticket purchase recovery, right? If you are a sports client, we actually worked with one of the big sports teams here, and they had this game day missions or event-based real-time triggers that they were sending out of AJO. So that could be your, excuse me, like a quick win use case, right? To validate that Northstar Foundation. And you can also send in like a post-event follow-up with some personalized offers.

That could be some like quick wins or low hanging fruit for AJO. Great.

Here’s another one from Amy. Could you please share the phases for use cases included in each phase? So the ones that I’ve talked about, the foundational journey, the behavior triggered or AI decision-based, I think that’s the phases you’re talking about. So it will be different for each customer, each org, each use case scenario, this is very general examples I get, but I can repeat them for sure. So phase one will be your foundational welcome journeys, right? Or newsletters, your, I don’t know, like depending on the industry, if you’re sending any birthday offers, things like that. Phase two could be your behaviorally triggered or cross-channel journey. So it’s not just email, just working across different channels, your email, SMS, in-app, things like that, push. Your third phase, which will be a little advanced, will be more decision-based using the offer decisioning features for your orchestration and achieving that personalization at scale via AJO. So that could be like the three examples.

Cool.

All right.

And I guess we leave this open. If there’s any other questions, get them in the chat.

And the poll is, it looks like Katie may have restarted the poll. I may have accidentally ended it.

Let’s, oh, here we go.

Okay, here’s another one.

I can update the audience in the live journey and I don’t have to pause to make, oh, this is a follow-up from the pausing of the journey question. I can update the audience in the live journey and I don’t have to pause to make any changes if I am right.

But when I make changes to the live journey, the new audience will take some time to start evaluating. And how much does it take to complete the evaluation? And do you suggest to use the pause feature here? Gotcha. Okay. So the audience evaluation will depend on your evaluation logic as well. Of course, how complex is your logic for that segmented audience? So I wouldn’t recommend pausing the live journey. I would say if it’s a live journey, they will keep flowing through the logic and then keep entering and leaving the journey as they get evaluated. So I wouldn’t recommend pausing the journey for that.

Chander Vaidi. Does that answer your question? Okay.

All right.

Okay.

There we go. Here’s the follow-up on the same one. So what is the purpose of having a pause feature? That’s a great question.

I am, because I don’t generally run journeys a lot in campaign, sorry, in AGO. So I’m not sure what people use it for, but if you can send up like a follow-up on this and exactly what you’re looking for, we can get somebody on either your TAM or CSM wall and we can get you some examples on when this gets used and when, how this is more valuable and which use case. We can talk more about that as follow-up. Cool. I’ll grab the name. They’re asking for a use case and we can definitely get that too, for sure. Got Chander Vaidi.

Okay, great.

Okay, well, I think that’s, thank you, Jaz from. Yeah. Okay, cool. Well, all right.

Thank you all for joining.

Thanks for taking the time today. I hope we hope this was really useful to you. And as Jaz said, we’ll follow up with deliverables. And if you have any further questions too, feel free to reach out and we’ll take a look at that use case for the pause functionality. And right, I hope you all have a wonderful time and thank you for joining. We appreciate it. Thank you everybody.

Thanks.

Cheers.

Oh, okay, cool.