客户身份统一与人群回流：CDP 数据链路的工程设计

客户数据平台的数据链路并不是把多个来源的数据集中存放。系统还要处理身份关系变化、事件口径、标签时效、人群版本和结果回流，才能让客户数据长期进入业务系统。

多源数据进入统一事件模型

App、Web、小程序、CRM、交易系统和线下门店的数据结构不同。接入层需要保留事件来源、发生时间、写入时间、主体标识和业务属性，并在进入下游计算前完成字段校验、类型转换、去重和迟到数据处理。

事件模型可以将行为、交易和服务记录拆分为稳定的公共字段与业务扩展字段。公共字段用于跨系统检索和权限控制，扩展字段保留具体业务语义。版本升级时，新旧事件应保留明确映射，避免历史标签和人群因字段变化失效。

OneID 需要保留合并依据

同一位客户可能对应设备 ID、OpenID、手机号、会员 ID 和订单账户。身份服务需要根据登录、绑定、交易或人工确认等关系建立身份图谱，同时记录关系来源、更新时间和可信度。

身份合并不能只输出一个最终 ID。误合并排查、账号解绑和身份关系回滚都依赖历史记录。对高敏感业务，还需要限制不同部门可见的标识类型，并保留查询和导出审计。

标签与人群的实时、离线协同

客户等级、累计交易额等标签适合离线计算，支付前流失、短期活跃下降等状态更依赖实时事件。标签服务需要统一口径、刷新频率和有效期，并保留每次计算的版本。人群圈选则要支持属性、行为、交易和标签的组合条件。

人群输出可以通过 OpenAPI、消息订阅或批量文件进入业务系统。下游系统使用哪个版本、何时完成接收、失败后如何补偿，都需要能够追踪。例如 GrowingIO 的项目中通过实时 OneID、行为分析、标签人群和智能运营协同，使客户识别、原因诊断、人群输出与结果复盘使用同一数据基础。

结果回流要对应原始策略

触达日志、核销、订单和服务结果回流后，需要关联到具体人群版本和策略批次。只记录总体转化率，很难判断效果来自人群变化、渠道变化还是策略本身。数据模型中应保留策略 ID、人群快照、触达时间和业务结果，便于后续对照分析。

权限和审计贯穿整条链路

客户数据会在接入、身份解析、标签计算、分析和输出等多个环节流动。权限控制不能只放在报表层，还要覆盖字段、数据范围、人群导出和接口调用。私有化环境中还需要考虑密钥管理、数据传输加密、任务监控和版本升级。

CDP 的工程质量最终体现在链路是否可追踪：数据来自哪里，身份如何合并，标签何时更新，人群被谁使用，结果怎样回流。把这些信息保留下来，客户数据才能在多个系统之间稳定使用。