Hands-On Salesforce Data Cloud

Chapter 1. Salesforce Data Cloud Origins

Salesforce Data Cloud (Data Cloud for short) is a near real-time customer data platform that can provide value to several different functional teams within an organization. A customer data platform (CDP) is primarily a data store—a repository for persistently storing and managing collections of data that support marketing and customer experience use cases.

A CDP gathers all available first-party customer data from an organization’s customer relationship management (CRM) software, websites, automation platforms, email marketing software, and point-of-sale (POS) systems into a single repository. Next, it ingests third-party and sometimes second-party data to augment the first-party data. The CDP then aggregates all the information to build unified customer profiles that can be used to create business value across the entire organization in a variety of ways.

In 2013, the term customer data platform (CDP) was coined by David Raab, who is often referred to as “the father of CDP.” CDPs first appeared in the Gartner Hype Cycle in 2016, and that same year, the Customer Data Platform Institute was founded by David Raab.

In 2019, Salesforce launched Customer 360 Audiences, its first CDP product. In 2021, Martin Kihn coauthored with Chris O’Hara the book Customer Data Platforms: Use People Data to Transform the Future of Marketing Engagement (Wiley, 2020). Among other things, Martin is the SVP of Strategy for Salesforce Marketing Cloud. In 2024, Gartner released its inaugural Gartner Magic Quadrant for Customer Data Platforms, in which Salesforce was named a leader in the CDP category.

Salesforce has long been known as the global leader in CRM software. Its products are used by more than 150,000 customers worldwide to harness the power of automation and AI. When leveraging real-time data, its products are further used to make customer experiences more personal, valuable, and memorable.

Salesforce has a rich and interesting history that began in 1999. It was the first software as a service (SaaS) company built from scratch and is today one of the most valuable cloud computing companies in the world. Salesforce’s early approach of building solutions in the cloud, considered revolutionary at the time, is now common practice. Salesforce’s longevity and continued success can be attributed to its vibrant user community as well as its ability to innovate quickly.

Salesforce has introduced many product solutions created exclusively for the non-technical business user community. The Salesforce Lightning component-based framework, Flow Builder, Dynamic Forms, and Dynamic Actions, as well as the Force.com platform as a service (PaaS) offering, are some of the low-code/no-code Salesforce offerings. These types of solutions are designed to make it relatively easy for citizen developers (business users with little to no professional coding experience) to quickly design, build, and launch applications without the need to understand or manage the underlying systems. Many benefits accrue to using low-code/no-code solutions, including faster time to value, decreased costs, and enhanced innovation.

Salesforce innovates in many ways by improving existing products, creating new products, and acquiring successful companies that fit naturally with existing Salesforce product offerings. Recent Salesforce acquisitions include Slack, Tableau, and MuleSoft. Like most enterprises offering a full suite of products, Salesforce often rebrands its existing products to better align with the overall portfolio of products and simplify its terminology. The rebranding of the Salesforce Data Cloud is no exception.

Evolution of the Salesforce Data Cloud Platform

The current-day Salesforce Data Cloud platform began as Customer 360 Audiences—a Salesforce Marketing Cloud product launched on November 19, 2019. Marketers used this early Salesforce CDP version to more effectively create and manage audience segmentation.

Customer 360 Audiences (C360A) was frequently used with Interaction Studio powered by Thunderhead—another Salesforce Marketing Cloud product that gave marketers the ability to pull in external sources and model the data. A few months later, Salesforce announced it had acquired Evergage, a CDP platform and real-time personalization platform. Interaction Studio then became powered by Evergage instead of Thunderhead.

In May 2021, C360A was rebranded to Salesforce CDP. This rebranding occurred at the same time as identity resolution capabilities were added to the product. Identity resolution is what makes it possible to build a single source of truth for a complete 360-degree view of the customer. Later, Salesforce rebranded Salesforce CDP to Salesforce Customer Data Platform, which was a change in name only.

In September 2022, the product was rebranded again to Salesforce Genie Data Cloud. This rebranding coincided with Salesforce unveiling Genie as its new hyperscale real-time data platform. This was a major announcement, and it represented a fork in the road where the Salesforce CDP stock-keeping unit (SKU) still existed but a new Genie Data Cloud SKU was also created. The CDP SKU retained the pricing model based primarily on number of licenses, whereas the Genie SKU was the first-ever Salesforce consumption-based pricing model. Importantly, full feature parity didn’t exist between the two SKUs.

The main reason for the difference in feature parity was the difference in architecture. The CDP SKU gave access to features built on a transactional database, which was Salesforce’s traditional architecture. However, the new Data Cloud SKU offered access to a near real-time hyperscale data platform that had been built from the ground up to support new architecture that would solve many of the existing challenges with the current architecture (Figure 1-1). Chapter 2 explains in detail the new Data Cloud architecture.

Figure 1-1. New Data Cloud architecture makes more features possible

A few months later, around February 2023, Salesforce rebranded the product to Salesforce Customer Data Cloud (Figure 1-2). This time, the rebranding removed Genie from the name. Not long afterward, the word “Customer” was removed from the product name. However, the “Customer Data Cloud” naming convention was used for licenses and permission sets in Data Cloud production orgs several months after the word “Customer” was removed from the product name.

Figure 1-2. Salesforce Data Cloud evolution

At the time of the last rebranding, which removed the Genie name, Salesforce initially developed separate Data Cloud product SKUs, mostly for marketing purposes. Specifically, Salesforce advertised the availability of Data Cloud for Marketing, Data Cloud for Tableau, Data Cloud for Health, and Bring Your Own Lake (BYOL) Data Cloud. However, there were no platform differences among the Data Cloud offerings for the different SKUs.

Frequent and Rapid Changes

It’s exciting, but also challenging, to keep up with the numerous and rapid changes that are happening with the Salesforce Data Cloud platform. Throughout this book, I’ve referred to additional resources available for supporting your Data Cloud journey over the long term.

Two important modifications happened at the same time as the rebranding from a CDP SKU to the Data Cloud SKU. First, the Data Cloud SKU didn’t require an organization to purchase Salesforce Marketing Cloud, whereas the CDP SKU was an offering that was available only to those who had purchased Salesforce Marketing Cloud. Second, Salesforce’s pricing model shifted to a usage-based consumption model for the first time.

Importantly, because of the pricing structure difference between the old customer data platform SKU and the new Data Cloud SKU, some of the newer Salesforce Data Cloud features and functionalities will not be available on the old customer data platform SKU. To access the newer functionality in full, upgrading to the newer Data Cloud SKU is required.

There are some Data Cloud features that will be limited or not available on the old SKU. Throughout this book, the features and functionalities of Salesforce Data Cloud will be described for the most current SKU. When known and wherever possible, any limitations of the old SKU will be called out.

Where Salesforce Data Cloud Fits in the Salesforce Tech Stack

As we’ll see in later chapters, the Salesforce Data Cloud application is accessible as an application in the Salesforce core platform. Even though users access the Data Cloud application after logging in to the Salesforce core platform, the data ingested by Data Cloud is actually stored within an off-core data lake managed by Salesforce (Figure 1-3). The Salesforce off-core data lake storage is discussed in detail in Chapter 2.

Figure 1-3. Salesforce Data Cloud high-level blueprint example

Salesforce Data Cloud is most often used in conjunction with Salesforce CRM core applications, including the Sales Cloud and Service Cloud objects. There also exist industry cloud use cases where the more traditional Sales Cloud and Service Cloud are replaced with specialized industry clouds with metadata and workflows more relevant to specific industries. Examples include Salesforce Health Cloud and Financial Services Cloud.

Data Cloud is billed separately from Salesforce CRM and industry cloud licenses. Tableau, Marketing Cloud Engagement, Marketing Cloud Account Engagement, Marketing Cloud Personalization, B2C Commerce Cloud, Loyalty Management Cloud, and Marketing Cloud Growth licenses are additional licenses that need to be obtained if your organization plans to make use of those platforms and tools.

If your organization doesn’t plan on using platforms like Tableau or Marketing Cloud, then you’ll not need to purchase those licenses to access Salesforce Data Cloud. Reach out to your Salesforce account representative or your Salesforce implementation partner for more in-depth discussion of which Salesforce licenses would be needed for your specific use cases.

Figure 1-3 highlights some of the basic components of a typical Data Cloud implementation. Marketing Cloud Engagement and Tableau are included in the high-level blueprint example, but they’re not required. We’ll see in later chapters how Salesforce Data Cloud actually works as we take deep dives into more of the possible inputs and outputs of the platform. Just to give you an idea now of some of the various data inputs we’ll be discussing, here is a list of common Data Cloud source inputs:

• Salesforce CRM, which could include the traditional Salesforce Sales and Service Cloud, or it could include Health Cloud, Education Cloud, Financial Services Cloud, Nonprofit Cloud, or other Salesforce industry-specific clouds
• Salesforce Loyalty Management Cloud
• Salesforce B2C Commerce Cloud
• Omnichannel Inventory Cloud
• Salesforce Marketing Cloud Engagement (previously ExactTarget)
• Salesforce Marketing Cloud Account Engagement (previously Pardot)
• Salesforce Marketing Cloud Growth Edition
• Salesforce Marketing Cloud Personalization (previously Interaction Studio)
• External cloud storage such as Amazon S3, Microsoft Azure Storage, Google Cloud Storage (GCS), or PostgreSQL
• Bidirectional data sharing with data platforms like Snowflake, Google BigQuery, and Amazon Redshift
• External original sources such as Adobe Campaign, Attentive, Emarsys, Epsilon, Oracle Responsys, Vibes, Google Ads, Meta Ads, and more

Over the last nearly 25 years, Salesforce has built a mature product with many different types of solution offerings, some of which are quite complex. This book will go into Salesforce Data Cloud. If you find that you have gaps in your Salesforce knowledge or you need to round out your knowledge in other areas, you can leverage free training at Salesforce Trailhead, engage with the Trailblazer Community, or read the Practical Salesforce Architecture book by Paul McCollum (O’Reilly, 2023). If you are employed by a Salesforce partner, you can access the Partner Learning Camp training materials. If you are a military member, veteran, or spouse, you can also access Salesforce Military for free training opportunities and support.

Today’s Salesforce Data Cloud can be a part of the solution for many different use cases, not just for Marketing Cloud. However, given the origin of Data Cloud, it’s not surprising that many Data Cloud implementations thus far have addressed use cases aimed at solving marketers’ problems. Throughout this book, we’ll highlight the different use cases that can be addressed by using this Salesforce Data Cloud while acknowledging that today’s use cases are still heavily focused on solving some important marketing problems.

Where the Customer Data Platform Fits in the Martech Stack

A marketing technology stack (Martech stack) is a collection of specialized software solutions that are used by marketers exclusively for marketing. It also includes many multipurpose software systems or platforms supporting critical business objectives. One such example is an organization’s CRM software.

An organization’s CRM solution is frequently used by teams outside of marketing, including customer service, sales, operations, and finance. Each of these teams may retain unique information about a customer, and if the organization’s teams share some components of the tech stack, like the CRM, they can centralize customer information. This allows for a more complete view of the customer by the organization.

This is important because every interaction with a customer or potential customer impacts an organization’s marketing efforts. Because of this, the modern definition of who uses the Martech stack has expanded beyond marketing alone and now includes customer service agents, billing specialists, and data scientists. We’ll see this is especially true of CDPs, which were developed to solve marketing-specific problems but now support many other types of use cases like fraud detection and health care patient outcomes.

Today’s Modern Martech Stack

The Martech stack humbly began as a simple customer list entered into a digital database. It then blossomed with the advent and advancement of the internet as a global marketing tool. Technology continues to evolve, and new tools and systems are being added to the stack in an effort to keep pace with the changes. Figure 1-4 includes eight of the most common components of a modern Martech stack. One of the most recent additions to the Martech stack is the CDP.

Figure 1-4. Today’s modern Martech stack

CDPs have been around for a little more than a decade and have been embraced by enterprises that need to centrally manage their customer data to remain in compliance with emerging privacy regulations. Some CDPs include modern features like customer journey orchestration, look-alike modeling, and marketing automation functionality. Many CDPs even come standard with or support Generative and Predictive AI capabilities. CDPs will likely not solve all your use cases, but they can serve as a centralized source of your unified customer data to inform the rest of your technology stack.

The Future of the Martech Stack

Marketers have many powerful new technologies at their disposal to leverage for the future. Virtual reality and augmented reality are exciting new ways to market to customers, and near real-time data capabilities now allow marketers to observe customer activity without having to wait hours or days to assemble reports.

Low-code/no-code ML and AI capabilities are options from a variety of SaaS companies. These advanced analytics capabilities can help in many ways. For one thing, they can provide more insights into omnichannel marketing efforts and the impact of those multichannels on the overall customer journey. Even traditional marketing channels have gotten a technology makeover. A quick response (QR) code can be added to traditional print marketing collateral, and fully digitized billboards are no longer a rarity.

Your initial thoughts might be that these technologically advanced tools surely have allowed marketers to convey more relevant, effective, and timely messaging to customers. In reality, that’s the exception rather than the rule. The primary reasons why are the customer data problem and the excessive exploitation of technology, which together have obstructed the marketing industry from achieving the nirvana of right customer, right message, right time. We’ll cover this in detail later on.

Establishing a complete 360-degree view of a customer hasn’t been a priority for most organizations because they’ve had cheaper alternatives that are effective. Television ads, radio advertising, and print advertising are relatively expensive when compared to digital marketing alternatives such as social media, email marketing, and search engine optimization (SEO). As technology becomes less expensive, the cost of digital marketing gets even cheaper. Thus, marketers have more of an incentive to overload target audiences with messages within every possible channel rather than to spend money building a 360-degree view of each customer.

As we’ll see, marketers’ excessive exploitation of technology has caused an uproar. Consumers have felt abused and that their rights to privacy have been violated. They have begun reporting spam more frequently, unsubscribing to email lists, blocking digital cookies and tracking, and disabling notifications. They have also responded by using secondary email addresses and/or temporary disposable addresses, which further exacerbates the customer data problem. As a result, governments have intervened with regulations enforcing rights to privacy.

The good news is that we have options available to solve these two problems. Before we discuss them, let’s dive just a little deeper into the problems so we can understand and better appreciate the urgency with which we need to act.

The Customer Data Problem

Organizations delight customers when they are able to solve their problems quickly and make their customers’ experiences more personal, valuable, and memorable. However, it’s difficult, if not impossible, for an organization to accomplish these things when it doesn’t have a coherent, complete view of its customer.

Customer data problems are what make it impossible to get a complete view of the customer. They mainly occur because of separate data silos and the proliferation of several cross-devices per individual. Thus, marketers either fail to recognize an individual as someone known or don’t have a complete picture of the customer because they can’t match up the existing data pieces about the customer. In clarification, let’s consider the two main customer data types: known and unknown.

Known Customer Data

Known customer data is often composed of personally identifiable information (PII), such as an email address the customer willingly provided when they completed a purchase or signed up for newsletters and loyalty programs. This first-party known data is incredibly valuable; it’s real information about a real person received with consent.

Problems arise, though, when these data points exist in separate silos. Sales and service departments, commerce websites, and marketing web forms will likely store known customer data in different formats and in different locations. In an effort to stitch together PII and other known customer data for each of these different business units, brands, or regions, the original data from each source may be replicated many times, across the organization.

Then, when the source data gets updated in one place, the copies existing elsewhere rarely get updated. Imagine a scenario where one customer recently moved and updated their phone number and mailing address with the sales department and those details do not get updated with the customer service department. Thus, when the customer calls a different department and provides their new phone number to an agent, they do not appear as a known customer, and all the rich history about the customer is not available to the agent.

This is further complicated because a single customer can have different name variations like “Robert” and “Bob,” along with multiple email addresses and phone numbers. These types of variations can occur within one platform within an organization, such as a CRM shared by different internal departments, and they can also occur within third-party platforms connected to the organization.

The consequences of having separate data silos often get in the way of providing a delightful experience across touch points and time. Yet it’s important to have an accurate and complete view of a known customer because marketing efforts to delight an established customer are considerably less costly than acquiring a new customer.

That is one reason why existing data about known customers forms the backbone of any first-party data strategy. A CDP excels at stitching together known customer data from separate data silos, and we discuss using a CDP to build a first-party data strategy in the next section.

Unknown Audience Data

Unknown audiences are established customers or potential customers who are engaging with the organization in some way but whose current engagement activity doesn’t result in unique identifiers that can be assigned specifically to individuals in the organization’s system. Each customer may have visited a website or clicked on an ad, for example, but not made a purchase at that moment on that particular device.

Perhaps they took up their research later in the day on a different device that created another unique identifier that can’t be matched to an individual. All these unique identifiers exist in isolation unless and until the individual becomes known to us on that device. At that point, identity resolution for unknown audiences can occur by associating pseudonymous unknown identifiers with known data.

Putting the Pieces Together

Solving the customer data problem that results from having separate data silos requires a single, unifying strategy involving identity resolution, which can be provided by a CDP. A CDP is a relatively new addition to the Martech stack and should not be confused with a data management platform (DMP). A DMP collects and organizes audience data from various sources, including online, offline, and mobile sources; the organized data in a DMP can then be used for segmentation and activation.

Both CDPs and DMPs allow organizations to examine aggregated data to better understand how customers as a whole move through the sales funnel. Both collect similar types of anonymous web and digital data, but a CDP connects an anonymous visitor with an established consumer’s unified profile once that visitor becomes known. CDPs primarily use first-party data and some second-party data, whereas DMPs mostly use third-party data with some second-party data.

DMPs rely heavily on cookie technology to identify behaviors and have frequently been used when marketers need third-party data for short-term customer leads and conversion. CDPs, on the other hand, are used to bring together siloed sets of individual data (Figure 1-5). For that reason, you’ll want to work with a CDP if you need long-term customer engagement that requires first-party data.

Figure 1-5. Piecing together a known unified profile and unknown audience data

Marketers have continued to rely on DMPs, rather than developing a first-party data strategy, because of the continued reliance on relatively inexpensive cookie technology. Many marketers still rely on digital marketing cookies as a major part of their customer data strategy. As we’ll learn in the next section, there have been a lot of arguments against using third-party cookies. As a result, the consensus is against their use, so there’s no better time than now for your organization to review the use of digital marketing cookies. So, what exactly are digital marketing cookies?

Digital Marketing Cookies

Websites create digital marketing cookies, which are small JavaScript text files that collect and store user activity, to track a user’s behavior. Cookies contain a unique identifier that allows a website to identify the individual when they return to the website. Cookies can include information like usernames and passwords, making it easier to log in to various sites. Cookies can also contain information such as shopping activity and which items were left in a digital shopping cart.

There are different types of cookies. Most are either first-party cookies, which work only on a single domain, or third-party cookies, which track users across multiple domains.

First-, Second-, and Third-Party Cookies

First-party cookies aren’t shared with other websites or advertising partners. Instead, they are created and used only in a single domain. First-party cookie data is important because it contains information such as language settings and personal identifiers that can improve the user experience and provide a more personalized service. It’s possible to delete first-party cookies at any time, but if you do so, you’ll need to log back in to any websites you visit.

Sometimes, the website a customer visits will ask them to accept a cookie to proceed, and in some cases, the website visitor might not be able to use key features of the website if they don’t accept. When prompted to accept cookies, visitors are given options on which cookies to accept if more than one type of cookie is being captured. Because first-party cookies are designed to improve the user experience of a website and are limited to only a single domain, most people generally trust and accept first-party cookies.

Third-party cookies, on the other hand, are created in one domain but shared across all the third-party domains that use the same tracking code. The primary function of a third-party cookie is to display advertisements as a result of the information gathered by tracking a user’s activity.

Most web browsers automatically accept first-party cookies, but third-party cookies, which can also be cleared from a web browser at any time, are already being blocked by some browsers such as Safari and Mozilla Firefox. Google, the leading internet browser worldwide, plans to completely deprecate all third-party cookies in the latter half of 2024 as described in the Privacy Sandbox for the Web initiative. This initiative, led by Google but placed on hold by British regulators (see the following subsection), will, when implemented, phase out third-party cookies and help limit other forms of tracking by restricting the amount of information sites can access.

Privacy concerns and related regulatory requirements caused by the excessive exploitation of technology are at the root of why many web browsers are beginning to block third-party cookies. As you would expect, this presents challenges for advertisers.

Second-party cookies are less prevalent, but it’s expected they’ll become more popular as third-party cookies cease to exist. Second-party cookies are created in one domain and only used in that domain, but the first-party data collected is then shared by the website owner with its trusted partners.

The Future of Cookies

We’ve already seen changes in how cookies are being used. In early 2020, most websites began asking visitors to accept cookies. This change was prompted, in part, by user privacy concerns that resulted in the California Consumer Privacy Act (CCPA) and the European Union’s (EU’s) General Data Protection Regulation Act (GDPR).

Google planned to fully deprecate third-party cookies by the end of 2024. However, in April 2024, the United Kingdom’s Competition and Markets Authority (CMA) ordered Google to halt its deprecation of third-party cookies temporarily amid anticompetitive concerns. In July 2024, Google announced a new path for Privacy Sandbox on the web that may delay the deprecation of third-party cookies indefinitely. Instead of completely deprecating third-party cookies, Google has proposed a different way of achieving a more private web experience. Discussions are ongoing with regulators on what the path forward will be.

In addition to Google’s efforts to create a more private web experience for individuals Apple has introduced Intelligent Tracking Prevention (ITP) 2.0, which makes it impossible for third-party cookies to be used for cross-site tracking. Apple iOS recent updates have also given users the ability to manage their own data sharing on their apps. Both of these changes make better protections possible and are a win for consumer privacy, but they represent a new challenge for marketers.

The good news here is that the death of third-party cookies as we’ve known them will likely force marketers to develop a sound first-party data strategy and be more intentional in building and engaging with audiences. Instead of focusing primarily on cheap digital advertising to drive sales, marketers will need to focus more on conversion rate optimization and creating better customer experiences. Building long-term relationships with customers and providing more personalized marketing could also help organizations build more customer loyalty and increase customer lifetime value.

Driven by data privacy concerns and regulation changes, cheap and easy access to third-party data is on its way out. It’s time for organizations to consider alternative marketing strategies such as adopting a first-party data strategy.

Building a First-Party Data Strategy

A first-party data strategy involves collecting customer data and using it to improve marketing efforts to build stronger customer relationships through personalization and creating more customer value. Building a first-party data strategy has always been important to marketers but is even more so now. There’s a new sense of urgency because of the deprecation of third-party cookies and stricter data privacy regulations and compliance requirements. As a result, marketers are exploring new and better ways to provide the best digital experiences by building more personalized relationships with customers and potential customers.

A CDP is at the center of building a first-party data strategy, and the focus of this book will be to explore the Salesforce Data Cloud in much detail. You may never need more than the Salesforce Data Cloud to build your first-party data strategy, but if you do need more, there are ways to go beyond your successful implementation of Salesforce Data Cloud to extend your first-party data strategy.

Extending the First-Party Data Strategy

First-party data that arises from a consumer’s direct interaction with the organization certainly helps marketers understand quite a bit about their customers, but more information is often needed to get a complete picture of each customer. Second- and third-party data help fill in the gaps.

A CDP is at the heart of your first-party data strategy and brings together first-, second-, and third-party customer data to build a single customer view. A data clean room can be an extension of an organization’s first-party data strategy by providing access to the very third-party data being taken away by privacy laws and the end of cookies. When used together, a CDP and a data clean room provide opportunities for organizations to process and analyze data more efficiently while still managing data in a compliant way.

Data clean room defined

The purpose of a data clean room is to assist organizations in processing and analyzing aggregated data that comes from trusted partners. In essence, a data clean room is built to create a secure and anonymous private data exchange for the parties involved. None of the parties have direct access to the other’s data, but the results of data matches allow all the partners to enrich their own data.

Marketers can use data clean rooms for a variety of reasons. Using aggregated data, they can better determine customer lifetime value and understand how customers interact with certain brands, and they can potentially identify look-alike audiences and build new segments. Data clean rooms can also be useful for finding wasted ad spending and avoiding duplicated effort across channels.

Types of data clean rooms

The most common data clean rooms are walled gardens from ad media publishers like Google Ads Data Hub and Amazon Marketing Cloud. With these types of data clean rooms, you’re able to analyze your ads’ performance from the individual publisher’s platform. However, analyzing performance from a cross-platform perspective is not possible, and there may also be restrictions on how you can use the data.

Some custom-built data clean rooms are offered by advertising technology (Adtech) vendors. It’s recommended that you perform your due diligence before engaging with a custom-made data clean room to make sure it has the requisite security you expect and that the data will be appropriately pseudonymized to safeguard the privacy of your customer.

Private data clean rooms are commonly built by brands and content owners, and several partners’ datasets can be shared to create an omnichannel view of the customer. Walmart Connect, NBCUniversal One Platform, and Disney data clean rooms are examples of private data clean rooms built on the Snowflake platform. Because these data clean rooms are cloud agnostic, they can connect to and function with any cloud environment an advertiser brand might use.

Data Clean Rooms and Customer Data Platforms Working Together

It’s possible for an organization to connect its CDP to a data clean room to allow its first-party data to be anonymized and analyzed alongside third-party sources. Depending on the type of data clean room used, marketers could create segments and build targeted audiences to be shared with the organization’s CDP where it can be sent to connected marketing platforms for activation.

Extending the first-party data strategy with data clean rooms is only made possible once you’ve unified and harmonized your individual customer data. For that, you’ll need to acquire a CDP.

Customer Data Platform Acquisition Approaches

Choosing a CDP acquisition approach for your organization is an important decision because CDP implementations can be very costly in terms of both time and money. If your organization has already selected Salesforce Data Cloud, then you’re ready for Chapter 2.

However, if your organization is still evaluating CDP products, you’re most likely deciding between a composable CDP and a CDP suite. If so, this section will provide you with some general guidelines and helpful suggestions for selecting the right CDP approach.

Build, Buy, or Compose?

There are three main approaches to acquiring a CDP. At one extreme, a CDP can be built completely from scratch, generally at considerable cost in terms of both time and money. At the other end of the spectrum, buying a CDP suite is most often the quickest way to get up and running on a CDP. Somewhere in the middle is the third option: constructing a composable CDP solution using Lego-style pieces of technology.

A number of factors will likely be considered when evaluating the approaches to acquiring a CDP, and each organization has a unique process for making these types of decisions. That said, there are a few general guidelines for selecting the right CDP that are applicable to most organizations.

Narrowing the Focus

It may be possible to quickly rule out at least one and perhaps more of the CDP acquisition types by navigating the decision-making flowchart provided in Figure 1-6. You can start by asking if your organization has the resources with the appropriate experience and expertise to build enterprise-level applications from scratch.

Figure 1-6. Determining whether to build, buy, or compose a CDP

Building a CDP from scratch takes a lot of time and money, so you won’t find it to be a cost-saving approach. There are few reasons you’d want to ever consider building a CDP from scratch; it really is an intensive process. One reason to consider it might be if you need a unique CDP application that will give you a competitive advantage.

Composable Customer Data Platforms versus a Customer Data Platform Suite

It’s much more likely that your organization would either buy or compose a CDP. To realistically consider the composable approach, your organization needs to have resources with sufficient technical skill sets to maintain the CDP after implementation. The more individual CDP components your organization uses to build out the CDP solution, the more varied skill sets will be required.

Each organization will likely have a unique set of requirements for its CDP, but there are five common components of most CDPs. Figure 1-7 defines the common components of the CDP system, but it’s also important to consider where your data sources exist and whether the data will have to leave your secure system as part of fulfilling the CDP requirements.

Figure 1-7. Common CDP components

Your development team will also need to possess the necessary CDP domain expertise to know what components to select and how to build a composable CDP. Otherwise, you’ll want to consider buying a CDP solution.

For many organizations, the situation is usually not so clear-cut that they can quickly know whether the preferred acquisition path is to build or to buy. Most often, a more detailed analysis will need to be undertaken to determine just how much, if any, of the existing systems and platforms can be used to meet an organization’s CDP requirements. In the flowchart (Figure 1-6), the central question is “Are few changes needed for the existing system to meet CDP requirements?” If the current system meets most of the CDP requirements and is not a custom-built solution, then a composable approach may be worth exploring.

Other Cost and Performance Considerations

In addition to evaluating requirement gaps, you’ll likely want to consider cost, efficiency, maintainability, and scalability. The various pieces needed to complete a composable CDP solution might be less costly than buying a full CDP suite, but the cost could end up being excessive if there are too many components to add, they are costly to integrate with the current system, or overhead costs increase significantly. Overhead increases because more skill set dependencies arise when you add several new components, and increased maintenance is needed when more connectors exist. There are also more vendors to manage and interact with. Scalability is more challenging with composable CDPs because all the pieces need to scale individually as well as together.

Buying a CDP solution means you’ll always have to pay for licensing. However, buying a CDP often results in a lower total cost of ownership and accelerated time to value. Fewer unique skill sets are needed because a CDP suite frequently includes pre-built, low-code/no-code options and because platform system maintenance is handled by the vendor. Acquiring a CDP system by buying it generally incurs a much lower risk than building or composing one because the vendor can demonstrate the capabilities of a platform that is built and ready to be used. Buying a CDP suite means, though, that you are reliant on the vendor to prioritize new feature requests and maintenance needs. Figure 1-8 summarizes some of the main differences among the approaches.

Figure 1-8. CDP acquisition approaches

Buying a CDP is often a great approach, but doing so means you’ll be relying on the vendor to provide all the expertise and support. Thus, a very important consideration when deciding from which specific vendor to buy a CDP solution is evaluating how likely it is that the vendor will continue to invest in its CDP platform in the future.

Because this is a hands-on book about Salesforce Data Cloud, we’ll assume that your organization has already decided to implement Salesforce Data Cloud or that it is seriously considering Data Cloud as its CDP of choice. Therefore, going forward, we’ll be diving only into Salesforce Data Cloud as the CDP solution.

Summary

In this chapter, we discovered why now is the time marketers should be implementing a CDP to solve the customer data problem. Of the three CDP acquisition approaches, the “Buy” approach is often selected to help shorten the time to value.

One of the best known CDPs available to purchase is Salesforce Data Cloud, which is the focus of this book. In this chapter, we learned about the evolution of Salesforce Data Cloud, and in the next chapter, we’ll take a deep dive into the foundations of the Salesforce Data Cloud platform.