Is it better to build or buy a CDP?

Is it better to build or buy a CDP?

Is it better to build or buy a CDP?

We’ll cut right to the heart of it: Building your own customer data platform (CDP) is feasible. But building a CDP that functions like your users expect it to and that translates into additional revenue is another thing entirely.

Often, building your own CDP makes the most sense when you already have a team accustomed to building, launching, supporting, and continuously delivering software products, and their time is relatively inexpensive. The CDP they'd have to build would have to store hundreds of millions of records. It’d have to scale with your business, improve with time, be easy enough for non-technical users to enjoy, and actually, as the end result, make your data actionable. This is a tall order.

On the other hand, buying a CDP comes with its costs, including licenses, systems integrators (SIs), and iPaaS pipeline services. But baked into those costs are full-time product, design, and support organisations incentivised to improve the service continuously.

Both routes are feasible and have their merits. Many companies try one, then try the other. In this article, we share questions we believe you’ll want to answer fully before you decide, in hopes of helping you decide only once.

And of course, a note on our rather clear conflict of interest, as a software firm that offers a CDP: We do recognise some bias. At the same time, we feel qualified to comment on the complexities of CDP construction. After all, we’ve built one.

First, the requirements

A CDP is a non-trivial innovation on a database, and much more than simply altering a data lake such as Amazon S3. Data lakes limit your ability to query, extract, and load into other systems, and tend to perform it at a speed and cost that’s impractical for marketing uses. CDPs, on the other hand, make the data available in marketing systems in more or less real-time.

Features you’ll want to consider:

- Data pipelines to pull in data: from the CRM, product, web, email, marketing, in-app messaging, advertising, and partners.

- A user interface that’s accessible to non-experts: that means lots of user research, user testing, UX design, and periodic refreshes.

- A highly scalable database infrastructure: that can accommodate hundreds of millions of known and anonymous profiles, update them with user activity in real-time, and respond to queries as close to instantly as possible.

- Marketing integrations: to email, automation, in-app messaging, SMS, social, and possibly the product itself.

- An adaptive roadmap: or, at the very least, a systems integrator (SI) such as Accenture, Deloitte, or Sapient to serve as a guide.

- Consent management, security, compliance, and legal considerations

Questions you’ll need to answer

1. Who will maintain our new CDP?

Useful software improves with time. For your CDP to remain relevant, someone must update it. Who on your team can own that function, and how much time can they dedicate?

I have always found it interesting that one of the most common objections you hear to buying a CDP—“We have too many legacy systems”—is the long-term result of deciding to build things in-house. Today’s legacy internal systems are often yesterday’s custom-coded solutions. As anyone familiar with such systems can attest, they rarely keep up with the times without significant upkeep.

For a CDP to be a successful, functional piece of software, it needs a lot more than just engineers. A CDP software like mediarithmics is built by product managers and product marketing managers who decompose user needs into a plan, and keep a pulse on that market, suggest changes, respond, and adapt. They pass their work on to UI and UX designers who guide the engineers. Without that full team, engineers, no matter how talented, tend to build things that feel as if they’re designed for engineers.

Plus, if maintenance isn’t anyone’s priority, maintenance costs will compound. According to the IBM Systems Sciences Institute, a bug that isn’t caught until the maintenance phase is 100x more costly to fix. Systems that are a low priority will fall behind in functionality.

Image credit: Databand

2. Who will secure it and ensure its compliance?

Any CDP you build that stores, moves, and processes customer data should aim to comply with standards like ISO 27001 and the strictures of GDPR. Who on the team will participate in the build to ensure those requirements are met, verify it continuously, and prepare for audits?

Beyond that, the “build” decision rarely means building from scratch. Smart engineers will likely devise a plan that builds on perhaps as much as 60% of existing services. If those services and microservices are not secure, and if—like many—they involve open source software, they can create serious security (and thus compliance) gaps.

3. Who will provide the integrations?

Integrations are not easy, which is why the integration provider as a service (iPaaS) industry is expected to quintuple from $2.4B USD today to $10.3B five years from now. The data pipelines you’ll need both to pull data from systems and to push customer data securely to activation systems like email or advertising are expensive to build. They also require updates as frequently as the integrated systems update their APIs and connections.

4. Who will conduct user testing and implement interface improvements?

One of the great advantages of buying into an existing CDP platform is the interface. These companies tend to employ user experience and user interface design teams to verify that what was planned and built actually works. This is a critical feedback loop that custom builds often miss. Systems that aren’t usable tend not to be adopted, and the change management needed to impose a new system on a company that feels resistant to change is a challenge in and of itself.

5. Who will support it?

When something goes wrong, who can the team call? If an engineering team that built the product wants to resume their work on other projects, who do they hand this off to? How do they prioritize support requests for the system? Who is ultimately responsible if bugs cause real damage, like a mistaken mass email that causes a material fallout?

6. Who will continue to innovate?

What many companies are buying into when they purchase licenses to software as a service (SaaS) platforms such as a CDP is the promise of innovation. They may accept that not all the features exist, but trust that one day, they will. And if those teams are heavily involved and responsive to that provider’s product team, they can shape its evolution.

What’s more, real innovation happens when you have one team supporting many use cases, as with a CDP platform that has many customers. One internal team building for one internal client, by contrast, has a natural barrier to innovation.

7. How quickly can you verify it will work?

It’s worth investigating how quickly your in-house engineering team can produce the CDP. If it’s more than a year, it’s worth considering that a pre-built CDP from a vendor has already been heavily user-tested and can be deployed in 2-6 months. Let’s say both options didn’t work. Which amount of time would you rather wait to realize it hadn’t worked? And where would you rather the blame lie—internally or externally?

8. How will it interact with other CDPs?

Private gardens are on the rise and no CDP can expect to remain an island. If you build your own CDP, how will it interact with others? And how will you overcome the challenge of securely sharing data without a neutral third party (a mandatory requirement) to create data alliances? More and more companies are creating data alliances with competitors. A partner-provided CDP helps make that handoff safe and amicable.

Build versus buy—making your decision

Part of what is so economical about purchasing software subscriptions is, as we have explored, the innovation. Sometimes that innovation helps a vendor leap far past the existing technology to do something entirely novel. Like, for example, mediarithmics, which is both a CDP and DMP. It’s a single source of customer data truth and a way to activate that data, eliminating the need for two systems, and all the messy connections therein. And even more than that, the reason mediarithmics can be both is because it’s actually a backbone to build upon. Not only does it feature a CDP and DMP, but you can build whatever else—a CRM, MDM, SCV, and so on.

Though it’s possible that an internal team could have similar market-leading ideas like combining a CDP and DMP, it is, in practice, uncommon.

There’s plenty to consider when deciding whether to build or buy. It is largely a question of expertise and outsourcing. Would you rather invest heavily in the teams and talent to build a software development, design, and support function internally, with no guarantee of success, or pay a premium to buy into such a function that already exists?

For many, that answer is quite clear. If you can have it all in less time and less risk (and possibly, have a backbone to build upon), it’s more economical to buy.

A note: Did we miss anything in this article? We’d love your thoughts and ideas. Please get in touch at info@mediarithmics.com.