Expert Perspective: CDPs, AI, and Modern Data Stack

Speakers:

• Joan Jenkins: CMO, Blueshift (Moderator)
• Vijay Chittoor: Co-Founder & CEO, Blueshift
• David Raab: Founder, Customer Data Platform (CDP) Institute

Welcome and Introduction

Joan Jenkins: Hello, everyone. We'll get started in one minute, just waiting for everybody to join. Welcome! All right, let's begin. We have quite a few attendees here.

I'm Joan Jenkins, CMO at Blueshift, and I'm super excited about today's topic, as I know you all are. We'll dive deep into a discussion about Customer Data Platforms (CDPs), Artificial Intelligence (AI), and the Modern Data Stack.

If you have questions during this discussion, please submit them via the Q&A button (not the chat). We'll address these questions during a dedicated 15-minute Q&A segment at the end.

Now, I'd like to introduce our two distinguished presenters: Vijay Chittoor, Co-Founder and CEO of Blueshift, and David Raab, Founder of the Customer Data Platform Institute. With that, I'll turn it over to Vijay.

Understanding the Customer Data Platform (CDP)

Vijay Chittoor: Thank you, Joan, and thank you, David. It's truly exciting to have this discussion with you. You were instrumental in defining and shaping this category from its very beginning, and it's remarkable to see how far we've come. I want to start by asking a foundational question: What is a CDP, and why is it essential for any brand today?

The core problem, which you've addressed for many years, stems from how customers interact with brands. These interactions generate a vast amount of data from various sources:

• Human Interactions: Data entered into CRM systems or digitized from customer service calls.
• Digital Interactions: Captured as web logs or mobile app behavior.
• Other Data Sources: Including transactional systems, loyalty programs, and more.

Traditionally, customer engagement primarily relied on basic messaging channels like email and SMS. However, over time, first-party data (data captured directly from customer interactions) has become increasingly crucial for a wider array of channels:

• Paid Media: First-party data is now highly valuable for personalizing ads, especially as third-party data usage declines.
• Customer Experience (CX) Channels: Brands increasingly seek to use an individual's entire profile for more relevant, contextual experiences.

The significant challenge lies in bridging the gap between understanding the customer (from the diverse data on the left) and intelligently engaging them across all these channels. This is precisely where the Customer Data Platform comes in.

David, many years ago, you defined a CDP as: "Package software that creates a persistent, unified customer database that is accessible to other systems."

Could you elaborate on this definition? What was the original need you observed, why did this concept gain such prominence, and how did the CDP industry get started?

David Raab: The initial driving force from a business user's perspective was that 10-15 years ago, marketers realized they had valuable data trapped in various silos across their companies. They wanted to cross-pollinate this data – for example, using email engagement information to personalize website experiences. When they approached their IT departments, most couldn't or wouldn't deliver. Essentially, CDPs emerged because IT departments struggled to provide marketers with the necessary unified data capabilities.

Many entrepreneurs, often ex-marketers themselves who had experienced these challenges firsthand, recognized this opportunity. They built packaged software solutions to create and manage these customer databases. This was revolutionary because, before CDPs, marketers typically relied on custom IT projects or third-party system integrators to build complex customer databases. Buying a ready-made package is far simpler than embarking on a custom development project.

The phrase "unified persistent customer database" is crucial because:

• Businesses needed comprehensive access to customer profiles, integrating all data from diverse sources.
• For technical reasons, this unified data needed to be stored outside existing source systems (CRMs, data warehouses) that were not designed for this purpose.

Finally, "accessible to other systems" is fundamental. The entire premise is that other operational and engagement systems require access to this enriched data. Therefore, a CDP must be engineered from its inception with the explicit purpose of seamless data sharing. This core concept resonated strongly within the market, addressing a significant unmet need, which led to the rapid growth of the CDP industry.

Vijay Chittoor: That's fascinating. Your definition has truly stood the test of time. We see many diverse systems on the right side of our diagram. Some require immediate responses, like contact center systems handling inbound calls where a one-to-one response is needed instantly. Similarly, on a website, content must be delivered immediately based on user behavior.

Other systems may require data via a push mechanism, triggering actions based on specific customer events. And then there's the concept of audiences for paid media, where first-party data is synchronized for targeted advertising. When you coined "accessible to other systems," could you elaborate on the nature and breadth of this required access?

David Raab: The primary reason "accessible to other systems" is fundamental to the CDP definition is that many systems assemble customer profiles but primarily for their own internal use; they don't share data effectively. The vision for CDP buyers was always a single system that all other systems could access – a single source of truth that was consistent and always up-to-date. This approach allows organizations to concentrate efforts on ensuring data quality in one central location, rather than duplicating efforts across disparate profiles in multiple systems.

As Vijay knows, building a system specifically for this level of accessibility requires deliberate engineering. Other systems, even if they held profile data, simply weren't designed to widely share those profiles, thus limiting the value they could provide compared to a true CDP.

Vijay Chittoor: That's very insightful. When you developed this definition a decade or more ago, CRM systems already existed and attempted to build some form of customer profiles. Also, data warehouses were prevalent (though not the cloud-native versions we have today from companies like Teradata, Vertica, etc.). Despite their existence, what specific challenges did these systems face – was it the accessibility, the persistent unified profile, or a combination – that prevented them from fulfilling the role of a CDP?

David Raab: Every system is designed for its primary purpose. CRM systems, for instance, are built for salespeople and call center agents to manage and interact with individual customer records for sales and service. They excel at managing single customer records, capturing interactions, and resolving issues in a transaction-oriented mode. CRMs are typically good for static data like addresses, phone numbers, or customer status, but they are generally:

• Inefficient at importing large volumes of external data.
• Limited in exporting their data broadly.
• Confined by a structured data model, making it difficult to store diverse data types. Most CRMs don't even store purchase history (that's typically in order processing systems) or web logs, as they lack the structure for unstructured or semi-structured data.

Perhaps the closest predecessor to a CDP was the Data Management Platform (DMP). DMPs did handle large volumes and ingested data from various sources, but they had numerous limitations:

• Weakness with first-party data.
• Limited detail storage, often collapsing data for efficiency.

Fundamentally, it's a "boring technology" problem: when a system is optimized for one purpose (like a car designed for commuting), trying to force it into another (like hauling a boat) without the right engineering often yields poor results.

Vijay Chittoor: That makes perfect sense. I think we now have a solid understanding of the problem a CDP solves. Now, let's pivot to discuss its benefits. Assuming a brand successfully implements a CDP, what should they aspire to achieve? The first and most obvious aspiration is a unified view of customers. But what true capabilities does this unlock? The CDP Institute's research, which you've published, highlights top benefits like analysis, orchestration, and message selection. These benefits directly align with intelligently engaging customers across various systems.

Let's delve into each of these three: analysis, orchestration, and message selection, starting with analysis. CDPs are not general-purpose analytics tools like Tableau or Google Analytics. So, what role do you see for analysis within a Customer Data Platform? What is the nature of the analytics unlocked by a CDP?

Benefits of a CDP: Deep Dive into Analysis, Orchestration, and Message Selection

David Raab: To preface this, it's interesting to note that the rankings of these benefits in our surveys don't change much over time. This indicates that despite common perceptions of confusion, the market's core understanding of what a CDP delivers is quite consistent. The most consistently desired benefit is the unified customer view.

Regarding analysis specifically, a CDP primarily enables it. While some CDPs offer built-in predictive modeling or analytical tools (similar to Looker or Tableau for cross-tabs), their main role is to make data readily available for analysis systems in easily consumable formats. This often involves pushing extracts or allowing direct connections. The key is that the data is continuously ready and updated, rather than requiring large, time-consuming projects to prepare for analysis. So, a CDP acts as a supporting technology for analysis.

Vijay Chittoor: That's a great point. The unified view we're discussing spans the entire customer journey, encompassing both digital and offline interactions. It also unifies multiple identities; often, brands might perceive a single customer as three different individuals due to disparate data entries across systems. By creating a unified view, and then leveraging that for analytics, brands achieve consistency in understanding customer accounts and behavior.

You mentioned the ability to uncover customer insights and predictive capabilities. Even before getting to advanced predictive models, what are some of the analytical applications you're seeing that focus on discovering audience segments, which can then be fed directly into orchestration?

David Raab: That's an excellent question. Every CDP system inherently includes a segmentation tool. While technically a third-party tool could be used, vendors integrate it because customers need it, and it's simpler when controlling the data model. Even basic segmentation tools, especially when combined with unified data that was previously inaccessible, unlock a huge amount of customer insight.

These insights often weren't available before a CDP brought disparate data together. This capability alone provides significant value. To be honest, many CDP users don't progress much further than this level of analysis within the CDP itself, and that's perfectly acceptable because they are already gaining substantial value.

Vijay Chittoor: That's very interesting. I'd like to hold that thought, as we'll discuss the CDP user journey in a subsequent section. But for those who do go further, let's delve into the orchestration use case. David, what does orchestration mean to you in the context of a CDP?

David Raab: It's intriguing that orchestration often ranks very high, even though it's one of the most advanced applications—encompassing cross-channel coordination, real-time understanding of the right message, right channel, and right time, combining real-time and batch data. Aspirationally, users expect their CDP to support this. While some CDPs have native orchestration engines, a CDP primarily provides the robust data foundation necessary for effective orchestration, whether internally or via external engines.

Orchestration is highly sensitive to data quality. To send the right message, you need a complete and up-to-the-second view of the customer's activities. This ensures you avoid irrelevant messages (e.g., promoting a product just purchased or referencing a location the customer left moments ago). Achieving effective orchestration truly demands high-quality, real-time data.

Vijay Chittoor: That's very insightful, and it ties directly into message selection. As you move towards orchestration, you're shifting from segment-level targeting to a one-to-one level. Message selection might seem like a single point in time, but true orchestration spans multiple points across the entire customer journey. Combining these two elements is what enables the profound personalization that CDPs can deliver.

David Raab: It's interesting that message selection often ranks lower than orchestration, primarily because message selection is a more straightforward and common task. It's often associated with outbound efforts and might involve some personalization or predictive elements. Many businesses already have tools for message selection and expect to simply improve it with a CDP. Orchestration, in our view of the data, is more aspirational – users hope the CDP will enable complex, cross-channel coordination. Message selection, by contrast, is seen as a practical improvement to existing activities, where the CDP offers clear benefits.

Vijay Chittoor: That's right. This also emphasizes the critical role of CDP's accessibility features. If a CDP cannot enable access for paid media (audience mode), inbound real-time interactions, and message triggering, then comprehensive orchestration will never be achieved. This is a key consideration as we move through our discussion.

So far, we've covered CDP basics and benefits. Now, I want to transition to two or three fascinating trends to make our discussion even more engaging.

CDP Trends: Evolution and Modern Architecture

Vijay Chittoor: The first trend I want to explore is the evolution of CDP types. Initially, DMPs were the closest to what we now understand as CDPs, primarily focusing on data management. However, today, Gartner's perspective highlights Smart Hub CDPs that actively participate in execution. Their descriptions emphasize targeting, message timing, offering the right product, and overall engagement.

David, how should brands and CDP buyers perceive the evolving function of CDPs? Is their role strictly data management, or are they moving significantly beyond that into execution and orchestration?

David Raab: It's a pertinent observation. When we analyze the market, out of approximately 170 CDP vendors we track, about three-quarters actively offer capabilities in orchestration or messaging. While building customer profiles remains the core function (and for about a quarter of vendors, it's their sole focus), the majority have expanded. This is largely because users prefer to minimize the number of tools in their MarTech stack, even if their current stacks seem complex. They acquire new tools only if they deliver something unattainable with existing solutions.

CDPs naturally expand their scope, a common dynamic in software development. As clients request new functionalities, product managers incorporate them, leading to increased capabilities. CDPs, in particular, have expanded significantly in response to marketing requirements. While some CDPs have focused on becoming more efficient data management engines (what Gartner calls "CDP engines and toolkits"), the majority have added execution features to meet client demands and compete effectively. Additionally, marketing clouds, which didn't start as CDPs, have also integrated CDP capabilities in response to client needs for unified profiles. This dual expansion from both specialized CDPs and broader marketing suites drives the market's functional growth.

Vijay Chittoor: That makes perfect sense. Building on that, let's examine use case evolution. This chart from the CDP Institute's data illustrates a progression: starting with simpler, basic data assembly functions, brands then aspire to real-time interactions (inbound and triggered outbound), eventually reaching true orchestration (combining campaign-level activities with real-time elements across the customer lifetime). Could you explain this evolution in the context of data management-focused CDPs versus execution/orchestration-focused CDPs?

David Raab: As you noted, a business doesn't generate revenue until it's actively delivering messages, running campaigns, or managing real-time interactions. People invest in software to achieve concrete, useful outcomes. Customer profiles that remain unused or are not leveraged for meaningful, profit-generating purposes are ultimately of limited value, even though they are a necessary foundation.

This framework shows that simpler use cases like data assembly require a more basic set of CDP functionalities. However, as you introduce more sophisticated outputs or goals for your CDP (e.g., real-time interactions or comprehensive orchestration), the CDP inherently needs to provide more and more capabilities. It's a straightforward progression: the more advanced the desired output, the more extensive the CDP's functionalities must be.

Vijay Chittoor: While there may be some semantic nuances in defining "campaigns," "real-time interaction," and "orchestration," your point is well taken. One perspective is that campaigns are segmented and batched, real-time interactions are distinct and immediate, and orchestration combines both across a customer's lifetime. In some ways, David, is it fair to say that the original definition of a CDP – its ability to be accessible across many applications – naturally led to the expectation of orchestration?

David Raab: Yes, I believe so. That fundamental accessibility to all systems implies that every interaction with every system will be known and captured by the CDP. This is precisely what enables cross-channel orchestration. Furthermore, it's not just about capturing data; the CDP must also be capable of pushing information out to all the other systems involved in orchestration. The question then arises: where does the "journey engine" or "orchestration engine" reside – within the CDP or externally? At the CDP Institute, we maintain a neutral stance on that specific architectural question. However, if you're a CDP vendor, you'd naturally want to include that capability if clients are demanding it.

Vijay Chittoor: Absolutely. That's a fascinating trend. So, we've discussed the definition and benefits of CDPs, and how their evolution is shifting them beyond mere data management toward sophisticated orchestration.

Now, let me address a quick reminder to the audience: please post your questions in the Q&A section. We won't get to them immediately, but we will allocate time for them after discussing a couple more trends.

With that, let's shift to our second major trend: how to architect a CDP in today's landscape.

CDP Architecture in the Modern Data Stack

Vijay Chittoor: One of the most talked-about trends in the CDP world is the modern data stack. Simplistically, this concept centers around the idea that analytics can now be largely centralized within your cloud data warehouse. While data warehouses have existed for a long time (even when you first defined CDPs), several recent changes have significantly accelerated the adoption of cloud data warehouses:

1. Cloud-Native & Serverless: They are easier to set up, spin up, and scale due to their cloud-based, serverless architecture.
2. Flexible Ingestion & Transformation: Historically, data warehouses often required complex ETL (Extract, Transform, Load) processes. Now, with technologies like DBT and the architecture of modern systems like Snowflake, raw data can be ingested directly into the data warehouse, and transformations can occur within the warehouse. The output remains relational tables feeding analytics tools.

While the analytical output might not have changed drastically, the ease of cloud deployment and flexible data ingestion into data warehouses has fundamentally reshaped the ecosystem. How does this impact CDPs? What are your thoughts on this trend?

David Raab: I completely agree. In the past, when data warehouses ran on traditional databases like Oracle or simple SQL, adding even a single field was a massive project. Architects had to meticulously plan its placement within the data model, all constrained by the technology's performance needs. Newer cloud data warehouse technologies are far less sensitive to database design, making it significantly easier to incorporate new data elements. They also scale more efficiently due to their cloud infrastructure. This has certainly loosened things up, but it doesn't magically solve all problems, especially regarding real-time processing, which we'll discuss later.

Vijay Chittoor: That's an important and insightful way to phrase it. While it changes things considerably, it's true that it doesn't magically solve everything. However, it's undeniable that the cloud data warehouse is becoming an increasingly vital data source for CDPs. You recently wrote about a transformation primarily on the source side of CDPs, perhaps less so on the destination side. Is that something you're observing?

David Raab: Yes, I believe so. With more data being captured in data lakes, data warehouses, or cloud data warehouses (and now "lakehouses"), it's less common to pull data directly from the original source system. This is often because another system has already pulled it for a different purpose. This is beneficial, as it makes the CDP more efficient and reduces overall workload.

However, a particular database engine still imposes some constraints. Just because data is in a cloud data warehouse doesn't mean it inherently provides:

• Identity resolution.
• Real-time access.
• Any number of other functionalities needed to make that data "marketer-ready" or "CDP-ready" for building unified profiles.

Ultimately, it's all about customer profiles, and most data warehouses weren't primarily designed for building them, even if the technology technically supports it.

Vijay Chittoor: That's precisely right. Let's delve into those limitations. On the previous slide, we discussed how DBT enabled easy data transformation within the data warehouse, which is part of the modern data stack. DBT highlights that the modern analytics stack is primarily geared towards batch-based processing, and most analytics tools leveraging this stack are optimized for such.

However, CDPs, as we discussed, fundamentally enable orchestration and real-time interactions. This means CDPs often look very different from pure analytics applications like Tableau or Looker. CDPs need to:

• Handle inbound use cases that demand true real-time processing.
• Manage near real-time triggers, which are computationally intensive, requiring the system to identify changes and push real-time updates to third-party systems.
• Perform sophisticated message selection, which is a complex computation. While data warehouses have improved in speed, they are generally not optimized as a compute platform for these immediate, high-velocity use cases.

Does this resonate with your observations? What other commentary do you have on these limitations?

David Raab: Yes, I fully agree with everything you've said. It boils down to supporting different use cases. Real-time processing, in particular, requires significant skill to design and maintain a system that supports it effectively. This is why we generally argue that a CDP needs its own database; it cannot only rely on the data warehouse, though some disagree.

You need the data prepared for that final analytical burst required to select the right personalized message. Many calculations are involved. While some can be done on the fly, every such calculation adds latency. In advertising, we're talking milliseconds; even on a website, where you might have half a second, the more on-demand calculations you demand, the harder it becomes. Therefore, you want the system to perform as much pre-calculation as possible, presenting pre-calculated values (like lifetime value, customer classification, or predictive scores that don't change every two seconds) for the final, rapid computation.

Vijay Chittoor: That's right. It's similar to the concept of indexed data in search engines. Google search is incredibly fast because it's not querying billions of pages in real-time; it has indexed the data, yet it can still absorb real-time signals.

You emphasized that while data warehouses are important, CDPs must go beyond that to prepare data. My discussions with customers frequently highlight the crucial role of a cloud data warehouse. Customers often prepare various data tables in warehouses like Snowflake, Redshift, or Google BigQuery. These tables might contain:

• Core Profiles: Basic customer information.
• Accounts/Households: Data for grouping profiles.
• Events: Data with timestamps, including stateful events like subscription status.
• Product Data: Information about offerings.

While much data is pre-aggregated into the cloud data warehouse, a significant amount of real-time, point-to-point data also needs to be indexed directly into a CDP to enable real-time use cases and orchestration.

Here's how we envision this architecture:

1. Unified Data Ingestion: CDPs must unify both batch data (including near real-time micro-batches from data warehouses) and real-time events.
2. Enrichment and AI: This unified data is then used to drive enrichment, including data science insights and pre-calculations.
3. Business User Empowerment: Leveraging this enriched data, CDPs enable business users to build audiences and personalization strategies without needing to write SQL. This addresses the historical challenge of technical reliance for marketers.
4. Omnichannel Activation: Finally, the CDP orchestrates and activates personalized experiences across every channel.
5. Closed-Loop Analytics: Crucially, CDPs should provide a final handshake back with cloud data warehouses to enable unified analytics across the entire modern data stack.

This architecture, which we champion with our customers, allows for real-time data processing, inbound real-time interactions, powerful orchestration, and seamless integration with existing data warehouse investments. What are your thoughts on this approach, and how do you advise organizations on architecting a CDP alongside a data warehouse?

David Raab: We absolutely advise organizations to leverage their data warehouse as much as possible. The data is already there, often pre-captured, cleaned, and prepped to some extent. Our primary guidance is to ensure a clear understanding of what transformations are needed for that data to be truly usable for your marketing or business use cases.

In most cases, unless specifically engineered for marketing use cases, data warehouses will have gaps. The challenge then becomes whether it's feasible to extend the existing data warehouse to fill these gaps, or if the effort is so substantial that it makes more sense to extract the data into a separate dataset for processing. There's no single answer; some existing data stacks are easily extensible, while others would require a massively expensive project. There are no shortcuts for everyone. You truly need to assess your specific use cases, their requirements, and your current resources to determine the best path.

Furthermore, you need to be forward-thinking. Consider not just current use cases, but also future ones. While incremental additions seem easy, they can lead to a "horrible mishmash" that eventually needs to be scrapped for a clean start—something nobody wants to do. As we all know, temporary fixes often become extremely permanent.

Vijay Chittoor: That's a great way to put it! And that perfectly ties into our earlier discussion about use case evolution and the journey of a brand with a CDP. If a brand truly aspires to power real-time interactions and orchestration, they must consider how to ingest real-time data and perform pre-computations for intelligent message selection. Your point is vital: use the data warehouse extensively, but recognize the need for a system that can specifically prepare that data for the high-value, real-time use cases that truly drive success.

That's been an excellent discussion. We've covered the evolution of CDPs beyond data management into orchestration and how to architect them within the modern data stack. Now, let's address everyone's favorite topic: AI.

AI and CDPs: The Next Revolution

Vijay Chittoor: Let's jump into AI. Today, AI is a massive buzzword, largely driven by generative AI in content creation. However, CDPs, as customer data platforms, are fundamentally enabling a broader concept: Customer AI. Customer AI is about answering the crucial questions of who, what, when, and where:

• Who should you target?
• What content should you present to them?
• When is the right time for messages?
• Where should you allocate spend (e.g., paid media channels)?

When we consider Customer AI, CDPs are vital enablers for several reasons:

• Speed to Market: Pre-assembled, unified data within a CDP significantly accelerates AI model development and deployment.
• Productionizing AI: CDPs make it easier to operationalize (productionize) AI/ML models by providing real-time data access for customer records, crucial for immediate web interactions.
• Feedback Loop & Experimentation: CDPs can close the loop by ingesting downstream actions, allowing AI models to learn from results and enabling next-generation experimentation.
• Customer AI + Generative AI: Profiles in a CDP can automate summaries for contact centers or personalize content using generative AI.
• Privacy & Compliance: As AI becomes more complex, CDPs can track what AI does with customer data, aiding in auditability and compliance.

David, do any of these points resonate more than others, or are there additional topics you consider when discussing AI and CDPs?

David Raab: Several points stand out. One crucial aspect that often gets overlooked is the role of AI in the data preparation and exploration stages. AI can significantly enhance understanding existing systems, unifying data, and improving identity resolution. Second, and implicitly foundational, AI requires good data. The quality of your AI output is directly dependent on the quality of your input and training sets, and the CDP is instrumental in providing this high-quality data, even if AI calculations are performed externally.

Regarding your other points:

• Productionizing AI is super important. This has historically been a major hurdle for predictive modeling – getting models onto customer records. The CDP serves as an excellent channel for this.
• Speed of building models is largely driven by the availability of well-prepared data, minimizing the need for extensive data prep for individual models.
• Experimentation is critical, and the CDP closes the loop on measuring results, allowing AI systems to learn what works. This is where unified data is vital: if an offer is made on one channel but the response comes in another, the CDP helps tie it all together.
• Auditability and safety are massive industry topics right now. While a CDP doesn't solve all problems, by organizing the data, it makes it easier to track inputs and how they're used for various projects, making the issue more tractable.

Vijay Chittoor: Those are great discussion topics. We've covered a lot of ground today: defining CDPs, their benefits, architectural considerations, and how they enable AI. Now, let's open the floor for questions from our audience. If you haven't already, please post your questions in the Q&A section now. I'll stop sharing my screen, and we can take some questions.

Q&A Session

Vijay Chittoor: We have several questions that have come in. One topic we might have touched upon, but it's worth revisiting for clarity: Could you delve a bit deeper into how a CDP differs from a CRM, and clarify whether an organization needs both or if there's significant overlap in functionality?

David Raab: Certainly. A CRM system is designed for a very specific purpose: traditional sales management and contact management, along with customer service interactions. It excels at:

• Calling up a single customer record quickly.
• Viewing known information about that customer.
• Capturing interactions, notes, or structured records of problems and resolutions.

CRMs operate primarily in a transaction-oriented mode, focusing on one customer at a time. They mostly deal with static data (addresses, phone numbers, customer status, organizational affiliations in B2B). They are generally not designed for:

• Importing large volumes of external data.
• Broadly exporting their data.
• Storing diverse data types like purchase history (often in order systems) or web logs, as they are structured data-centric.

A CDP, by contrast, is interested in comprehensive customer profiles. While it will happily ingest and utilize profiles from a CRM, its fundamental differences are significant:

• Wider Data Scope: A CDP captures a much broader variety of data than a CRM, including web logs, other event-based data, and unstructured data. This is a core requirement of a CDP.
• Data Depth: CDPs store and unify a much deeper level of detail from across all customer touchpoints.
• Analytical Purpose: The CDP analyzes this unified data for groups of customers, building segments, and enabling sophisticated applications beyond individual record management. While it can retrieve individual profiles, its primary function extends far beyond that of a CRM.

Vijay Chittoor: That's spot on. To build on your point, consider a customer interacting with their bank. Data from a sales interaction goes into one CRM, service interaction into another system, non-logged-in web data into a third, and logged-in web/mobile data into a fourth. Each of these systems builds a mini-profile relevant to its specific function. The CDP's role is to understand the customer as a whole person, unifying all these disparate interactions – digital, human-assisted, sales, marketing, and experience-related – into a single, comprehensive view. This holistic understanding is the core of a CDP's value proposition.

Let's move to another question related to the modern data stack. People are discussing composable CDPs and the build vs. buy dilemma. The question is: Is a modern data stack genuinely a cost-effective way for IT to integrate multiple disparate solutions? Let's discuss this integration and data sources. Are there true cost advantages to centralizing data through systems like Snowflake, Redshift, or Google BigQuery, versus using many point-to-point solutions, and how does that influence CDP architecture?

David Raab: Again, every organization is unique. In most cases, I would expect that pulling data into a central cloud database is more efficient than managing a multitude of point-to-point integrations. While point-to-point might work for two or three systems, it quickly becomes complex. It's challenging to say whether one specific technology is universally "better"; you really need to perform a detailed cost analysis based on your specific requirements.

There can be issues, for example, if you try to perform complex analytics directly within a cloud data warehouse, it can become very expensive. We often see specialized tools that sit on top of the cloud data warehouse, pulling out data to perform complicated calculations more cost-effectively, and then pushing the results back in. While cloud data warehouse providers might not emphasize this, it's a common practice in the real world. So, life remains complex; there are no universal shortcuts.

Vijay Chittoor: David, you were supposed to solve all these complex problems for us! But it seems we'll always contend with real-world complexity. However, the key takeaway is clear: cloud data warehouses and data centralization are powerful ideas that unlock many analytical use cases and serve as vital data sources for CDPs.

Brands should complement this by selectively integrating real-time, point-to-point connections into their CDPs (minimizing them but ensuring critical real-time data flows). The CDP then acts as a computation engine, driving message selection, orchestration, and personalization – this is where significant benefit and value are realized.

Let's take one final question, combining a couple that came in: How do you show an ROI for a CDP? And how does the CDP's value relate to the convergence of ad tech and martech? CDPs often highlight engagement and loyalty outcomes, but what about paid media outcomes? Essentially, where does the ROI from a CDP come from, and what are the biggest ROI-driving use cases?

David Raab: Since RFPs were mentioned, I should point out that the CDP Institute (CDPinstitute.org) offers an RFP generator and a use case generator that can assist in designing RFPs and identifying use cases.

Regarding estimating ROI, it relates to the categories we discussed earlier (data, analytics, predictive, etc.). Value truly comes when you're interacting with the customer. A shorthand formula for ROI calculation, which we cover in workshops, involves:

• Number of customers affected.
• Change in value per customer.
• Cost involved in implementation and operation.

It's a straightforward ROI calculation, assuming you have those numbers.

Vijay Chittoor: That's right. The ability to personalize to a degree that dramatically improves conversions, increases lifetime value, and boosts downstream engagement is a core ROI driver. Simultaneously, on the cost side, workflow efficiencies are built in: IT dependence for basic segment building is reduced, business users are empowered to operate faster, and experimentation increases, leading to more measurable outcomes. These are typical ways of measuring CDP ROI, and it's often significant.

While this is specific to Blueshift, a Forrester study attributed a 781% ROI and an average revenue lift of $128 million per customer to Blueshift. This was a systematic, time and risk-adjusted study. The ROI attribution stemmed from:

1. Uplift from real-time interactions and AI-powered targeting: CDPs enabling real-time capabilities and AI led to more conversions and revenue.
2. Cross-channel coordination: Orchestrated messages across channels drove incremental customer lifetime value (LTV), which is highly measurable.
3. Workflow efficiencies: Reduced dependence on IT for marketing tasks.

These are key thematic ideas that form a strong ROI case.

David Raab: To refer back to the categories we discussed earlier, those benefits on the right, like less IT reliance and fast reaction times, represent practical cost savings and operational efficiencies. While they might seem less "sexy" than revenue gains, they are real and significant. Some studies demonstrate that these cost savings alone can almost pay for the CDP, even if direct business improvement isn't immediately visible, though the bulk of the business benefit certainly comes from higher revenue.

Vijay Chittoor: That's absolutely right. The majority of the business benefit comes from higher revenue, but the cost savings can indeed offset the CDP investment. For our listeners, I encourage you to focus on the business benefits primarily driven by orchestration, message selection, and predictive use cases.

Conclusion and Farewell

Vijay Chittoor: With that, we've covered many questions and had a fantastic discussion. I'd like to invite Joan back to provide some closing remarks. Joan, it's been a truly insightful discussion, and I've certainly benefited from your perspective. Over to you.

Joan Jenkins: Yes, definitely! Thank you everyone for joining. This has been such an insightful discussion. If you have any further questions that haven't been answered, please don't hesitate to reach out to Vijay or David directly; I know they are open to providing additional information.

This webinar will be available on-demand, and we'll send out a link to everyone who joined. Feel free to share it with colleagues, friends, or anyone interested in CDP. I believe it contains truly helpful information.

Vijay, any final remarks?

Vijay Chittoor: Firstly, thank you, David. It was incredibly insightful to hear your perspective, especially since you've witnessed the evolution of CDPs from day one. My biggest takeaways from today's discussion are:

• Start with Use Cases and Benefits: Encourage CDP customers to prioritize use cases and benefits, as everyone ultimately focuses on ROI and stack simplification. Choose CDPs that deliver the full range of value.
• Leverage the Modern Data Stack: Embrace the modern data stack and data warehouse, but also understand that CDPs are crucial for preparing data into an executable form for orchestration and message personalization.
• AI as an Enabler: Treat CDPs as significant enablers of AI. AI represents the next major revolution in enterprise technology and customer experience, and CDPs are a very, very critical part of making that revolution possible.

Those are my key takeaways. I'm excited to have had this discussion. David, it was great to have this audience here, and I look forward to continued dialogue with all of you. Feel free to reach out to me or David via email or LinkedIn. Thank you.

David Raab: Thanks, everyone. Thanks, Joan.