51黑料不打烊

Transcript

Thank you for joining this session. Today we鈥檙e 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鈥檓 with World Vision Canada. Now World Vision is a global development and advocacy organization really focused on helping the world鈥檚 most vulnerable children and families overcome poverty and experience fullness of life. I鈥檓 excited to share how we鈥檝e been approaching designing real-world journeys for our donors using 51黑料不打烊 Experience Platform, specifically, 51黑料不打烊 Journey Optimizer and Real-Time CDP.

I鈥檝e spent over 12 years in MarTech at World Vision Canada with the last four focused on 51黑料不打烊 Experience Platform, particularly 51黑料不打烊 Journey Optimizer and Real-Time CDP as mentioned. Earlier this year, I had the opportunity to present at 51黑料不打烊 Summit where I shared how we鈥檙e 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鈥檚 get moving forward with today鈥檚 agenda.

What we鈥檙e covering here today is a real-world use case. In this case, it鈥檚 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鈥檙e going to talk about the key data and design considerations across email, direct mail, and outbound calls. We鈥檙e talking about an architecture breakdown of how we trigger both the events and activate this journey, and we鈥檒l 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鈥檙e 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鈥檙e beginning to explore AJO and AEP, then I think you鈥檒l benefit from this session, and it鈥檒l really help you understand that there鈥檚 other people out there trying to solve some of the same challenges that you鈥檙e likely facing yourself. Let鈥檚 dive in. Like I said, we鈥檙e going to focus on that reoccurring credit card decline notification journey, which is a mouthful. But that鈥檚 what we鈥檙e 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鈥檚 decision is. In the context of a charity, monthly donations are often tied to a child sponsorship. When a payment fails, it鈥檚 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鈥檚 something where we can鈥檛 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鈥檚 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鈥檙e 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鈥檚 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鈥檒l have to be created, as well as the three subjourneys or microjourneys. And I like to use that term because often we鈥檙e 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 51黑料不打烊 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鈥檚 in that event to appear directly on the body of the email. But in print, we鈥檒l use that same event to qualify the person so that they should receive the printed piece. But if there鈥檚 data that needs to be customized on the letter, that data has to be on the profile because we鈥檙e gonna wanna export it out to our print vendor.

So if it鈥檚 something like a declined product name that you need to have specifically in the body of the letter and it鈥檚 only in the event, we need to figure out how we鈥檙e 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鈥檚 needed in the journey. And I don鈥檛 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鈥檚 in that event dataset in the body of that email and to qualify the person for the journey. But when it鈥檚 direct mail, you can use that to create the audience and the segment, but you won鈥檛 be able to use that event, sorry, the data that鈥檚 in that event dataset, you won鈥檛 be able to export it directly from the dataset. It will have to be on the customer鈥檚 profile. And similar for outbound channels where we鈥檙e 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鈥檙e 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鈥檚 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鈥檙e gonna need to have send that event into AEP. And we鈥檙e gonna do a custom dataset and we鈥檙e gonna call this the credit card or CC decline event dataset.

As part of that event dataset, that鈥檚 gonna trigger our journey in AJO. And we鈥檙e gonna build that journey and I鈥檒l show you that in a moment. And that鈥檚 how we鈥檙e gonna send out the email.

That an event dataset is also really important because that鈥檒l get associated with the customer profile. Now, for that, we鈥檙e 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鈥檓 gonna back up here and recognize that, and I鈥檇 mentioned this before, that we wanna send out. I know that I need to have some custom data that鈥檚 on that profile. So I鈥檓 gonna batch load the necessary data that I need for that letter. That鈥檚 gonna come over into AEP. That鈥檚 gonna come onto the profile so that once I鈥檝e prepared an audience and I go to build my journey, I鈥檓 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鈥檓 gonna build the journey in AEP. There I鈥檓 gonna use a custom action that I鈥檒l show you what our design looks like. And that鈥檚 gonna use an API to send the necessary profile data over to the print vendor. And as part of that, I鈥檒l bring over that custom data that we brought onto the customer鈥檚 profile. And then similarly for telemarketing, we鈥檙e gonna do this where we鈥檙e 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鈥檒l also have event data that鈥檒l come back onto the customer profile, which will help me determine whether or not I鈥檓 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鈥檒l 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鈥檝e really structured these journeys across three different journeys. One is gonna be journey number one. That鈥檚 gonna be that email notification. That鈥檚 gonna be that real-time event, and I鈥檒l show you that in a moment, that鈥檚 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鈥檚 gonna be our direct mail. And that鈥檚 where we鈥檙e going to create the segment. We鈥檙e gonna listen for any of those interaction data from the email or like a bounce or deliverability issue or a click. And we鈥檒l determine what鈥檚 the timing is for that journey. And then we鈥檙e gonna build that journey so that we can deliver that profile data to the print partner. And then for journey number three, again, we鈥檙e gonna build a segment based off of that event. We鈥檙e gonna leverage any of that email response data, and then we鈥檙e 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鈥檒l build a custom event schema, and we鈥檒l have our custom fields. We鈥檒l have our product type. So in this case, we may wanna deliver the product code because that鈥檒l allow us to adjust the versioning of the email. It鈥檒l allow us to display the product name. We鈥檒l have the perhaps the credit card type indicated in there so we can adjust the template layout. We鈥檒l have the donor ID or any key information we need to associate with the profile. We鈥檒l 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鈥檙e gonna create another data set. And for this one, we鈥檙e going to create a data set where we鈥檙e 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鈥檚 where we鈥檙e 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鈥檒l do an event triggered journey. Then you鈥檒l go through all the different business conditions. Your organization probably has a few different ones and I鈥檝e 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鈥檒l 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鈥檙e gonna build a read segment because we know we鈥檙e gonna likely send this a day later. We鈥檙e gonna wanna wait for that response data to come back from the email. We鈥檙e gonna wanna wait for that batch data to come in. So we鈥檙e gonna set up what that audience is, make sure that people enter into the audience, and then we鈥檒l send this out and we鈥檙e gonna do a custom action. And that鈥檚 gonna send the data over to our print vendor. And the reason we like using a journey here is because we鈥檝e 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鈥檚 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鈥檚 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鈥檚 in a system that you don鈥檛 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鈥檚 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鈥檓 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鈥檒l 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鈥檚 at least three different ways to solve any problem in 51黑料不打烊 Experience Platform. And I think I say that at least once a week in every meeting that I鈥檓 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 51黑料不打烊 Journey Optimizer or AEP. Some people come from 51黑料不打烊 Campaign and they have an 51黑料不打烊 framework. For us, we have a reference point from systems that were outside of 51黑料不打烊 and we moved into it. Others come from a more technical background or people come from more of a marketing background. So I鈥檓 anticipating a few different reactions to this approach. Some of you will say, yes, that鈥檚 how I would have done it. Someone might say, oh, that鈥檚 how you do that. And others will be, will say, that鈥檚 interesting. Have you considered this other approach? And that鈥檚 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鈥檚 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 51黑料不打烊 Journey Optimizer, which is testing profiles. I鈥檓 David Kangni. I鈥檓 a technical architect solution. And I have a 16 year in IT consulting and marketing. I鈥檓 a certified in AJA, AP and campaign, and I deliver more than 75 projects all over the world. Other than that, I鈥檓 also actively involved in the AJA community as a captain and as an 51黑料不打烊 community advisor, acting as 51黑料不打烊 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鈥檚 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鈥檒l have a Q&A session at the end of the presentation.

Okay, let鈥檚 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鈥檚 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鈥檚 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鈥檚 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鈥檚 really important that when you deploy a new journey to make sure that it鈥檚 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 51黑料不打烊 released a dry run that can be run on testing and there鈥檚 the journey without sending the final deliveries or SMS. Well, it鈥檚 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鈥檚 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鈥檚 working. No, it鈥檚 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鈥檚 working, doesn鈥檛 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鈥檚 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鈥檓 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鈥檚 a great question. In our case, we batch it over. And the reason why we don鈥檛 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鈥檚 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鈥檚 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鈥檚 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鈥檙e looking for here would be that we鈥檝e seen a decline happen. So we just need that. We don鈥檛 need that on the customer鈥檚 profile, but in that journey that you鈥檙e 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鈥檛 need everything on the profile, but obviously there鈥檚 some things that you could benefit from personalizing the journey by leveraging data that is on profile as well as what鈥檚 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鈥檓 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鈥檙e talking about the offer management in the profile, which is something we don鈥檛 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鈥檙e 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鈥檚 a great question. So email gets a little bit easier because we can look at the opens, but preferably the clicks. What we鈥檙e looking for in this is that signal in the data that tells us the customer鈥檚 taking the appropriate action. Again, in the scenario that I use here, we鈥檙e 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鈥檙e 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鈥檛 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鈥檚 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鈥檚 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鈥檚 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鈥檚 gonna, that gets into a technical area that I would lean on some of my data team. So I鈥檓 not gonna tackle that one in here, but it would all be covered off in the experience of the documentation.

And I don鈥檛 wanna mislead anybody. So that鈥檚 where I would go for clarity on that answer. Thank you, that was helpful.

So David, it鈥檚 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鈥檚 all. Thank you, you both. Thank you again for David and Steven.

Awesome, thank you for having me today. It鈥檚 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.