Every brand which has multiple customer servicing touch points has most likely, at some point in time, has thought of having a Customer Data Platform (CDP) that stitches and unifies customer behavior across all data sources. But what follows the realization of the need for a CDP is the overwhelming task of figuring out the answer to “Is it better to buy or build a CDP?”
There are number of factors that need to be considered before arriving at the ‘build or buy’ decision. Here in this blog, I have tried to simplify those points.
1. Time factor
If you choose to build, even the simplest CDP platform would require a minimum of 6 months to a year to build internally. Any increase in complexity and integration of new data source would result in a longer development cycle.
If you wish to buy the platform, you get a head start in terms of time to go live as the CDP comes pre-equipped with connectors and graphical schema management interfaces that help you integrate all your data sources quickly and get the unified view of customers.
Hence it boils down to the question of balancing how early you need a CDP versus how much development man hours you’re willing to dedicate.
2. Technological know-how and resources
Does your organization have the competencies to build a CDP in-house? Creating a CDP platform requires experienced Big Data Architects, Data Engineers, Data Scientists, UX Designers & Engineers, and others.
Even if you get the resource mix right, then there are critical next stages of defining the specs to cover all your business use cases. For example, what happens when the same cookie is shared between multiple login accounts or what happens when two different customer IDs share the same mobile number? All these are serious considerations that would make or break the usability of your CDP.
This brings us to another important consideration of selecting the right data storage and processing technologies that are scalable with your ever increasing data volume and number of sources.
Hence, organizations with large IT budgets with a varied pool of IT resources can consider the build option over the buy option. Organizations which choose to build, and get it right, also get a lot of flexibility to implement custom use cases through the in-house CDP.
However, in almost all other scenarios you might be better off with a buy option as you can choose from multiple CDP vendors and select the one that is the best fit to solve all the use cases that you have in mind.
3. Recurring costs
There are recurring costs on the infrastructure side for persistent data storage, backups, and processing of 360 profile views in real time. There are also the costs of human resources required to support and monitor the CDP systems on an ongoing basis. In some cases you would also need a team of dedicated Data Scientists to develop, maintain, and recalibrate the ML enabled analytics embedded in CDP. In this area, the buy option gives a considerable advantage because of two primary reasons:
- A CDP vendor can absorb such costs over a large pool of clients hence the recurring costs would be lower.
- The CDP vendor can give access to latest product upgrades in the form of new connectors, new functionalities, new embedded ML models, analytics, and continuous updates to UI.
Relates Read: David Raab, The CDP Man, on How AI and CDP can Unlock Possibilities for Marketers
4. Expertise necessities
By virtue of working across various industry clients and also multiple clients from the same industry a CDP vendor is able to bring in a lot of expertise in terms of best practices in creating 360 profiles and suggesting strategies to get better campaign uplift. It is quite difficult to hire resources and build this kind of an environment in-house. Hence the buy option has a clear edge over the build option.
With the above under considerations, is it conclusive that the buy option is typically better than the build option. The exception to the above is for organizations who need custom CDP functions, and have existing IT capabilities and budgets that can be easily deployed.
