It’s nearly two months since my last post on building a classification scheme for CDP vendors.   Work has continued behind the scenes.  I still don’t have a final solution but have made enough progress to warrant an update.

Where we currently stand is several of the CDP vendors have provided lists of technical features they see as important differentiators.   I’ve reviewed these and classified them based on the core CDP functions they support.   These functions fall into two categories:

• building the unified customer database itself (ingestion, transformation and identity unification, storage, and sharing with external systems).  All CDPs do this.
• applications that use the database (analytics, campaign management, and personalization).  Many CDPs offer one or more of these but it’s not a core requirement.

Looking at the specific differentiators, it turns out that about half of them apply to nearly all customers who might want a CDP.  I’ve labeled those “base”.  The rest relate to specific channels or uses.  I’ve identified these as:

• semi-structured and unstructured data
• real time processing
• Web marketing
• mobile marketing
• advertising
• B2B marketing
• offline marketing

I’m perfectly aware that these categories overlap: B2B marketers use the Web, Web market involves unstructured data, and so on.  But each category is something that some marketers might use and others might not.  Since the ultimate goal of this exercise is to help marketers find CDPs that meet their particular needs, breaking the features into categories related to those needs seems reasonable.

Naturally, two sets of dimensions (functions and uses) lends itself to a matrix.  In practice, though, such a matrix would have many blank cells because so many items fall into the “base” use case.  So to make the presentation a bit more manageable, I’ve presented two tables below: one that lists the base items only and one that has each of the other uses in a column of its own.  In both cases, the rows are grouped by function.  (To be clear, there’s no particular relationship among items on the same row in different columns.  That said, it might make sense to have one row list the connectors appropriate for each use: B2B systems should have connectors to Salesforce.com; mobile systems should have connectors to SMS gateways, advertising systems should have connectors to DMPs, etc. )

If you read the entries carefully, you’ll see that I’ve marked several with questions, mostly about whether they’re too vague.  Ideally the items would be specific enough that we could easily determine whether or not a particular vendor offers that item or not.  So things like “has API” are too general, since APIs differ greatly.  Tightening up these definitions, and adding more items as needed, is the next step in this process.

As always, I eagerly await your comments and suggestions.

(Note: tables converted from Excel using Tabelizer. Worth knowing about!)