[Music] [Corey Bayless] Hello, everyone. Welcome to my virtual Adobe Summit presentation.
My name is Corey Bayless and today I'm Wrangling Data for Scalable Marketing Workflows with Adobe Marketo Engage. So welcome. I'm currently a director and product owner of 12 different instances of Marketo at Prudential Financial.
The agenda for today is we're going to start with an intro and we're going to see success at scale, data encapsulation, the market automation cycle, omni-channel integration with the channels being web form fill out, list import, web service APIs, and salesforce.com. And then finally we'll show what enabling Adobe ecosystem with the native integration capabilities. And then we'll finish up with wrap up and key takeaways. So let's dive in. So a little bit about me, I'm an Enterprise Marketo user for 11 plus years. I've been in some of the largest Marketo instances in the world, Microsoft, Expedia, AWS, and now Prudential and the many different Marketo instances that they use. I'm a five-year Marketo Champion, Adobe Experience Cloud Enthusiast, an AWS cloud practitioner, a Python developer, automation enthusiast, love data compliance at GDPR. I don't love GDPR, but I love making sure that we're compliant so we pass GDPR and don't incur giant fines. I'm a preserver of MOPS lives everywhere, basically including myself with saving people from technical debt and the solutions that I've used to also solve various enterprise level solutions. And I have a workflow diagram obsession, which you will find out in my presentation because there are a lot of workflow diagrams.
So my motto in life is, "Automate everything and be allergic to manual work." That has been the thing that's maintained and been constant in my life since the start of my career, and it has not failed me yet.
So success at scale, right? How Adobe Marketo Engage can automate omni-channel data intake, right? Let's learn about that. So what is success at scale? So success at scale is with the building the solution with a thought of data encapsulation in mind. One data point can encapsulate an entire database of people, and it creates seamless targeting and workflow management. With the simple idea of how do I do more with less, right? A consolidated frameworks, simplified troubleshooting, reduce the bloat in my programs, and I'm able to handle that omni-channel from a small business to enterprise level, right? This is a model that works for everything.
With the general idea of coding from scratch is very expensive, right? So I want to use templates and I want to templatize wherever I can. If I have a recurring use case, I want to have a template for it. And sometimes that takes time to figure out what your recurring use case is. There's so many different ways something can be handled and solved in Marketo. That's the beauty of the system, as well as also one of the issues of the system is that there is a lot of different ways that you can solve something. So it's not always, this is the best way to do something, but it's the way that I've done it and it's the way that I've had success with it. So that is definitely something to take in mind is that you can take these practices, you can bring them and make them your own, or you can use them to improve your understanding of the system. It's going to be both ways, however you want, right? But with the general idea that I always have one multi-use landing page template that's very flexible, it's very responsive, it's super cheap for me to build them, I'm easily able to design, I have little to no development or small amount of development that I can use CSS, HTML, JavaScript to be able to solve my problems. But I'm also very, very quick to market in terms of how efficient I am to get things in front of my customer, right? I have an idea of one multi-use email template I can code from scratch or I can build an email template depending on what it is, as long as I have good design modules and branding and I can solve all the various things that makes email nice and cheap, right? That's the goal. I want to make everything nice and cheap.
So what is solving at scale, right? So in this case, in this presentation, we're going to be doing one Marketo instance or we're doing many Marketo instances. In my tech stack or in the Prudential tech stack, we have four customer-facing instances. We have 12 total, 6 sandboxes, 6 production instances. But the general rule of thumb is that if I can solve my own problems, technical or non-technical with myself or my team, then that means I can build foundation and I can understand how I need to solve my various issues. So companies that get there by understanding that foundation and data flow and expected connectivity of their tech stack generally will have the most success. Systems that talk to each other need to talk to each other. They have to have flexibility. They have to have agility. They have to have compliance and they have to have the ability to connect through APIs and talk to each other. AEP can be an excellent work around for the different systems and being able to read and monitor data in other systems and then supply that information back to Marketo. It provides necessary data visibility so that Marketo has what it needs in order to have success, in order to give the customer the right journey that it needs to go down, right? Marketo in itself can't actually talk to other Marketo instances. So in my case, I actually need to use AEP or I use OneTrust in order to help federate data to my other systems in order for my systems all stay in sync. It's a pretty complex ecosystem of things that works together, but it works very well and it does what we need to do at scale to maintain Prudential's compliance.
So understanding data encapsulation, right? So one value can be used to target an entire database of people. What do I mean by that? I mean, one string value on a Marketo record across 40,000 records can now be used in a smart list to call that one particular value on that field to pull in your entire target database or entire target segment that you're trying to capture, right? Then once I'm able to capture those 40,000 people, I can send them and distribute them based off of personas and different types of behaviors and all kinds of different, like clicks email, or visits landing pages, or fills out this form, or is a member of this program. I have a lot of flexibility in how I can manage that, right? So 10k, 20k, 30k, 500,000 or 1 million records that I'm trying to send an email to, it gives me the ability to have coordinated distribution. One of the things that is super important is that Marketo actually struggles to target unique values, meaning one email is one value. So if I have 10,000 emails and I'm only able to use 2,000 emails and one particular smart list filter, and I need to target 10, that means I need 5 email address is smart list filters in order to target the 10,000 people. But if I encapsulated the data, then I could use one value to target the entire segment of customer that I'm going for.
So the Marketo framework is we simplify everything, right? I map all workflows from start to finish. And you'll see how I did that here on the right side. For Prudential, we use OneTrust as our single source of truth, as I've said before. But AEP can also be used to solve for that particular use case, right? It's all about creating good data intake, right, for key. And good data in is good data out. And good data in creates good personalization opportunities that then you can then use in email and you can use for other various things using Target or other Adobe ecosystem products, right? AEP can help facilitate and understand the different journey analytics through your Customer Journey Analytics software like CJA, or you can use Target or you can use Adobe Analytics. But basically, you're creating everything that encompasses the entire ecosystem and workflows and web flows of how a person will travel through your different digital assets. Super important to understand that, right? So if I were to understand personalization in the simplest form, this is a great example. is a token that I could bring into an email through the HTML. And based on the person that's receiving that email, before the email goes out, Marketo looks to see in the database, "Hey, does this person have a value?" Okay, it does. Pull that value in, and then I can even add a default element there if that person doesn't actually have a value there. And it's important to always cover your bases for the different errors that you might run into. Not everybody's going to have a specific value, and sometimes you need to backfill that with a default value in case that exists or doesn't exist.
And then when you get into Velocity, it becomes even more dynamic, and you can have conditional-based logic to be able to pull in different values based off of custom objects or different field values, and how you want one or the other. Think of it as a many-to-one scenario. So you do all of these things, and you manage all of these workflows, and guess what? Now it's all automated, and I don't actually have to do anything. Instead, I focus directly on my mailable data pool. All my channels are handled, and it all goes into a spot where I expect it to.
When it works great, it's really, really nice.
So let's start with the web form fill out solution, right? So what does that look like? So a Global OPS Form Campaign logic, the smart list filters cover two criteria. One being, the person is created in my system, or the second being, they already exist in my system, but they fill out a form and they qualify for compliance, again, if they need to. This can be built out in a multitude of ways, but I use a simple logic of the email. The form naming convention contains email with the flow steps of being, okay, cool, now I'm capturing all of that form fill data, everybody who's coming through a form, I'm capturing that data. They're qualifying for one or the other triggers. It's a trigger solution-- Triggers operate in or situations, right? It's a person is created or they fill out the form with the flow step being that I'm requesting campaigns. Everything I do for constant recurring request campaigns or runtimes, I'm always using request campaigns to do it.
And just the rule of thought is, preference stamping should only be done at one spot in your system, and it usually should only be done in the administrative workspace, right? Because if you have lots of users in your system, you want to make sure that you protect these compliance frameworks at all costs because if those get disrupted, it can disrupt your entire system. It can be really, really problematic, right? So you want to make sure that you as the primary Global OPS preserver is the ability to maintain and make sure these flows are constantly always doing what they're supposed to be doing.
So the logic of a request campaign, a lot of people will know how to build a request campaign. But if you don't, I'm going to show you real quick, is that a request campaign has a limitation that it has to be in the workspace where the request is being made. So I can't make a request campaign or a request to a campaign across a workspace. I actually have to pull data in, in order for that data to successfully run through the various workflows that I need, and it has to be in the administrative workspace in order to do it. And then I can distribute outbound based on my partitions and other workspace logic, depending on how complex your Marketo system is, right? But with the idea that if I have constant run times with preferences, meaning people are always constantly getting assigned new preferences or running through different preference containers, the request campaign is basically, it is the entire grouping of all of those different flows that I want to constantly be running and rerunning against all of the different people who qualify. So instead of having it in a multitude of places, I have it in one spot, and I can be very controlled in how I distribute these different preference types. It's very, very effective, and it also allows me to handle troubleshooting in a much easier way. As you can see to the right, I have a positive and a negative. I always like to show negative being unsubscribe, and it allows me to quickly and easily call in these request campaigns when I need to call them in my various other programs and the way that I'm running my different workflows. Just allows me to quickly call to things without having to make Marketo search through an entire database of campaigns in order to find what they need to find. This allows me to easily name and explain without having to click on it what I expect this campaign to do. That's how I do things. I like to make things nice and simplified with the ability to visually know without having to click-through things what this campaign is actually designed to do.
So data encapsulation for form fill compliance, I like to call it also the singularity data stream. That's what we're creating, right? One data point can create curated targeting with good strategy. In this case, I have my preferences of email communications being true, and the opt-in date was this time with the person went through this particular campaign. But I also have a negative, which is my preference center where I'm handling unsubscribes. Unsubscribed date, , unsubscribed reason is from preference center, which is what I always have people have to go through in order to unsubscribed. And then I make sure that those values are all cleared out to enable and show that this person went through the things at the time and they unsubscribed. So therefore, email communications false and then email communications date is null, meaning they're not subscribed and they also have the unsubscribed as true. So that actually will allow Marketo to block that person from receiving marketing emails. It's built-in as a system level constraint in Marketo campaigns. So very, very good to know that.
But the primary benefit of all of this is that I'm able to bottleneck critical data in my system. I have less forms, I'm able to easily reuse, and I'm able to easily control my data flows. Web form fill outs at the top level, it goes into program level trigger membership and different automated emails that go out. And this is for native forms with the Global OPS campaign, always listening for that web form fill out with a trigger with the request campaign going to the various request campaigns that I needed to go to email communications, email communication opt-in date, , all the various things that you want. And your preferences can be a multitude of things. This is just an example, right? But with the idea that once it's all done, I'm able to store it in my mailable data pool in my static list. If that's how you want to do it or you want to use smart list, it's up to you. But I have the idea that I've now created a new data stream, which is the compliance data stream. And so all of my other data that's coming through, if I merge it into this one compliance stream, then I have a singularity data stream.
Omni-channel Marketo Compliance data stream. There you go. So let's go through global list imports. Global list imports, not super tough. Person is created through a list import. We want to be able to manage and process them. If the person already exists in the list import, then we can also run them through there as well. But with the flow steps that it's conditional based logic based off of the data that's coming in through the Excel. Map your Excel spreadsheets to the fields that trigger these campaigns to maintain consistent compliance and workflow management. This allows me to control everything that's coming in that might be happening outside of my vision. So it allows for my marketers to successfully complete the tasks that they need to do while also maintaining the compliance on these records. It's a win-win scenario for both. I don't have to manage it. And if it's taught correctly, keywords taught correctly, right? If I train it correctly, then I should be able to get my marketers, my field marketers to be able to do the things that they need to do, upload the data they need to upload, and have the success they need to have and apply the consents based off of compliance they capture at the event or wherever they're generating that list. It's a good way to do it.
Now let's jump into the web service API. So web service APIs are a little bit more complicated. This one is challenging, right? But if a business is able to solve this particular issue, it gives an ultimate ability and agility to solving a lot of different runtime issues that a big company would face. It's why there's actual businesses that are dedicated to solving just this issue, which is pipeline integration, right? But the big thing is, is that if companies that solve this problem in marketing, they understand one key element to their data intake. And that is that automation is absolutely mandatory. Not solving for this creates a dependency of manual list import processing. And that's never good. And that basically means that every single day, I have to process a list that's being sent from a vendor. I'll process that list. I'll make sure it has all the things that I need to have. And I'll basically rinse and repeat that process every single day until the campaign runs its cycle. That doesn't sound like any fun. It shouldn't sound like fun to you. And we definitely don't want to be doing that, right? And it is actually the difference between a MOps team being proactive versus a MOps team being reactive. I'm reactive to all the things that are happening and I don't really have time to be proactive versus if I automate the things, now I don't have to worry about these workflows and I can be proactive towards my roadmap.
So the singularity data stream, when it comes to the API, right? Understanding the web service API is you need to have a really good understanding of APIs in and APIs out. That is the most important thing as a Marketo practitioner and understanding your native integration isn't always going to work. Marketo forms are always going to be available. But if you're trying to get data from another source and you have developers who are able to do it, understanding how they could build these APIs into your Marketo instance can save you a lot of issues. And the better that you are at it, the more clean your data will become. So highly recommend people spend that time to understand how APIs function because it will save you a tremendous amount of time downstream.
But when I'm pulling data in, and we get all of those things done, I'm able to then pull this data into what's called the Marketo API Data Processing Hub. And what that does is allows me to create layers in Marketo. And that's super important because if I have an APIs gone wild scenario, right, where only APIs are going in and I'm not controlling any of the data, then I don't really actually have the ability to curate the journey for that customer. But if I follow this route, then I'm actually able to handle the import, process the data through the necessary compliance that I needed to follow. But I'm also then able to send that to the program that I need it to go to in order to automate the program membership and all the various other elements and requirements that I might need for analytics, right? And if I'm able to automate these cloud deliveries and write attribution, I'm able to highly control my lead sources and I'm able to control the data, right? So if I use this program, I could send them into a nurture stream. I could add them to a program. I could activate other triggers. I could send them down a crazy long list of different resources and assets that I needed, that I need that person to get, that I need them to get, right, drip nurturers or different types of nurture campaigns, I now have the ability to do that. And that's really, really important. But another big piece to this is that if the customer data is going to travel, right? And the expected destination has to be reached in order for me to have success with compliance and also for the program source for how I want them to receive their automated emails based off of form fills or other types of requests that may or different types of use cases that you might run into. But I now have the ability to be confident in what I'm doing. And I know that it's going to reach the destination that it needs to reach. So that's really important to understand. But then the next thing is, is that when I'm using web service APIs, I need to understand what is the power of deduplication, right? Marketo lead Id is the best lookup method for managing deduplication and lookup when creating records via the API. If you don't do this correctly, you can create a massive problem of duplicates and it can be very problematic. But if you have the ability to have the Marketo lead Id, as data is being pulled in and it's a person that already exists and this other system already knows who that person is, then it's going to actually write the attribution into that record as opposed to creating a new person. And that's important for the deduplication elements of what you want to focus on. But once data is controlled and I do it all correctly, then I'm able to create a singularity data stream with my web service APIs that go through my Marketo API Data Processing Hub. And what ends up happening is that now that I can process that, I'm able to manage that data in a more automated way. And how I do that through my API data processing hub logic is I have a person is created or data value change. You've noticed that there is a definite pattern here to how I do things. Either person is created brand new in the system and I want them to do this thing or there's a data value change that happens and on a person that already exists, but I'm still accounting for them being able to qualify for this campaign and qualify for all the flow steps and the compliance campaigns for preferences that I need. If they already have the preferences, that's fine. Marketo will skip signing them the preferences. It won't overwrite anything. It just skips them and says, "Yep, that value is already there. We don't need to write it, they'll be skipped." So that's how I handle it. And then I send the request campaigns and that's how I branch off my data, right? So continue with the singularity data stream. Here's a use case that we used. I had an automated third-party consent that was being captured. I needed them to send, they didn't want to use native Marketo form. Okay, that's fine. We had developers on that side and I had developers on my side and we needed to connect all the dots and make sure everything was coming in. Well, it came in through a CSV file upload process, which then was processed by one of my data warehouses. They got the client code secret and Munchkin ID that they needed and they fired the data into Marketo. My Marketo API Data Processing Hub pulled that data in and it created a fork in the road. It split it off to the Marketo program and it split it off to compliance campaigns, right? So I was able to mark all the campaigns, hit the compliance requirements and also create the curated journey for the customer by sending them the automated email. And you can see how I broke that down using workflow diagrams to be able to show my leadership what this was actually going to look like without actually having to even open up Marketo, right? A lot of people don't really understand Marketo. So it's really important that you know how to create a workflow diagram that shows how Marketo actually functions. I love using draw.io. It's a free service, but I'm also able to use this and say, "Hey, I can curate this workflow diagram to match the experience that we're looking to match for this customer and also in order to maintain and hit the compliance." Being in Marketo for so long, I'm actually able to visualize data workflows, which is a really big proponent for you to get very good at Marketo. Something I recommend, understand how activity is written to a log, understand how that log moves in a sequential order. And then once you understand those things, then you can be able to operationalize that logic in the way that I've showed you through this workflow diagram. You can build these however you want, but I highly recommend you get good at them because it's great for becoming much, much better at Marketo.
So the API automation, when you want to think about it in the simplest forms, it's basically a static list or an Excel list that's being automated to a particular cloud delivery location with the data mapped in. And those fields are mapped in by the API name of the field that lives in Marketo. It's not the friendly name, it's the API name that you need to have on that file and how you're coding it. And when you do all of those things correctly, it allows for me to write additional attribution like the person source or lead source in to the file. And so when the person is created or is mapped to, then we know that that data value is changing, my trigger campaigns will fire, the compliance will happen, the split in the road will happen, all the things that I expect and I'm able to test all of that, right? It's very easily, I can test it. I know that it's going to do what I want it to do, right? We're doing all of this throughput. I can see the results directly in Marketo as it moves through.
All right, so when we go through it, right, and we look at-- Okay, how did I actually create that fork in the road? I'm going to explain it. So at the program level for my Marketo Data API Processing Hub, I have a smart list that's doing, it's listening for people who come in and I have a add member to the target program in my workspace that I'm looking to add to, right? With the idea that program status is my change trigger, which is a trigger available in smart lists. And I'm saying old status, they're not a member and my new status, they become a member. Now I've been able to activate that Marketo program and run people down the automated cycles and journeys that I need them to run down, right? And I'm able to back up all the data, do all the things, stamp all the compliance, pass all the data to my OneTrust instance and there you go. And that maps do all the compliance requirements that I face at Prudential.
And then once I'm able to add those Marketo programs and then able to send the email, change the program status, and capture all the analytics that I want based on the channel and how people are coming in, therefore, handling my web service APIs.
So let's jump into the Salesforce data flow, right? So Global OPS Salesforce data flow was a tough one because we had a lot of data coming in from Salesforce and I needed to be able to figure out, okay, what are all the various channels, all the different channels and person sources or lead sources that are coming into Marketo? How do I understand that, right? So as I continue to audit the system, I use my people performance report to use custom columns and this is how I did it. So custom columns are really, really cool because it's a smart list that gives you the ability to expand an analytics report for people performance report in a big way. So how I did it here is I created my smart list or actually my coworker created the smart list and then we're able to pull those smart lists through custom columns in the analytics report and then the output was that I was able to see all of my group by person sources by the top level channel, which is my original source type, which is basically your top level channel of how data enters in the system and then I'm able to create my pipes like I showed you before, right? And then now I'm able to create an analytics report that actually gives me the distributions of how each channel is performing without actually having to do anything. It's an automated report that comes to me every day and I'm able to view and see, okay, how many lists imports? How many form fills did I have? How many data points synced over for my Salesforce instance? I'm able to see all of that. I'm able to manage and monitor it all. And that's super important because as a Global OPS practitioner, right? And somebody who's obsessed with automation, if I don't understand these things, then how do I manage this data? You can't, right? It's impossible. So super important, really cool way to build a people performance report using custom columns. Highly recommend you test this and understand it. It's super critical for being able to understand analytics.
So the Salesforce data flow is an interesting one, right? So as we have this quota that we can't go over 12 million records across 12 different instances of Marketo, we got to make sure that we're adhering to that quota. So anybody who came in from Salesforce, I needed to basically delete them who didn't have an email address. If you don't have an email address and you come in from Salesforce, I can't really utilize the data. It's taking up room. I'm going to delete you. I'm sorry ahead of time. So that's what I do. But once I was able to get through all of that, I created what's called the Person Resource Mapper, which then had this general idea for my person source mapping from Salesforce. And I'm able to then look at my Salesforce data flow, which is my source type is Salesforce.com And my person source is all my target sources that are coming in that was given to me by my personal source report, right? And because of those things, I'm able to create my mapping and work backwards from outside in, right? I'm working from here's the end of all the different values that are coming in. And as I continue to build, I need to make sure I separate all of those different channels and how they're coming in. And then I can distribute them however I need to, based off of the fact that I now control that data, right? So now all of the data is in one spot. I have a marketing seed list that I can activate and I can do all of the things that I need to do and create all the reports and activate and send emails and do all of the things that I want in a compliant, cohesive way that doesn't cause all of this bloat and confusion and difficulty in management. It's all consolidated. Data hygiene is all there. All the things that I'm looking for in order to be successful.
So that was pretty fun. So let's talk about what it means to incorporate AEP. So AEP is an interesting tool, right? It's very, very effective in what it does. I like to think of it as my brain, my system, my data brain, right, that I utilize. It allows me to create visibility for Marketo utilizing all of its various API intake opportunities that it makes available, right? I can connect to other databases that Marketo couldn't connect to. Marketo is very like cut and dry. I can either send data out or I can take data in. I can't really go into another platform, look to see if it has the things and pull it back. Marketo doesn't do that very well, right? So what I need to do is basically follow all of the things in order to consolidate my channels like you saw. And once I get everything into my mailable data pool, guess what? AEP now has the ability to do two very, very important things. It can read static list membership. It can also lead program membership. Those are two critical things because they can pull data out of Marketo. I can't send it to AEP, but AEP can pull it out of Marketo and create those profiles. All I need to do is provide the static list Id to AEP and then they can read that data. That's literally all it is. That's all it takes. And then once you have that Marketo lead Id in AEP, and AEP can curate and create those segment lists in Marketo. Now you have a very effective mechanism that allows you to create this really good tracking.
So thank you. I hope you guys all enjoyed that. Let's look at some key takeaways from this project. So original source type is the highest level of entry for Marketo. Every person entering the system needs to have a lead source. Omni-channel is broken down by the original source type. And once that's identified, you can build encapsulating workflows. Data encapsulation is critical to understanding, and makes targeting workflow management a breeze when you build it the right way. You always want to think Global OPS, how can I solve this at a global perspective as opposed to a program level perspective? And it goes on from there. If you can solve it in layers, then it'll make your workflows a lot easier to manage. Common recurring run times for preferences and other various things that you might need to run are great for request campaigns. Learn how to build them, utilize them. They are amazing. Learn how to visualize the data flow and activity logging. When you can visualize how something flows through Marketo, you become very, very good at using Marketo. And create your compliance data stream that auto-encapsulates your data and allows you to pull in all of that data without having to go through individual values, right? And do all of those things. And if you do all of this right, this is my motto, you sleep better at night. That's the key.
And then obviously, the last couple of things, limit the number of resources and templatize, templatize, templatize. Thank you all. And you can find me on LinkedIn. Thank you for listening. [Music]
