Untitled - April 6, 2026

00:00:00 Speaker: What's up guys. Welcome to the humans of MarTech podcast. His name is John Taylor. My name is Phil Gomez. Our mission is to future proof the humans behind the tech so you can have a successful and happy career in marketing. What's up folks? I've got a solo episode today, but it's not really solo. I'll be joined by various MarTech pros sharing their opinions. The landscape of marketing technology architecture has been undergoing a seismic shift, and many don't even realize it. In this sort of transformational terrain, there's a remarkable development that a lot of folks are calling warehouse native MarTech an innovative breakthrough that promises this idea of reshaping the entire industry for the better. But it comes with plenty of questions and skepticism. Here's today's main takeaway. As we navigate the potential transformation to warehouse native MarTech, the single most critical action is to prioritize achieving high quality, well structured data. It's the golden key to unlocking the full potential of these emerging tools and strategies. This episode explores the various facets of warehouse native MarTech and its viability, pulling in insights from industry experts, piecing together a comprehensive view of this groundbreaking shift. Let's get started. So what are warehouse native MarTech or connected apps? In December of twenty twenty one, snowflake introduced a new term connected applications. Unlike traditional managed SaaS applications, connected apps process data on the customer's own data warehouse, giving customers has complete control over their data. Benefits include preventing data silos, removing API integration backlogs, enabling customer analytics, upholding data governance policies, improving SaaS performance, and a couple of other things. In other words, instead of making a copy of your data warehouse and your customer data, like most customer data platforms and marketing automation platforms do today, everything lives on top of the data warehouse, and you don't have to pay for copying your database. Some companies solving this in product analytics are Rackham Indicative and qubit census and high touch reverse ETL platforms are also doing this, being warehouse native activation tools that sit on top of your data warehouse and don't actually store any of your customer data. And some messaging companies are also solving this use case natively on the cloud warehouse. Some of these are zero message gears and castle dot io. Yeah. So, um, message gears is a marketing, um, customer marketing platform. And our original tool is an ESP. That means like an email service provider. So just think of like, um, marketing emails you get in your gmail. Um, we have customers like Home Depot and best Buy and, um, Expedia, that's India waters. She currently leads growth and technology partnerships. At message gears, she explains how her company's differentiation comes from its unique handling of customer data. And what we're solving for is, um, our competitors like Salesforce Marketing Cloud or Oracle responses, they were built way before message gears and they require a copy of customer data to live within their tool. Um, and that's not like when they were built that was needed because there were not modern data warehouses like snowflake or Google BigQuery. And since those have been created, like new marketing tools can be built because, um, they can handle querying. So message gears is big differentiator is that we don't have to have a copy of that customer data. Um, and we're solving for big companies are wasting a ton of money having to move and copy data into all of their marketing tools. So, um, you know, if you just imagine there's just companies have a lot of marketing tools and each tool has to have a copy of this data. So you just imagine that can be, um, you're not working off the most up to date data, you're having to pay to store that data in all these tools. Um, and if you're ever trying to like run analytics, like what's working, what's not, you have all these different silos of data that aren't matching up and you can't get a clear story of like, what are our customers like, what do they want? We, you can't tell this customer story and deliver a really amazing experience to them. So message gears, instead of having a copy of data that lives within our ISP, um, we just plug directly into wherever our customers like open table, T-Mobile party City, wherever they store their customer data, which is in most cases is like Snowflake or Google BigQuery or redshift. Sometimes like Databricks, we just plug directly into there and we use that for our source of truth so they can have the best analytics. They can have a really good experience by using the most up to date data. Um, because like inherently when you copy data, that means it's out of date. Um, so yeah, that's the, that's the problem we're solving for. That's our big differentiator. And to be honest, like truly telling someone that four years ago, they were like, but our data lives in our ESP and like, it's somewhere else though, and it's having to get in there and they're like, I don't think so. And I'm like, okay, you know, like, I can't, you know, you can. It's now it's just sort of like interesting to we were just having to be thought leaders for so long and like tell people about this approach. And now everyone's like, let me see. We get it. So the main takeaway here for me is message gears. Differentiation comes from its unique handling of customer data, right? By plugging directly into modern data warehouses and not requiring a copy of data within its tool itself, it offers cost effective solutions and up to date insights, allowing businesses to craft a more personalized customer experience. Potentially. This approach has positioned Message Gears as a thought leader in the tech space for over a decade now. While Message Gears has been around since twenty eleven, more and more startups are waking up to this idea of directly accessing brand's first party data instead of relying on cloud data syncs. So I think I just want to kind of, I think the first customer interview where we got this feedback was somebody who just mentioned what you mentioned, right? I have millions of customers. I have like five million customers, right? It does not mean that I'm getting the value out of them, right? So right number of customers does not directly correspond to the value. That's Arun Thulasi, CEO and co-founder at Castle dot io, a warehouse native customer engagement platform that sits directly on top of your cloud data warehouses. Arun and his team have set out to disrupt this traditional MarTech to fix some of the fundamental problems as it relates to the significant disconnect between the number of users a company pays to store in their marketing automation database, and the actual value that they derive from them. Like if you if you look at a very small B2C company, right, they have millions of subscribers, it does not mean that they are making a lot of money. Right? So for us, I mean, people say that we will kind of our pricing is based on the value that you get. But is it really true for the existing solutions? Right. Are you actually getting those value right? For us, we understand that. I mean, I mean, still we might not be completely correct, right? But we understand that, you know, we, we we're kind of pricing based on the number of team members who are using this tool. And that is a more kind of an accurate, um, approximation of the value that a company is getting. Right? Obviously, there are more marketers who are using the tool. Obviously, you know, they are bigger and everything, right? So for us, you know, that is the kind of differentiation, right? And, and because we are obviously not storing the data, I mean, we might store the data to kind of, you know, solve certain use cases or to kind of optimize some of because we don't want to kind of write, run queries all the time on the data warehouse. That's an optimization for that. And to solve like real time use cases, transactional use cases, we might store the data, but we don't charge you based on the kind of, you know, compute that we do, right. I mean, we charge you just based on like the number of team members you're using the tool. And that's how we are solving that particular problem. And the second problem is obviously the data lookback period that you mentioned, right? So I think for both B2B and B2C, but especially if you just talk to a B2C company, like a travel company who is planning like vacations, right? So like, if you plan a vacation now, after six months, you'll be planning another vacation, Right. And with the data retention of six months, right, how are you going to do retargeting or re-engagement does not make any sense, right? So obviously for e-commerce companies, right? I mean, you would want to kind of, uh, segment users based on the purchase they made in the last Christmas, right? So are you really able to do that? Or if you are able to do that, at what cost? Right. So those are obviously and then it's about, um, marketers waiting for data engineers, right? They'll raise a JIRA ticket and they wait for like three months, right? It's just like they'll keep on refreshing the page and see if it works, right. Um, so yeah, I think that is another problem, right people. I mean, in our case, your data is already there in the data warehouse, right? Uh, I'll agree that there is some friction with using the data warehouse data for marketers, but I think that is slowly getting solved with a lot of things which is happening on top of the data warehouse, right? So for me, um, this is actually a no brainer, right? It's just a matter of educating, uh, the folks that this is how ideally this should work. So for me, the main takeaway from Arun here is, you know, traditional MarTech has many shortcomings, notably this disconnection between user storage costs and the value derived and restrictive data lookback periods as well. Uh, however, Arun emphasizes that castle dot io is leading the charge here in overcoming these these hurdles, uh, with its unique pricing model based on team member usage and its efficient immediate access to data. Message gears in Castle, Io's groundbreaking approach in MarTech isn't merely an isolated occurrence. It's part of a broader trend that calls for a deliberate rethinking of pricing metrics within the industry. This movement emphasizes the alignment of price with real value and accessibility. It's worth highlighting the intricacies of selecting the right pricing metric. It's not just about being innovative. It's about making choices that truly resonate with customer needs and market demands. Yeah. I mean, you know, there's different people will play in different areas and will try to use price metrics that either help or hinder, you know, their competitive differentiation. That's Dan Bukowski, a SaaS pricing expert. Yeah. You'd like a pricing metric that aligns with customers business requirements and perceived value of the product, you know, allows the company to capture fair value, predictably minimize minimizes operational friction between the buyer and the seller, or sort of both sides can exert reasonable control over the metric. Yeah. And there's going to be a bunch of trade offs, you know, in there. Right. So one of the things is like, how innovative do you want to try and get with a pricing metric? So one of the examples that is loved by all the pricing consultants, and I'll use it right now as well. Rolls Royce did this with jet engines, right? So Rolls Royce does only make cars but they make jet engines. And you know most companies in that industry sold. You know, by the jet engine. Instead, Rolls-Royce decided to charge power by the hour was there. Uh, so the the you only is usage based pricing again, I don't know, twenty, thirty years ago, however long this was, you know, so not new. Um, but, you know, it aligns the value, you know, because the, then the airlines are only making money when their, their flights are, you know, running, right. So they got to play and sitting in the hangar, right? It's like, well, why am I, I've got an asset that's not income producing, right? So it matches the cash flows of the, of the buyer and the seller, which is really nice. It matches to the, the value. And then also, you know, they can start taking on, uh, a lot of the extended sort of jobs to be done, the ancillary jobs, uh, that, you know, go outside of the asset, right? So they can have, okay, you're not just paying us for the engine running, but you're also that's, that's covering your maintenance and replacement, right? You're just paying one sort of fee, right? And it just makes a whole bunch of things very streamlined. The thing is, is that you really only want to do that If you're. That takes time though. That takes that takes energy and educating your market about that change. So if you're, you have better success, if you're like the industry leader in doing that. Um, or if you're, uh, product is much more innovative. So those are, those are two ways because otherwise it can, it can get, you know, kind of expensive to be like, oh, because everyone else is because everyone else is coming to you, right? They're coming to you to buy a CRM and they're like, oh, well, Salesforce charges my seats, so you must charge my seats. You're like, no, we charge you by the number of actions your reps take in the system each day. And you're like, why? I've never heard that before. And now you got to have a whole conversation educating them about it, right? Like hopefully you wouldn't do something as, uh, not smart as that, but you could imagine, like people try to get too cute, let's just say with their pricing metrics, right? It's like, it's like just to be different. So those are some of the things I would want to think through. So main takeaway for me here is that basically explains that choosing a pricing metric should be a strategic and nuanced decision that aligns with customer needs, perceived product value, and market dynamics, right? An effective pricing metric allows the company to capture fair value, minimizes operational friction, and is within reasonable control for both the buyer and the seller. However, innovation in pricing metrics such as usage based pricing changes like we're seeing with castle dot io and database usage. These changes need careful consideration as it can be costly and time consuming to have to educate the market about this change, especially in the customer engagement platform space or the marketing automation platform space, where people are just used to paying by the number of people in their database. Um, such innovative approaches are more successful when they're implemented by industry leaders or highly innovative products. Right? And that might be the case here for for castle I o but attempting to be different just for the sake of it can lead to confusion and complexity. So it's crucial to ensure that choosing pricing metric enhances customer value and business profitability, rather than simply being different for the sake of being different. And I don't think that's the case for for Castle here and not message gears either. Like they're, they're both doing this to enhance customer value. Okay. So before getting into the weeds of the viability of this warehouse, native MarTech shift, let's get the lowdown from one of the most respected voices in MarTech. What I feel is very clearly happening is making sure we can get all of our data from across our company into the warehouse, and then secondarily, that we have the ability to access data from the warehouse, you know, across any of our applications that would leverage it. You guessed it. That's Scott Brinker, the MarTech landscape creator, the VP of platform ecosystem at HubSpot and the acclaimed force behind chief MarTech dot com, hailed universally as the MarTech world's ultimate wellspring of knowledge and insights. Now, that's a little bit different than saying truly warehouse native, because it's almost a question of layers. It's like, oh, do we just have this one layer of it's the warehouse? And then everything operationally, like just works directly with the warehouse. There are folks who are experimenting with that. I think it's an interesting thing, but, uh, I think the two challenges to that, um, is one you mentioned, which is the fact that the warehouse can have all of the data is a benefit on one hand, but it is also a challenge on the other is, you know, data is not inherently rationalized. It doesn't, it does not become like naturally, like, oh, the definition of what we're doing here matches the definition here. And we agree this is the standard source of reference for this field, you know? No, I mean, getting a lot of the stuff that goes into these data lakes and these data warehouses. When you look at them collectively, you know, across the organization, it's incredibly messy. Now, having the ability to get access to it and start to do stuff with it, I think is super powerful, but it's definitely not, it's not rationalized, uh, you know, and so I think there's a lot of opportunity for like layers on top of this, uh, you know, that serve as that. Okay, well, what's the context? What's the rationalization? Um, that whole field here around, you know, like, uh, data catalogs. And in many ways, when you think about it, individual MarTech products are kind of like, they almost have this concept of the data catalog like built into them. They're providing that sort of structure, you know, and then you know how the mapping happens. The other dimension to it, which is also worth keeping in, is just this issue of performance. I mean, for a long time, why this was even conceivable was just the performance of, uh, read write data in a warehouse. You didn't even have a prayer of like, uh, using that in any sort of system that was going to have live interaction. That's changing a bit, but I think there's still a lot of cases here, particularly once you start talking about like, you know, web interactions or app interactions or things like this, where literally millisecond performance differences matter, uh, in the user experience, they matter. You know, in like, you know, how search engines rank you and do these sort of things, uh, is I think having operational databases that are tuned to the particular engagement, uh, you know, that they're running. I think that architecture still holds here for a while. Um, so I don't know, I guess it would be. Yeah, my, my sense is, yeah, universal data layer. Yes. I think most MarTech companies are going to be pushed by market forces to make sure they can contribute data to that warehouse, if not also leverage data from it. But will that completely eliminate all other localized contextual, specific databases? I don't see that happening here in the next few years. So takeaway from Scott here is that while the rise of the data warehouses are undeniable, it doesn't spell the end for localized databases. As the industry continues to evolve, there will be ongoing exploration and experimentation to determine the best strategies for data management for different types of companies. But ultimately, the most successful solutions will likely involve a blend of warehouse native tools and dedicated operational databases or local copies of data. As we talk about the shifts in data management landscapes, the CEO of a marketing automation platform provides a practical example of these changes, discussing how their customer data platform component is actually built on top of snowflake. This notion of you basically copy data from one place to another and then use those copies to do some things. Or can you just all drink from the same well? And you know, and not move the data around. So I think that's pretty cool. Founder and CEO of Optimove. I think there are some implementations of, of people being, let's say five snowflake and my client has snowflake. So I can say your data is already there. You know, let me have access to it. When I consume it, we're going to be you're going to be, we're going to do it from your snowflake credits. So like you will be paying for it from a computational perspective, which could be convenient for, for clients at the same time, sometimes to do more applications that are, that are a bit more powerful. You do need to have the data living kind of like closer to where you're at. So to your point, we run on snowflake from with our clients, right? If they have snowflake, we can do snowflake to snowflake data mirroring. And then you basically have zero ETL, which is, which is amazing. It's, it's snowflake thing. But then comes like when our customers are engaging with our UX, we're not using snowflake as a, as the database for the UX because designers a data warehouse, it's not, it's not necessarily going to respond fast enough. It's not necessarily going to. So it's an analytical data warehouse in the cloud. So if you want to go up and crunch large amounts of data and get it running in a, you know, in adequate times, a for, for a, for a pretty economical cost. They're amazing for that, right? It's a game changer. I think we're just seeing all of our clients, you know, they used to run on this and that. Now everybody's moving to. I think it's a snowflake or BigQuery. I think those are the two big winners. And but at the same time, I still think that you need you do need copies of data. And close to you to achieve some of the things that you want to do. But it's, it's, it's obviously always open. And I think as technology evolves, right. Maybe that will be that constraint will be completely lifted. I mean, and there's better ways to copy data today, right? It's a better way to copy it. It's better ways to, to make sure it doesn't break along the way, along the way. There's a lot of, but still, I think that's still the main use cases. So the takeaway from here is, you know, he, he talks about the use of snowflake and the benefits that it offers, such as eliminating the need for extensive ETL processes. He also highlights that, you know, while snowflake is highly effective for large scale data analysis and is becoming the preferred choice over traditional cloud warehouses. There are still instances, according to Pini, where data copy is closer to the user. Are necessary for certain powerful applications. As technology continues to evolve over the next couple of years, these constraints may be lifted and improved. Ways of copy data are potentially emerging. But the need for local copies of data is still present in many use cases for now. So Penny kind of echoes what Scott shared earlier. So whether it's technically possible or not, not everyone is on board with the notion of zero copy data or using MarTech without ever needing to copy data in any of your tools at the center of the zero data copy argument. The implication is that copying data creates inefficiency in the form of of excess cost. That's Michael Katz, CEO and co-founder at M particle, the leading independent and packaged customer data platform. I would argue one, like the cost of storage is not the it's not the big driver of cost. Um, it's cost of compute. I think everybody knows that. So create as many duplicate copies as as you want. Like that's not going to, that's not going to change things by orders of magnitude. Secondly, I think that it's been proven over time that, um, there's a ton of efficiency to be gained by replicating data, right? For, for different uses and use cases. Um, so I would, I would add on to the argument that not only is it, is it, um, not true, it may lead people down the wrong path, solving for the wrong thing. And that's just the cost side of the equation. There is also like the value side, right? At the end of the day, you have to minimize costs in order to maximize investable resources to, to drive growth, right? Well, to drive customer value, which leads to leads to growth. We can't have the tail wag the dog. And that's, that's ultimately what a lot of these, a lot of these guys are recommending is start with a proposed solution without clear definition of the problem or opportunity, hone in on certain features or benefits of of certain features, which again, I would, I would call a sleight of hand. And, and then what? Like where does that, where does that leave you? It usually leaves people with shelfware, Which is why, you know, the dirty secret behind a lot of those reverse ETL companies is they have a churn problem. They have a really, really bad churn problem because it sounds like an easy button and everybody wants an easy button until they press the easy button and they realize that things aren't so easy. So main takeaway from Michael here is that he's basically dismantling the zero copy data concept. Um, and he offers a vital reminder that not all that glitters is gold in the world of MarTech. By focusing on the practicalities of cost and the importance of efficiency and value for the customer, he encourages businesses to ask the right questions and prioritize what actually matters. His argument against zero copy data serves as a caution against getting swept up in appealing and potentially misguided solutions in MarTech, emphasizing instead a thoughtful approach to data management that delivers real value to customers. Many industry experts agree with Michael that one of the biggest hurdles for warehouse native MarTech is computing charges and creating a load on your data warehouse or snowflake instance. That can add up pretty quickly. Here's what Arun from Castle I o that we heard from recently, or at the top of the episode. Here's what he had to say about his solution at Castle I O. For this compute challenge. So I think compute charges is a very common problem in the existing cloud data warehouse, right? I mean, if that is not done right, it can probably kind of kind of have really bad effects on the data warehousing ecosystem as well. Right? So I'll give you my take on this, right? So your data warehouse actually contains all your customer data, right? Now, if you decide to kind of obviously, you know, this compute charges is something that you have to take into account while deciding whether you want a data warehouse or not. Right. But my understanding is that a lot of people would still want to have a data warehouse because of the kind of value it adds, right? So now once you decide to have a data warehouse, right. And then you say that I have all my customer data in my data warehouse, right? And I want to kind of enable not only data analytics, I want to enable marketing also because marketing is where all the money is, right? So people can spend a lot of money on marketing right now. So, so that is the thing, right? Once somebody decides that I want to enable it for marketing, right? So then what is the best way to do this? Right? So first thing is right, you can actually have data engineers write these queries to kind of create segments and do everything on top of this data, right? Or you let applications which are running on top of the data warehouse write these queries, right? So I mean, the major reason of this compute charges, right? I mean, a lot of people don't talk about it is because data, I mean, people are hiring analytics engineers in bulk, right? They just kind of hire like, if I want to have a solid use case, we'll have more people. And these are not really experienced folks, right? I mean, so data engineer writing SQL, optimal SQL queries takes a lot of, you know, years of experience, right? And, and people are missing that, that comes here and then kind of writing models and models on top of that is the reason for the cloud compute charges, right? So my take is very simple, right? Once you kind of collect all this data on the data warehouse, the, the system, which is actually better to write the queries are applications like us, right? For example, if you are just adding even a minor filter in US audience builder, right? We just take two, two days, right? We just run all kinds of load tests just to make sure that, um, the customer doesn't have to kind of like pay even like one dollar extra, right? So for me, um, uh, for me, right, this is like the most scalable model, right? So once you see the value in the data warehouse and enabled for marketing, right? Obviously there are going to be compute charges, right? But if you use a warehouse native application, your compute charges are going to be minimal and it's going to be optimal, right? So that is how I see this. So the takeaway here for me basically explains like how his team prides itself on paying careful attention to even minor filter additions in their audience builder query tool. He noted that a thorough load testing process is carried out to ensure customers don't have to pay for unnecessary compute costs. For him, this is way more scalable and despite the inevitability of compute charges, utilizing a Whereas, native application ensures these costs are minimized and optimized. Despite hearing this solution on compute charges and the benefits of zero copy data for many use cases, Michael Katz, CEO of Unparticle, held firm on his stance going back to the value of customers here. Yeah, so I hear what you're saying. If we look at like the marketing tech stack, we say that there's an analytics or like data visualization component. There's going to be like a customer engagement platform. There may be like experimentation tool. There's going to be like a customer support service like Zendesk or something like that. I don't know, say there's like between five and ten different categories that you see, um, across like most MarTech stacks, even if they were all built natively on the cloud data warehouse, like one who, who does that benefit? Like that benefits the data warehouse provider that doesn't, that value doesn't necessarily accrue to the, um, to the customer. And then, and then two as, as you've, um, uh, as you've started to create multiple data sets that are leveraged differently by the different vendors, If they're all if they're all running their own compute cycles on the data warehouse. How do you know that that's cheaper? Like, you know, like theoretically it may be, but I don't think anybody's ever done like a side by side comparison. Like at the end of the day, whether it's snowflake, whether it's m particle, like in a sense, we're all kind of reselling cloud compute in a way, either like very directly with like a, with a markup or it's, it's bundled into a set of services. Um, to, to, just to assume that, uh, there's inherent cost savings just because you don't have to create multiple copies of the data. Like I don't, I don't know if that's necessarily true. Main takeaway here, Michael's analysis of warehouse native approach in MarTech opens this nuanced conversation about the real world implications of this trend by examining who benefits from this strategy and challenging the common assumption that it leads to cost savings. He encourages everyone to have a more critical evaluation here. The discussion underscores that what might appear as an intuitive solution needs a bit more robust evidence and careful consideration to understand its true value and impact. If all of our tools in the MarTech stack essentially live on top of the data warehouse, who does that really benefit the customer or the cloud data warehouse companies themselves? Michael. Scrutiny of the warehouse native approach invites a broader conversation about adaptability and tailored solutions in MarTech. It challenges the standard view, paving the way for alternative methods that don't cling to conventional wisdom. Recognizing that one approach doesn't fit every single scenario and every company is different. Some companies are proposing a hybrid approach and shaping the conversation around customization and efficiency. In my mind, it doesn't need to be black and white. If zero data copy isn't achievable. And by the way, that's what we are saying right now as well. It's not something that we are seeing. That work will work for everybody in the near term, but it doesn't mean that we shouldn't be moving in this direction because it's just more optimal. That's Tamara Grosberg, VP of customer strategy at Action IQ, an enterprise customer data platform. Right. So when the enough work is done to create this robust, uh, data Environment internally by the client. Then why not take advantage of all of this investment, right, and use the data from where it is and decrease the costs? And again, as I mentioned before, it doesn't mean that we will never, ever go and find necessary data somewhere else, but it doesn't necessarily need to be zero percent or one hundred percent, either only zero copy or completely go. Composable CDP road. Uh, it's really in, in from our standpoint, that action IQ. It's creating this environment. And another term that we are very fond of is future proof environment where you can really utilize the different components from best in breed, be it a vendor or an internal solution and not being locked into something rigid for a long time, right? Being able to choose what works for you today and optimize. So main takeaway here, action IQ doesn't prescribe a one size fits all approach to handling data, but rather emphasizes flexibility and optimization. The company sees value in moving towards a zero copy model when applicable. And you know, at some point in the future, focusing on creating future proof solutions that can adapt to various needs. Um, this philosophy underscores a commitment to innovation and client centered solutions in the MarTech arena. The push for flexibility in optimization and data handling hints at a wider trend affecting large enterprises. This focus on. Whereas native solution aligns more closely with the complex needs of large organizations, maybe more so than with SMEs and startups setting the stage for a broader industry shift that some experts have continued to explore. Yeah, so I, I definitely think it is the way forward for enterprise. And I would, I would kind of define enterprise as, let's say, you know, ten thousand employees or more. I absolutely think that the need for an interface for market automation, both in interface as well as a duplicative database is going to be blown away. I completely agree with that. That's Y Bailes, a senior exec at blueprint X, an enterprise focused MarTech and growth agency. And I think where we have a number of projects right now with customers that have either purchased a CDP, such a segment in the past, or they're trying to build their own from scratch. And it's no surprise that all of those same customers are revisiting the conversations of, well, can't we just like call a sin grid or just some delivery service instead of doing all this because you're going through our API anyway with these automation tools. So can we just package up HTML and then call a delivery service? And you're like, well, yeah, you can. And then it's like, well, well, can't we just query a view that you're going to stage for me with leads anyway? Because it's just, you know, we got a large table and I go, yeah, actually you can, right? But you know, it's not a worthwhile tangent, but for our business as, as a partner that I'm not, I'm no longer vendor side, but we have to navigate that partner ecosystem where you've got adobes and you've got the salesforces of the world that make money off of that. So I think you've nailed it where the pricing model is going to change, which I've always thought marketing marketo's pricing model and database size has been interesting versus marketing cloud on my end. I think some vendors are going to do much better than others unless they pivot earlier on. But again, this just applies for enterprise. I still think the SMEs and the quick starts where you you migrate from like a MailChimp into HubSpot and then a HubSpot into Marketo. I think that'll still apply for SMB companies, and I don't see that going away. But I think JT mentioned it earlier, which I haven't seen anything yet, but I think it will happen is I think you're going to see a work management. So imagine like an asana bolted on with Marketo or HubSpot better light where it's end to end. I think that is going to take up more of the SMB market. And then enterprise is going to be where you don't even have an interface, right? Where you just, you really are just calling into a warehouse. So I definitely agree with that. But then, you know, I'm not trying to pat my own back, but that's why I think SQL is so important is imagine if you're on one of these customer's teams, and we are advising customers right now on how to make headcount decisions and org structure changes based upon them redoing their entire stack. And it's, it's sounds again, like completely terrible to say, but when they pull up org charts, we make decisions crossing through individuals based upon their skill set. And you sure as hell believe somebody knows SQL. We'll put them over on the CDC project that we're in a warehouse, right? So that comes down to the versatility of the skill set of don't just be the Marketo operations send person that is purple family, which is great. And I grew, you know, my career was built upon the purple family and I love that, but be the purple fam that also can talk about, you know, cloud storage and being able to push between different integrations and kind of massage on that. So I think that's the future for sure. So take away from Wyatt here. He basically believes that the future of enterprise is moving away from traditional marketing automation, requiring its own database leaning more towards direct engagement with the data warehouse. The shift is driven by the desire for more efficient and direct data access and manipulation, potentially replacing some vendor services with simple calls to delivery services or direct queried from stage views. This change may impact current pricing models and necessitate vendors to pivot their strategies. But for smaller and startup SMEs, integrated end to end solutions like a combination of work management system and marketing automation tool are likely to be more popular than the warehouse native approach. Warehouse native tools being more impactful for enterprise is an argument that's echoed by message gears. When talking about the differences between API integrations and the warehouse native approach. Here's India Waters from message gears. Again. This is her take someone who thinks about like, oh my, my data is is up to date. It's via API. If you're thinking about Salesforce and Pardot that like for a small to medium sized business, setting up individual APIs to access that real time data is not a big deal. Like it's not that huge of a heavy lift. But even if we just keep this example on the small to medium sized business or like example, you're going to be updating your Salesforce environment to add new fields regularly or occasionally. And then you're having to get in your tech team's queue to add that API to then add into Pardot. They don't automatically update and then you like, you know, if you've ever plugged in any other type of like, um, sales tools into your Salesforce environment, the matching of fields is like really like complicated. And it's just like you're trying to force a square peg into a round hole. Is that what it's saying? And you know, like even just now, like on a, on a sales level or, um, you know, we're a small business, um, messaging is a small business. And the fact that we're running into these issues between syncing between like Salesforce, Salesforce, Pardot, um, we use some sales tool called like demand based, like the sinking of all those on a small business side is already getting complicated. So imagine that for a Best Buy or a Home Depot that has like so many SKUs, so many customers, a bunch of data that you can have on first party data that they're collecting, you know, on their customers, it gets complicated quick. And if you're having to match up like in, you know, Google BigQuery, we call it firstname. And then in this in Salesforce, they call it like it's all one word. First name like that is just like, but imagine a bajillion million times like that is super complicated and it just gets super hairy. So to have message, here's just essentially be a view into your modern data warehouse. Like what you see, what they have invested in this modern data warehouse, what they've set up as their schema, what they've decided to name their schemas. That is exactly what is reflected in message gears, while also not having to pay to store that data in message gears, while also like, you know, the there's all these new data privacy laws and, you know, in some of the evaluations that we go through, it's, it's funny because you'll sometimes encounter someone who like still doesn't get it. They're like, yeah, but like for, for PII data, like, you know, what are we doing with that? Like, how do we make sure it's not getting synced into your platform? And we're like, oh, we still have someone that's not getting it. Like we're not storing any of the data. So we don't even, you know, and like HIPAA compliance and stuff like that. It's like, it almost doesn't apply to us because it doesn't because we don't store any data. Um, so the takeaway from India here, the hybrid cloud component of messages sets it apart by ensuring high throughput while avoiding the complexities of data synchronization. And its approach aligns directly with the client's existing data structure, eliminating traditional challenges of data storage, synchronization, and API integrations. This enables a more streamlined and efficient experience even as data needs and regulations evolve. Emphasizing message. Message. Gears innovative stance in the MarTech landscape. Some of the emerging tools to replace API integrations are called reverse ETL, basically pushing data from your warehouse to your business tools. Some of the startups solving this are high touch and census. The question, though, is does warehouse native MarTech sitting on top of the warehouse also replace the need for reverse ETL solutions? On top of also replacing API integrations. Here's Arun again from Castle. Oh, right. I think that's a very interesting question. Right. So yeah, obviously it will actually reduce I mean remove the need, eliminate the need for having a reverse ETL pipelines, right? But I like I mentioned earlier, right? It should not be the reason why you're starting a warehouse native solution, right? So if you're building a warehouse, native solution should be that existing solutions have this kind of problem. And we want to solve that, right? Right. If you're just kind of in the market just because you want to eliminate reverse ETL, then I'm pretty sure you're going to die like pretty soon, right? Because like solutions like customer I o right? They are actually building a reverse ETL into this thing, right? Why would I mean, obviously they'll choose you, right? Um, but if but if like I mentioned, right. I mean, it's about like some of the limitations of the existing tools if you can solve using warehouse native approach. So then that is where I think this is going to kind of go. So the takeaway from maroon here, you know, warehouse native solutions might theoretically replace the need for reverse ETL. But again, Aroon, you know, his successful pivot relies on problem solving and enhancing existing functionality for customers. The focus should be on creating value and meeting user needs, rather than simply seeking to disrupt existing processes. Obviously, though, reverse ETL platforms are going to have some hot takes about this question of whether warehouse native MarTech will replace the need for reverse ETL tools. Um, yeah, I have an interesting opinion on this. That's Tejas Manohar, the co-founder and co-CEO of High Touch, over a reverse ETL tool that's taking a controversial stance against the package CDP claiming that it's dead and that they can replace it. So first and foremost, I think, uh, the launch of these warehouse native customer engagement tools or, you know, CDPs, adding features that start to import data from the warehouse or I still predict what I said in the blog post a couple of years, you know, all the existing MarTech providers will start to copy the the home page of high touch and start talking about how the warehouses already see it happening iteratively in the space. Um, will they be able to repot from their products? It's a different question. But yeah, all of this is, is, is I, you know, validating that, um, MarTech and data can't be separate and these worlds need to intersect and that the reality is whether you like it or not, it's not really a debate. The, the source of truth that a lot of businesses is becoming the internal data platform like Snowflake and Databricks, etc.. I mean, marketing teams do agree with this. Rather, they say it or they don't if you ask them. Usually what I ask them is, you know, um, if you want to know how your campaigns are doing, what do you look at today? It's generally like a, a report. Where is that report? It's in a BI tool. Where is that BI tool? Something like tableau, whereas a tableau or power BI or looker, whatever, sitting on top of it, sitting on top of a data warehouse. And that's where the data is in the organization. So, um, I am not bullish on, um, I'll go out there and say it. I'm just not bullish on warehouse native, uh, marketing tools coming in and taking over the Bres and the Salesforce marketing clouds of the world. Also, it just doesn't really make sense. Like, you know, there's, there's not just email platforms when it comes to marketing. There's advertising channels, there's personalizing your apps. There's all these, all these different channels and those can't really replatform onto the data warehouse. So I'm not, I'm not really bullish on that whole trend. I don't think enough marketers care about the data warehouse to frankly, decide whether to go with a Salesforce Bres or Adobe or VRE or message carriers or Castle based on whether it integrates with the warehouse. Um, marketers need to use their, uh, their data and they need to use their data across their tools, channels and solutions like high touch, uh, make that really, really easily easy without saying you need to move to another tool to build campaigns or to manage your email templates or to do all these things that are fundamentally Not related to the concept of data activation. This is an IP warming, and there's all sorts of concerns that a customer engagement or ESP platform handles that, just not related to the data warehouse. So, um, whereas in the CDP space, every single concern you mentioned out of those eight is a data problem in some way. Data quality, data governance, privacy, um, collection, identity, those are all data problems. That's not the case for ESP. So yeah, personally, I'm quite bearish on this, uh, this trend of creating a new startup that's a warehouse first take on an existing software category, like a marketing platform, because it doesn't matter to the business teams or to the end user, like marketers, as long as they can use data effectively across their tools. And high touch is a much more. While Warehouse Data platform is. Philosophically, it seems like the future and the right way of doing things. None of that. None of that matters. You know, what matters is. Can you use data effectively across these tools and and high touch solves that problem. The easiest, fastest way for your organization without saying, you know, get a new data warehouse, get a new email platform, etc., which I think is the novelty of it. So the takeaway from Tejas here, his insights indicate that while the marketing industry will continue to embrace a warehouse native approach, for some things, it doesn't necessarily spell a complete overhaul of the entire MarTech landscape, at least not immediately. The future likely holds more integration and convergence than a radical replacement of existing tools and platforms, especially some of the bigger names that have, you know, really good market penetration. Businesses needs to focus on merging their data and marketing efforts seamlessly without being lured into acquiring new platforms unnecessarily. Interestingly enough, not all reverse ETL vendors have a negative view on warehouse native approach. It's a great question and a nothing would be better than if we ended up in that world, right? Uh, I think because it would mean less proliferation of data, right. And more consistency. And I stated that as my goal when we started this thing. And so I want that. That's Boris Gibbs, the co-founder and CEO at census, another reverse ETL platform. So, so my ability to predict when is limited, right? What I can tell you is that we've been doing it for longer than anyone else. So like you said, census is effectively a warehouse native solution and has been since before that was a term our product, you know, connects natively to these warehouses. And what does it do is it lets you activate that data, right? As a marketer, take it and put it into a customer engagement platform, let's say. And we now also support, right? And we launched a couple of months ago to great fanfare, something called the Audience Hub, which is a component in our product. Like it's you can buy it effectively as a separate SKU or it's part of our broader, you know, you can buy the fat plan. And it is a, that's not the technical term I just got. My sales team will kill me. Uh, but, um, this audience hub is a segmentation experience that you are super familiar with, right? That is native to the warehouse. It's just an extension of what we've already built that gives you, you know, the ability to create segments and test them and experiment with them and all of that without ever writing a line of SQL, all of which runs natively against your warehouse. And, and then you can activate that too, right? So, so here's what we know from having worked on this for years. First, they only they work seamlessly. This works seamlessly only if you have perfect data in your warehouse to begin with. Yeah. And a lot of what census does, you said it yourself, right? When you describe reverse ETL, it's about getting the data in the right form. And it's about helping you build the right transformations, the right shape of the data to make it useful. And warehouses, they are optimized for storing tables of data. That's it. They're very, very, very good at it. Right. But if you think of Marketo, Marketo is not operating on tables of data. It's operating on users or contacts or whatever nouns you use. Right? And what we found, and I know a lot of the companies you've named, right, like their friends and, and they have to build a lot of the same functionality that census has already built, things like validating the data before you use it. Uh, the ability to customize to some degree, the kind of the relationships. Oh, and by the way, data warehouses don't show you what the relationships are. So census understands relationships between things and you need that if you're going to build a segment that is users who have done this event twelve times, right? Then you need to know that there's a users table and an events table and the related a certain way. Oh, and let's not get started about many to many relationships between like a workspace and a user and, and so on and so forth. Right? And so, yes, I think warehouse native tools are going to increase, uh, the absolutely will happen. But I actually think the fastest way for, uh, for people to build that if you're an app developer is actually no joke to call us, uh, and work on top of census, which is already a basically a perfect layer on top of the warehouse to give you more benefits, right? So, so, uh, I have nothing to announce today, but like, definitely app developers should contact me before they try to build all of this themselves. Um, but yeah, I think the need for data pipelines will reduce over time. And won't that be a great day? Like, I don't care about data pipelines. Like who? Who does? That's not that is not a user goal. Yeah. It's like the same way Apple. You know, they don't ever really try to talk about like the, the megahertz or whatever. Or I guess now it's gigahertz. You know, it's, it's like, what is the thing you can do? And if ETL, if moving data just disappears as a concern. Great. I think that's many, many years away. I think people will declare it long before it's true because it markets really well, right? They'll declare things to be a zero ETL framework or whatever or some some other thing like that. That's very plausible. And it will be true over time. But, you know, I hate to play the math game again, but like the speed of light is a real thing. And like data cannot instantaneously be in all places at all times. Like that's, that's actually not possible. So, so this is all going to get better. Uh, and I can't wait for the day when as a, as a marketer, when you use an application, you don't have to think about how data is loaded into it. And that was always the goal of census. So if we get there because everyone becomes warehouse bound, then I will be so happy. FIL swear to God, like I'll be just so happy because I think the fact that companies manage complicated systems of data movement is, is a distraction. Yeah. Like there should be one. Like what you need to work on is transforming and modeling your users. That's a hard problem that you need to spend time on. And we try to make it as easy as possible for you to do that. I don't think we perfect to say we solve it for you. Uh, and then everything else should be like. I think a couple of years ago, I was on a panel and I said something kind of glibly, but I really do believe this is like every application you use should just be a very lightweight cache on the core data warehouse that you have or the data platform that you use. And. And that's what we want to make possible. So let's, let's, let's make it happen. So the takeaway from Boris here, like he basically believes that the future of data management will lean towards warehouse native tools, reducing the need for complex data pipelines. And you know, these tools will allow for seamless integration and activation of data for various uses such as marketing, without requiring extensive data manipulation skills. However, Boris explains that the transition to this state depends on the perfection of data stored in the warehouse and a comprehensive understanding of data relationships. And although there is considerable amount of work to achieve this future, the end goal is to make applications merely lightweight caches on top of the core data warehouse, thus making data movement a background concern for the user itself. This will allow companies to focus more on transforming and modeling their user data, a critical task that demands their attention. Well folks, I hope you enjoyed getting a taste of different opinions and sides on this debate here. The shifting tides of warehouse native technology are definitely promising, but they come with a fair share of skepticism. This shift is not just a simple tool swap, as we've kind of heard from folks, but it's a nuanced evolution requiring careful understanding and strategic decision making, uh, shaped by your company's unique needs and data maturity. Is zero data copy really achievable? Does it save costs for the customer, or does it more benefit the cloud warehouse companies themselves? How long will local database copies be a requirement? Can compute charges really be solved with higher quality queries? Will warehouse native MarTech affect more enterprise or startup companies and will warehouse native MarTech will replace the need for reverse ETL pipelines. Yet amidst all of the complexity and all these questions, a promise shines through a future of reduced data pipelines, seamless integration, and more efficient direct data access. The challenge, as well as the opportunity, lies in the journey towards that future, a journey fueled by the symbiosis of pioneering tools and clean data. You heard it here first, folks. As we navigate the transformation to warehouse native MarTech, the single most critical action is to prioritize achieving high quality, well structured data. It's the golden key to unlocking the full potential of these emerging tools and strategies. We'll catch you next time.