Solving Adobe Journeys Beyond Email

Transcript

Thank you for joining this session. Today we’re going to focus on designing multi-channel journeys, and that means going beyond just journey optimizer delivering e-mails, but delivering channels across various digital and non-digital channels. My name is Stephen Cave and I’m with World Vision Canada. Now World Vision is a global development and advocacy organization really focused on helping the world’s most vulnerable children and families overcome poverty and experience fullness of life. I’m excited to share how we’ve been approaching designing real-world journeys for our donors using Adobe Experience Platform, specifically, Adobe Journey Optimizer and Real-Time CDP.

I’ve spent over 12 years in MarTech at World Vision Canada with the last four focused on Adobe Experience Platform, particularly Adobe Journey Optimizer and Real-Time CDP as mentioned. Earlier this year, I had the opportunity to present at Adobe Summit where I shared how we’re evolving our engagement strategy for our donors using AEP.

Feel free to scan the QR code on the left-hand side and see that full presentation where you can understand our journey to get to where we are today. Or if you want to connect with me, you can scan the QR code on the right-hand side and find me on LinkedIn. But let’s get moving forward with today’s agenda.

What we’re covering here today is a real-world use case. In this case, it’s going to be recurring credit card payment decline notifications.

What I mean here is not your typical e-commerce notification of a credit card is declined, but if somebody is making payments on a recurring basis, suddenly it gets interrupted, you need to engage the customer.

We’re going to talk about the key data and design considerations across email, direct mail, and outbound calls. We’re talking about an architecture breakdown of how we trigger both the events and activate this journey, and we’ll talk about tips for scalability and operational hand-off. This really focuses on how a marketing ops person will break down a customer journey when planning it in AEP. Or if you’re a marketing person and coming from a marketing perspective, how maybe you want to think of how your journey will actually need to get executed within the platform. If you’re beginning to explore AJO and AEP, then I think you’ll benefit from this session, and it’ll really help you understand that there’s other people out there trying to solve some of the same challenges that you’re likely facing yourself. Let’s dive in. Like I said, we’re going to focus on that reoccurring credit card decline notification journey, which is a mouthful. But that’s what we’re going to be working on.

The business objectives around this, and we really want to drive resolution to avoid losing any revenue, and we want to alert the customer promptly so that we can try to retain them or discern what the customer’s decision is. In the context of a charity, monthly donations are often tied to a child sponsorship. When a payment fails, it’s not just a financial issue, but it actually disrupts the relationship between the donor and the child. In our context, a sponsor sponsors a specific child, and that child now has a sponsor, and they often correspond. That’s something where we can’t just restart a subscription. Because of a declined credit card, this is where we want to notify the customer and understand what they want to do next.

So that’s really important to us in our organization. And we need to send that across multiple channels that really run the range from being a digital channel to some of the offline channels. We also, when we’re designing this, we want to minimize the number of teams that are involved for the ongoing maintenance to ensure the long-term scalability and agility of this overall journey. So here’s what our approach looks like. We really need to identify the customer journey requirements. We need to look at the key components, such as the event that’ll have to be created, as well as the three subjourneys or microjourneys. And I like to use that term because often we’re talking about the customer journey as a whole, but when you execute it within the platform, it really breaks down into three different journeys within the platform in this particular case.

And now in Adobe Experience Platform, you have to think of it, the data either lives on the profile or it lives in event datasets. And this is important because in email journeys, you can use the event data directly, both in qualifying the person to receive the journey, but, sorry, and also use the data that’s in that event to appear directly on the body of the email. But in print, we’ll use that same event to qualify the person so that they should receive the printed piece. But if there’s data that needs to be customized on the letter, that data has to be on the profile because we’re gonna wanna export it out to our print vendor.

So if it’s something like a declined product name that you need to have specifically in the body of the letter and it’s only in the event, we need to figure out how we’re gonna enrich that and have it on the customer profile. And this requires some of that planning to happen upstream so that the right data is available where and when it’s needed in the journey. And I don’t wanna gloss over that too quickly because it really helps for you to wrap your mind around this. And once you understand it, it helps you then plan journeys a lot faster. So when it comes to email, again, you can use the event data that’s in that event dataset in the body of that email and to qualify the person for the journey. But when it’s direct mail, you can use that to create the audience and the segment, but you won’t be able to use that event, sorry, the data that’s in that event dataset, you won’t be able to export it directly from the dataset. It will have to be on the customer’s profile. And similar for outbound channels where we’re activating an audience to a destination, you need to use that, you can use that event to qualify the audience, but if you need to export any data that has to be customized as part of what a call agent will use, it has to be on the profile when you’re doing that activity.

Our approach is to sketch out a complex journey such as this. And I wanna take you through how we sketched out this particular one. And there’s no need for a full technical architects diagram, but it really does help to sketch out all the moving parts of a journey and figure out what data is moving between platforms and any of the considerations that you need to factor in there. So let me take you through this one. We know that a credit card decline event has occurred. And as part of that, we’re gonna need to have send that event into AEP. And we’re gonna do a custom dataset and we’re gonna call this the credit card or CC decline event dataset.

As part of that event dataset, that’s gonna trigger our journey in AJO. And we’re gonna build that journey and I’ll show you that in a moment. And that’s how we’re gonna send out the email.

That an event dataset is also really important because that’ll get associated with the customer profile. Now, for that, we’re gonna be able to create the audience that we need for direct mail. We can create the audience we need for telemarketing. But one of the other things I’m gonna back up here and recognize that, and I’d mentioned this before, that we wanna send out. I know that I need to have some custom data that’s on that profile. So I’m gonna batch load the necessary data that I need for that letter. That’s gonna come over into AEP. That’s gonna come onto the profile so that once I’ve prepared an audience and I go to build my journey, I’m able to export the data that I need. So again, the flow here is from the profile, I build the audience I need for direct mail. I’m gonna build the journey in AEP. There I’m gonna use a custom action that I’ll show you what our design looks like. And that’s gonna use an API to send the necessary profile data over to the print vendor. And as part of that, I’ll bring over that custom data that we brought onto the customer’s profile. And then similarly for telemarketing, we’re gonna do this where we’re gonna activate an audience out to a destination to our call center. Now, the other thing that we recognize in this diagram is that once I send that email, I’ll also have event data that’ll come back onto the customer profile, which will help me determine whether or not I’m sending out a direct mail or telemarketing. So for instance, if the email bounces, then I know that I should probably move to one of these alternate channels right away. Whereas if the email is opened and clicked, I may actually want to delay sending out a letter or telemarketing because I’ll be looking for that action to come through where the credit card issue has been resolved.

So now when we talk about our approach to the journeys, we’ve really structured these journeys across three different journeys. One is gonna be journey number one. That’s gonna be that email notification. That’s gonna be that real-time event, and I’ll show you that in a moment, that’s gonna have a personalized email and use a lot of the attributes that are in the event dataset all in the body of that email. Journey number two, that’s gonna be our direct mail. And that’s where we’re going to create the segment. We’re gonna listen for any of those interaction data from the email or like a bounce or deliverability issue or a click. And we’ll determine what’s the timing is for that journey. And then we’re gonna build that journey so that we can deliver that profile data to the print partner. And then for journey number three, again, we’re gonna build a segment based off of that event. We’re gonna leverage any of that email response data, and then we’re gonna activate an audience out to our call center and to their systems.

Our approach for the event schema looks a lot like this. So we’ll build a custom event schema, and we’ll have our custom fields. We’ll have our product type. So in this case, we may wanna deliver the product code because that’ll allow us to adjust the versioning of the email. It’ll allow us to display the product name. We’ll have the perhaps the credit card type indicated in there so we can adjust the template layout. We’ll have the donor ID or any key information we need to associate with the profile. We’ll have the event name so that we can look at that event name and make sure they qualify for the right journey and any other information such as payment type. When we look at bringing over the batch data and putting it actually on the customer profile, here we’re gonna create another data set. And for this one, we’re going to create a data set where we’re bringing just the information we need that needs to be on their profile, because we know that this is going out for a payment email. We know that we need to display that product name, and that’s where we’re gonna create that on the profile. Again, using in our case, the donor ID, you may use the customer ID, whatever your unique identifiers would happen to be.

Then when we go to building the journey, for that email journey, we’ll do an event triggered journey. Then you’ll go through all the different business conditions. Your organization probably has a few different ones and I’ve obfuscated a little bit here so that I can display it in a forum such as this. But this is typically how we build it where we introduce any of the key conditions that cause you to branch off. It may take you down to three different languages. In our cases, we have people that support one child and multiple children. So we would create different templates and that’ll trigger to the appropriate version of the template based on that event and what the customer needs.

For the direct mail channel, again, this case, we’re gonna build a read segment because we know we’re gonna likely send this a day later. We’re gonna wanna wait for that response data to come back from the email. We’re gonna wanna wait for that batch data to come in. So we’re gonna set up what that audience is, make sure that people enter into the audience, and then we’ll send this out and we’re gonna do a custom action. And that’s gonna send the data over to our print vendor. And the reason we like using a journey here is because we’ve set it up so that our journeys can write our contact history when those have been sent over. Now, when it comes to designing a journey, we have to think just beyond the technical.

We have to ask ourselves like which teams are actually gonna manage and maintain this? How often is it gonna change? Should business users or marketers be able to manage the elements? Or does a lot of the logic need to live upstream? And that’s where you can go back to this original diagram and kind of map out what teams are involved with this. And it really helps facilitate some conversations. Now, depending on the size of your organization, you may be, wear all of these hats and you can design this any way you want. But in larger organizations, sometimes there’s different teams. And as part of that, that means anytime you wanna make a revision, that may mean changing data upstream and that may be outside of your team. And this is where the conversations that we have around building a journey really have to be based in what works best for your organization based on what you need to do. Because if something can be better executed, but it’s in a system that you don’t control and that means that you have to get in line in a queue to make any changes or revisions, that can become cumbersome to maintain in the future. And that’s where you just need to decide on which version of a journey and which design works best for your organization to manage and maintain it in the future.

So I’m just gonna wrap up here with a few key reminders. You need to know what data lives on the profile and what lives on the event and why that matters.

You have to think of designing microjourneys for each channel and their different purposes.

You need to use the real-time events to build a responsive and intelligent journeys using the information you learn from one journey to feed into your considerations and audiences for your other journeys. And you have to plan for future updates and reduce any reliance on other teams or multiple teams. That’ll make things a lot easier. And if you do these things, I think that your future self and your marketing ops team will thank you.

So in my experience, there’s at least three different ways to solve any problem in Adobe Experience Platform. And I think I say that at least once a week in every meeting that I’m in. And the right version depends on your org structure and constraints. And also it depends on where you come as a practitioner using the Adobe Journey Optimizer or AEP. Some people come from Adobe Campaign and they have an Adobe framework. For us, we have a reference point from systems that were outside of Adobe and we moved into it. Others come from a more technical background or people come from more of a marketing background. So I’m anticipating a few different reactions to this approach. Some of you will say, yes, that’s how I would have done it. Someone might say, oh, that’s how you do that. And others will be, will say, that’s interesting. Have you considered this other approach? And that’s what I love about the idea of using the experience makers skill exchange so that we can have that conversation about how are there different ways to approach solving one’s problems. And I look forward to any discussions. And with that, I look forward to having those conversations in the Q&A portion. Thank you for sharing rules, robust framework, and your solid strategy, Steven. Our final experience maker spotlight is David Kangni. Welcome David. Hey everyone. Welcome to the experience maker, the skill exchange. Today we are diving into a crucial topic for anyone working on Adobe Journey Optimizer, which is testing profiles. I’m David Kangni. I’m a technical architect solution. And I have a 16 year in IT consulting and marketing. I’m a certified in AJA, AP and campaign, and I deliver more than 75 projects all over the world. Other than that, I’m also actively involved in the AJA community as a captain and as an Adobe community advisor, acting as Adobe campaign mentor and the North America user group leader. Other than that, the fun fact about me is I hold three different citizenships and I traveled to 40 plus country and counting.

You can connect with me on LinkedIn by scanning the QR code on the screen.

Today, here’s a quick look of what we will cover. So we will start by understanding why testing matters, and then we will demystify test profile by what are test profile, how to create test profile, and how to use this test profile in your journeys and campaigns. After that, I will share with you some key testing scenarios and couple of my best practices and some pitfalls to avoid when you are testing your journeys. Also, we will share the key takeaways and we’ll have a Q&A session at the end of the presentation.

Okay, let’s do the first thing, is why test profile matters.

Test profile matters because of five key step for me. The first one is the regulatory compliance to make sure that you respect the data privacy and the up-to-date preference of your customer. The second one is to assess performance as test integration with a different vendor, make sure that your data are completely propagate and on time in the different system to prevent negative customer experience and avoid sending incorrect message or disrupting real journeys, to validate the journey logic with personalization. And the last one is to identify and rectify any bugs and logic flaw before you go live. Then, now we will try to demystify test profile. So I know that it’s complicated in AJO because you need to go through a data ingestion process, but the test profile are just there realistic as a real customer and you can mimic your real customer data and it’s allow you to test your profile from an end to end. So you will have the same demographic data, the behavior or the preference as a real customer.

You need one thing that is essential to running your journey in test mode, which is to set up your profile as a test profile. And it’s a flag under the schema and you can manually create your test profile or bug import them. And from there, you will be able to simulate the membership in your segment and audience. And the nice thing is the test profile are following the same XDM schema as your real profiles. Then we will move to the test profile creation. To create and implement this profile, we will have four steps. The first one is to define your test scenario, which means you need to identify the journey you want to test, the customer type you want to test and the behavior you want to test. Here, you will have your segment, your event, your attribute, and they will all depend on your journeys. The next step is to identify the required attribute for your logic and for your personalization and segmentation and ensure that all your test profile are included in all that critical data points. After you identify the XDM attribute and define the scenario, you will be able to create and import profiles, whether you do it manually through the UI using the AJA UI accelerator, or you can do it via data ingestion methods or API methods. And lastly, you need to ensure that the test profile flag is equal to true and verify that the test segment can be used in your journey.

So this slide is just to share with you different links to how to create the test profile and how to test your journey. So I have two links to create this profile, three to test your journey, and all of them cover most of the use case or most of the challenge you can face when testing a profile. Now let me share with you the key testing scenario, which is for me, some strategic approaches for validation.

For testing purpose, we will have like, you know, five key testing scenario. The first one is usually the unit testing. The unit testing, you take the individual component and you test it to make sure that if I take a profile for David, this profile will show the David loyalty number of plan, the David birthday, et cetera, and you test only the unique profile to make sure that everything is working fine. The second one is the end-to-end testing. The end-to-end testing will depend on a journey or a campaign, but the goal here is to test all your journeys from the entry to the end to make sure that your test profile is working as expected and going through all the different variation of your journey. The third one is the regression testing. Why the regression testing is important is to make sure that you are able to make your new journey work and not broken the existing journey. So it’s really important that when you deploy a new journey to make sure that it’s not impacting your other journeys. The fourth one is the negative testing. Make sure that you test the invalid input and unexpected behavior. And the last one, which I think is really important because one issue we have with my team is the performance testing. Why the performance testing is important because it allow you when you have another vendor or like SMS vendor or voice vendor to make sure that you are able to send a specific threshold to them that they can support.

So the next slide is for me the best practices I can share with the community on how to master your testing process. So for me, six are really important to me is always start small and then expand. So start with a smaller journey or smaller chunk in your journey, as example, test the audience entry, test a couple of condition in your journey before just trying to test all your big journey like 50 activity in one testing.

Then document all the test case and make sure that you check all the box before moving to the last and to the end-to-end testing. Or use a descriptive naming convention. As example, I know that when you are creating a new journey the default naming convention is not the fancy one. So I always recommend to add a correct and a clear naming convention for your testing and even for your journeys.

The fourth one is regularly update the test profile and keep them aligned with the schema chain because the AEP AEO is a moving target. So we still have a development in process. So every time you update the schema or your data set make sure that you update your test profile accordingly. And then the fifth one is to test in staging environment.

But I know that Adobe released a dry run that can be run on testing and there’s the journey without sending the final deliveries or SMS. Well, it’s still better to test first in the staging environment before moving everything to production. And the last one is the collaboration. And you have to involve all the key players during the testing because there are no data, they know the use case and you need to involve all of them to make sure that you complete the loop.

Okay, now let me share with you some common pitfalls to avoid. Some common pitfalls to avoid is the insufficient test profile. One example is I will give you is the testing of the SMS opt-out. We had an issue because the testing profile that we were using were all using the same phone number. And when you test up, what we noticed is AGO was picking randomly one of the profile linked to the number and unsubscribe. And the team was, oh, the opt-out, the unsub was not working. Why? It’s just because they are using the same number for all the test profile, okay? The second one is the update test data is, as I said, the moment you update your schema, you need to update your test profile because it will reflect in your personalization and in your business role.

The third common pitfall to avoid is testing only the happy path. And I can share some example by creating an account. So in our company, when you create an account, you have a digital account and just like the normal account. So you can create an account without having the digital account. And when the initial implementation was done, the team just test the creation of the account itself. And then when you create a digital account, the user receive again a welcome journey, which is not supposed to happen. So this is because they just test the welcome process when someone create an account without checking if the user have a digital account or not. And the fourth one is the lack of testing plan or what I call inconsistent testing because you just go into the system and test some piece of your journey and make sure that it’s working. No, it’s a pitfall to avoid because you will not have enough data to make sure that everything running. And come the fifth one, which is the overconfidence because you test a piece of your journey, you test superficial or you test couple of profile and it’s working, doesn’t means that it will work for all your millions customer.

What are the key takeaways for this session on what the test profile will help you to do is to validate the data flows. So it’s help you refresh the data as needed. It help you mirror your real segment as a VIP buyers or car abandoners. Testing profile will help you optimize performance. So I will recommend to at least test load 10,000 profile, but I even go sometimes to 10 millions. The third key takeaways is to enable collaboration. I mean, share test profile across your team and cross channel journeys. Make sure that all the team is involved in testing your profiles.

The fourth one is ensure the compliance. Make sure that with your test profile, you are able to test the opt-out, the preferences and the difference privacy laws, such as CASEL and GDPR. And the fifth one is to prevent customer facing errors. And you can use your test profile to mimic the real customer data.

That brings us to the end of the presentation. Thank you for your attention. I hope this session has provided valuable insight into optimizing your journey with test profile. And I’m now happy to answer any question you may have. Thank you, David and Steven. Great insights and practical thinking here.

So here is the list of a lot of questions coming up. Steven, how is the credit card decline event sent to CDP, stream, edge or batch? Yeah, that’s a great question. In our case, we batch it over. And the reason why we don’t do stream or anything like that is because this is something that we can afford to do in batch because this is a payment we would notice declining over time, because it’s their second or third payment that may have been a long standing subscriber or donor in our case, which is different than what you would wanna have in something where a decline event occurs right at the time of a transaction.

Thank you. Great thinking. And David, it’s a question for you. If you have a real profile with an email as identifier, can I use this email to create a test profile or do I need to use other email that does not exist as a profile? Yes, you can use this email to create a profile because to set up a test profile, it’s really just a flag to update in the attribute. So you can update any profile with this attribute and you will be able to use this profile for your testing. The second approach you may have is if you have some mailbox such as Gmail, you can create some aliases. So basically, david.cunyplus01atgmail.com or david.cunyplustestingatgmail.com will go to the same mailbox. So it can be also an approach that you can use to do your testing if your identifier is email addressed.

Hope it answers your question.

So Steven, we have a question for you. Do we need all the behavioral events flowing into customer profile or will Data Lake will be enough to trigger journeys? Let me try to parse that one again how we would have tackled this. So the behavioral event that we’re looking for here would be that we’ve seen a decline happen. So we just need that. We don’t need that on the customer’s profile, but in that journey that you’re designing and all the branches that kind of flow into different nodes in a journey, there may be different aspects that need to be on the customer profile that would affect the version of a template that you might send to someone. So again, it really depends on your scenario, but you don’t need everything on the profile, but obviously there’s some things that you could benefit from personalizing the journey by leveraging data that is on profile as well as what’s in the event.

Hope the practical tip from Steven was helpful to you. Here is next question for David.

How do you structure or manage test profiles in Agile to reflect different audience segments, consent status, and channel preferences? Okay, in that case, you can create multiple test profile. So my personal approach is for every dataset or every use case, I create the same dataset, the same test dataset as the dataset to ingest the real customer profile. And I use this dataset to ingest the data, and in that way, I’m mirroring exactly what a real profile will have. If I have a dataset which ingest like user who enroll or welcome user or user who purchase, I use the same dataset, but I just introduce the test profile flag in there. And in that way, I use them to create the test profile and split them into the audience or into the journeys.

Thank you, David. It was insightful. Steven, we have a question for you. Do you use any decisioning engine in Agile to determine the next actions in your use cases so as to deliver the desirable customer experiences? So it depends if you’re talking about the offer management in the profile, which is something we don’t use in the product, we manage our next best action by, yeah, we do mine the data as best we can to understand the signals that tell us what to use and what would make sense to be sent to the customer that way based on, again, their donations and their behaviors. And we’re trying to funnel everything back into the CDP so we can get a richer sense of what the customer would desire as that next best action.

Thank you, Steven. So I have one more question on your multichannel approach. Given a multichannel approach, what do you do to listen to determine if the customer should continue in that journey or that channel? That’s a great question. So email gets a little bit easier because we can look at the opens, but preferably the clicks. What we’re looking for in this is that signal in the data that tells us the customer’s taking the appropriate action. Again, in the scenario that I use here, we’re trying to understand does it make sense for us to go out in other channels or does it make sense for us to continue to go out into channels? And we’re looking for that sign of awareness. So one of the things we would look for is have we seen a credit card get updated? When can we bring that event in to the profile? Because now we can put those people into an audience and say, exit the journey at this time. Anytime we have enough signals there. The one of the ones we use as a proxy for that is of course, if we see a donation happen right away, we can easily move somebody out of a journey if that donation event occurs after a decline event.

Thank you, that was insightful. So David, I have a question for you on your strategy. What is your strategy for testing journeys with multiple entry points or reoccurring entry conditions? Okay, great question.

In this case, you don’t have any black or white answer. But the thing is, when you are going into testing mode, the delay or the waiting are reduced to 10 minutes. So basically, if your wait in your complex journey is 10 days, you need to make sure that you take the action such as open and clicks are the easiest one in the next 10 minutes before the test wait completed. Otherwise, if it’s like the purchase case, you need to ingest the data so you can ingest the data to Postman into this. And the other thing that is really complex is if you have to wait four days and it’s a mix of read audience and event, in that case, you really need to define a QA plan to go over the different case. But we call it an end-to-end case, but it will like you reduce the time of the wait, et cetera. And the last one is if you know that your full journey is 10 days and you have a time enough before the go live, you just run it as a normal journey with like a few population, like 10% of your user. And then like, you know, let’s see how they flow through. You adjust before the go live with the total population. Thank you. That was insightful. And I think this is a question for Steve. Can you please explain on how do you pass event data via API, was it a custom API or custom action? Sorry, can you repeat that question? Sure. Can you please explain on how do you pass event data via API, was it a custom API or a custom action? So I think that’s gonna, that gets into a technical area that I would lean on some of my data team. So I’m not gonna tackle that one in here, but it would all be covered off in the experience of the documentation.

And I don’t wanna mislead anybody. So that’s where I would go for clarity on that answer. Thank you, that was helpful.

So David, it’s a question coming up for you. Can we delete test profiles from AP once the testing is complete? Oh, yes. Oh, yes, because for healthcare, you have what they call data lifecycle delete a profile by entering the identity into the system and have this profile delete, but it can take up to 15 days because you delete it from the data lake and the UPS and the identity store. Otherwise you can run some API calls to delete the profile, but keep in mind that if you use the API calls, it will keep the test profile identity graph in that case, when you re-ingest the same test profile using the identity, it will just stick with the data, some of the data that stays in the data lake. So the delete is possible, but depending on the approach you take, you need to make sure that you completely delete all the different items and objects. That’s all. Thank you, you both. Thank you again for David and Steven.

Awesome, thank you for having me today. It’s been a great experience.

Yeah, thank you all for joining us today. It was fun and it was a pleasure to have the conversation and spend this time with all of you. And thank you to Hadoop beef to make this event possible.