“What is a composable CDP and how does it compare to packaged CDPs?” is a simple pair of questions that rarely gets a simple answer.   Vendors, analysts, technologists, and business users give answers that make sense from their own perspective but often leave buyers confused.  In this article, we’ll try to answer from the perspective of a buyer whose only real concern is finding which solution best helps to do their job.

From that buyer’s perspective, the first question to answer is how a CDP – of any type – adds value to their work.  The short answer is that CDPs make complete data about each customer easily accessible.   Even more concisely: CDPs build profiles.  These profiles help users to understand their customers, build segments, predict actions, select the best messages, personalize those messages, and measure results.  Those users are most often in marketing but could also be in sales, customer service or operational departments.  Any user that interacts with customers can benefit from a CDP.

The Difference Between Packaged and Composable CDPs

The difference between composable and packaged CDPs is mainly a difference in how those profiles get built.  Packaged CDPs build the profiles within a single system that includes tools to collect, assemble, store, and access the customer data.  Composable CDPs build the profiles using multiple systems, a.k.a. “components,” to provide the different functions.

The central component of a composable CDP is typically a data warehouse built with a cloud database such as Snowflake, Databricks, Amazon Redshift, or Google BigQuery.  Other components such as FiveTran or RudderStack collect and load data into that database, while components such as Hightouch or Census give users access to the database to create segments, extract data, and run campaigns.  Still other components handle different aspects of building the profiles within the database, such as identity matching (Reltio, Infutor), data quality (Informatica, Talend), and predictive modeling (SAS, DataRobot).  (As we’ll see shortly, many of these vendors actually provide more than one component.)

You can think of this composable CDP architecture as creating an “unbundled CDP.”  Because the different components generally connect to the data warehouse, rather than directly with each other, many vendors describe this approach as “warehouse-native.”

Composable vs Packaged CDPs: Advantages and Disadvantages

Most business users have little interest in the details of CDP architecture, composable or otherwise.  What they do care about are the impact this choice will have on their ability to use the results.  While the details vary greatly with different products in the same category, it’s generally fair to say that each approach has its own advantages and disadvantages:

• Packaged CDPs are preassembled and complete.  This means deployment will be faster, require less technical support, pose less risk of failure, and take less on-going maintenance.  Many packaged CDP vendors have been in business for ten years or more, meaning their products are more technically mature, contain more advanced features, have sophisticated user interfaces, and offer large libraries of connectors to source and activation systems.  Similarly, their employees have had time to become expert in their products and CDP applications.  There is also a large number of packaged CDP vendors that specialize in particular industries, which enables them to build industry-specific functions and data models, connectors to common industry systems, and staff expertise in industry problems and solutions.  On the downside, buyers may pay for features they don’t use or that don’t fully fit their needs.   It’s also more painful to replace an entire CDP than a single component, so vendor lock-in is a greater concern.
• Composable CDPs are assembled from functional modules.   This means buyers can leverage existing resources and buy only the functions they need, reducing cost and choosing the best products for each task.  Basing their architecture on the major cloud databases also lets them easily employ the features built into those databases and integrate the third-party applications available their partner marketplaces.  The smaller footprint of individual components makes it easier to replace them than replacing an entire packaged CDP, so vendor lock-in is reduced.  The main disadvantage is the heavier burden placed on IT departments, which will need more expertise in managing customer data and spend more time integrating and maintaining multiple components.  Data processing costs in a cloud database are often higher than the cost of the same processing in a CDP database, especially where high volumes are involved.  Cloud databases also often struggle with real-time applications at scale.

Other factors don’t necessarily favor one approach over another. 

• Total cost could be higher for either approach: while the price of a packaged CDP will usually be higher than the price of one or two components, the integration and support costs will be higher for a component-based solution, and even the software cost could be higher if many separate components are needed.
• Either approach may struggle to meet unusual requirements.  Components are themselves packaged software, so they are not inherently more customizable than a packaged CDP.  Both groups will contain some products that are highly customizable and some that are not.  The need for customization will also depend on what features are already built into each system: some features that require customization in one product will already be available in other products.  Requirements that span several components may be more difficult to meet in a composable solution since all the components will need to support them. 
• The need to copy data into a CDP is often cited as a disadvantage compared with the composable approach of using data that is already stored in a data warehouse.  In fact, many warehouses do not include all the data sources needed for CDP functions, so some new copying is usually required in any event.   Moreover, the added cost of copying and storing data in a CDP may actually be less than the cost savings gained from processing that data in a CDP instead of a cloud warehouse.  The security impact of copying is also mixed: while storing data in two places adds some security risks, limiting many users to the subset of data stored in a CDP may create less risk than granting those users access to the full data warehouse.

The CDP Institute’s Build, Buy or Compose online free course looks at all these issues in greater detail.

Boundaries are Blurring Between Composable and Packaged CDPs

The architectural distinction between composable and packaged CDPs remains clear: either a system builds its own database – packaged – or it works with a database built elsewhere (composable). But changes in both sets of products are making the practical boundaries harder to draw.

• Composable vendors including Census, GrowthLoop, Hightouch, and RudderStack have all introduced modules that provide a more-or-less complete set of profile building functions.  Some have expanded further to include campaign design, predictive analytics, and journey orchestration.  Using components from a single vendor should require less integration work than combining components from different vendors.  This reduces one key disadvantage of the composable approach, although it also increases the potential for vendor lock-in and pressure to accept suboptimal components to stay within the product suite.  Quality and maturity may suffer when vendors expand beyond their original core competency.
• Packaged vendors including ActionIQ, Lytics, Segment, Redpoint Global, and Tealium have separated their product functions into modules that can be purchased and deployed separately, and can work against an external database.  That is, they are effectively offering components that can be used with other vendors’ products as part of a composable architecture.
• Packaged vendors including Amperity and Simon Data can build their CDP database in a cloud database such as Snowflake.  These same database instances could be part of a larger warehouse using the same cloud database, avoiding the need to copy data.  (Amperity and Simon both also offer modules that can act as stand-alone components.)
• Many packaged vendors including Adobe, Salesforce, Treasure Data and mParticle, as well as others listed above, can use external data in operations such as audience segmentation and analytics.  Typically the data is read on demand without storing it in the CDP’s own database.  This reduces the need for copying while still using the CDP’s own database to build and store the core elements of customer profiles.

Choosing Between Packaged and Composable CDPs

As the previous section suggests, choosing the right product requires much more than the understanding the distinction between packaged and composable CDPs.  The real starting point for an effective selection is understanding your own requirements, and the gaps in your current systems that prevent them from meeting those requirements.  Once you understand the gaps, you can begin to look at how specific CDP products could fill them.

As a general rule of thumb, companies with a mature cloud data warehouse in place might do better with a composable approach, especially if their warehouse already performs key functions such as identity matching and profile assembly.  The fewer gaps there are, the more likely they can be filled by buying a few components.  Conversely, companies with many gaps and a minimal or non-existent warehouse are more likely to benefit from a packaged CDP.

Gaps are not the only factor to consider.  Other key elements include

• Technical resources: in most cases, the composable approach will require more technical effort and customer data expertise than the packaged CDP.  Assess the true scope of technical support needed for each approach, and whether adequate resources are available to provide it.  Factor in your organization’s willingness to invest in long-term support and enhancement as well as the initial deployment.  Also bear in mind the opportunity cost of employing technical resources that might otherwise be used for other high-value projects. 
• Customization requirements: both packaged and composable approaches ultimately rely on packaged systems.  Assess whether you can find a packaged CDP or combination of components that meet your requirements.  If not, assess the degree of customization needed and the effort to achieve the customization under the different approaches.  The answers depend more on what you find in particular products than in a general choice of packaged vs composable. 
• Future requirements: regardless of how thoroughly you document your current needs, you will surely add new requirements in the future.  Assess the difficulty of supporting those as-yet-unknown requirements with different solutions.  Composable solutions are generally a better bet when you expect many new requirements because you can switch systems more easily as your requirements evolve.  But a mature and flexible packaged CDP might also be a good choice because it has more capabilities available without switching.  Again, this depends more on individual products than the general packaged vs composable choice.
• Delivery risk: the more components you need to select, install, and integrate, the greater your risk of time- and cost- overruns and functional shortfalls.  At some point, it is safer, faster, and probably cheaper to deploy a single CDP package instead.  Assess the risk of the alternatives in your particular situation, and consider the opportunity cost of unexpected delays. 
• Scale and performance risk: not all systems can handle extreme requirements for data volume or processing speed.  If you have such requirements, it’s essential to assess closely the ability of selected products to meet them.  Both composable and packaged CDPs may be able to meet extreme requirements, although the risk of failure is higher for a composable solution since each component is a separate potential bottleneck and unexpected interactions between components may cause problems. 
• Execution risk: end-users may lack the skills to take advantage of a CDP; existing systems may not be able to access CDP profiles; organizational hurdles may block use cases that require cooperation across departments.  These problems are not caused by a CDP, but some systems will make them easier to resolve by providing more powerful features, better interfaces, tighter coordination across functions, or more ways to connect with external systems.  The higher maturity and tighter integration of packaged systems may give them a slight edge here, but the best solution will depend much more on the individual products than the over-all CDP architecture.
• Cost: in general, a solution that requires only a few changes to existing systems and buying a few components will cost less than a packaged CDP, while a packaged CDP will cost less than a solution that requires many changes and new components.  But there’s no way to know the exact costs expected in your situation without a careful analysis of specific options.  When assessing cost, also consider how cost will change as your operation grows larger or more complicated.  Different vendors may take wildly different approaches to volume-related costs, and the processing costs of cloud databases in particular can be unaffordable at scale.

By now, you’ll have noticed a consistent message in these discussions: the only way to make a sound choice is to assess individual systems against your own, specific requirements.  The choice between packaged and composable CDPs is only clear at the extremes: composable CDP is best when you have just a few gaps to fill, and packaged CDP is best when you have many.  But even knowing how many gaps you have depends on a detailed understanding of your requirements and current systems.  Similarly, selecting specific systems requires that assessing those systems against your requirements: just knowing whether they are packaged or composable is never enough.

In short, from a buyer’s perspective, the distinction between packaged and composable CDPs is interesting and may help you to identify which systems to consider.  But a sound choice requires looking beyond the labels to understand how well each solution can meet your needs.  There’s simply no substitute for a careful, detailed selection process.