如何有效控制客户数据平台(CDP)的研发成本,降低失败风险?

最近有朋友来咨询CDP数据方面的问题。他们找了个软件公司研发私有化的CDP。确定需求后,那个软件公司奋战了三个月。最后试用阶段,业务部门多次发现客户和订单关联错误,客户的流失预测模型也有点莫名其妙,与经验格格不入。这让公司上下普遍担心里面的客户数据和预测模型有问题,最终谁也不敢用。了解完整个情况后,我告诉他,在这个项目上,数据问题是次要的,失败的罪魁祸首是错误的软件研发方法。CDP项目不是传统的纯软件项目,照搬传统的研发方法,不仅成本大,还会存在巨大的失败风险。

这是为什么呢?

我们先从CDP诞生的背景和特点谈起。传统软件(比如CRM、ERP和各类前端系统)主要功能是信息化业务流程。它们在提高日常运营效率的同时,也帮助企业收集和沉淀了与客户相关的数据。在营销领域数字化浪潮的推动下,这些数据就成了CDP生长的土壤。CDP的目标就是挖掘这些沉淀数据的价值,帮助企业在信息化的基础上,进一步实现精细化和智能化。因此,CDP项目本质上与AI或者机器学习项目是一样的,有严重的“数据依赖症”。这些数据在大部分情况下不是为CDP量身定做的,会存在各种各样的未知问题。这就给CDP项目带来了一种很难控制的风险:数据的不确定性。它对项目的影响是全方位的。

我用几个实际的例子来说明这种影响。我们曾经帮助某培训机构规划一个私有化的CDP。在需求分析阶段,业务部门早早就提出了一个庞大的客户标签体系。我们梳理数据后发现只有12%的标签能够对应到客户数据,业务部门不得不重构标签体系,以获得更多的数据支持。另外一个CDP项目在集成客户数据时,技术人员发现好多独立客户实际上是同一客户,但是无法通过手机号关联。原来,销售人员故意登记错误的手机号,用以私藏客户资源。研发人员抛弃原先一步到位的集成方法,采用渐近式的清理方案:在CDP中加入了一个带界面的半自动化数据清理界面,让业务人员专门安排人定时检查和清理,逐步剔除数据问题。当然一些功能上线后也会产生问题,特别是需要机器学习模型的功能。它们对数据特别敏感,数据上一有风吹草动,很有可能就会影响到线上的应用效果。我们曾经帮助一个零售行业的客户基于CDP建立了商品推荐服务,上线测试2周后突然出现点击率大幅度下降。紧急检查后发现,有一波促销活动大幅度改变了用户的线上行为。这种改变反映到了行为数据中,最终影响了推荐模型。我们和业务部门一起讨论,快速调整推荐方案,定制了数据过滤机制,最终实现了稳定的效果。

不难看出,对数据的深度依赖让CDP项目更加复杂,方案调整频繁,传统的瀑布式研发方法必然捉襟见肘,大概率会导致失败。开头提到项目正是采用了这种线性的研发方法,最终走上了失败的道路。


在双重不稳定(需求+数据)的研发背景下,必须采用敏捷开发的方案,力求通过“小步试错、快速迭代”的方式控制项目的研发成本,降低失败风险。每次迭代时要注意一点:必须有可行性研究。它针对业务场景或者功能需求,回答诸如“能用现有的数据解决这些问题吗?”或者“有没有可能利用这些数据开展进一步的优化工作?”之类的问题。这个可行性研究完成后,才能进入正式的工程开发。可行性研究是降低每次迭代成本的关键手段,不能回避。很多情况下,一些迭代在可行性研究阶段就终止了,避免了后续的开发和测试。

敏捷开发方法能够有效控制CDP项目的失败风险,降低研发成本。如果还想进一步压缩CDP的研发成本,使用产品化的CDP是一个不错的选择。受篇幅限制,我们下一篇重点讲如何挑选一款合适的CDP产品,提高研发效率,降低项目成本。