Composable CDP vs. Packaged CDP: How To Make an Informed Decision and Determine the Right Solution for Your Organization

This is part 2 of a 3-part series produced in collaboration with Glenn Vanderlinden of Human37.

{{line}}

If you’ve had a chance to look at our previous post in this series, you already know that the CDP exhibits the properties of antifragility — a concept developed by Nassim Taleb in his book, Antifragile. 

Antifragility is a property of systems in which they increase in capability to thrive as a result of stressors, shocks, volatility, noise, mistakes, faults, attacks, or failures. - Wikipedia

Over the last 12 months, there has been a lot of chatter about the CDP being dead and being replaced with the data warehouse. People have even made claims to the tune of “Snowflake is killing the CDP” when Snowflake only offers a couple of CDP components. 

It’s important to note that everybody who has written about the death of the CDP is referring to the Packaged CDP, and believe that in the near future, every company will assemble a Composable CDP.

Therefore, in reality, the CDP as a piece of technology is only becoming more relevant as a result of the noise, the attacks, and the volatility in the industry.

Without further ado, let’s jump into part 2 of the series where we share some ideas on how organizations can better evaluate their CDP needs and make buying decisions that they don’t end up regretting.

Technology

Since you’re reading this, you’ve likely witnessed the fierce debate between the proponents of the Packaged CDP and the torch-bearers of the Composable CDP.

And then there are those who believe in a hybrid approach — a point in the CDP spectrum that sits between composable on the left and packaged on the right. 

To strengthen their argument, each camp spins up “ultimate guides” and “hot takes” describing the superiority of their solution. If you look closely, you’ll notice a pattern resembling an obsessive focus on technical capabilities — features and speed — as well as on implementation time. 

In fact, some vendors actively use confusion as a strategy to win people over. 

Industry newcomers are easily overwhelmed, feel lost, and tend to believe that it’s only the technology that matters, and choosing the right solution comes down to evaluating the technical elements of the two approaches. 

Well, we’d like to highlight two facts about Composable and Packaged CDPs:

1. Both solutions are viable and one isn’t better than the other. Moreover, it doesn’t even have to be either this or that — organizations can determine the right mix between the two.
2. More importantly, there’s a lot more than just the tech specs — like company culture and team philosophy — that must be taken into account if companies must choose either solution. 

Allow us to explain the role of culture and philosophy in the CDP buying process. 

Culture 

Let’s start with the cultural implications by asking ourselves these three questions:

1. Do we need it or do we want it?
2. Do we prefer to buy or derive joy from building?
3. Do we have what it takes to move fast?

Now let’s dig deeper.

Do we need it or do we want it?

Some organizations want the best tools even when they don’t necessarily have a need. And yet others choose to compromise even when there’s a strong need for tools with specific capabilities — attributing it to cost or some other excuse.

Depending on which of the two your organization falls under makes a significant impact on technology-buying decisions. 

If a clearly-defined need is enough to get buy-in for new tools and if that’s enough to get clearance from procurement — more on that below —  the desired Customer Data Stack (CDS anyone?) can potentially come down to adding just the one missing CDP component, or deploying a version of a Packaged CDP.

However, if execs at your organization are determined that they “want” the latest and the greatest tech — whatever that looks like to them — and have prioritized the procurement of such tech irrespective of what teams need, well, that’s a battle you probably don’t want to fight.

We need it, we have buy-in, now can we please just buy it?

Buying decisions often come down to the procurement process — which can either be swift or riddled with inefficiencies. If it’s the latter, assembling a Composable CDP, by onboarding and negotiating with multiple vendors, can be arduous.

The same is true for security audits and legal compliance. 

For instance, conducting a Data Processing Impact Assessment (DPIA) required under the GDPR for each high-risk data processing activity can be lengthy and resource-intensive. And organizations that opt for a Composable CDP might need to prepare separate DPIAs depending on the level of risk assessed for each vendor. 

Therefore, organizations should opt for a composable approach only if the procurement process is seamless. Else, opting for a Packaged CDP might be a better bet.

Do we prefer to buy or derive joy from building?

Organizations with a strong engineering function are likely to prefer the build approach by assembling a Composable CDP. They’re also likely to already have a data warehouse in place which as you know, is one of the key CDP components.

It’s good to keep in mind that assembling a Composable CDP requires more data engineering prowess than deploying a Packaged CDP. Moreover, as the CDP evolves and grows more heads, organizations need to continuously make adjustments to fill the skill gaps that might arise as they integrate new components. 

Do we have what it takes to move fast?

One of the key arguments from both sides of the CDP camp is that one is faster to implement than the other. 

But can it be that simple?

Speed is contextual and depending on an organization’s priorities and people resources, either of the two approaches — composable or packaged — might be faster to implement.

But implementation alone can’t be the goal (unless that’s baked into the culture, of course). 

Enablement or giving non-data teams the knowledge and the autonomy they need to actually use the tools in their day-to-day is key. Not doing so leads to operator friction that can potentially topple the efficiency of your stack. Once again, depending on the priorities of the teams involved, either approach might be faster to adopt and execute.

Philosophy 

Now that we’ve talked about the cultural implications, it’s time to talk about the philosophical ones by asking some more questions: 

1. Is there alignment between data and non-data teams?
2. Do data teams care more about building infrastructure than delivering outcomes for the business?
3. Does anyone even own the CDP initiative?

If you’re into philosophy, you probably know that questions beget questions. 

Is there alignment between data and non-data teams?

Do data and non-data teams understand each other’s needs, priorities, and constraints? Are they aligned on responsibilities? Moreover, has it been established where the CDP budget will come from and which team will make the final call in the procurement process? 

When the data team considers the non-data team as a customer and the non-data team considers the data team as a service desk, their priorities are misaligned.

And when priorities are misaligned between teams that are supposed to work together toward a common goal — the modern data divide as we like to call it — and there isn’t enough incentive for organizations to change that, then it’s best to let data teams do their thing and equip non-data teams with tools that empower them to deliver business outcomes. If Marketing needs real-time ingestion of behavioral data to send a personalized welcome email within minutes of a sign-up, they should have the tools that make that use case possible instead of dismissing it as an “edge case”.

Do data teams care more about building infrastructure than delivering outcomes for the business?

Is performance prioritized over execution speed? Is technical excellence more important than the ROI on data infra? If the answer is yes, then organizations need to take a hard look at why they invested in a data function in the first place. 

Organizations with a strong focus on good infrastructure need to invest in building a bridge between their data and non-data teams for the latter to derive value from the investment.

Good data infrastructure is supposed to be used — by non-data teams to deliver more relevant, timely, personalized, and privacy-friendly content and experiences. 

Does anyone even own the CDP initiative?

Is there a team or a group of individuals that is willing to take or has been assigned ownership of the organization’s CDP? 

The introduction of a CDP, in whatever form, leads to a material shift within an organization. Getting buy-in and going through procurement successfully is just the beginning. 

Proper implementation, upkeep, and adoption across the organization to ensure that teams continue to derive value from this new piece of technology requires tremendous, ongoing effort. And in the absence of proper ownership, the CDP will end up as yet another piece of tech that nobody uses or cares about — a digital transformation promise drifted into oblivion.

Ideally, organizations need to hire semi-technical data talent — an individual or a group of ops pros who own the CDP initiative and continuously work towards bridging the gap between the data team and the rest of the organization.

Conclusion

Good technology is important — very important. But there’s no denying that at the end of the day, good outcomes are what keep the wheels of a business rolling. And good outcomes happen when people are productive. And people are productive when good processes are in place. 

Good technology → efficient processes → happy people → sound business.

The conversation need not be Composable CDP vs. Packaged CDP, it's a false dichotomy.

It should be about empowering teams to deliver personalized and privacy-friendly experiences by opting for whatever CDP approach works best — composable, packaged, or a hybrid.