This exploration typically leads to an organization deciding to invest in a platform that makes it possible to join their internal data silos together to gather data from various business angles, create one single unified profile for each unique customer, and then take action by personalizing customer communication across a variety of channels in real-time.

Traditionally, the preferred approach to such an investment has been to build custom applications in-house over concerns that a third-party solution won’t meet their unique requirements, security, or connect with existing systems. But in the race to stay ahead of digital innovation and the growing expectation for personalized customer experiences, engineering teams are struggling to continuously upgrade their architecture, integrate new technologies, and capture user data from sources and via methods that didn’t exist until very recently.

These challenges bring CIOs back to the long-standing debate of whether to build software in-house or buy software from a vendor – a decision that returns a different answer for each business landscape.

When business stakeholders present the concept of a Customer Data Platform (CDP) to their counterparts in their organization’s CIO office and engineering department, their very first natural reaction is often, ‘Hold your horses – we’ve already built a data lake that does exactly what you’re selling’. The words ‘data’ and ‘customer profile’ are loaded – people have an instinctive reaction and assume that their organization already manages customer data in a professional way (of course) and uses that same professionalism as the foundation for every communication with every customer (of course).

While the first assumption is often right, the second, unfortunately, isn’t. Just because an organization has built a data lake that gathers customer data, it doesn't mean that they can claim the data is used to personalize every customer interaction. While that professional approach leads to solving the data and profile challenges, it doesn’t answer the business needs around omnichannel orchestration and personalization, so the question of build or buy still looms. Using the example of the CDP, let’s discuss the three most common pitfalls you need to be aware of to help you answer the question: build or buy?

Communication and connectivity

Interactions between a customer and a brand are, in theory, very similar to human communication: the customer has a long history of interactions across offline and online channels and often, a current intent to purchase something, require assistance, or even to churn. The brand on the other side is expected to take into account that long history of interactions and listen to that customer's current intent, and then take the right action in real-time. This is just like what happens during a human-to-human conversation where knowledge about past interactions, current context, and intent is detected automatically and used to influence conversations.

In our scenario of arguing for a CDP, this is where the gaps are first detected. Data lakes aren’t real-time and aren’t well connected to a very wide ecosystem of channels used to speak with a customer – for example, display, search, social media, email, etc. Data lakes simply aren’t built with experiences in mind.

Brands usually focus on customers – known customers, that is. The tendency to focus on known customers is understandable but at the same time, it leads your marketing department to disregard the importance of unknown, unauthenticated visitors across your digital real estate. Personalization and 1:1 customer journeys are just as relevant (or one could argue, even more important) for unknown customers. Don’t overlook the potential of improving the experience for them.

Start with the end

A known example of build vs. buy regarding a CDP is when one of the leading European telecommunications providers decided in June 2020, after a lengthy process, to not purchase a CDP and instead, build one on top of Google Cloud Platform. Nine months later, the to-be architecture was presented to the business stakeholders: it involved a mix of applications like Google Dataprep, Google AI, Google BigQuery, some Dataiku, some Collibra, and some other ingredients.

While this combination of applications is a great way of building out a data and profile foundation, it doesn’t help design and deliver experiences. The business stakeholders weren’t happy with the proposal and sent the architecture team back to the drawing board, simply because important concepts were left out. There were no answers to the following questions:

• How can a marketer build out an experience in a user-friendly way?
• How can a marketer take action and send a segment to one of the twelve different Demand Side Platforms (DSPs) which are in use by the Paid Media team?
• How can a journey be orchestrated across multiple channels, spanning a time period of weeks to months during which a customer may or may not take a specific action?

The above story applies to every three out of five brands that I meet. Yes, the ingredients of an experience are data, profile, and content. Yes, building an application on top of a cloud provider’s infrastructure is the logical starting point. And yes, that’s what every productized CDP has done. Microsoft Azure, AWS, Oracle: their infrastructure is helping brands build out a data and profile foundation and makes it possible to build out an application layer on top of that data foundation.

Technically, this is a great approach. But when building a CDP, people often forget that it’s not the developer, data engineer, or data architect who is building out customer journeys and experiences: that’s a job for the business stakeholders, and they usually don’t have a deep technical background. Instead, they need a friendly user interface (UI) that takes away the massive complexity and instead proposes a point-and-click approach. Building such a UI is a project by itself and introduces a whole dimension of new challenges which will make or break your application and its adoption.

Build and maintain

It’s no secret that the digital marketing space is evolving rapidly. What is relevant today isn’t tomorrow, and as the social media ecosystem evolves, new players are added and others disappear overnight. Increasing limitations on third-party cookies impact data collection going forward and who knows what else in the future will make designing and delivering experiences more difficult?

Based on feedback from various organizations across industries like retail, financial services, and telecommunications who’ve all tried to build their own platform, planning to build something and then completing the build typically takes between two and three years. Two years in marketing technology is a lot. It’s all too common for requirements to fluctuate over time and for internal teams to not be able to shift gears fast enough – or at all. This results in poor adoption by the business teams and impacts the return on investment.

Building software is one thing, maintaining it is something else. The advantage of building something yourself is that you have full control and you don’t depend on external teams to develop new features or roll out upgrades. The reality of building in many organizations is that ‘building something’ is considered a project with a beginning and an end. But a platform to manage customer experiences is a never-ending project, and many organizations aren’t ready to cope with the ongoing flow of feature requests and operational changes. If you build, don’t overlook what it’ll take to maintain your application in the long-term.

The verdict

Building your own CDP can be a smart investment that your organization should only consider if it has sufficient time and resources for development. You also need to have a strategy to secure your CDP’s connectivity with applications outside of the company to ensure long-term viability, along with user interfaces that are available and intuitive for day-to-day use.

When resources are sacred and leading digital transformation is a top priority, then investing in a comprehensive, extensible platform can reduce costs and maximize performance more than any homegrown solution ever could. It also guarantees a specialized solution that can be continuously enhanced by a dedicated partner, which, in turn, supports your IT staff in what they do best rather than distracting them from core business tasks.

The two most important drivers for any decision between build and buy should always be use cases and time-to-value.

Time-to-value is an easy one: how urgent is the need? High urgency typically leads to a buy-decision for clear reasons.

Use cases should always be the final argument: what does the business need? Is the business in need of analytical insights? Is the focus on deriving machine learning-based insights? Or is the business need focused on journey orchestration, audience activation, and omnichannel delivery?

Do your homework and document what the business wants in detail before making any decision. And finally, if the business use cases demonstrate a need for journey orchestration, audience activation, and omnichannel delivery, don’t hesitate to buy. Trust the application layer built by a software vendor, partner with that vendor on the vision and implementation roadmap, and have your business users rely on a friendly and functional UI that makes them independent and provides value in the short-term.