I’m not generally known for my prowess in DIY projects. When anything needs fixing or putting together, and certainly when constructing from scratch, I prefer to leave it to people who know what they’re doing. The reasons for this are primarily time, inclination, and disposition, together with the knowledge that other people tend to be better at this kind of thing than me and have done it many times before. Is this the right mindset when implementing a customer data platform?
Defining The Customer Data Platform
The term customer data platform (CDP) has been in use for some time and refers to a packaged software application that unifies customer data from multiple sources, enabling improvements in data quality, analytics, targeting, and personalization. In the past, this might have been referred to as a single customer view, a long-held aspiration for marketers. This would ensure the best possible insight-led marketing, delivering a joined-up customer experience and accurate measurement of outcomes.
As Steven Casey and Katie Linford stated in the New Tech: B2B Customer Data Platforms, Q3 2021 report, the need for more and better data is driving adoption of B2B CDPs. Next month at Forrester’s B2B Summit EMEA event (October 11–12 in London), I’ll be on stage talking about achieving successful data unification with CDPs. There is a wide and growing selection of solutions on the market, meeting a range of use cases. Nevertheless, rather than buying an “appliance” CDP, why not build your own using a suitable database platform, ensuring that it exactly meets your requirements?
Previously, this would have been achieved using bespoke components comprising, at a minimum, a database, ETL (extract, transform, and load) tools, and a suitable analytics platform. Putting all this together would almost certainly have required specialist IT expertise, incurring considerable time and expense. Just as CDPs have emerged as a ready-to-deploy answer to marketers’ needs, though, the original tools and components have also improved, making it much easier to create a bespoke solution.
Surely, using these modern tools to create a solution that exactly meets the specific requirements of individual marketing teams will deliver the best outcome? Integration with the rest of the martech stack would be straightforward using the plethora of available APIs, without any limitations over data volumes and connections. All this with no vendor salespeople involved, no need for software licences and contracts, and complete control over hosting and everything else.
Even with the improvements in the tools available, though, there are a number of drawbacks to attempting a self-built solution:
- Putting together a bespoke CDP still requires considerable technical skills and competencies.
- A long-term commitment to the resourcing of a project, spanning development, maintenance, and support, would be necessary.
- Such a project necessitates a much more detailed and more widely circulated business case, involving considerable additional buy-in and sign-off across the business.
- The additional complexity, moving parts, and stakeholders involved in an internal project make it harder to manage.
- There’s always the risk of another business-critical priority coming along and usurping such a marketing project.
(Or to put it into other words, as I’ll say in my Summit talk, when you build your own software, one of the biggest benefits is that you have unlimited scope, and the biggest drawback is … you have unlimited scope!)
Benefits Of A Packaged Solution
These downsides to a self-build approach make an off-the-shelf CDP the better option. A packaged CDP is easier to deploy by “revtech” teams, readily integrating into the existing revtech stack. This is very much no- or low-code technology in action, with only minimal IT oversight remaining necessary.
The market for CDPs is rapidly maturing, with a wide range of capabilities and strengths, as outlined in Katie Linford’s evaluation, The Forrester New Wave™: B2B Standalone CDPs, Q4 2021. This should mean that almost any use case and deployment environment will be supported, even if some modest configuration is required.
Choosing such a solution immediately provides access to rich functionality, ongoing development, customer support, and an existing ecosystem that are all hard or impossible to replicate internally. Clearly, a commercial vendor spreads development costs across its user base as well as exploiting feedback to make improvements. This user community can also be tapped into for advice and guidance when deploying and adopting a solution.
Any vendor selection carries risk, especially involving a new solution category and where there is less organizational experience. Nevertheless, this can be mitigated by undertaking a rigorous selection process and nurturing ongoing relationships. Internal projects are not risk-free.
Finally, to address the notion that a bespoke solution will exactly fit the needs of a business, note that the competitive advantage derived from a CDP is based on configuration and deployment, not the underlying technology. In other words, use a CDP to improve responsiveness, personalization, segmentation, and targeting by focusing on data, process, and adoption.
There’s no reason to engage in DIY to achieve these outcomes, which, as I mentioned, I’ll be talking more about at Summit next month. And you can be sure I’ll be leaving my tool belt at home!