How to Decide if You Should Build vs. Buy a CDP

With the deprecation of the third-party cookie, the increased scrutiny on tech giants like Facebook around questions of customer privacy, and new limitations on brands’ abilities to track customers’ browsing behavior across the internet, the pressure is building for brands and publishers to create first-party relationships with their customers.

Customer data platforms (CDPs) have risen in importance as a result, as they offer a promise to create a unified view of the customer across all touchpoints to help a brand gain a real understanding of who the customer is, what their preferences are and what their intent may be. Having the ability to share this view across the organization’s marketing ecosystem makes it possible to provide consistent experiences across the customer’s journey with the brand.

To Buy or Not to Buy, That Is the CDP Question

When it comes to CDPs, organizations have to decide whether they should buy a pre-packaged CDP or build their own. But the choice between build and buy isn’t as straightforward as the phrase may imply, as it relies on a myriad of factors. 

Let’s start by defining what buying a CDP should mean. When you buy any software product, the hope is that you can significantly reduce the time to value, the total cost of ownership and stay ahead of the competition with continuous innovation. You also hope that your purchase significantly reduces the amount of effort you put into writing custom code and supporting the software and that the vendor provides pre-built connectors to common applications that you’re already using. 

We all know that buying doesn’t guarantee any of these things.

Related Article: Is That New CDP Truly a Customer Data Platform?

Build a CDP Yourself?

I’ve met with various digital and marketing leaders who are grappling with an internal push to build their own CDP. A very common argument I hear is, “We have a very unique tech stack with a lot of custom/legacy applications and it would be very difficult to integrate an external vendor application into our world.”  They often go on to say, “We already have a data warehouse (Snowflake, Amazon Redshift, Google BigQuery, etc.) which we have already integrated into our custom stack, so creating a unified customer profile is not that much of a leap from where we are today. So why not build it ourselves?”

Every mid- to large-enterprise has a data warehouse. A data warehouse organizes, processes and transforms massive amounts of data for advanced querying and analytics in a structured database environment. Some organizations even have a data lake to hold on to data in its original format before it is routed to a data warehouse for further processing/querying. As businesses cope with ever-growing data volumes, cloud-based data lakes and warehouses with scalable infrastructures are becoming increasingly common.

But before we can determine if extending your data warehouse to create a unified customer profile is a viable option, we need to break down what a CDP needs to do beyond what a data warehouse can do for you.

You would need to build out the following components yourself if you were to take on the challenge of building this solution in-house:

• The ability to unify customer data from various touch points such as web, mobile, email, CRMs, in varying structures and formats into a persistent user profile.
• A unified, real-time customer profile that is accessible through APIs to all other applications within your marketing technology stack. This needs a data repository that can scale to accommodate millions of known and anonymous profiles, update with user-activity in near real-time and provide a sub-second response when queried by various touch points in real-time. To be very clear, data warehouses do not answer real-time queries from consumer-facing applications.
• The ability to segment customers based on their demographic, psychographic and behavioral characteristics, and create lists that can be shared with your marketing automation platforms for email, SMS and social media channels.
• Pre-built integrations with email service providers, social media and paid advertising platforms, analytics and BI and marketing automation platforms.
• Scalable data infrastructure capable of holding and querying billions of rows of user engagement data and generating insights, customer traits and behavioral scores
• Personalization Engine (Optional) — Instructions on what the user should see based on their traits, intent and context on every channel via real-time APIs.

Sounds ominous? I would say! I’m not saying you can’t build these capabilities yourself — with enough time and money, anything is possible. However, it’s helpful to keep these things in mind. There is one more reason organizations may want to build rather than buy. Many organizations see data as a strategic asset and may feel uncomfortable giving control of their data to an external vendor. This is a valid concern, because vendors like Adobe and Google hold on to the raw behavioral data from their respective analytics offerings and you have to pay a hefty price to get access to it. Without ensuring that you have unfettered and economically viable access to your own customer data, you should never sign up with a CDP vendor.

Related Article: Lessons Learned From CDP Implementations

Hard Cost, Opportunity Cost and Time to Market

This should be a straightforward one. With the current economic landscape, do you have millions of dollars sitting around to invest in a large-scale build initiative? If you do, do you have the time it will take to perform such a complex initiative?

If you’re like most organizations, you are scrambling to figure out how to pivot before your organization and your industry is disrupted entirely. Waiting around for years before you roll out that new digital product or a novel way for your customers, employees and partners to interact with your organization is not an option.

Can You Support What You Are Building?

At some point, you have to decide what business you are in. Should your focus be on providing a service or product to your customer or are you in the business of supporting, patching, and upgrading software applications, customizing legacy software, or building digital platforms from scratch?

What if We Just Buy From One of the Popular Marketing Clouds?

Adobe, Salesforce, Microsoft and many of the other tech behemoths have quickly repackaged or rebuilt their solutions to include a Customer Data Platform at the forefront of their offerings. They claim that everything works seamlessly with their existing suite of products and if you are already using their software for content management, targeting and personalization, digital experience management, marketing automation and more, then you need not look further than buying their CDP. 

The argument would make logical sense if it was actually true.

When you purchase software products from large vendors, you are not “buying.” You are committing to an ecosystem of often disjointed applications with no guarantee that the various applications within the ecosystem connect seamlessly with each other, let alone play nicely with the thousands of marketing applications their customers may already be using. You will absolutely need to write a bunch of custom code (that the vendor won’t support) to meet your unique business needs.

Related Article: Understanding the Myths and Realities of a True CDP

The Role of Implementation Partners in Making a Decision

Large organizations often depend on large System Integrators (SI) such as Capgemini, Sapient, Accenture, Deloitte, etc to help them make (or justify) a decision because they have worked with organizations like yours on this same problem. But remember, SIs rely on billable hours for their livelihood and can’t survive unless there is large amounts of work doing custom coding and integration work. SIs also form lucrative partnerships with bigger vendors, which can lead them to recommend some combination of the following two options:

1. Purchase a CDP from a large software vendor -— This would guarantee the SI a steady flow of cash from up front implementation fees, ongoing customizations, support, managed services and so on.
2. Building a CDP from scratch — The SI would stitch together various open-source and cloud technologies, which obviously demands a monstrous effort including strategy, technical design, implementation, not to mention ongoing support, change requests and so on. In this case, you are paying them to build a ‘software product,’ which they are never set up to build, launch and support — if they were, they wouldn’t be in the services business.

Decisions often get made in large organizations based on what is considered safe: large software vendors, large SIs that you won’t get punished for bringing into your organization in case there is failure.

Related Article: 10 Lessons From Hertz’s $32M Web Design Lawsuit Against Accenture

Agile, Modern, Zero-Code Platforms

As mentioned above, a software purchase turns into a build project because of the custom code required to make the software meet your needs. A different class of platforms can significantly reduce the amount of custom code your team or your implementation partners have to write and support. They allow you to achieve a high degree of customization, while affording you the following benefits:

1. You’re not locked into an ecosystem that makes it impossible to keep up with innovations in the martech landscape.
2. These configurations are code-free or low-code configurations which means they are supported by the software vendor. There is no need for support clauses in your contract with your system integrator that are simply a path to more change requests.

Some CDPs on the market belong to this family of SaaS platforms, but they’re usually in niche industries and less mainstream than the usual suspects. Your implementation partners are highly unlikely to recommend going with a vendor who would charge a reasonable subscription fee with a zero-code, configuration-only deployment model because there is nothing in it for them. The choice of buying from a large software suite puts your solution at 60% buy and 40% build. If you choose to build entirely from scratch (a monstrous effort), depending on how intelligently you architect your platform, you’re sitting at 70% build. Zero-code platforms can reduce your time to market to a fraction of traditional methods.

Fail Fast

CDPs that offer a more agile, modern architecture with a zero-code deployment model allow you to test things out quickly. Instead of wasting years on an implementation and then failing, you want to determine the chance of success in a few weeks. You should be asking your vendor to give you a trial period of say 8-12 weeks and use this time to see if you can launch a few key use cases. After all, if you can’t launch something in a few weeks, you’re not buying, you’re building. I’m not saying there’s no risk going with a smaller, more agile software vendor, but I am saying — if you’re going to fail, you should fail fast and pivot as quickly as you can.