The composable CDP and what it means for product analytics

Data warehouses are also changing how companies store their customer data in CDPs (customer data platforms). CDPs became popular in the last decade as hubs for collecting, transforming, and activating data generated by customer interactions across digital touchpoints.

Now, we’re seeing the emergence of a new kind of CDP: the composable CDP. This new approach is built around the data warehouse. It offers a modular system of best-in-class tools instead of the rigid, monolithic architecture found in traditional CDPs. In this post, I’ll chart the evolution from CDP to composable CDP and how this shift affects the future of product analytics.

A brief history of CDPs

A CDP is an all-in-one data platform built for marketing and product teams. CDPs serve as a database of all customer information with a bundled activation layer that leverages data for marketing automation. Before there were CDPs, there was web tag management.

Foundational to digital advertising and marketing, a tag requests an invisible piece of content on the web, e.g. a transparent tracking pixel. In the early 2010s, CDPs emerged as a replacement for tags to address their many limitations.

CDPs take a data-centric approach to managing customer information. Instead of the “fire and forget” of tags, CDPs collect customer data centrally using SDKs or APIs, transform it, and push to downstream apps for activation. They work across web, mobile, and other platforms. Most CDPs have an opinionated schema to simplify downstream consumption, so it’s up to the company to adhere to the CDP’s spec to get the most value out of it.

Today, CDPs manifest as a persistent, unified customer database that provides the following key capabilities:

Data collection: Ingest data in real time from any data source, including full customer-context.

Data storage and governance: Store schematized data indefinitely, provide access control and governance.

Data transformation: Enrich the collected data, primarily through identity resolution, which merges an individual’s cross-channel interactions into a unified profile.

Data activation: Synchronize profiles and audience segments to downstream apps, e.g. marketing channels.

The future: composable CDP

Although CDPs were a catalyst for growth early on, they have increasingly become a bottleneck in the adoption of modern data practices. Their fundamental limitation is that they’re built on a simplistic data layer, preventing many rich data applications from leveraging customer information to the fullest.

Composable CDPs address this by using a standards-compliant cloud data warehouse as the data platform around which a whole ecosystem of lego-block style building blocks can be built to provide best-in-class solutions for different needs.

This is an evolution of the CDP architecture towards greater data-centricity, elevating the data warehouse as the single source of truth and compute platform for all customer needs:

Data collection: Extended to also collect non-clickstream data (like state) from application databases, third-party SaaS tools, etc., providing a 360 degree view of the customer.

Data transformation: Easy stuff is easy still, e.g. identity resolution through DBT, but more advanced capabilities are available due to the full power of SQL. Users can perform joins or do complex computation, e.g. ML-based identity resolution with Zingg.

Data modeling: Regain full control over your data model to match your business needs, now and in the future.

Data activation: The data warehouse’s sophisticated data manipulation capabilities enable a richer ecosystem of data activation tools, avoiding data silos.

Today’s major cloud data warehouses (e.g. Snowflake, Databricks) are positioning themselves as the Composable CDP of choice. A rich ecosystem of thoughtfully designed and well integrated data apps and services have emerged around these platforms.

Product analytics and the CDP

The emergence of the composable CDP is driving a shift in product analytics. First-generation product analytics tools, such as Mixpanel and Amplitude, ingest product instrumentation data sourced from their SDK or from a CDP. The data is placed in their compute silos and analytics are limited to the out-of-box capabilities provided by these tools.

In contrast, the next generation of product analytics tools can leverage the rich set of data and compute capabilities offered by the data warehouse. It’s therefore no surprise that 80% of first-generation product analytics deployments export instrumentation data to the data warehouse for richer analytics. This leads to greater complexity and costs.

Let’s take a look at what a typical product analytics workflow looks like using Optimizely Warehouse-Native Analytics on a composable CDP:

Data collection: Pull instrumentation data from Segment, Snowplow, or Rudderstack, alongside business data from your application databases or third-party SaaS tools using Fivetran. Land all of this data in a cloud data warehouse, such as Snowflake, Databricks, AWS Redshift, or Google BigQuery.

Data transformation and modeling: Build a data model in Optimizely Warehouse-Native Analytics with the full flexibility of a general purpose SQL capable data warehouse, potentially leveraging open source tools such as dbt.

Product and behavioral analytics with Optimizely Warehouse-Native Analytics: Start from self-service product analytics templates, and then for deeper, richer understanding of product usage and customer experience, continue with ad hoc data exploration.