The rise of the CDP Automation Application

The Customer Data Platform (CDP)

Traditionally (and these aren’t even that old, so tradition is used loosely here) a CDP is a headless tool that is used to create a dataset representing all of the information about a company’s customers. These are accessible by other tools, focusing on:

• integration of data about customers from various sources
• de-duplication of said data and customers
• persisting all of it to your data warehouse (hence the headless)

Examples of CDPs that built the category are Segment and Amplitude, followed by an open source version with Posthog.

Co-opting the CDP

Recently there has been a surprising growth in the number of tools acting explicitly or implicitly as a Customer Data Platform (CDP). Some of which I’ve used, some of which I haven’t:

• customer.io
• Atlan
• Pocus
• Census
• Hightouch
• Klaviyo

These include marketing platforms, data catalogs, reverse ETL, and even sales accelerator tools. All of these that I have included have some marketing around them being a CDP out there in the world. So why did all of these different categories decide to enter the CDP space? I would posit the answer is related to automation.

Workflows are processes

Everybody has recurring tasks that they perform at home. Maybe you make oatmeal every morning. Let’s assume you aren’t a maniac and you make your oatmeal the correct way (on the stove) - every morning you take out a pot, measure some milk, put it in the pot, measure some oats, put those in the pot, turn on the heat, and so on.

Cooking oatmeal is a workflow: you decide you’re hungry, so you take the steps needed to make delicious, savory oatmeal. Workflows are processes (like cooking oatmeal), with step by step actions that occur based on some trigger condition.

Automation

In yesteryear, and still to some extent, business processes were performed by humans. A credit card application was at one point reviewed by a human, who followed some process and then returned an approval or denial. Today, most credit card applications along with other rote tasks are automated by a computer.

These automated workflows are inherently cheaper than those performed by humans: we’re really slow counters compared to machines, and we’re really bad at doing more than one task at once. Therefore, much of work today is humans designing workflows that computers then execute.

The distribution of automation and growth of SaaS

Automation from 1980 to 2010 was migrating out of individual tools where they started (by and large databases), and into the 3rd party GUI schedulers (Control-M, ActiveBatch, JAMS, Stonebranch) or business-user focused RPA tools (Pegasystems, UiPath, Zapier, Appian). Integrating or embedding these tools into your own application is super painful because of the nature of their design: rigid for a reason¹.

One great example of early automation is Salesforce, who built their own (awful) workflow tool built around Apex and XML. This was a company with hundreds of millions of dollars, and their automations barely hung together. Imagine trying to build automation within your own application pre-2010 when you were a tool NOT focused on automation.

~10 years ago, code-first orchestrators (Airflow next, now Prefect and others) entered the scene². As the barriers to entry for creating applications have slowly been reduced to rubble³, so have the barriers to entry for embedding workflow automation into applications: all thanks to the orchestrators. Code-first orchestration tools mean that automation can be exposed to users of SaaS applications when previously that was really hard to build for those application developers.

From Orbit to Klaviyo to customer.io: powerful automation is now been distributed into the SaaS applications. So why are they calling themselves CDPs?

The CDP Automation Application

The answer is: CDPs serve automation…always have.

The entire reason for a CDP to exist, is to take some action based on unified information. Automation without triggers is useless: if you don’t know you’re hungry, you (probably) will never start the process to make yourself some oatmeal.

The original CDPs were headless: developer tools aimed at being for integration and segmentation in service of analytics. What they morphed into were operational integration tools: serving some action (make my oatmeal!) in some other system (Control-M, ActiveBatch, some custom tool, etc).

It seems to me that what these tools are hearing from users:

• I want a unified view of all my data (CDP)
• I want to take action with it (Automation/workflow tool)
• All in one place

and that they’re taking action to build this thing - carving out market share from two different categories.

What’s next?

Is the modal CDP destined to move towards the SaaS applications that are adding workflows⁴? Or is co-opting of the CDP market an indication of intense competition for market share driven by hungry startups?

It is possible that these tools are simple filling in the CDP space with opinionated platforms based on users⁵? Is a Revenue Data Platform just a CDP and automation tool for GTM teams? Maybe one could call that, a CDP Automation Application. ;)

My bet: this is an overall market expansion for both automation and CDPs, where the low end of the market (less technical users and those who wouldn’t buy a standalone or automation tool) or the audience-specific parts of the market (GTM, marketing, etc.) will enjoy CDP features tailored to them, and eventually become a funnel into the high end CDP and workflow tools mentioned above when their use cases expand or a company consolidates.

In the end, more competition for customers is a good thing and drives innovation. I think we’re seeing that play out in the CDP space today.

What was I listening to when writing this?
Chris Thile - Another New World