I recently shared a post that outlined why organizations should use Composable CDPs to turn their data warehouse into their CDP. This post detailed many advantages of Composable CDPs over traditional packaged CDPs.
However, since Composable CDPs are a relatively new technology, some people and organizations may have questions or hesitations about them. In this post, I will tackle some of the common objections or concerns I have heard in prospect meetings during my first few weeks at Hightouch.
What if my data warehouse isn’t production-ready?
Composable CDPs, by definition, leverage customer data stored elsewhere to perform their CDP functions. A true Composable CDP doesn’t store customer data but instead sits atop a data warehouse. In most cases, the data warehouse will be from a cloud provider like Snowflake, Databricks, Google, Amazon, etc.
But what if your data warehouse isn’t finished? In our experience, most enterprise organizations have some sort of data warehouse they can tap into, even if the data quality or completeness isn’t adequate yet for it to be the primary source of customer data. This lack of faith in the data warehouse can be for several reasons:
- The data warehouse implementation project is not yet complete
- The data warehouse doesn’t have all the data sources ingested yet
- The team hasn’t validated that all data in the warehouse is accurate according to the desired data governance standards
The truth is, your “Customer 360” initiative will never be “done.” Curating a digital twin of your customers is a never-ending journey. Organizations have to ask themselves if they would rather work with the data they have in the data warehouse or start from scratch within a separate system with limits and opinionated ways of managing customer data.
I say, “Don’t let the perfect be the enemy of the good…” and find places where a Composable CDP can add value. Your unfinished data warehouse likely has more complete data than a packaged CDP limited to subsets of customer data.
Will my cloud data warehouse compute bill go up?
Another Composable CDP objection that surfaces occasionally is cloud warehouse compute costs. Most people know that cloud warehouses charge based on how much computing their servers perform on their client's behalf. When you build audiences and journeys or analyze data within a Composable CDP, those tasks translate into warehouse compute charges. So naturally, organizations worry that as they use a Composable CDP, they could rack up charges on their cloud warehouse bills.
While this is a valid concern, in most cases, cloud data warehouses have become so efficient that compute charges have become less expensive over time. In addition, Composable CDPs have architected themselves to make queries as efficient as possible to minimize compute charges and have safeguards in place to prevent clients from inadvertently doing things that would result in unforeseen cloud warehouse bills.
It’s also important to remember that packaged CDPs also have data warehouse costs. These data warehouse costs are often hidden in the price of the packaged CDP. When using a packaged CDP, you have to perform multiple functions that can result in high data warehouse compute charges:
- Ingesting or ETL from the packaged CDP to the data warehouse
- Normalizing the data to make sure it gets combined with other data in the warehouse
- Transforming and enriching the data in a way it can be sent back to the CDP
- Pushing normalized/transformed data from the data warehouse back to the packaged CDP
These actions must happen continuously to synchronize the data warehouse and packaged CDP. Costs to do this can add up and are comparable to compute changes incurred by a Composable CDP. In most cases, the overall computing charges will be lower via your cloud data warehouse provider because of their economy of scale advantages over packaged CDP vendors. So, when you factor in the total cost of ownership, you will likely see that even with the cloud warehouse compute changes they create, Composable CDPs will be less expensive than packages CDPs.
The most crucial point, however, is that the Composable CDP completely shifts what a data warehouse is for your organization. Instead of viewing the data warehouse as a cost center for your IT team to manage (and foot the bill on), it becomes a revenue-generating machine! The customer 360 models and insights curated in the warehouse are now the very engine of your business. The successes of marketing personalization can be tied directly to your investments in the warehouse, even at the individual query level, so you can directly compare the exponential value return of the marginal compute being added to your warehouse bill.
Can I perform real-time use cases?
Another common objection to the Composable CDP approach is real-time use cases. Because Composable CDPs leverage data in the warehouse, they require data to be sent to and processed by the warehouse before the CDP can activate it. For example, if customer behavioral data from a website is sent to the data warehouse, it may take several minutes to arrive. This delay can prevent organizations from implementing real-time use cases, including same-session personalization of offers or cross-sells.
However, it’s a misconception that Composable CDPs cannot address real-time use cases. Hightouch’s Personalization API allows customers to cache important subsets of their data, making it available for real-time use cases like in-app and on-site personalization. Event streaming forwards events in real-time to any downstream tool, which enables use cases such as triggered messages. In addition, cloud data warehouses are making tremendous advancements in the speed at which they can ingest and process data to support real-time use cases. For example, Snowflake recently released Dynamic Tables, and Databricks has released Delta Live Tables. These technologies are closing the “real-time” gap for data warehouses and will likely continue to improve over time.
In addition, in several client conversations, I heard that getting data into packaged CDPs could take twenty-four hours. Once the data is ingested, packaged CDPs can perform real-time use cases, but if the data needed for these real-time use cases takes a day to be uploaded, it defeats the purpose!
As a final side note, I’ve often seen organizations think they need real-time, but their use cases don’t require that speed. Many organizations I spoke to would be ecstatic if they could personalize once a day or week. And even if they could adopt real-time use cases, they don’t have the teams to be able to create the creative assets needed to operate at this pace. The more I dug into why they need real-time use cases, the more I found that it was rarely an actual organizational need. For example, several retailers mentioned cart abandonment as a real-time use case. Who wouldn’t want to strike while the iron is hot if users abandon products in their cart? But this is an example of why real-time can be deceptive. You don’t know if the cart is truly abandoned until the session ends, which can take thirty minutes or more, so this is not a case where you need millisecond real-time activation.
Is a Composable CDP as much work as a DIY initiative?
Another question I received in my conversations was related to the idea of Composable CDPs as do-it-yourself tech. Many organizations believe that they can build their own technology instead of relying on a vendor they have to pay annually. Given the advancements in technology, some organizations choose this do-it-yourself approach when building tech stacks (Personally, I have always avoided do-it-yourself since it is difficult for an internal technology team to compete with a vendor that specializes in a specific technology). On the other end of the spectrum are packaged SaaS solutions where you outsource most of the technology to a 3rd-party vendor.
Some of the organizations I spoke with were unsure as to where Composable CDPs sat on this spectrum. Their fear is that using a Composable CDP might be too close to the do-it-yourself approach– and that it requires a lot of work for their technology teams. Luckily, this is not the case. Composable CDP vendors offer turnkey solutions and the accompanying support in a similar way to all other packaged CDP vendors. The only difference with the composable approach is that you can choose which CDP modules you want to use and pay for. With packaged CDPs, you often pay for all CDP components whether you use them or not, but Composable CDPs offer more flexibility. Composable CDPs allow you to work with the vendors you want to work with, knowing that it is difficult for one vendor to be the best at everything.
So while Composable CDPs offer many of the benefits of a do-it-yourself approach, they provide all of the support organizations want and expect from a packaged CDP.
Will it be easy enough for my marketing team to use?
The other objection I heard, though less so, was about the marketer-friendliness of Composable CDPs. Having used Hightouch in my first few weeks, I was puzzled by this objection since I have been a digital marketer, and when I used Hightouch, I found it to be very marketer-friendly.
But as I dug into this one more, I began to understand that the marketer-friendly objection reflects more of a historical reputation than a current one. Composable CDPs evolved out of reverse ETL, which data teams initially used more than marketers. Data teams would set up data pipelines between data warehouses and martech vendors so their marketers could get the needed data and audiences. These reverse ETL products were somewhat technical, and data teams often shielded them from marketers.
However, as reverse ETL products evolved into Composable CDPs, most adopted more marketer-friendly user interfaces since marketers desired self-service. Instead of requesting help from data teams, marketers wanted the ability to create data pipelines and build user audiences independently. So, over the past few years, Composable CDPs have invested heavily in enabling marketer self-service.
Hightouch audience builder and activation
However, as is often the case, no matter how much progress a technology makes, it retains its reputation from when it was first introduced. While I’m sure all Composable CDPs (Hightouch included) could improve the friendliness of their user interfaces, I think this objection is a holdover from the past. Thousands of users at leading organizations use Composable CDPs daily, including marketers. I have seen that Composable CDP user interfaces are not significantly different from those of packaged CDPs, so I don’t think this is a significant reason not to consider a Composable CDP.
Are Composable CDPs legitimate, proven technologies?
One of the comments (excerpt below) on my post last week questioned whether Composable CDPs were legitimate technologies relative to packaged CDPs:
The viability of Composable CDPs is a valid concern to raise. Packaged CDPs have been around for over a decade, while Composable CDPs have only been around for the last few years. It’s natural for organizations to be skeptical about new technologies, especially when they offer different ways of solving problems. But I would argue that we are in the midst of a sea change regarding CDP. Packaged CDPs are notorious for overpromising and underdelivering. The migration to cloud data warehouses as the central source of customer data is undeniable.
Companies like Hightouch have amassed many big-name customers, and we haven’t seen any organizations that migrated from packaged CDPs to Composable CDPs go back to packaged CDPs. While some organizations may continue to use a packaged CDP, I think most industry observers would say that Composable CDPs have proven their value and are a viable alternative. We see that vendors that have resisted adding composability to their CDP offerings lose market share and get acquired. At the same time, many traditional packaged CDP vendors have begun to embrace composability to stay relevant.
Final thoughts
So those are the common Composable CDP objections I’ve heard in my first few weeks at Hightouch. Hopefully, I’ve done a decent job of sharing a perspective on how Composable CDPs respond to these objections and how important they are or are not when making CDP purchase decisions.
Please let me know if you have other Composable CDP objections I should tackle. Also, if you can think of additional counterarguments to the objections above that I should have mentioned, please let me know!
