[Music] [Catherine Coppola] Okay. Hello, everyone. Thank you for coming. We're happy to have you here. This is Build B2B Better: A Guide to Developing Practical Business Solutions.
My name is Catherine Coppola. I am a Senior Field Engineer here at Adobe, Subject Matter Expert on Marketo, AJO, and RTCDP B2B. [Emeel Mkary] I'm Emeel Mkary. I'm a Principal Field Engineer. I cover Experience Cloud and Adobe Experience Platform. And we are super excited to have you here today to talk about B2B use case development. So this is a quick overview of our agenda. We're going to start with the problems of solution capability versus business use case, then we're going to jump into the architecture overview, discuss how B2B is different. Then the meat of our presentation is going to be the B2B use case template and examples. So we're going to walk through very closely some good and bad examples of use case writing for technical implementation. We'll connect that back to our entity relationship diagram, the ERD, and hopefully close out with why you need to write a B2B business use case.
Great. So in the last few years, as we are helping clients work through their implementation for Adobe solutions, we discovered that many of them have been finding themselves a few months after they launched the solution having to restart again. And clearly, they're having a lot more fun out there. I don't know what are you doing here. But having said that, the reason we found when we looked into it, that most of those accounts did not have a very clear business use case defined early on, did not know what their audience is that they're going to go after or activate against should be or what activation channels they're going to go after. And the biggest part of it all, they didn't point out any of this into their ERD when they designed it. While when we created this, we wanted to begin or help you begin with the end in mind. That's what will give you success. So another thing that we discovered as we work with these projects, when you work on an AEP project or Marketo project, you are going to be in a room with a large number of your teammates from different teams. And each of them have a different take on the language that you use day-to-day. Because we come from different backgrounds because we come from different solutions and technologies, if I say attribution, what do you think about, Cath? When I hear attribution, I think of program acquisition fields in Marketo. Very good answer. But when I think about attribution, I think about the revenue, the end goal, what is the conversion, and how did it all start? How did I bring the top funnel folks come into my ecosystem? So that could be email, as you just said, but there could be social media, or paid media, or other systems, or other channels, I should say. Okay. What if I said to you, Emeel, we really need to focus on scoring. What are you thinking about? I think about Real Madrid. Real Madrid? The soccer team? - Soccer team. - Okay. - Scoring. - Okay. Sure. Maybe we're talking about soccer. Hey, maybe we are talking about soccer, but I'm thinking about lead scoring and Marketo or using AEP for our lead scoring, right? But if I'm talking to the events team, they might be talking about net promoter scores. So the idea is that we need to talk to each other because we have all of these different words. Yep. That's right. I'm not going to bore you with much, but R-O-A-S. Anybody knows what that is? R-O-A-S. R-O-A-S.
Letters in English, maybe. Anyone know that one? [Man] Return on Ad Spend or Revenue on Ad Spend. - That makes sense. - Fantastic. See, one of the-- How many we are here? 120? 110? One of us knows what it is. So thank you. I don't have any prizes today, but I'll shake your hand after. So the point as Cath said, you guys are a large group. When you sit in a large project as Marketo, or AEP, or other solutions, you will have at least 20, maybe more folks from different teams in your company working on it. Just try to break the silos when we say, solution capabilities versus business use cases. And that's very important because the first thing when you work with Ultimate Success, our team, the first thing we're going to ask you as you're going into this implementation, what is your business use case? And I found out that not many of our clients agree on the definition. So I did a little bit of search, and I found that it says a functional use case describes a functional requirement of a system from the end user's perspective. Usually, it points back into a system or a solution capability. So things like segmentation, or create unified profile, or activate an audience against the destination, send an email or send an offer. All of these are capabilities. You purchased the solution because it does that. So when we ask for the business use case, it should be not that. These are already included with your package, with the solution. Here is a contrast for a business use case because we're at Summit.
During Summit, I'm going to send a push message to the account director when one of you folks that is part of a buying group goes into and scans their ID at a booth, trade show booth, or attend a webinar. The point here or my goal in doing all of this is to shorten the purchase lifecycle as I capitalize on your interest in near real-time. Now that's a business use case.
The definition of a business use case, it focuses on the potential financial or operational gain for your organization. And it is going to have to be including business objectives, and those objectives are not going to be related to a solution. They will be related to your business. It's a business objective. And you will need to define how you want to evaluate those business objectives. What are the KPIs? Not just what their KPIs are, you're going to need to tell me if you don't meet that goal against the KPI, what is the risk to your business? The next thing is the target audience. As you write your use case, who are you trying to go after? Or who are you trying to communicate with? And then specific to Adobe solutions like Marketo and AEP, you will need to define where is the data coming from, your data source, and where are you going to activate the audience.
Now I get this question, I kid you not less than a few times a week from different accounts. Why do I need a business use case? I want to send an email. I have a contract. I need to cut out the other system. I don't want to spend the money on the other system. I need to send emails as of beginning of April. Obviously, that's not going to happen if you're starting today. But to answer that, I need to take you a little bit-- I'm not going to try to read the whole architecture with you, but I want to show you a little bit about what our architecture looks like. On the left here, you see all of the systems, all of the touchpoints where data is generated and likely stored. On the right, you will see where you're activating the audiences. In the middle are all of the operations that happen in AEP.
So the other thing I'm going to point out here is that we have a server here called Edge that will come back in a couple of slides, another server which we call the hub, and then we have the data lake. These are three instrumental sets of servers that our infrastructure are built on.
In our system, when you are bringing any type of data, it will all land in the data lake eventually. It may go first to the edge or the hub and then land in the data lake. The data lake will act as the storage for all of the upstream and downstream systems. And our method of data ingestion for the data lake is going to be append and not update.
In our customer profile, real-time customer profile, we have two different data stores. One of them is a profile store, which will host all of the data fragments, including attributes and behaviors and supporting entities.
So anytime you're sending data, it doesn't matter what the data ingestion method. If it's enabled to real-time profile, it will be stored in the profile store. The second part is every piece of data, every fragment you're sending to AEP will have to have at least one ID. If you have two or more IDs, then I start from a relationship between them, and I create the ID graph based on storing those relationships in the ID store.
This is important because we do not store the profile as it is. It is called real-time customer profile because when you ask AEP, any of the services, AJO, Real-Time CDP, or CG, not CGI, but Real-Time CDP or AJO for activation, when you ask for an audience, it will go and run that job in real-time looking at all of the IDs related to that audience and looking at all of the data relevant to that segment or audience that you're looking at.
So first point is the fragments are stored in the profile store. The identities and relationships in the ID store. Relationships, not the identities. Sorry. And then important to remember, as I said, because we don't store everything in the profile all the time, what's here is subset of what's in the data lake.
Everything that you inject is going to go back to the data lake eventually.
Now coming back here to our architecture again, the first data ingestion method I have is with the SDKs or the API to our Edge network or Edge servers, which allows you to do segmentation on the Edge with real-time activation within seconds.
The second way is streaming, which comes into the hub, and then it will make its way to Real-Time CDP and eventually to AJO as well, where it may take a few minutes, but you will be able to stream it. And within few minutes, you can activate against it. The third is when you batch data into our system, it will go first if it's unable to profile, it will go first to a profile, and then it will land in the data lake. And that the evaluation on that, I'm going ahead, is going to take 24 hours.
Another point to point out here is your entity relationships or your entity data is going to make its way to AJO B2B. In AJO B2B, you can create the audiences based on buying groups. And then from there, you can either activate it through Marketo or you send it back to Real-Time CDP for activation on other systems.
The next is as the events take place using either the streaming ingestion or the Edge, it will go through the pipeline. And then within minutes in streaming fashion, it will come to AJO B2B, empowering near real-time activations.
And the last thing I'm going to call out is you have AEM Assets Essentials that connects to AJO for content creation.
Now as you bring the data into AEP, I mentioned for you three different types of data ingestion. One of them is streaming, and the other is batch, and then we have the data into Edge. The important differences between streaming and batch are, as you batch data, you can bring a lot of data all at once. But then you're not going to be doing that too frequently. Where as you bring data with streaming, it's going to be smaller in size and it will be much higher frequency.
On the other hand, latency of the data availability for activation. With streaming, it's low latency. With batch, you're going to need to wait for the evaluation, which happens every 24 hours.
This is important because when we talk about the types of audiences available to you on AEP, one of them is audience that you can create on the Edge server that I pointed out a few minutes ago. There you can create simple logic and with real time activation to the next page. But on streaming, you can go a little bit more complex. And then you can also have a little bit longer lookback window up to 24 hours. And you can do activation near real-time.
On the batch audiences, you will be able to use all of the data in the data lake, but then the latency is going to be 24 hours.
Now before we get any further, we would like to tell you a little bit about how B2B is different. So I think, hopefully, you picked up on a lot of what Emeel's talking about, but needless to say, it's complicated. And B2B is a little more complicated. The data structure changes, and we'll go over that in the ERD portion. But how is B2B different? We have longer buying processes. We have longer relationships with the customers and longer decision-making processes. Oftentimes, we're dealing with group decisions and consensus and executive sponsorship, which means that different people have different roles in approving the purchase of our goods. Additionally, this also makes things more complicated data wise is the lead to sales cycle. So there's a marketing sales handoff. Sometimes there's a handoff back from sales to marketing as well, aligning on MQLs, SQLs, definitions like that really matter. And then there's the latest and greatest, which is account-based marketing, and maybe you heard earlier today, buying groups, right? So these are the newest ways to segment for your B2B use cases. There's many stakeholders. There's varying levels of influence within the account. So to put it more simply, in B2C, the end user is often making a purchase decision for themself. They're purchasing on behalf of themself. I'm oversimplifying our B2C use cases. But if I go to the store and I buy toothpaste, my decision might be quick, and my relationship to the organization is over until the next time I decide to buy toothpaste. Whereas in B2B, we're making purchase decisions not on behalf of ourselves, but on behalf of a business. That means that if I leave the organization, you still have a relationship with the account, right? So they're similar, but they're not the same. And so I wanted to bring up-- I realized there's a lot of text on this slide, but I do think it's important. I'm going to skip over what individual audiences are. That's when you just start marketing to a person. Let's focus on account and buying groups. An account is an organization. So you're doing your marketing and your segmentation based on the organization. That might be the industry vertical, the number of employees, the region of the headquarters. This is B2B with account-based strategies, and your target marketing is based on the account level. Buying groups are different because it's for the stakeholders within that organization. So it's group level stakeholders for a specific buying decision, or we could think of it, some of us, as an opportunity. It's way more complex, and it might include things like engaging not only the practitioners, but the sponsors, the IT, the finance department, the legal department, things like that. So just to illustrate for you, well, they're all technically implemented very differently. And so just to illustrate that for you, this is an example. So everyone you see on the screen is a member of the account ACME, but let's say I'm Adobe and I have a lot of different products, right? I have Photoshop, I have AEM, I have RTCDP, and not everyone at ACME is going to be involved in every purchase. It doesn't make sense for me to market Photoshop to the VP of engineering, but it does make sense for me to market AEM to the VP of engineering. I can create different buying groups based on the product or the opportunity that I wish. So it really allows you to tailor more closely. It's super helpful when you have multiple opportunities on single accounts.
And that's what brings us to the meat of our presentation, our business use case template. So we're going to teach you how to write a good business use case. So we'll go over the template. And I do have paper copies of this template. If anyone wants one after, I can give it to you, or you can get in touch with us, and we can email you a copy later. But with that, I'll hand it back over. Thank you. All right. One of the things that we would like to remind you of, please state as clear as possible, what is the objective? What does your business want to execute on? At this point, we don't want you to think about the technology or which solution is going to deliver it. We just want you to state what your business needs to do.
We broke it up in a little bit into sections. The first-- You can't see it there. But the first section in yellow is where you give it a clear name, define what you're trying to do in the summary, and, again, define your business objectives.
On the second section, we're going to cover it a little bit in more depth on the next slide. But this is where you define your audiences who's going to be included into the activation? And when or who's going to be excluded? Even if I'm included at one point, should I stay there indefinitely? Likely not. You want me to take an action. And when I take it, you want me out. And then the third part of this is, write in natural language what you are trying to do so your data engineers can actually understand where to get the data from.
And then the last part on this slide is the data sources. Where does the data live today? So when you're defining your audience, you're going to have different levers to work with. First thing I want to point out, when you're activating an AEP, you're activating against a profile, which is a person. There are attributes to the person, including the email and phone number and what have you. But that person belongs to an account, and that account has one or more opportunity. And you may have one or more buying group. Each one of those categories has different characteristics that you can play with to define a concise audience relevant to your use case and give you, hopefully, the goal that you're going after.
So as you work through defining your audience, think through all of these elements and define it well enough to be relevant to your use case.
That's exactly right, Emeel. Think of it this way. If you write incorrect requirements and they're implemented per the requirements, it doesn't help, right? So we need to write the requirements clearly so that it can be implemented correctly. And that brings us to the activation portion. So in this phase, I don't want you to try to design.
The team should be thinking about, "What do we have available? What do we have licensed? We have Marketo. We have AJO B2B. We have Target. Some other third parties. What are the channel solutions that we can activate on?" But don't go further than that in the designing. Then we need to articulate the user journey touchpoints. So describe in as much detail as possible how you're going to interact with the customer, what emails are you going to send, messages you're going to send, all of that is required to make sure that it's viable for the data structure. The next part is the personalization components, and it's small on the screen, but it's actually really important. It's super important for when you're designing and implementing, right? And I like to think of personalization as really two parts. There's personalization of the journey. That's when do you receive a message, if you receive a message, what channel it's on, how it's served. And then there's the personalization of the content, right? That's what's inside. So for example, in an email, it might be an account number or it might be a sales rep's information, things like that. So there's the journey personalization and the content personalization, and it's really important that we're writing out what we require. Don't worry about designing it, just what you require to execute the campaign.
After that, there's routing automation, right? This is a little B2B specific, but what types of sales routing needs to occur and when? So do we need to get a certain record to sales in a certain amount of time? That brings us to speed to lead. What is the speed at which a qualification must occur? Must we send the email within minutes, or can we send it tomorrow? If they fill out a form, how soon do we follow-up? It might seem like a minor detail when we're executing the campaign, and do we send it right now or do we send it tomorrow? But it actually makes a really big difference in the implementation. And then, of course, we have KPIs and success evaluation. So what the KPI-- What we're going to set out to achieve, we're looking for numbers here. If you have an expectation that your CTOR is 20%, we want to know the expectation is 20% because we want to know if we're meeting that, as well as the conversion. So there should always be some meaningful conversion that really indicates the success evaluation.
So with that, let's do an example together. Now I did write this example purposely to make Emeel's blood boil. So this is a bad example that we're going to go through, and let's see how mad we can make Emeel.
Imagine I came to you, and I said, "Okay, the marketing team wants to recreate their existing campaign. It's called Welcome-Nurture-NEW-2019. New and 2019. It was new at the time that we made it, and we're going to do a simple lift and shift onto the Adobe technology. I won't be helping with any lifting today.
We told our executive sponsor that we would go live by the end of the month, and we just need to get this onboard. We need to get it going. Yes, a very realistic timeline. And because of that, the audience is going to come out of the CRM. It's going to be fine. I'm just going to upload a CSV so that we can get this going, get this off the ground, and we will figure out the audience and the segmentation later. What goes into the CSV? I have an Excel spreadsheet. It's all up here. So okay-- This is very important. In our old solution, we had virtual hobbits, and they belong-- I love that movie. Have you guys seen it? The Hobbit? The virtual hobbits belong in the lowest content block. We use them in every single campaign. They're mission-critical. We need to, by the end of the month, rebuild this feature functionality in our new solution. So we have to get the virtual hobbits up and going, okay? Great. And then, of course, we need to include an advanced lead scoring program, also mission-critical. We need that for the sales team. That's got to go in as part of the Welcome-Nurture-NEW. Back into soccer now. Yes. And the goal is to make our new members feel as warm and welcome as possible. Anybody needs a blanket? You want to get warm? Okay. So let's look at the red flags.
All right. I mean, the first thing I've been trying to be a little bit funny there. But the first thing, you're telling me it's new, but it's 2019. They don't go together. Also, never ever expect a project moving from one system to another to be lift and shift. Each system has its own architecture. Each system has its own data structure. If you are going to lift and shift, I will guarantee you, three to six months later, you'll come back and ask us, why is it not working? All right. The next is manually uploading and figuring out the segmentation later. So at this point, the marketing team should not be assuming anything about the design. So don't worry about if it needs to be uploaded or how the segmentation is going to work. If you tell me that you can upload a CSV, it tells me that you have the data somewhere. You must have a query somewhere. And so that is what I'm looking for is what attributes are you using to create your CSV. Don't worry about how it's going to actually work in the system at this point. We'll get to it later. The next is the virtual hobbits. Now hopefully, you realize I'm being funny, but what is a virtual hobbit? It's a feature that you loved about your old solution and you want to recreate it. Yep. Just tell us what exactly does it do, and we'll tell you how to what parts of our system can do it for you. Right. So what does it do? What did you like about it? What did you rely on? So trying not to rebuild old functionality and new function, but see what we can do to meet the requirement itself without the design yet.
The next is lead scoring. This is mixing use cases. What's more likely is that this nurture will influence a scoring program, and that is something we should account for, but we shouldn't jam it into the same use case.
And the last. Warm and fuzzy is a very good feeling, but I can never quantify it. I cannot measure it. So yeah, you can use that language, but quantify what that means as you go through it. And I'm getting ahead of myself here. Okay. So with that, let's write this better.
Okay. So the first part we're going to call out here is we are naming it Welcome nurture campaign for new customers. The goal here is to, yes, get or create a warm experience. I want to personalize the experience, make it warm for my visitors. And if you keep them about the solution they just purchased, create, establish trust, and encourage them to complete the relevant content and touchpoint.
You can use the context of saying, this is our old campaign that has been successful since 2019. We want to move it from the old system to the new system. Definitely include that context. We don't want to lose track of our previous success.
But as you define your business objectives, you're going to tell me that you would like to encourage or have new customers finish their onboarding paperwork. You're going to educate them about the new features and the new offering. Drive early stage engagement with the personalized content.
Much better. Thank you, Emeel. So this avoids a lift and shift mindset. It adds context of our past success that we're not going to forego. And it sets clear objectives for the use case. Now moving on to the audience descriptions and the data sources. So here you can see and this is the part I think that trips customers up the most. And I've read a lot of your use cases. I've been in a lot of your environments and talked to many of your team members and some of you yourselves. This is what trips customers up is that they can't articulate who they're talking to. They don't know what data fields they use, right? And that's where we work with them. Okay? But here, a clear description would be that has an opportunity closed-won in the past two days, is a member of our opt-in is true, visited onboarding pages in the past two days, and registered or registered for our welcome webinar. So we're saying, "Okay, who is in this audience? And then who do we exclude?" So let's say, in this case, we're targeting our new practitioners, so we're not going to include anyone from the executive sponsorship role in the buying group and profiles who are unsubscribed because it's technically marketing. And let's say for a certain line of our products, they have a different onboarding program, so we're going to exclude anyone with those closed-won opportunities. Of course, if they changed companies, and if they've already filled out the onboarding paperwork, we're going to exclude them as well because they've already met the goal. And then, of course, you can give some definition, some context. Don't forget. You're basically writing instructions for an architect to design and to design your implementation. So talk to them like a human and try to express what you need because that's where the conversation happens where it might be that, "We're not going to use this opt in field. You might want to use this one, and we can refine the use case," right? And then, of course, I'm going to list my data sources. That's very important for the implementation. We need to know where the data is being sourced from because it goes back to the architecture that Emeel was showing earlier, that complicated architecture. We need to know where it's coming from and how fast you need it. So how did I do with that one? Great. You defined the audience very well and what attributes you would like to use to define the segment and also the events. You also clearly articulated your objectives. So you've done great. Great. Okay, let's keep writing this use case. Our activation channels and solutions, that's what we have available. You would be surprised how many times you might see that your team's confused about what they have available to them or they didn't know they could use certain licensing. And then we're going to talk about the touchpoints, right? And this when I'm reading through this, what I'm also doing is walking through in my mind that architecture diagram and the ERD, and we're going to look at the ERD together. But as they enter the journey upon qualification, they receive an email for four weeks driving them to relevant web pages, and the sales rep is going to check-in on them personally via phone, and invite them to a meeting at the trade show booth. The components of personalization are based on previous email and web interactions, and if the customer completes the necessary paperwork, which is a form, hiding this message for the remainder of their journey. And the content is going to be a few fields that I've picked, first name, date of onboarding, and their sales rep information. The routing, also important, right? Because when we're designing, we need to know where we need to get the data and how fast. So as the customer completes the process, their lead score is updated by one, and then for every webinar, they get 10. We're trying to gauge how well they're introduced to the new product with this score. And once they reach 15, the salesperson is notified that this part of the journey is completed. And if they do not engage, we'll have a follow-up in a few days. And then the speed to lead. How fast do they need to receive their first message? Do they need to receive it within minutes, or can we wait a couple days, right? And that'll make a difference to our design as well. And then, of course, sales alerts. How fast do we need those? Usually pretty fast. What do you think? Great. Now you stated the solution, which solution you will be involved in the activation. You stated, I'm sorry, the type of touchpoints. You highlighted the personalization requirement, which is very big. When we talk about the ERD will come back to it. And you identified the clear routing and speed expected. Great. Okay. Next part is mine. I forgot that. But we said many times that you need to define your KPIs and not just what the KPIs, but also the goals you would like to reach. So here we're saying, we want to have 95% complete onboarding paperwork within the 7 days. And we want to reduce the call center follow-up by 35%. We also want to have 30% attend the onboarding webinar. And we want to see a greater than 50% open rate to all the emails.
Very clear, very measurable, and it will be quick to evaluate on our system. Our goal is, or the way we will evaluate our use case, successful campaign will automate the process of onboarding paperwork, completion, elevating the required follow-up emails or follow-up calls from the call center.
Much better. We now have measurable KPIs and a clear understanding of what success looks like.
But what about my ERD? Okay. We're going to look at two very simple versions of the ERD.
And before we get to it, this is a color-coded version of the RTCDP B2B Edition data model, right? So if you just do the out-of-the-box model, this is what it looks like. These are the objects. I've color-coded it. So what I want you to do is follow along with the colors. I'm going to tell you a story that you can extract just from the data model. Cat is a field engineer at Adobe since December 2nd 1982, the first day of Adobe's founding. That's my relationship to the account. Adobe, the account, is headquartered in San Jose and has more than 10 employees and is interested in purchasing a product. Notice the account is purchasing the product, right? Okay, so Cat will influence this decision, this opportunity, along with other employees of Adobe. She does not influence every opportunity we have with the company.
She visits a web page, she fills out an interest form, and she fills in all of this information.
Now she subscribes. She's a member of our product marketing list. And because she's a member of the list, she's invited to a certain webinar.
When she registers, that's an event. We're going to send her an email, and after arriving, record that she has attended and note her program success. So it's a little silly and confusing, but it helps you under-- I hope what you get out of this is that you can tell a whole story just by looking at an ERD. So now how many of you have seen an ERD before or work with them regularly? Okay, some of us. Okay, now for those of us who have never done that, let's look at this ERD.
What I have pasted at the bottom is just the requirements-- Don't take a picture of it yet. You want to take a picture of the next one.
Is the requirements of the campaign. Now I read a good use case, I have my ERD, and I know the architecture that Emeel showed me. How many people think that based on my use case and my ERD, I can achieve my goal? How many say, yes, you can achieve your goal? You can achieve your goal. Why? Anyone know? Yeah. There's something really key missing here is the opportunity. That was we forgot to include the opportunity in our ERD, right? Everything's related to the person, but we're segmenting based on the opportunity. So that would not work. So, Emeel, can you please fix this? I'll do my best. So we just updated the ERD. We included the opportunity and the opportunity relationship.
Do we think now this is going to work? How many say, yes, this should work? Okay. I think it would work. It'll work. Yay! Look at all of that content we highlighted there. You can see clearly that with the B2B activity, you can find the event that tells you that there was opportunity closed in the last two days. You have in the person table, you have your marketing opt-in equals true. And I have web page activity that tells me the page names. So if I visited three onboarding pages, you will be able to see that there in the last two days. And if I register to our webinar, you also can see that in the B2B activity table. What I hope you get out of this is we showed you three key elements, enterprise architecture, valid requirements, and an ERD. And you should try to proceed with all of your use cases having all three of these because and the requirements are at the basis of it because you can't check your ERD or your enterprise architecture against anything if you don't have your valid requirements. So we read the requirements. And literally, sometimes I'll read your requirements, and I'll circle. And I'll say, "Okay, that's there. That's there. And can I get it streamed? Can it be batched?" All of those things. Yep. Now we really hope by this moment, we've been going at this for 40 minutes, that you can answer this question. Why do I need a business use case? First, you need to know what data you will need to identify your audience and where you're going to activate them. The other is where you're going to activate them.
Which channels? How fast do you want to act on it? If somebody scans their badge in a booth, do you want to reach out within five minutes or within five days? What type of audience are you going to need for that use case? Is it going to be Edge, streaming, or batch, or maybe a combination? Will the data you need be available when you need it? All of that is important before you start loading your data into the system. So that is why you need the business use case. Okay. Thank you. Thank you, guys.
[Music]
