企业官网建设流程全解析

一、先厘清：CDP 到底是什么，和 CRM 有何不同

很多团队在启动客户数据项目时，第一反应是“再买一套 CRM”。但 CDP（Customer Data Platform，客户数据平台）与 CRM 的定位完全不同。CRM 以“销售流程/工单流程”为中心，解决的是“谁在跟进、跟到哪一步、有没有超时”；而 CDP 以“客户实体”为中心，解决的是“我到底有多少客户、他们是谁、分别在什么状态、我能否随时取用”。 一句话区分：CRM 记录过程，CDP 沉淀实体。CDP 的核心交付物是统一的客户主键（OneID）与可对外服务的标签画像，它不负责业务流转，但为所有上游系统（含 AI 客户经营系统）提供可信的数据底座。二者不是替代关系，而是“实体底座 + 流程系统”的互补。一个常见的成熟组合是：CRM 管销售动作，CDP 管客户事实，AI 在二者之上做经营性判断。

二、CDP 整体分层架构（五层）

从工程视角，一个可落地的 CDP 通常划分为五层，自上而下是“数据进来—变干净—认出人—贴上标签—被调用”的流水线：

• 采集层（Ingestion）：负责把埋点、业务库 CDC、文件、第三方开放接口等异构数据源统一接入，支持实时与离线双链路。该层的关键是“只采集、不加工”，保持源数据的原始性。

• 清洗与标准化层（Cleanse）：做格式归一、去重、脏数据过滤、字典映射，例如把“男/M/1”统一成性别维度的标准码，把金额币种统一折算。

• 身份识别层（Identity / ID-Mapping）：通过确定性匹配与概率性匹配，把同一自然人在不同渠道的标识（手机号、设备ID、unionid 等）归并到同一个 customer_id。

• 标签与画像层（Profile）：在 OneID 之上构建规则标签、统计标签与模型标签，形成客户 360 视图，并支持自定义分群。

• 数据服务层（Service）：以人群圈选 API、标签查询 API、实时特征 API 的方式对外输出，供营销、BI、AI 系统调用，是 CDP 价值兑现的出口。

这五层的关系是“下层为上层供数”，任何一层缺位都会导致上层不可用。例如没有身份识别层，标签就会重复挂在多个临时 ID 上，画像永远拼不完整；没有服务层，前面四层再扎实也只是一堆没人用的表。

三、核心模块拆解：从采集到服务

对应五层架构，工程上落为六个核心模块：

• 多源接入模块：支持 Kafka 实时流、Binlog CDC、批量文件（CSV/Parquet）、HTTP 回调四种形态，统一抽象为“源—主题—落库”配置，新增数据源不改代码只改配置。

• 实时/离线双链路：实时链路走 Flink/Spark Streaming 做秒级标签，离线链路走 T+1 批处理做重算与校正，两者结果写入同一标签服务，保证最终一致。

• ID-Mapping 引擎：维护“原始标识→自然人”的映射图，支持新增标识自动挂靠与冲突消解。

• 标签引擎：规则标签用 DSL 配置（如“近30天消费≥3次”）；统计标签来自聚合任务；模型标签接算法服务输出分群概率或评分。

• 画像存储：采用宽表 + KV 混合，宽表供分析型查询、KV 供低延迟点查，冷热分离降低成本。

• 服务网关：提供人群圈选（类 SQL 过滤表达式）、标签点查、订阅推送三类接口，并做鉴权、限流与审计。

四、身份识别与 ID-Mapping 的关键设计

ID-Mapping 是 CDP 的“地基中的地基”。实践中分两步：

• 确定性匹配（Deterministic）：基于强标识的精确相等，例如归一化手机号（去空格、去国际区号）后做哈希。代码示例：

  -- 归一化手机号并生成稳定哈希主键 SELECT user_id, md5(regexp_replace(phone, '[^0-9]', '')) AS phone_hash FROM ods_user_raw WHERE regexp_replace(phone, '[^0-9]', '') > '';

• 概率性匹配（Probabilistic）：当强标识缺失时，用设备、地址、姓名拼音等弱信号计算相似度，超过阈值则并入同一簇，常用 SimJoin 或图连通分量算法处理。

无论哪种方式，最终都输出一个不可变的 customer_id，并保留“原始标识—customer_id”的映射历史，以便追溯、纠错与合规删除（被遗忘权）。注意：身份识别的准确率直接决定了上层所有标签与 AI 判断的可信度，宁可保守也不宜过度合并。

五、与 AI 客户经营系统的衔接

CDP 解决“客户是谁、处于什么状态”，而 AI 客户经营系统解决“该找谁、推什么、什么时机、什么话术”。二者的接口就是 OneID + 实时标签 + 特征服务。AI 侧不再各自爬库，而是订阅 CDP 的标签变更事件，结合自身模型做出经营性判断。这也正是“AI 做判断，人只做执行”得以成立的前提：判断所依赖的事实，必须由统一数据底座供给，而非散落在十几个业务库里各算各的。当 CDP 把客户事实讲清楚，AI 才有资格做判断。

六、落地建议与常见坑

• 先建身份识别，再建标签。很多项目一上来就做几百个花哨标签，结果 OneID 没打通，标签全部挂在重复 ID 上，价值归零。

• 数据治理要先行。字典不统一、编码不规范，清洗层会无限膨胀，后期返工成本极高。

• 服务层要“可被调用”而不是“仅供看板”。CDP 的终极价值在激活，而非又一个报表系统。

• 从“一个主题域”切进去，例如先打通交易与会员，验证闭环后再扩展渠道与行为数据。

• 重视数据质量监控：ID 合并率、标签覆盖率、服务 SLA 要常态化看板化，否则劣化无人知晓。

这类客户数据底座与身份识别能力，正是上海广瞬科技 AI 客户经营系统持续打磨的方向。

—— 上海广瞬科技有限公司