Types of CDPs: Offline Merchants Must Choose One That Fits Their Business Needs (Part 2 of 3)

In our previous article we introduced the concept of CDP, who needs it, and the use cases for having one.

Now we’ll delve into the types of CDPs (hint: they’re not all the same) to help refine your thinking.

By and large the major driver in choosing a CDP boils down to one key barometer:

Ease of access to your data.

E-commerce businesses find themselves in the enviable position of having the easiest access to their data. That’s because e-commerce is ~20 years old and benefits from fresh technology. It also helps that the CAGR in e-commerce is coming at the expense of brick and mortar merchants and investors are plowing money into businesses swimming with the CAGR current of e-commerce growth, not against it.

Long way of saying that e-commerce is attracting the sophisticated spectrum of the bell curve.

One step below e-commerce are large brands with mixed use of in-store and online retailing. Think of Walmart as an example here.

While these retailers are often not digitally-native (though we have seen digitially-native brands open brick and mortar stores after finding that online customer acquisition costs were untenable), they do have the budgets necessary to collect their own data from offline sources.

Or at least demand that their vendors collect it for them.

That’s because moving into offline commerce muddles things greatly, as guests are not as easily trackable, but larger brands can skirt some of these headaches with large balance sheets.

Below large retailers are mid-sized retailers with mixed-use or in-store only experiences. These merchants will sometimes understand the need for a CDP but are stymied by their offline systems. Yes, it’s relatively easy for them to collect customer data for their Shopify storefront, but how do they get data on their customers – particularly the unknown – coming into their brick and mortar locations?

Lastly, and the furthest down the totem pole, are small brick and mortar merchants. Frankly, these merchants will struggle to spell CDP. Even if they could rationalize why they want it, they couldn’t afford it. That’s because, as we highlighted in our previous article, the costs of integrating to their disparate customer data sources are just too high. These merchants expect to pay $1 a year for CDP, demand that it work perfectly with 24/7 support, then wonder why none of the vendor’s SLAs get met.

Of course these same merchants are complicit in padding the pockets of SMB payment processors to the tune of $5,000- $10,000 per location annually. If they’re going to get a CDP, it’s going to need to come from someone fleecing them on payment processing: there’s simply no other money to go around. (Just don’t expect the CDP product to be any good.)

We made a quick graphic to show you how we think the CDP pyramid looks in practice.

With this as background, here are the three types of CDPs.

First is the build-your-own CDP. This is arguably the most flexible and feature rich CDP available. The downside is that you need to bring your own engineers. We see this type of CDP taking market share from the first-generation, general purpose CDP companies as brands/retailers want more control over their CDP architecture.

This type of CDP assumes that your engineers have access to all your data, and that said data is orchestrated with APIs. Because of this, likely customers are very technically savvy DTC or e-commerce brands, though it’s not unreasonable to expect large mixed use retailers to use such kinds of CDPs assuming they have access to all their data.

Build-your-own CDP example: Rudderstack.

Next are general purpose CDPs. These solution providers really started (and ended) with e-commerce merchants in mind. The first generation of this type of CDP to have any real market share was Segment, and the followers came flooding in thereafter. Why? Because CDP is a glorified database, and not that hard to build, frankly. We’ll get into this in our subsequent article, but just know that there are a ton of options for general purpose CDPs.

This type of CDP doesn’t have as much extensibility as build-your-own CDPs, but it’s much cheaper to set up and maintain. It will do a great job of offering 80/20 value, but again, the user is responsible for bringing all of their data.

General purpose CDP example: Adobe, Amperity, Bloomreach, Blueshift, mPartice, Salesforce, Segment, Tealium, and about 100 others.

The last type of CDPs are more purpose built. These CPDs often have fewer features because they’re not trying to appeal to every e-commerce merchant. They offer specific integrations, specific workflows, and are usually well versed at how to most successfully leverage CDP for their particular niche.

(soft pitch) Purpose built CDP for offline commerce example: Aben.

In summary:

1. e-commerce merchants have the most flexibility in CPDs options. Because access to their data is so easy, even smaller e-commerce merchants can get a powerful CDP solution out of the box.
2. Larger mixed use retailers also have the same CDP options in theory, but they will need to bring their own data, and should thus expect to pay more to use general purpose CDPs.
3. The simplest way to determine what kind of CDP to use is to understand what data you have, and what data you don’t.

Do you have access to your credit card data for your unknown customers?

Do you know how to get this data?

At the end of the day merchants with a brick and mortar presence are at a relative disadvantage because offline data is hard to come by. Aben is an expert at sourcing this data to make a CDP work for mixed use retailers.

Don’t believe us?

(hard pitch) Then ask why the credit card networks give Aben, and nobody else, access to their transaction data.

Hint: because we know payments infrastructure better than any general purpose CDP.

In the final article of this CDP series we’ll discuss the evolution of CDP, where it’s headed, and why merchants need to understand these macro trends to align with the right solution.