客户数据分散，不一定意味着需要再采购一套平台。评估CDP项目时，更重要的是先说明：哪些业务问题无法通过现有系统解决，需要怎样的数据，最终由谁使用。
下面用一套可复核的工作方法，把“看功能列表”转成“验证业务任务”。
一、先区分问题，而不是先确定产品
同样是“客户信息不完整”，原因可能不同：
| 具体问题 | 先检查什么 |
|---|---|
| 销售看不到最新跟进记录 | CRM录入流程、同步规则和权限 |
| 注册转化率算不清 | 事件定义、成功状态与漏斗口径 |
| 网站和App中的同一用户重复统计 | 标识来源、身份关联规则和合并历史 |
| 标签在人群导出后很快过期 | 更新频率、计算完成时间和下游同步 |
如果一个问题可以通过修正数据口径或完善已有接口解决，就应把这个方案纳入比较。只有明确缺口，新增系统的价值才有讨论基础。
二、把需求写成可执行任务
“支持统一身份”过于笼统。可以改写成：
在测试环境中，让同一测试用户先匿名访问网站，再登录App。检查登录前后的事件分别属于哪个标识，是否发生关联，以及关联后能否解释历史统计变化。
每个任务至少写清五项：输入数据、执行动作、预期结果、异常情况、验收负责人。
例如评估分群能力，可以先准备一组已知结果的测试数据：哪些人满足条件，哪些人不满足，哪些人的关键字段缺失。运行后逐一核对，而不是只看界面是否能选出一个人数。
三、沿着数据流检查能力
一个常见的数据使用流程是：采集或导入数据、处理与关联、形成标签或分群、交给业务使用、记录使用结果。每一步都需要单独验证。
1. 数据有没有采对
“点击提交”和“提交成功”不能默认是同一个事件。前者表示操作，后者通常需要业务系统确认。测试时应包括失败提交、重复点击和延迟上报，避免把正常演示当成完整验收。
2. 关联规则是否能解释
不能仅凭“关联率高”判断身份处理质量。还要核对错误合并是否出现、弱关联是否被当作确定关系，以及规则变更后历史结果如何解释。
3. 标签能否按需要更新
不要只问“是否实时”。应约定业务允许的等待时间，再测量从事件发生到标签计算完成、分群可见、下游可用分别经过多久。
4. 下游是否真正可用
导出成功不等于业务使用成功。还需要确认目标系统收到什么标识、怎样去重、失败如何重试，以及是否有结果记录可供复盘。
四、把成本放在同一范围内比较
可以把成本拆成：采购或订阅、数据接入、存储与计算、运维、升级、培训和迁移。不同方案应使用相同业务规模与观察周期比较。
如果一份报价包含实施，另一份只包含软件，就不能只比较总价。容量、接口和环境条件不同，也会影响费用解释。
五、用小范围验证代替一次性铺开
优先选一个数据范围可控、负责人明确的任务，例如注册流程分析，或一组用户标签的计算与输出。
测试结束后保留原始输入、规则版本、运行时间、异常记录和核对结果。若任务没有通过，先区分是数据缺失、规则不清、接口问题还是功能限制，再决定是否扩展。
CDP评估的产物不应只是一张功能打勾表，而应是一组有边界、有输入、有结果的验证记录。这样即使最终选择完善现有系统，也能留下可继续使用的需求和数据规则。
