Eric Dodds (00:00)

Record to the cloud. We are live. All right. Welcome to a webinar hosted by RudderStack, and Max, thank you for joining us.

Max Werner (00:15)

Glad to be here.

Eric Dodds (00:19)

Steer your customer data, that's a great slide. Okay, agenda for today. So, Marketo is an extremely popular marketing automation tool. Very powerful. You can do some incredible stuff with it. In my previous life as a marketeer, saw some really amazing things happen with Marketo, but the bane of existence for data engineers who are dealing with Marketo on behalf of their marketing team is API limits. Something we hear constantly about at RudderStack, and so we're going to talk about some unique ways to deal with that. So, we'll cover how to extract data from Marketo with the API. We'll talk through APIs and rate limits, those are two separate things. A lot of times you'll lump those things together when you're dealing with limitations in Marketo. So, Max is going to break that down for us. And then we have a really neat architecture with webhooks and cloud functions. And then we'll have a bonus round talking about custom triggers. So, this is really cool stuff, as a recovering marketer, I'm really excited to talk about this having felt the pain before. So let's dive in and we'll do some intros first.

Eric Dodds (01:41)

Okay, I will introduce you, Max, and then I would love for you to give a little bit of background. But, Max Werner, I actually met him as part of the process of Proposify, a company that's previously becoming a RudderStack customer, and had the joy of working with him to get data pipelines and everything set up. He's done work with all sorts of companies, including huge brands like Warner Bros, who has a crazy data pipeline set up across thousands, I guess, of different pieces of the puzzle there. And then also Obsessive Analytics is a consultancy that you run. And yeah, so without further ado, Max, thank you for joining. Do you want to give just a little background and talk about being a data engineer?

Max Werner (02:34)

Yeah, sure. My background is originally starting out in web analytics and Google Analytics, and playing around with Tag Manager and these kinds of things. And that naturally just developed further into becoming the designated data plumber. Google analytics doesn't cut it, and it needs to be a little more advanced, and all the problems that you run into then. And that's what I originally designed Proposify for, to help implement the CDP that shall not be named on this webinar. And eventually we also implemented RudderStack for different functionality, and then eventually from that, I moved on to doing that same thing again for Warner Bros. It's a crazy, crazy scale. The analytics wing on Warner Bros has close to a hundred employees alone.

Eric Dodds (03:35)

Wow.

Max Werner (03:36)

So, it's crazy, and when they're dealing with event streams, it's terabytes and terabytes of data on a weekly basis. So a lot to do. A lot to do.

Eric Dodds (03:48)

Yes. Very cool. And, I'm Eric Dodds, director of customer success at RudderStack. And like I said, I have a background in marketing, so really interested in this chat. So, let's go ahead and dive in.

Max Werner (04:06)

Alrighty. So let's start with the easy way to set up, and it's just like the API because we're always need to get data out of Marketo. Sure, lots of the point of CDPs is to pump data into destinations. But you often want to have it back out of those systems into your warehouse, so you can run some data modeling on it, use it for analytics, reporting and all these fun things, or to just have your own internal data sanity check. And well, you can really do it one or two ways. You can build it yourself, which means you can do exactly whatever you want it to do. Marketo has a field of robust API, both for importing data, supporting data, and nice bulk API. But of course, every time you've got to build it yourself, it takes some time.

Max Werner (04:57)

And then of course we've all never shipped perfect software with zero bugs whatsoever. So, the errors are a concern and of course, ongoing maintenance that comes with that. Much easier if you use a service to extract that data. Rudder has a great functionality called Cloud Extract where you're basically, you authorize your Marketo instance and it pumps it into your warehouse. There's other services like StitchData or FiveTran that do similar things for, of course, other tools as well. Pros, of course here, is just it's a turnkey solution. You need to set up your API keys, and your warehouse connection, and that's it. And, because you didn't build it yourself, somebody else gets to maintain it, so it's just working for you. First, the con here being it's not free, I doubt that building it yourself is free either because the time invested, but of course there's a cost to that now.

Eric Dodds (05:59)

And.

Max Werner (05:59)

Sorry?

Eric Dodds (06:01)

One question there, Max, I'd love to just talk through really quickly, a couple of use cases. So, one I can immediately think of is getting a complete picture of the customer journey, right? So, a lot of times you will have... And I'll just give an example off the cuff here, a lot of times you'll have different teams looking at different parts of the customer journey. So let's say, you have the top of the funnel, so that would include web analytics. And then someone does some mid funnel conversion, maybe they fill out a form, or request a demo, or something of that nature. And then, a lot of the nurturing and other components there would live in a tool like Marketo, and then maybe they actually get into the product, and then you have the product analytics.

Eric Dodds (06:49)

And so, just one use case off the top of my head is getting an understanding of, even answering questions of, what emails has someone gotten throughout that entire process? That's really valuable to know, but it's actually really hard to get visibility on that without either constructing it by hand, or trying to unify the data. So, I think that's one area where one usage of pulling data from Marketo, but I'd love to know from your experience, what are a couple of other types of use cases where it can be really useful?

Max Werner (07:25)

Yeah, sure. That insight is super important, right? Platforms like Marketo or HubSpot or whatever, they tend to have some analytics pieces built in where you can look at some of these reports. But a marketing platform with an analytics system built on top, is just never going to give you the same insight as having just the underlying raw data in a warehouse, and connecting it to API tool. So it's just better right off the bat there, what you can do with it. Other use cases are, you need to get data out of these systems when these systems do things to your data. Sounds a bit weird, but not like... Use something like Rudder and you push your user information into Marketo, but it being a marketing automation platform, it does things to those user records there, right?

Max Werner (08:17)

There might be logic built into Marketo for lead scoring, different drip campaigns, right? And all these things. And Marketo can just change data values on your user objects there. And that is data that you most likely want to have accessible in other systems. Of course, it can natively integrate with things like Salesforce and push it around there, budge. If you want to get that lead score, for example, out of Marketo and into how your ticketing system like Zendesk or Intercom or something like that, you're going to be hard pressed to get it out there reliably. So having it in your warehouse and then using my product to sync it back into those systems solves that quite nicely.

Eric Dodds (09:06)

Yeah. That's a really, really good point in that, once you deliver data to a downstream system, it's not like that data is static in the downstream system. And I would say just from my own personal experience, and I think our audience would agree, dealing with point-to-point integrations among SaaS tools... I guess, a least common denominator would be a lot of pain around custom fields, and field sinking, which is just incredibly painful data types even. And so I just think that's such a valuable way to think about architecture, where you say, your data and your downstream tools, doesn't stay static. Point-to-point integrations are challenging. So get that data back into the warehouse and then you can do whatever you want with it, and then syndicate it to downstream tools. Cool, okay.

Max Werner (10:09)

[crosstalk 00:10:09].

Eric Dodds (10:09)

I know that was a lot on this one slide, but I thought that was helpful context for me at least.

Max Werner (10:15)

Yeah. And the point-to-point is absolutely a problem because you have this issue that is, you're starting to daisy chain systems together, right? With the CDP it's a lot easier because you have a hub and spoke system, but if you just say, "Okay, I have Marketo and I use Salesforce." So Marketo integrates with Salesforce, Salesforce integrates with Gainsight now, and then you keep daisy chaining your data around. And there's just so many points of failure that can completely break all that automation that you're trying to achieve. All right. Is there a CDP? And then in the middle, you can just say like, on top of your warehouse, you push the same data. That's your source of truth. You push it into all of the destinations at the same time. And then, it's not this single point of failure.

Eric Dodds (11:05)

Totally. One last point on that, that I think a lot of people have experience is, when you get into the daisy chain architecture, which is a term we need to trademark by the way. When you get into the daisy chain architecture, it almost requires someone who has a tribal knowledge of the progression of all the connections, and all the dependencies in order for the system to operate, right?

Eric Dodds (11:38)

So usually if there's a problem, it's like, okay, we need to go talk to this person because they're the one who knows, "Oh, well this was the workaround from Marketo to Salesforce. And then when it needed to go from Salesforce to Gainsight, we had to do this workaround, because it was this custom field, or this data type, or this limitation, or whatever." And obviously that's not the way to run a stack, but I think that's pretty common when you get into that daisy chain architecture. I know you've never played that role, Max, but just theoretically.

Max Werner (12:08)

No. Never. It's not like that kind of job puts food on my table. No. Not at all.

Eric Dodds (12:19)

Okay. Cool. All right.

Max Werner (12:22)

So moving on, the problem, of course, with these kinds of systems, when you use API, is that you have API limits and rate limits. And as Eric alluded, those are different things that can each be their own significant headache, right? So let's again, use Marketo as the example, of course here, the more services you're trying to integrate with Marketo, they're all going to consume your same API limit. So that's generally like in Marketo's case, number of requests per day, Salesforce stuff like rolling 24-hour thing with an hourly basis, that's weird but whatever.

Max Werner (12:56)

So, that's your one limit. If you exceed that, things don't only just stop working, Marketo will reject the incoming API call. So, if that's critical for your stack and you're all sudden are not getting new signups, or any of these kinds of things, because the API is over the limit, that's not good.

Max Werner (13:16)

You can try and replay it from your warehouse the next day, if you have the limits but that's not exactly great. The other issue is rate limits. So, that's the number of requests per certain timeframe, which Marketo also has, where you can only send... It changes weirdly often, I think it's currently sitting at a hundred or 200 requests per 20 seconds. So even if you have a hundred thousand API limit per day, you can't punch those all through in a few minutes, because it will just have that secondary problem. So that's actually far more nefarious awful problem, because some of your things might fail if you have a high burst volume, all of a sudden, but then a little later, a few minutes, everything's working fine again.

Max Werner (14:08)

So, also not a great thing. These two moments together, generally just make people like us, sit there like this, and try and figure things out, because you just know that something failed at some point, for some reason. And Marketo also doesn't give you any great logs or anything on why what failed.

Eric Dodds (14:29)

Don't get me started on error logs from marketing SaaS tools.

Max Werner (14:36)

Well, they don't exist.

Eric Dodds (14:40)

So there's no place to start.

Max Werner (14:42)

Exactly. So, looking at this problem, that you have these API limitations, and especially when want to integrate more things with it, or get more information out of it, the logical question becomes, how can you work around that? Well, lots of tools, including Marketo have a cool feature called webhooks, which most people here on the panel probably know at this point.

Max Werner (15:09)

But it's basically just something happens that you get some payload, that you can send to some URL. That's it. Marketo doesn't care what happens at the destination, it will just fire something into the void. It can handle responses and do things off it, but it generally doesn't care. So, the idea here for this webinar is that we say, "We take these webhooks and we attach it to some cloud function." And I'll show it on the next slide exactly what the process of that is. Your Marketo, your webhooks, your cloud functions. And in your cloud functions, you basically just run your track, identify calls, or whatever you want, or any extra processing that you might be interested in, like Clearbit enrichment or something like that. And then use RudderStack to track calls, to punch it back into your database, into your warehouse.

Max Werner (16:07)

There is a great benefit to that, that is webhooks are free. They don't cost you anything, and they don't have limits. And since Marketo, doesn't really care if they succeed or not, there's no rate limits or anything like that. So basically, we'll get into more details about how to build this. But I guess that the rough overview is webhooks to send POST requests.

Max Werner (16:37)

You can send it as GET requests too, but especially once you're sending your confidential user information, more of it, you probably don't want to have that in your URL, and GET requests. So use POST requests and HTTPS.

Eric Dodds (16:52)

Yes. Oh, wait.

Max Werner (16:54)

Security is important to [crosstalk 00:16:56].

Eric Dodds (16:58)

Yes. Minor detail, PII in a URL is not the best practice.

Max Werner (17:06)

Check your Google Analytics if you have URL parameters in there.

Eric Dodds (17:10)

Ah, yes, that is actually funny. Back when I was consulting and liked doing Google Analytics and audits, you can find some things in there that are like, "This is frightening." Let's walk through-

Max Werner (17:24)

Credit card information. I had a client once that had credit card numbers, full credit card numbers in a form submission with a GET on it. Yep. So use POST requests and HTTPS it's the less...

Eric Dodds (17:41)

Oh, that made me feel a little sick to my stomach.

Max Werner (17:44)

It should.

Eric Dodds (17:47)

Let's walk through one quick example here with this architecture. So let's just... If you could just run us through using an example of something that happens in Marketo that fires via webhook, and then walk us through maybe some track call or something. Just walk us through what that would look like. Like an actual thing from Marketo.

Max Werner (18:11)

Yeah. I'll have that switch later on actually, the full workflow.

Eric Dodds (18:16)

Oh, perfect.

Max Werner (18:17)

We'll see that all. Of course, with all these things, these are custom-built things, and we just said earlier, building custom things is bad, costs money, is error prone. So you might ask, "Why? Why should we do this?" And you alluded to that already, but there's a couple of benefits. You are bypassing API limits. You can do more things with it, like your cloud functions, you're not just restricted to taking that incoming data for somebody, open an email, and pass it on. You can call other services or do other things with them. You can even do a little bit of [inaudible 00:18:58] on that. You can directly filter out garbage and don't pass it into the RudderStack.

Max Werner (19:06)

And generally speaking, unless you run your own web server that has some PHP power or something, that is processing that function, it's very scalable and robust. So don't DIY that, use a service like Lambda on web services, or Amazon, Google Cloud functions. I'll be showing you a little example, it's on Pipedream which is another product that you can do these things. So, don't build that part yourself, use a platform for that. And yeah, that's benefits, fast, scalable, and you can do all kinds of stuff with it.

Eric Dodds (19:46)

The other interesting thing there, now that I think about the webhook essentially creating a payload that goes through RudderStack is that you could also trigger things in other SaaS tools as well.

Max Werner (20:02)

Oh yeah, absolutely. If you use identify calls or track calls, depending on what destination you have that Rudder source connected to, that can be a very extensible part of your ETL process.

Eric Dodds (20:16)

Sure. Yeah. That's super interesting. Because obviously you want it in the warehouse, so you can do deeper analysis. But there are certainly situations in Marketo where going back to the point-to-point or daisy chain situation, you want a combination of things in Marketo to trigger something in another tool in the stack, update something or whatever. And that's a very neat way to do that in the common paradigm of an event stream going through the RudderStack data plane, because SaaS tool will accept it just like they would accept an event coming from your website or app.

Max Werner (20:53)

Okay. Generally speaking, the Rudder integrations are more trustworthy than the point-to-point integrations.

Eric Dodds (20:58)

Yeah, sure. I'm biased.

Max Werner (21:05)

So the workflow, and we'll have step-by-steps for that in just a second, it's basically like you use a smart campaign in Marketo, you add triggers to it, filters, if you so choose, activate it, create a webhook, write your code and the cloud function. And last but not least, again, add security to it. Because there's one important problem, your webhooks are public URLs. If you just have to take whatever comes in and pass a through RudderStack and that URL, somebody finds that, or it was leaked somewhere, you have issues. So add a little security on top of that, which we'll get over, is very, very easy. So step one, let's make a smart campaign. Very easy, you can see the orange part there, those are the triggers, and you can add as many as you want to a campaign, and filters, if you so want.

Max Werner (21:58)

A couple of notes here are any and all triggers, so if you have five triggers on there, any of those conditions being satisfied will trigger the webhook. So it's not like somebody needs to open an email, and become member of a program at the same time. I'd rather just... Any of those will trigger it. So we'll keep it in mind. But the filters are applied to all triggers. So, any trigger is activated, it needs to fulfill whatever your filter combination is like, one and two, or three and four, whatever.

Max Werner (22:30)

And very important thing, you need to get into the settings of that smart campaign and on the bottom right corner you see`, and set it to, every time, because otherwise your people will execute... Each person will execute the webhook exactly once. And if you use that for something like open an email, well that defeats the purpose. So generally speaking, you want to set that to, every time, for this kind of pipeline process. And of course, you can set multiple different campaigns, with different triggers, and filters, if you still want. You can attach them all to the same webhook. It doesn't matter. It's all up to your personal organization desire in Marketo.

Eric Dodds (23:11)

Right? So, if you have a pretty complex setup, you might want to add hierarchy, develop a taxonomy around which types of behaviors trigger, and have different smart campaigns for that, but you can send everything through one webhook, which is...

Max Werner (23:28)

You can. Yeah.

Eric Dodds (23:30)

[crosstalk 00:23:30].

Max Werner (23:30)

Depending on your complexity, of course, you might want to create a couple of different ones. It's not exactly difficult to create multiple Lambda functions or have you, that handle things slightly differently. But if you want to send them off at the same time... And I'll show you in just a sec, how you can actually make that still organized when we get to the webhook part. And [inaudible 00:23:52] warning, this looks real ugly. So this is the edit webhook interface in beautiful Marketo, the URL is the URL that you will have to attach to your cloud function. So, I'd again use Pipedream here, but this would be your public cloud function URL for Google. If you want to use AWS, and you have to connect it to the AWS API gateway, that gives you a URL to then connect to a Lambda function and pass it on.

Max Werner (24:21)

Can you set your request type again, POST for PII information, and make sure it's an HTTPS URL. The template part here is the really neat part. Marketo, like most systems that offer webhook functionality is just, here's the thing that sends a webhook, and you can see whatever it spits out. Sometimes, they provide you documentation if they're graceful, but generally speaking, you get what it is. Marketo, you can actually customize exactly what you want to get with this token feature, which is basically any field that you have in Marketo. And even some meta things like campaign name, and default mailings, you can customize the actual payload you're sending to the webhook.

Max Werner (25:00)

Has the benefit that if you do want to send multiple different campaigns to a webhook, and including that campaign name or ID in the templates here, lets your cloud function then do different things based on a switch, or an if-statement, or whatever on that key, and execute slightly different logic, if you want to use the same record. Again, it all depends on your scale, right? And how complex your workflows are, if you want to use multiple workloads or just one.

Eric Dodds (25:33)

Yeah. I love this, because I'm thinking about the data engineer's perspective and setting up this pipeline. And it just makes it really easy to have basically a shared spec between marketing, data engineers, and then analysts, or other people downstream who are going to be using the data in the warehouse, or even in a SaaS tool. And in many ways, the liquid tag nature of the tokens in Marketo, make it really easy to collaborate on what the payload looks

Max Werner (26:11)

Exactly. You add new fields to Marketo easy peasy, right? You just throw it in here as well. It makes the writing of the template a bit hard, because again, we want to make this all JSON, and code it. So, that's why you see it looks JSONy, but then has some tokens in there. Just use a code editor, do it in there nicely, tapped out and everything, and then just paste it back in. It's probably easier than to write it in here, because you, of course, have no syntax highlighting [inaudible 00:26:40] here. Yeah, and it's super extensible, really, really good to use. Yeah. Again, trial and error, you need to actually write your own JSON payload there, because otherwise, it'll exactly spit out in the webhook, what you write in here.

Eric Dodds (27:00)

Yep.

Max Werner (27:01)

Typos and everything. So, following the [inaudible 00:27:09], so we have a webhook, and we have a campaign. You go back into that campaign on the low tab, you simply say, call webhook, and select the webhook that you just made, or whichever one you want to choose. And then you just need to activate it under, schedule. Again, that's very important, otherwise nothing's going to happen. And it makes debugging hard as well, so activate it. And that's most of the Marketo portion, right? Your campaign that determines which triggers and under what conditions you want to call the webhook, and the webhook that has the fields that you want to pass on to an external URL.

Max Werner (27:50)

Now, we just need to handle that incoming payload, and for easy-to-view purposes, I use Pipedream because they have a very generous, free tier, and you can do all kinds of little ETL logic there. So, you create a webhook trigger there and it just gives you the URL, then you can pop over into Marketo. Of course these specifics here will slightly differ based on what your platform of choice is, like AWS and Google, [inaudible 00:28:26] probably has something like it. I don't know.

Max Werner (28:31)

But yeah, that's basically been it. You have your trigger in Pipedream, that is the webhook, which connects to simple JavaScript or, again, whatever your code of choice is on your platform of choice. And then it can become as simple as you want it to be. If you have a very basic trigger system that is just, I want to know, they open an email, which email it is, I want to send a track event that is, this person opened this email. That's all you need, right? You initiate your analytics SDK. You give it the right key and the data plane you're on, and make your track call happen. As soon as that's there, and your campaign is active, data will start flowing right in.

Eric Dodds (29:19)

Love it. It sounds so simple when you say, "Wow, it'd be great to send a track call every time someone opens an email." But it's hard. But this is a really, really elegant way to handle that. Yeah.

Max Werner (29:34)

Yeah. As important as it is, you don't DIY this part, like that cloud function platform. Right? Because the part that makes it so nice and elegant is that these things exists, right?

Eric Dodds (29:47)

Sure.

Max Werner (29:47)

The scalability, the security parts, the SSL certificate for the endpoint, right? You don't have to worry about any of that. It just exists. And it's generally also fairly easy to put extra security in.

Eric Dodds (30:02)

Yeah. I was going to say, the security's huge. And then, we all know that you get it set up the first time, and you start sending data, and then you go through the feedback loops of, "Well, we need to add this, or we need to add this, and all of that." And if you're trying to maintain infrastructure, but also maintain data integrity, and provide value to downstream teams, those are really hard to do, both of those at the same time. Especially if there's an option that just outsources the infrastructure piece for you.

Max Werner (30:34)

Yeah. All right. So speaking of security though, again, you webhook is a public URL. Like what I just had here, that little code that just asks, line dot track, there's no security in here whatsoever. Anything that comes through, it'll look for the payload in the body, in this case for some piece, so if they don't exist it my error it out. But generally speaking, it will just execute that code regardless of who's sending the data. So, add some security to that. Marketo actually has a neat feature where you can set up custom headers on your webhooks that are included. So, set that custom header to some API like anything, just don't make it password or something like that. But just generate a random string, attach a bearer, that means Marketo will send along that header in every webhook, which you then combine and modify your cloud function slightly to directly say, if this API key is not what it should be, or it doesn't exist, just stop immediately.

Max Werner (31:45)

And that for the most part, is all the security that you really need. If you have, you can talk to your Marketo account manager and get the IP ranges that they send information from. And if you have a security group on AWS or something that can send data in, you can bolster it up even more. AWS API gateway handles even like, you can set API keys there, have it generate API keys. So, you can do the rate limiting if you want, to keep track of what's happening. So, there's lots of ways to attach that. But basically for the takeaways, don't just let it sit there naked. It needs to have at least this basic care, even if it's just some fixed stream that you type in. Just so that if somebody tries to denial of service attack that URL, A, it's not going to break that URL. And, B, it doesn't flood your warehouse with garbage.

Eric Dodds (32:47)

Yup.

Max Werner (32:48)

And of course, SSL only. Don't send data unencrypted, this is all customer data. This is a great big old security pain point of view, if you sent that unencrypted. Yeah. So, that's the basic workflow. We have some bonus stuff coming up and any questions so far? Crickets?

Eric Dodds (33:17)

I don't see any on the chat. Yeah.

Max Werner (33:21)

Let's get into some of the bonus pieces because you can do a lot more than just these standard things like open email.

Eric Dodds (33:30)

But, wait, there's more. I'm excited about this.

Max Werner (33:37)

There is a whole bunch of really useful things. So what we've gotten so far over, you can replicate a lot of that data extraction functionality fairly easily. These things like data value, [inaudible 00:33:48] data or something you can keep track of. Even if you attach a data value change trigger to an identify call, that's basically your user [inaudible 00:33:59]. But as bad as point-to-point integrations are, people use them. Salesforce, for instance, comes with its own set of triggers where you can, in Marketo, actually react to things that Salesforce is doing through your Marketo leads.

Eric Dodds (34:17)

Sure.

Max Werner (34:18)

Yeah. So, that's useful. Whatever is happening in Salesforce, you can do a couple things there. What's even cooler is... And now we're getting into this feedback loop, is you can set up custom activities in Marketo that if you want to track things manually. So generally speaking, if you send a tracker off to Marketo, it's going to ignore it, unless you have a custom activity configured that matches that. Here's the neat part though, when you create a custom activity, that immediately creates a Marketo trigger link, that you can then use. So, I have the bottom right screenshot here, like an Intercom conversation. So if you have a custom activity called Intercom conversation, this will become a trigger, which means if someone performs that activity, then you can use that as a trigger to call a webhook. Yeah. Be careful on your feedback loop there, because now you can actually do something circular. But for most, right, this is a very powerful way of extending the trigger count law even further, and really customize what you want to get out of it. Yeah.

Eric Dodds (35:39)

That's very cool. I just have so many little interesting use cases that are popping in my mind. I love it.

Max Werner (35:48)

Yeah. And you can also error log. Remember when I said Marketo can respond to non-200 status codes? I had an error sprung from webhooks. That's a trigger. So theoretically, you can have a very simple trigger somewhere else, that is just like, if the webhook is non-200, send this other webhook that is just logging your errors, and that can help you at scale, see what's happening. If you include that, the error message in the template. So, again, you can really... You can take a lot of the burden out of Marketo, and because it has limitations, there's things that don't work for everyone. And if you just remove that out of the platform, and move it into your CDP, not just is it in your warehouse? And you can use it everywhere else. But it gives you just that flexibility, and reduces your vendor lock-in, because the more logic you remove out of that system, the more you can easily switch it to something else, if you have to.

Eric Dodds (36:54)

Sure. Very cool.

Max Werner (36:59)

Yeah. So that's basically it as far as this workflow is concerned. Hope that gives some people some ideas like, it's not that scary, it's not that difficult to set up. You have the slides and the recordings to go through, and happy hacking, I'd say.

Eric Dodds (37:24)

Yeah. Any, any questions from any of the attendees here? Feel free to raise your hands or drop something in the chat, and we'd be happy to answer it. Here's a question that came in. Are there any limitations around the custom activities?

Max Werner (37:56)

It depends on what you mean by limitations. They take a bit of configuring, but they're not subject to API limits or something like this. You can punch in as many as you want there.

Eric Dodds (38:12)

That's cool.

Max Werner (38:13)

Yeah.

Eric Dodds (38:14)

Very cool.

Max Werner (38:16)

Yeah. I think there was one question on LinkedIn earlier about this... Where a question about like, is Marketo discouraging the use of APIs...

Eric Dodds (38:28)

There was.

Max Werner (38:29)

... and are using the APIs or webhooks, and well, API is a little, and hence there's solutions like this. There is one concern that Marketo does have, that is if your response time is bad, because if you have a large volume of webhooks that are being triggered, and your response time is too long, then that can error out. And that's in the order of seconds, multiple seconds per process. Then Marketo is getting finicky.

Max Werner (39:12)

So easy enough to keep an eye on what your event volume is there, what you're sending through, and scale your solution accordingly. So, for instance, if you get to do these thousands and thousands of requests, or you want to do more, time-intensive extra processing, maybe call some other APIs, might have to scale your solution. For instance Amazon has something like Kinesis where you can just basically punch data in, it just takes it. And then you can do further downstream processing later on.

Eric Dodds (39:43)

Sure.

Max Werner (39:44)

There's alternatives to this. You can extend this second half basically of this cloud function, and processing part to make it more scalable. Standard-like Lambda thing or whatever is going to handle hundreds of requests per second. No problem.

Eric Dodds (40:00)

Yup. Sure. Yeah. But when you get into multiple thousands of requests per second, you get into potentially needing the streaming service type thing, if you're... Like the Kinesis or Kafka methodology, if you're doing stuff at scale internally.

Max Werner (40:21)

Yeah. That's literally enterprise scale.

Eric Dodds (40:25)

Yeah.

Max Werner (40:27)

Most mid-sized companies are probably not going to run into any such limitations.

Eric Dodds (40:34)

Sure. Awesome. Well, this has been great. I learned a ton, and I hope that our audience learned how to do some really cool stuff with Marketo cloud functions and RudderStack. And let's do it again. Max, really enjoyed it, and I would love to learn more from you.

Max Werner (40:56)

Sounds good. More than happy to be here anytime.

Eric Dodds (40:59)

All right.

Max Werner (41:00)

All right. Have a good one, everybody.

Eric Dodds (41:03)

Thanks for joining everyone. Bye.

Max Werner (41:05)

Bye.