CDP、CRM、DMP、DSP、MDW、CDM：客户数据体系差异与协同实战

CDP、CRM、DMP、DSP再加上 MDW 和 CDM这六个缩写放在一起能准确把差异讲清楚的人说实话不多。我这两年接触了不少零售、电商、金融行业的客户数据管理项目发现一个共性现象业务侧和数仓侧各说各话有人把 CDP 当 CRM 用有人把 DMP 当 CDP 买还有人一听 DSP 就以为是广告投放系统结果电子工程师眼里的 DSP 是数字信号处理器。这篇内容不是给你念官方定义而是按我实际搭客户数据体系的经验把 CDP、MDW、CRM、CDM、DMP、DSP 的差异拆开讲透再给出一套能照着做的协同落地方案。适合正在做客户数据中台选型、或者被标签画像怎么打通折磨的运营、产品、数据工程师。1. 六个缩写到底啥关系先按存、算、用、买归类再谈协同1.1 从系统动作看六个系统其实分属四类很多人一上来就背定义背完还是不知道谁管谁。我习惯用存、算、用、买四个动作去归类这样边界一下就清楚了。存解决数据放哪、怎么组织的问题。代表是 MDW主数据仓库/主数据中心负责把分散在各业务系统的客户主数据、订单、行为数据做集中归集。算解决数据怎么变成资产的问题。代表是 CDP 和 CDM。CDP 做实时画像、OneID 合并、标签计算CDM 更偏规范和模型定义人和业务对象的统一模型长什么样。用解决业务侧怎么消费数据的问题。代表是 CRM管销售跟进、客户服务、营销活动执行。买解决广告流量采买的问题。代表是 DSPDMP 在中间做数据供给把人群包交给 DSP 去投放。这里要说一下 CDM。搜索CDM你会看到三种完全不同的东西一是微软提出的 Common Data Model通用数据模型二是某些软件工具的版本号比如CDM v2.12.00;三是国内很多团队直接翻译成 Customer Data Management客户数据管理。我在这篇文章里按通用数据模型 客户数据标准来理解因为只有站在模型的层面CDM 才能和 MDW、CDP 产生真正的协作关系。你要是把它理解成客户数据管理的总称那它和 CDP 的关系就得反过来CDM 是方法论CDP 是落地的平台。还是一头雾水的话我举个类比。MDW 像一个大仓库所有货物先进库CDM 像仓库里的货架规则和标签规范规定什么货放哪、怎么编号CDP 像仓库门口的值班员能实时认出每个进来的人知道他是谁、以前来过几次、喜欢什么CRM 像销售手里的客户档案本和跟进记录表DMP 是广告投放部门用来做人群圈选的黑板DSP 是替你把广告递到用户面前的投手。分工不一样谁也替代不了谁。1.2 最容易混淆的三组名词一次说清楚第一组CDP 和 DMP。这两者的数据对象完全不同。DMP 的核心是匿名 ID比如设备 ID、Cookie它不需要知道这个人是王女士还是李先生只需要知道在广告侧这个设备属于什么人群;CDP 的核心是实名可触达的客户比如手机号、微信 UnionID 或者会员卡号运营要能直接对这个人做推送和服务。时效性也不一样DMP 的人群包通常是批量圈选、批量同步更新周期可能小时级甚至天级CDP 强调实时用户刚在 App 里加购一分钟后销售打电话过去就能叫出他的名字。还有一个隐藏差异DMP 的数据大多是第三方采买加广告平台回流的来源广但准头有限CDP 的数据主要来自企业自有系统是做精细化运营的可信底座。第二组CRM 和 CDP。CRM 管的是关系跟客户的交互记录、销售阶段、工单、合同都沉淀在 CRM 里CDP 管的是事实用户看了什么、点了什么、买了什么、投诉过什么这些事实被汇总成画像。一个很大的误区是把 CDP 当成能存数据的 CRM。实际上 CRM 的数据模型是按销售流程设计的客户字段就那些CDP 的数据模型是事件驱动的今天新增一个浏览行为就多一个事件类型。两者一旦对接上常见做法是 CDP 把客户画像、实时标签推送给 CRMCRM 把销售跟进结果、成单记录回流给 CDP互补关系非常明显。第三组MDW 和 CDM。MDW 是存储层负责把各源系统的数据搬进来做清洗、标准化、汇总CDM 是规范层负责回答客户这个对象包括哪些属性、状态字段的枚举值怎么定、订单和客户怎么关联这一类问题。通俗点说MDW 是里面放了什么数据的总账CDM 是数据应该长什么样的宪法。没有 CDM 约束的 MDW很容易退化成贴源层的大杂烩下游用数据时每个团队有自己的一套口径这是很多企业数据仓库越建越乱的根本原因。2. 协同应用主线一条从广告拉新到私域运营的数据闭环怎么走2.1 典型的用户数据流转链路六个系统单独拿着都没什么用真正的价值在于串成链路。我用一个从公域获客到私域运营的完整链路来演示用户点击广告 → DSP 执行曝光 → DMP 圈选人群包并回传投放数据 → 用户落地页注册/下单 → CDP 实时接收事件 → OneID 识别新旧用户 → 画像标签更新 → 数据回流至 MDW 汇总 → 按 CDM 标准落仓 → 业务系统CRM发起跟进/营销/服务 → 转化结果再次回流广告平台做模型优化。这条链路里DSP 和 DMP 管的是拉新和触达CDP 管的是承接和识别CRM 管的是服务和转化MDW 和 CDM 管的是沉淀和标准。每一环都依赖上一环的输出拔掉任何一环数据流就断在中间。比如你把 DMP 的人群包直接拿去 CRM 做营销一定会发现大量用户无法匹配到会员身份因为 DMP 侧只有设备 ID没有手机号CRM 根本不知道他是谁。2.2 数据回传与模型优化的双向通道很多团队以为数据流是单向的其实整套体系里至少有三条回传路径缺一条都会影响效果。第一条CDP 向 DSP 回传转化事件。用户在广告流量里产生注册、下单、付费等关键行为后CDP 把这些转化事件回传给广告平台平台模型才知道哪类人更容易转化从而优化出价和定向。这里的关键是回传窗口和匹配方式一般通过点击 ID 或设备 ID 匹配延迟超过 24 小时效果会明显下降。第二条CDP 向 DMP 回传人群包。CDP 算好高价值人群后需要把人群同步到 DMP 做扩量或排除。同步时要注意 ID 类型映射CDP 里存的是手机号DMP 不一定能直接用可能要先通过合作方把手机号转换成对应的设备 ID 或平台识别 ID。第三条CRM 向 CDP 回传统一后的客户状态。比如客户在 CRM 里被标记为高意向这个结果要回流给 CDPCDP 更新标签后再次同步给 DMP下一轮广告投放就不再给这个用户毫无针对性地硬广轰炸而是换上跟当前阶段更匹配的内容。这三条回传路径落地的难点不是技术是账号权限和数据合规。数据合规要求严格的时候很多 ID 转换动作必须在安全域内完成这对团队的流程规范要求很高。2.3 一个服饰零售品牌案例完整跑一遍我拿之前参与的一个服饰零售品牌项目为例。当时客户手里有线下门店的会员数据、天猫旗舰店订单数据、企业微信的导购数据还有投放在字节和腾讯广告的投放数据。数据是有的但互相不通会员在门店消费的记录广告投放系统不知道广告带来的新客到了天猫下单导购系统也不知道。我们分了三步打通第一步用 CDP 承接所有渠道的客户身份。手机号作为主键把线下会员、天猫订单、企微好友、广告点击四种 ID 全部做映射合并。当时仅 ID 映射表就建了三千多万条合并之后识别出约 800 万独立客户。第二步用 CDP 的标签能力算高价值人群。规则很简单近 90 天有购买且累计消费超过 1000 元的客户打上高价值复购标签加购未下单的客户打上临门一脚标签只看不买的打上新客培育标签。第三步把人群包推到 DMP 做二轮投放同时把 CDP 画像推给 CRM 做导购任务。高价值复购人群在 CRM 里由专属导购发起换季回访临门一脚人群在 DMP 里用优惠券广告做定向挽回新客培育人群则在后续一个月里持续用内容广告触达。最终效果比较直观广告侧的新客识别率提升了 30% 以上因为多了 OneID 环节广告点击用户能和老会员数据做匹配CRM 触达的复购率比原来用全量名单群发提升了接近一倍。这个项目最大的体会是不是数仓有多牛而是每个系统终于做了自己最擅长的事。3. 实操落地客户数据平台接入周边系统的关键细节3.1 先盘需求再定边界一张责任表分清是谁的活很多项目一出问题就互相推诿根子是系统边界没划清。我动手搭体系之前一定会让业务和数据团队一起填一张责任边界表业务问题主责系统协作系统这个客户最近 90 天买了什么CDPMDW 提供订单汇总销售跟进记录在哪查CRMCDP 供画像参考广告投放给哪类人群看DSPDMP 提供人群包经营日报的客户数是哪个口径CDMMDW 出数CDP 可对账客户地址变动了怎么办CRM 修正CDM 定标准CDP 更新画像匿名用户怎么后续触达CDPDMP 承接广告触达这张表的价值在于让所有人意识到客户数据不是某一个系统的私产。CRM 里的客户档案是交易型数据会有更新、删除、合并CDP 里的客户画像是派生型数据依赖上游多个系统的实时输入MDW 里的客户总表是分析型数据按 CDM 模型加工供报表和算法使用。三个层面搞清楚了后面出问题就知道去查哪个环节。3.2 打通身份标识OneID 设计的五个要点OneID 是整个体系的承重墙设计不好CDP 标签、DMP 人群包、CRM 匹配全部会偏。我在这块踩过不少坑总结下来五个要点第一定好 ID 优先级。一般原则是登录类 ID 优先于设备类 ID手机号优先于邮箱企业微信 UnionID 优先于普通 OpenID。不是所有 ID 都要参与合并优先级过低的 ID 只能做辅助参考。第二ID 映射表的更新不能全量覆盖。每天会有新用户、新设备、新的绑定关系还可能有解绑和失联的情况。我通常采用事实表 合并关系表两张表事实表存所有原始 ID 和对应的时间戳、来源渠道合并关系表存分组 ID、合并原因、操作时间。这样即使后来发现合并错了也能回溯修正。第三合并要留人工确认入口。自动图算法合并经常会把同一个设备但有多个家庭成员使用的情况判成一个人导致画像污染。高风险会员、黑名单客户必须人工确认后再合并不能全自动。第四OneID 要暴露给下游用。DMP、CRM、MDW 拿到的同一个 OneID 要能对得上。实际操作时可以在 CDP 里定义 OneID 生成规则然后通过数据同步工具把 mapping 表下发到其他系统至少保证核心链路用的是同一份映射。第五性能要提前压测。ID 映射表上亿条之后关联查询会非常慢。我建议为高频业务单独建宽表而不是每次都走实时关联对账和统计走离线实时场景只保留最近 N 天的活跃映射。3.3 事件数据模型设计字段标准别搞特殊CDP 的核心资产是事件流。同一类事件在不同的接入渠道里可能出现十几种命名注册可能叫 register、signup、user_register看商品可能叫 view_item、product_view、detail_view。CDM 在这里的职责就是统一事件名和属性名落仓以后所有系统按同一套模型对接。一个实用的事件模型长这样{ event_id: uuid_v4, event_type: view_item, event_time: 2025-01-15T10:30:0008:00, user: { one_id: xxx, source_id_map: { phone: 138****1234, union_id: o_abc123, device_id: IDFA-xxx } }, context: { channel: mini_program, scene: search_result, ip: 1.2.3.4, ua: iPhone/17.2 }, properties: { item_id: sku_888, item_sku: RED-M-001, price: 299, category: outwear } }字段设计没什么高深的东西但有几个细节很容易被忽略。event_id 必须是全局唯一且带幂等的数据回流时重复发一次下游能识别出来直接丢弃event_time 必须带时区不然跨域投放的数据回流到数仓时间对不上user 节点里同时保留 one_id 和原始 ID 映射方便排查。属性字段尽量用扁平结构嵌套别超过两层否则后面做标签加工时会很难受。3.4 工具选型自研还是采购别一上来就纠结没有一套现成系统能同时满足 CDP、DMP、CRM、MDW 的所有功能。所以在工具选型上我给团队的建议是先定哪些必须买、哪些可以自研、哪些用开源改造。必须买的通常是 DSP 和 DMP 这类跟广告平台强绑定的服务因为设备 ID 库、媒体资源、投放优化算法都需要和头部流量平台深度绑定自研几乎不可能。CDP 比较尴尬自研周期长采购价格高。我的建议是如果企业已有成熟数仓团队可以选择一个轻量级 CDP 或直接基于 ClickHouse/Doris 自研画像服务如果业务部门很急想三个月内看到效果那就买成熟 CDP 产品但要留好底层数据导出的接口防止后面被厂商绑定。CRM 的开源生态比较成熟像芋道 CRM、青动 CRM 这类开源项目做二次开发性价比很高。不过要注意开源项目主要解决了客户管理 销售流程的问题它并不是 CDP别指望它具备 OneID 合并和实时画像能力。网上很多人搜永久在线的 CRM 网站或免费 CRM期待一个免费的网页工具就能解决所有客户管理问题这种理解是错的CRM 的可用性取决于它背靠多少真实、及时、合规的数据页面常驻在线只是最基础的条件。团队可能花几周搭起来一个开源 CRM却发现里面的客户数据没有数据仓库支撑越用越虚最后变成一个记录 Excel 的工具。我整理了一个简化选型评分表供你参考维度自研采购商业版开源二次开发交付周期6-12 个月1-3 个月2-4 个月定制灵活性高中中高数据主权完全自主视合同而定自主长期维护成本高需养团队中年费高中需养少量开发生态完整性低高中适合场景超大规模、强定制业务急、预算足中小团队、预算有限3.5 落地优先级从 0 到 1 的四个阶段企业预算有限时不可能六个系统一起上。我通常会建议按下面四个阶段排布第一阶段先打基础统一埋点规范和数仓分层。不管后面上什么系统最底层的数据采集和口径必须先行。这一阶段重点做 CDM 和 MDW把业务对象模型定义好把数据从业务源系统同步到数仓。没有这一步后面 CDP 拿到的就是脏数据DMP 人群包也建不准。第二阶段上 CRM把跟客户互动的主流程管起来。对绝大多数企业来说CRM 是最容易见效的销售和客服人员第二天就能用上客户跟进过程也能完整沉淀下来。第三阶段上 CDP。这时候数仓里已经有清洗过的事件数据和订单数据CDP 的 OneID 合并和实时标签才能真正发挥价值。如果没做前两步就上 CDP你会发现标签算出来没人信因为源数据太乱。第四阶段把 DMP 和 DSP 的广告链路接进来。这个阶段的前提是 CDP 已经有可输出的高价值人群否则 DMP 只是在用第三方数据盲投效率很有限。4. 现场实录客户数据对不上、人群包失效这类坑怎么排查4.1 为什么 CDP 和 CRM 的客户数量总对不上这是被问得最多的问题。一般情况下CDP 的客户数会大于 CRM 的客户数因为 CDP 覆盖了所有被识别到的匿名和实名用户CRM 只保存了达到某个业务阶段的有效客户。但如果你发现 CDP 客户数突然比 CRM 少了几十万问题通常出在 ID 映射表更新失败或者 OneID 合并范围过大把多个真实客户错误合并成了一个。排查思路先对账注册用户数这一个口径分别查 CDP 的注册事件和 CRM 的客户创建记录按天对比差异再看 ID 映射表最近同步的成功率最后看有没有人工合并误操作。经验是给所有合并操作加审计日志出问题能直接定位到人、到时间点。还有一种常见情况是 CRM 做了客户归档或删除但 CDP 不知道。CRM 删掉一个客户后CDP 里的画像标签如果没联动更新就会继续向 DMP 推送这个人的数据造成删了还在投的尴尬。解决方法是打通删除/归档事件CRM 侧变更后立即通知 CDP 做状态同步。4.2 DMP 人群包投放后转化率波动大我见过团队忙活一周建好一个人群包投出去第三天转化率暴跌 60%。原因往往是人群包规模太小系统匹配量不足。3000 人以下的人群包在头部广告平台里基本跑不出有效样本AI 模型无法学习效果一定不稳定。一般建议人群包至少 5 万以上新客扩量包最好 50 万以上起步。另一个原因是设备 ID 有效期问题。iOS 的 IDFA 在用户重置广告标识后就会失效安卓也有 OAID 重置机制。人群包如果用的是三个月前的数据实际能触达的人数可能不足 50%。排查时先看 DMP 系统报告的有效匹配率低于 60% 就说明 ID 已经大量失效需要重新从 CDP 同步数据。还有一个容易被忽略的因素投放时间段。服饰、食品等品类的转化率受季节和促销活动影响极大如果人群包的建包时间在双 11 前、投放时间在双 11 后人群意图早就变了效果自然差。4.3 MDW 里出现串号和重复数据多系统回流到 MDW 后最典型的问题是同一个客户存在多条记录。原因是不同系统用了不同的主键CRM 里有 customer_idCDP 里有 one_idDMP 回流的数据里只有 device_id到了 MDW 如果直接合并就会出现同一个人被识别成多个人或者 A 的历史订单串到 B 的名下。解决办法是在 MDW 里建立统一的实体关系模型把 natural key比如手机号和 business key比如 customer_id分开存MDW 层不直接覆盖业务系统的原始键也不直接 c CRUD只做增量追加。加载任务必须有幂等键比如订单事件唯一键是 order_id event_type客户更新唯一键是 customer_id modified_time。没有幂等键的回流任务禁止上线。这里想多说一句我在网上看到不少关于dmp 文件的搜索比如达梦数据库命令行备份 dmpOracle 导入 dmp 文件dmp 文件修改标头版本这里的 DMP 是 Dump File数据库备份文件和我们讨论的 Data Management Platform 完全是两个世界的同名缩写。做数据管理的人要习惯这种同名词和开发沟通时最好说全称避免理解偏差。4.4 字段命名混乱怎么用 CDM 治理中小团队最常见的数仓问题是同一个字段在不同表里叫法完全不一样。CRM 里叫 customer_name订单表里叫 buyer_name埋点日志里叫 uname到了报表环节还得靠人工翻译。CDM 的落地方式不是去改所有源头系统的字段而是建立一个映射标准层。具体做法是在 MDW 贴源层之上增加一个标准模型层所有字段按 CDM 规则重新命名。比如统一命名规范客户主键为 customer_id订单主键为 order_id商品主键为 item_id统一时间为 event_time统一渠道名为 channel_code。CDM 标准模型层输出的表只认这套命名下游报表和算法都基于这套标准取数。维护 CDM 需要单独的元数据管理流程至少要有三件套数据字典每个字段的明确定义和枚举值、数据血缘字段来自哪些源表、经过哪些加工、数据负责人字段出问题找谁。没有这三样CDM 很快会变成一纸空文。4.5 实时还是离线时效性怎么选很多团队一开始就追求实时把所有链路都改成 Flink 实时计算结果资源消耗巨大业务又用不上。我建议按场景区分实时场景CDP 的实时事件接入、电商风控、客服弹屏、导购实时推荐。这些场景对延迟的要求是秒级到分钟级。准实时场景标签更新、人群包同步延迟 5-15 分钟完全可接受。Django 也好Flink 也好没必要为了做到分钟级把所有数据都走流计算。离线场景MDW 的汇总表、经营报表、算法训练集T1 就够了甚至 T7 也没问题。现在很多 CDP 产品会把旁路捕获作为卖点就是通过监听数据库日志或者消息队列的方式不改动业务代码就能拿到实时事件。这个方案确实能减少业务系统的改造但下游要额外处理日志解析、幂等、乱序问题复杂度并不低。建议中小团队优先用埋点 SDK 服务端事件上报实现简单也好排查等团队数据能力成熟了再上旁路采集。从我自己的实践来看最值得警惕的不是技术选型而是先买工具再想场景的顺序错误。多花两周把 CDM 的数据模型设计和跨系统的责任边界表格讨论清楚比多花半年在 CDP 和 CRM 的数据对不上、标签算不准这些烂摊子里挣扎要划算得多。客户数据管理从来不缺概念缺的是把每个系统放在对的位置上并且用一套共同的标准把它们串起来。