客户数据平台往往在问题还没说清楚之前就被买下了。这是我参与过的每一次选型都会看到的情形。最先被提出的问题几乎总是选哪家的工具，而真正应该排在前面的问题是另一个：今天有哪个决定我们做不了，只因为数据散在五个地方，彼此对不上。
从第二个问题出发，最后需要的系统常常比预想的小。从第一个问题出发，买回来的功能没有人会打开。
- 选型从使用场景开始，而不是从厂商比较开始。
- 没有对客户的统一定义，客户数据平台统一的只是矛盾。
- 同意属于架构本身，不属于验收环节。
- 足够窄的起点比完整铺开更快拿出可展示的结果。
- 有时候最诚实的答案是并不需要一个单独的平台。
目录
客户数据平台很少败在工具上
市面上的系统之间的差别，比厂商的演示文稿显示的要小。持久的客户档案、身份识别、向外部系统开放的接口，如今大家都做得到。提出这个概念的机构把客户数据平台定义为一种软件，它生成并维护一份持久的、统一的客户记录，并让其他系统可以调用。这个定义很窄，而窄正是它的价值所在。
我近距离看过的项目，没有一个是败在技术上的。它们失败的原因是事先没有人决定什么算一个客户。是邮箱地址，是门店里的会员号，还是网店里的设备。只要三个部门给出三个答案，再好的平台产出的也不过是一份整齐统一的矛盾。
第二件事是归属。系统总得有人负责，如果没有指定，默认就落到信息技术部门头上。这本身没有错，但结果是维护的优先级按人手安排，而不是按营销的需要安排。
选择客户数据平台真正靠的是什么
现在我一律从使用场景开始，而且最多三个。不是先列三十个再挑，而是下个季度应该跑得更顺的那两三件事。一条欢迎流程，知道这个人是否已经在门店买过。一次投放，把老客户从拉新campaign里排除掉。一份报表，不把同一个渠道算两遍。
这些场景会告诉你哪些数据源真的需要接进来，通常比担心的要少。数据源又会告诉你哪些质量问题必须先解决，因为平台不会改善数据，它只会让缺陷更快地暴露出来。
第三点是同意。在欧洲，法律依据不是脚注，它就是架构本身。如果授权没有随记录一起流动，一份技术上完美的档案也没有用，因为你不被允许激活它。相关规则写在《通用数据保护条例》第六条里，它属于选型阶段，而不是验收阶段。
投入开始回本的那一刻
价值不会在上线当天出现。它出现在有人第一次提出一个原本需要两周协调的问题，而答案当天下午就到了的时候。走到那一步花的时间，比任何一份方案里写的都长。
能缩短这条路的，是一个足够窄的起点。一个市场，一个渠道，一个场景。跟技术上能做到的相比，这听起来很保守，但它能早早拿出一个可以展示的结果。在这类项目里，可见度就是换取第二阶段预算的货币。
之后如何证明价值，是另一门功课。想找方法的话，我那篇关于营销组合建模的文章，比任何仪表盘都更诚实。
如果重来一次
我会把关于客户数据平台的决定往后推，把定义方面的工作往前挪。什么算客户，同意如何记录，结果由谁负责。这些不是前期准备，这些就是项目本身。
另外我会一直留着一个问题：到底需不需要一个单独的平台。如果数据仓库本来就在，激活也只走少数几个渠道，那么客户数据平台有时是对一个问题的昂贵回答，而一张定义清楚的表也能解决它。问一句不花钱，偶尔能省下很多。