在客户数据平台建设中，很多项目会从多端数据接入开始，把 Web、App、小程序、CRM、订单和会员数据统一汇入平台。但数据接入只是第一步，真正决定 CDP 是否可用的，是后续身份、标签、人群和回流链路能否稳定运行。
1. 先定义统一客户主键
CDP 底层通常需要维护统一客户表，用来承接不同来源的身份标识。一个简化结构可以包含统一客户 ID、登录 ID、UnionID、手机号哈希、设备 ID、首次访问时间、最近活跃时间和画像版本。
关键不在字段数量，而在主键治理策略。统一 ID 需要能够承接身份合并、拆分和更新，避免后续标签计算、人群圈选和路径分析受到历史身份变化影响。
2. OneID 映射要区分确定关系和弱关系
OneID 解析不能只靠简单字段匹配。手机号、会员 ID、登录账号通常属于高置信关系；设备 ID、Cookie、匿名访问标识更适合作为辅助关系。
工程上可以维护身份映射表，记录标识类型、标识值、统一客户 ID、置信度、来源系统和更新时间。这样在客户画像、路径分析和标签计算时，可以明确每类身份关系的可信边界。
3. 标签计算要有口径和更新机制
标签不是静态字段。比如“近 30 天高活跃”“最近 7 天浏览过会员权益页”“有复购倾向但未完成下单”，都需要依赖行为事件和业务数据持续计算。
成熟的标签体系需要同时记录口径说明、依赖数据源、更新时间、失效规则和负责人。否则平台里会出现大量“看起来有用、业务不敢用”的标签。
4. 人群圈选需要支持组合逻辑
业务团队实际使用 CDP 时，很少只使用单一标签。更常见的是组合条件，例如近 30 天活跃、浏览过某类内容、未完成转化、不在黑名单中、所属渠道为特定来源。
因此，人群模块需要支持交集、并集、排除、时间窗口和行为次数条件。底层可以结合列式存储、倒排索引或 Bitmap 提升查询效率，减少每次圈选都依赖数据工程师写 SQL 的情况。
5. 触达结果要回到分析体系
CDP 不能只负责“圈人”。人群被分发到短信、企微、App Push、邮件或其他触点后，还需要记录是否送达、是否打开、是否点击、是否带来转化、是否影响复购和留存。
在实际项目中，GrowingIO 的产品链路可以作为一个样例：通过增长分析识别路径、漏斗和留存问题，再通过客户数据平台沉淀 OneID、标签和人群，最后连接智能运营能力完成触达与效果复盘。
这样，客户数据平台不只是客户资料库，而是连接数据资产和业务动作的中间层。
