Arch Day 89
Arch Day 89: CDP客户数据平台
Arch Day 89: CDP客户数据平台
2026-06-27
第三阶段 - 零售域深度CDP数据平台ID-Mapping用户画像隐私合规
日期: 2026-06-27 (Day 89) 阶段: 第三阶段 - 零售域深度 标签: #CDP #数据平台 #ID-Mapping #用户画像 #隐私合规
核心概念
一句话定义
CDP（Customer Data Platform）不是CRM也不是DMP——它是"统一客户数据+实时个性化"的平台。CDP的核心使命是：从所有渠道采集客户数据，通过ID Mapping构建统一客户视图，实时计算用户标签和画像，并向营销、推荐、客服等下游系统输出数据能力。
为什么关注
在后Cookie时代和隐私法规趋严的大背景下，CDP成为企业数据驱动增长的核心基础设施：
- Cookie废弃：Google在2024年正式弃用第三方Cookie，传统DMP失去数据源
- 隐私法规：GDPR累计罚款已达58.8亿欧元，EU AI Act 2026年8月生效，中国《个人信息保护法》严格执行
- 全域经营：企业需要打通线上线下、公域私域的客户数据
- 实时个性化：用户期望"懂我"的实时个性化体验
- 数据孤岛：70%+的企业存在严重的数据孤岛问题
CDP vs CRM vs DMP vs 数据仓库
┌──────────┬──────────────┬──────────────┬──────────────┬──────────────┐
│ 维度 │ CDP │ CRM │ DMP │ 数据仓库 │
├──────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 定位 │ 统一客户数据 │ 客户关系管理 │ 广告受众管理 │ 企业数据中心 │
│ │ +实时个性化 │ │ │ │
├──────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 数据类型 │ 第一方+第二方 │ 第一方 │ 第三方为主 │ 全部 │
│ │ 已知+匿名 │ 已知客户 │ 匿名为主 │ │
├──────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ ID标识 │ OneID(持久) │ 客户ID │ Cookie(临时) │ 业务ID │
├──────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 实时性 │ 实时+批量 │ 批量为主 │ 近实时 │ 批量（T+1） │
├──────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 主要用户 │ 营销/产品/数据│ 销售/客服 │ 广告投放 │ 数据分析师 │
├──────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 数据保留 │ 持久存储 │ 持久存储 │ 90天（Cookie）│ 持久存储 │
├──────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 典型产品 │ Segment/ │ Salesforce/ │ BlueKai/ │ Snowflake/ │
│ │ mParticle/ │ HubSpot │ Lotame │ BigQuery │
│ │ 神策/LinkFlow│ │ │ │
├──────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 2026趋势│ Composable │ AI CRM │ 逐渐衰退 │ Lakehouse │
│ │ CDP兴起 │ (AI Agent) │ (Cookie消亡) │ │
└──────────┴──────────────┴──────────────┴──────────────┴──────────────┘
误区与反模式
| 误区 | 现实 |
|---|---|
| "CDP=另一个数据仓库" | CDP关注客户维度+实时能力+对外输出，数据仓库关注全量数据+离线分析 |
| "买个CDP产品就解决了" | CDP需要大量数据治理和业务定义工作，产品只是工具 |
| "CDP越全越好" | 采集不需要的数据反而增加合规风险和存储成本 |
| "实时=所有数据都要实时" | 只有影响实时体验的数据才需要实时，其他T+1足够 |
| "DMP还有用" | 第三方Cookie已废弃，DMP的核心数据源消失 |
知识点详解
一、数据采集
1.1 采集方式全景
┌─────────────────────────────────────────────────────────────┐
│ CDP数据采集全景 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 客户端采集（前端埋点）: │
│ ├── Web SDK：页面浏览/点击/停留时间/滚动深度 │
│ ├── App SDK：启动/页面/事件/崩溃 │
│ ├── 小程序SDK：页面/事件/分享 │
│ └── 采集方式： │
│ ├── 全埋点（自动采集所有交互） │
│ ├── 代码埋点（开发手动插入埋点代码） │
│ └── 可视化埋点（运营在页面上圈选元素） │
│ │
│ 服务端采集: │
│ ├── 订单数据（交易系统→Kafka→CDP） │
│ ├── 会员数据（CRM→API→CDP） │
│ ├── 客服数据（工单系统→CDP） │
│ └── 门店数据（POS→CDP） │
│ │
│ 第三方数据: │
│ ├── 广告平台回传（Google/Meta/抖音） │
│ ├── 社交平台数据（微信/微博） │
│ ├── 数据服务商（天眼查/企查查） │
│ └── 注意：需遵守数据授权和隐私法规 │
│ │
│ 离线数据导入: │
│ ├── Excel/CSV批量导入（历史数据迁移） │
│ ├── 数据库定期同步（CDC/批量抽取） │
│ └── ETL管道（Airflow/dbt） │
│ │
└─────────────────────────────────────────────────────────────┘
1.2 数据采集规范
事件数据模型（Event-based）:
{
"event_name": "product_view", // 事件名
"event_time": "2026-06-27T10:30:00", // 事件时间
"user_id": "M000001", // 用户ID（已登录）
"anonymous_id": "device_abc123", // 匿名ID（未登录）
"properties": { // 事件属性
"product_id": "SKU_10001",
"product_name": "夏季连衣裙",
"category": "女装",
"price": 299.00,
"source": "search"
},
"context": { // 上下文
"platform": "ios_app",
"app_version": "3.2.1",
"os": "iOS 18.0",
"device_model": "iPhone 16",
"ip": "xxx.xxx.xxx.xxx",
"city": "上海",
"utm_source": "douyin",
"utm_campaign": "summer_sale"
}
}
核心事件清单（零售场景）：
├── 浏览类：page_view, product_view, search, category_browse
├── 交互类：add_to_cart, add_to_wishlist, share, review
├── 交易类：checkout, payment, order_completed, refund
├── 会员类：register, login, level_up, points_earn, points_consume
└── 营销类：coupon_receive, coupon_use, promotion_click
二、ID Mapping（身份解析）
2.1 ID Mapping核心架构
ID Mapping = 把"碎片化的用户身份"关联成"统一的人"
┌─────────────────────────────────────────────────────────────┐
│ ID Mapping引擎 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ID采集层 │ │
│ │ │ │
│ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │
│ │ │手机号│ │邮箱 │ │微信 │ │设备 │ │Cookie│ │ │
│ │ │ │ │ │ │OpenID│ │IDFA/ │ │ │ │ │
│ │ │ │ │ │ │UnionID│ │OAID │ │ │ │ │
│ │ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ │ │
│ │ └────┬───┴────┬───┴────┬───┴────┬───┘ │ │
│ └──────────┼────────┼────────┼────────┼─────────────┘ │
│ ▼ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 确定性匹配引擎 │ │
│ │ │ │
│ │ 规则： │ │
│ │ IF 手机号相同 → 合并（置信度=1.0） │ │
│ │ IF 邮箱相同 → 合并（置信度=0.95） │ │
│ │ IF 微信UnionID相同 → 合并（置信度=0.98） │ │
│ │ IF 登录同一账号 → 关联设备ID（置信度=0.9） │ │
│ └────────────────────────┬────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 概率性匹配引擎 │ │
│ │ │ │
│ │ 特征： │ │
│ │ ├── 同一WiFi网络的多设备 │ │
│ │ ├── 相同地理位置 + 相近时间 │ │
│ │ ├── 相似浏览行为模式 │ │
│ │ ├── 相同收货地址 │ │
│ │ └── IP + User-Agent组合 │ │
│ │ │ │
│ │ 算法： │ │
│ │ ├── 逻辑回归/XGBoost（特征→匹配概率） │ │
│ │ └── 阈值：概率>0.8才合并 │ │
│ └────────────────────────┬────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Identity Graph │ │
│ │ │ │
│ │ 节点：各种ID（手机号/设备ID/Cookie/账号ID/...） │ │
│ │ 边：匹配关系（确定性/概率性 + 置信度权重） │ │
│ │ │ │
│ │ 算法： │ │
│ │ ├── 连通分量：找到所有关联的ID组 │ │
│ │ ├── 社区发现：识别ID簇 │ │
│ │ ├── 权重裁剪：去除低置信度边 │ │
│ │ └── 主ID选择：每个簇选择一个主ID（如手机号） │ │
│ │ │ │
│ │ 存储：图数据库（Neo4j/JanusGraph）+ 缓存（Redis） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
2.2 ID Mapping难点与解决
难点1: 同一手机号多人使用（家庭共用）
├── 现象：一个手机号关联了明显不同的行为模式
├── 检测：行为向量聚类，发现多个行为簇
├── 解决：一个手机号 → 多个"身份"（主身份+家庭成员）
└── 注意：大部分场景不需要区分，只在高精度场景处理
难点2: 一人多号（工作号+生活号）
├── 现象：两个手机号的设备ID有重叠
├── 检测：概率性匹配发现高度相似的行为
├── 解决：基于设备ID/地址/IP的概率性合并
└── 置信度：通常0.7-0.8，需要谨慎
难点3: ID变化（换手机/换号码）
├── 现象：旧ID不再活跃，新ID出现
├── 检测：旧设备上出现新手机号登录
├── 解决：保留历史关联，标记时效性
└── 策略：关联关系设置TTL（如180天未活跃则弱化）
难点4: 大规模数据的图计算性能
├── 挑战：亿级节点的Identity Graph
├── 解决：
│ ├── 增量计算：只处理新增/变更的边
│ ├── 分区计算：按区域/时间分区并行处理
│ └── 近似算法：不需要全局最优，局部最优足够
└── 工具：Spark GraphX / GraphFrames
三、用户画像
3.1 360度客户画像
┌─────────────────────────────────────────────────────────────┐
│ 360° 客户画像 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 基础属性（Who）: │
│ ├── 人口统计：性别/年龄/城市/职业 │
│ ├── 会员信息：等级/积分/注册时间/来源渠道 │
│ └── 联系方式：手机/邮箱/微信/地址 │
│ │
│ 行为特征（What）: │
│ ├── 浏览行为：访问频次/停留时长/浏览深度/搜索词 │
│ ├── 购买行为：购买频次/客单价/品类偏好/SKU偏好 │
│ ├── 互动行为：收藏/加购/评价/分享/客服咨询 │
│ └── 营销响应：优惠券使用率/Push打开率/活动参与率 │
│ │
│ 价值特征（How Much）: │
│ ├── RFM：最近购买/购买频率/消费金额 │
│ ├── CLV：客户终身价值预测 │
│ ├── 利润贡献：毛利/净利 │
│ └── 钱包份额：在品类中的消费占比估计 │
│ │
│ 生命周期（Where）: │
│ ├── 阶段：新客→活跃→沉默→流失→召回 │
│ ├── 成长轨迹：每月消费趋势 │
│ └── 流失风险：未来30天流失概率 │
│ │
│ 偏好特征（Like）: │
│ ├── 品类偏好：最常购买的品类Top5 │
│ ├── 品牌偏好：最常购买的品牌Top5 │
│ ├── 价格偏好：低价/中档/高端 │
│ ├── 渠道偏好：App/小程序/门店/直播 │
│ └── 时间偏好：常购买的时段/星期 │
│ │
│ 预测特征（Will）: │
│ ├── 下次购买品类预测 │
│ ├── 下次购买时间预测 │
│ ├── 价格敏感度预测 │
│ └── 响应概率预测（对某活动/商品的响应概率） │
│ │
└─────────────────────────────────────────────────────────────┘
3.2 画像数据模型
-- 用户画像宽表（核心查询入口）
CREATE TABLE user_profile (
member_id BIGINT PRIMARY KEY,
-- 基础属性
gender TINYINT,
age INT,
city VARCHAR(20),
register_channel VARCHAR(20),
member_level VARCHAR(10),
-- RFM指标
rfm_recency_days INT, -- 最近购买距今天数
rfm_frequency_30d INT, -- 30天购买次数
rfm_monetary_30d DECIMAL(12,2), -- 30天消费金额
rfm_segment VARCHAR(20), -- RFM分群标签
-- 行为特征
visit_freq_7d INT, -- 7天访问次数
avg_session_duration DECIMAL(8,2), -- 平均会话时长(秒)
cart_abandon_rate DECIMAL(5,4), -- 加购未购比例
-- 偏好
top_category_1 VARCHAR(50), -- 偏好品类Top1
top_category_2 VARCHAR(50),
top_brand_1 VARCHAR(50), -- 偏好品牌Top1
price_preference VARCHAR(10), -- LOW/MID/HIGH
channel_preference VARCHAR(20), -- APP/MINI/STORE
-- 预测
churn_probability DECIMAL(5,4), -- 流失概率
clv_prediction DECIMAL(12,2), -- CLV预测值
next_buy_days INT, -- 预计下次购买天数
lifecycle_stage VARCHAR(20), -- NEW/ACTIVE/SILENT/LOST
-- 元数据
updated_at TIMESTAMP
);
-- 标签明细表（灵活标签）
CREATE TABLE user_tag (
member_id BIGINT,
tag_key VARCHAR(50), -- 标签键
tag_value VARCHAR(200), -- 标签值
tag_type VARCHAR(20), -- BASE/FACT/BEHAVIOR/PREDICT
confidence DECIMAL(3,2), -- 标签置信度
source VARCHAR(20), -- 来源系统
expire_time TIMESTAMP, -- 标签过期时间
updated_at TIMESTAMP,
PRIMARY KEY (member_id, tag_key)
);
四、实时标签引擎
4.1 批流一体标签计算
┌──────────────────────────────────────────────────────────────┐
│ 批流一体标签引擎 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 实时流（Flink）: │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 行为事件 │──→│ Flink │──→│ 实时标签 │ │
│ │ (Kafka) │ │ 实时计算 │ │ (Redis) │ │
│ └──────────┘ │ │ └──────────┘ │
│ │ 规则： │ │
│ │ ·加购30min│ │
│ │ 未付款 │ │
│ │ ·浏览品类│ │
│ │ 统计 │ │
│ │ ·实时意图│ │
│ │ 识别 │ │
│ └──────────┘ │
│ │
│ 离线批量（Spark）: │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 数据仓库 │──→│ Spark │──→│ 批量标签 │ │
│ │ (Hive) │ │ 批量计算 │ │ (HBase) │ │
│ └──────────┘ │ │ └──────────┘ │
│ │ 任务： │ │
│ │ ·RFM计算 │ │
│ │ ·画像更新│ │
│ │ ·模型预测│ │
│ └──────────┘ │
│ │
│ 标签合并层: │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ 查询时合并： │ │
│ │ 实时标签(Redis) + 批量标签(HBase) → 完整画像 │ │
│ │ │ │
│ │ 优先级：实时标签 > 批量标签 │ │
│ │ 更新频率：实时标签=秒级，批量标签=T+1 │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ 标签API服务: │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ GET /api/user/{member_id}/tags │ │
│ │ GET /api/user/{member_id}/profile │ │
│ │ POST /api/audience/select (人群圈选) │ │
│ │ POST /api/user/{member_id}/event (事件上报) │ │
│ │ │ │
│ │ SLA: P99 < 50ms │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘
4.2 实时意图识别
实时意图识别 = 根据用户当前行为，实时判断用户"想做什么"
意图类型：
├── 购买意图：反复浏览同一商品/加购/查看评价
├── 比价意图：在多个同类商品间切换浏览
├── 流失意图：访问频率下降/浏览时长缩短
├── 投诉意图：查看退款政策/联系客服
└── 探索意图：广泛浏览不同品类/新品
实现方案：
├── 规则引擎（简单意图）
│ IF 同一SKU浏览>3次 AND 查看评价 → 购买意图(高)
│ IF 加购后30分钟未付款 → 犹豫意图 → 触发催付
│
├── ML模型（复杂意图）
│ 输入特征：最近N个行为事件序列
│ 模型：LSTM/Transformer序列模型
│ 输出：意图分类 + 置信度
│
└── Flink实现
事件流 → 窗口聚合(5min) → 特征提取 → 模型推理 → 意图标签
→ Redis更新 → 下游消费（推荐/营销/客服）
五、GDPR/个保法对CDP架构的影响
5.1 合规要求对架构的影响
GDPR(欧盟) + 个保法(中国) + CCPA(加州) 的核心要求：
1. 数据最小化原则
├── 要求：只采集必要的数据
├── 架构影响：
│ ├── 采集前必须有"目的性评估"
│ ├── 不需要的字段不采集（而非"先采后删"）
│ └── 数据保留期限设计（到期自动删除）
└── 实现：数据分类分级 + TTL机制
2. 用户同意管理（Consent Management）
├── 要求：明确告知用途，获取用户同意
├── 架构影响：
│ ├── 需要Consent Management Platform (CMP)
│ ├── 每条数据需要关联"同意记录"
│ ├── 同意粒度：按目的（营销/分析/个性化）分别授权
│ └── 2026新要求：一键拒绝机制，与同意按钮同等显眼
└── 实现：consent表 + 数据处理前consent检查
3. 数据主体权利（DSAR）
├── 要求：用户有权查看/导出/删除自己的数据
├── 架构影响：
│ ├── 需要数据查询接口（"我的数据在哪里？"）
│ ├── 需要数据导出功能（结构化格式）
│ ├── 需要数据删除功能（被遗忘权 / Right to be Forgotten）
│ └── 30天内必须响应
└── 实现：数据目录 + 自动化DSAR处理流水线
4. 数据跨境传输
├── 要求：数据出境需要安全评估
├── 架构影响：
│ ├── 中国用户数据需要境内存储
│ ├── 跨国企业需要"数据本地化"架构
│ └── 出境需通过安全评估或标准合同
└── 实现：区域化部署 + 数据分类标记
5. 自动化决策透明度
├── 要求：用户有权了解自动化决策逻辑
├── 架构影响：
│ ├── AI推荐/定价/风控需要可解释性
│ ├── 用户可以请求"人工审核"
│ └── EU AI Act 2026年8月生效，高风险AI系统需合规
└── 实现：模型可解释性 + 人工覆盖机制
5.2 隐私优先的CDP架构
┌─────────────────────────────────────────────────────────────┐
│ 隐私优先的CDP架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 数据采集层 │ │
│ │ ├── 采集前：用途声明 + Consent获取 │ │
│ │ ├── 采集时：数据加密传输 (TLS) │ │
│ │ ├── 采集后：PII自动脱敏/加密 │ │
│ │ └── 不采集：非必要数据（数据最小化） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 同意管理中心 │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ Consent │ │ 用途管理 │ │ DSAR │ │ │
│ │ │ 采集/存储│ │ 营销/分析 │ │ 处理引擎 │ │ │
│ │ │ │ │ /个性化 │ │ 查/导/删 │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 数据存储层 │ │
│ │ │ │
│ │ 安全措施： │ │
│ │ ├── PII字段加密存储（AES-256） │ │
│ │ ├── 访问控制（RBAC + 数据分级） │ │
│ │ ├── 审计日志（谁在什么时候访问了什么数据） │ │
│ │ ├── 数据保留策略（TTL + 自动归档/删除） │ │
│ │ └── 数据本地化（区域化部署） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 数据使用层 │ │
│ │ │ │
│ │ ├── 使用前检查Consent（每次数据读取前验证） │ │
│ │ ├── 匿名化/假名化（分析场景不需要PII） │ │
│ │ ├── 差分隐私（聚合查询时添加噪声） │ │
│ │ └── 用途限制（营销数据不能用于风控） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
六、Composable CDP（2025-2026新趋势）
传统CDP vs Composable CDP:
传统CDP（Packaged CDP）:
├── 自带数据存储
├── 数据从源→CDP→目标，存了一份副本
├── 数据新鲜度依赖同步频率
├── 存储成本高（重复存储）
└── 代表：Segment, mParticle
Composable CDP:
├── 不自带存储，直接读数据仓库
├── 数据仍在数据仓库中（Snowflake/BigQuery/Databricks）
├── 无数据副本，减少安全风险
├── 数据最新（直接读源头）
├── 满足数据最小化原则
└── 代表：Census, Hightouch, dbt + Reverse ETL
架构对比：
传统CDP:
源系统 → ETL → CDP(存储) → 营销/推荐/客服
Composable CDP:
源系统 → ETL → 数据仓库 ← Composable CDP(计算+激活)
↓
营销/推荐/客服
Composable CDP的优势：
├── 数据治理更简单（单一数据源）
├── 合规更容易（减少数据副本）
├── 成本更低（不重复存储）
├── 灵活度更高（SQL定义标签/画像）
└── 2025-2026年已成为主流趋势
架构设计实操
CDP完整架构设计
┌─────────────────────────────────────────────────────────────────────┐
│ CDP完整架构 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────── 数据采集层 ────────────────────────────┐ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │Web SDK │ │App SDK │ │Server │ │3rd │ │Offline │ │ │
│ │ │ │ │ │ │API │ │Party │ │Import │ │ │
│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │
│ │ └──────┬───┴──────┬───┴──────┬───┴──────┬───┘ │ │
│ │ ▼ │ │
│ │ ┌──────────────────────────────────────────┐ │ │
│ │ │ 数据采集网关 (Consent Check) │ │ │
│ │ └──────────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────── 数据处理层 ────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 数据清洗 │ │ ID Mapping │ │ 数据标准化 │ │ │
│ │ │ ·格式校验 │ │ ·确定性匹配 │ │ ·字段映射 │ │ │
│ │ │ ·异常过滤 │ │ ·概率性匹配 │ │ ·编码统一 │ │ │
│ │ │ ·PII脱敏 │ │ ·Identity │ │ ·质量评分 │ │ │
│ │ │ │ │ Graph │ │ │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────── 存储层 ────────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 事件存储 │ │ 画像存储 │ │ 标签存储 │ │ 图存储 │ │ │
│ │ │ Kafka+ │ │ HBase │ │ Redis+ │ │ Neo4j │ │ │
│ │ │ ClickHouse│ │ (宽表) │ │ HBase │ │ (ID │ │ │
│ │ │ │ │ │ │ │ │ Graph) │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────── 计算层 ────────────────────────────────┐ │
│ │ │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │
│ │ │ 实时计算 │ │ 离线计算 │ │ ML计算 │ │ │
│ │ │ Flink │ │ Spark/dbt │ │ ·流失预测 │ │ │
│ │ │ ·实时标签 │ │ ·画像刷新 │ │ ·CLV预测 │ │ │
│ │ │ ·意图识别 │ │ ·RFM计算 │ │ ·意图分类 │ │ │
│ │ │ ·事件聚合 │ │ ·标签计算 │ │ ·Lookalike │ │ │
│ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────── 数据输出层（开放API）──────────────────┐ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │
│ │ │ 营销系统 │ │ 推荐系统 │ │ 客服系统 │ │ BI/报表 │ │ │
│ │ │ 人群圈选 │ │ 实时画像 │ │ 客户视图 │ │ 分析查询 │ │ │
│ │ │ +触达 │ │ +个性化 │ │ +服务 │ │ │ │ │
│ │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────── 治理层（横切关注点）───────────────────┐ │
│ │ ·数据质量监控 ·隐私合规(Consent) ·审计日志 ·数据目录 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
AI增强
AI在CDP中的应用
1. AI用户画像
├── 自动标签发现：从行为数据中自动发现有意义的用户分群
├── 标签自动命名：AI给自动发现的标签起可理解的名称
└── 画像补全：基于已有数据推断缺失属性
2. 实时意图识别
├── 序列模型：LSTM/Transformer处理行为序列
├── 多模态：文本（搜索词）+ 行为（浏览序列）+ 时间模式
└── 输出：当前意图（购买/比价/流失/投诉）+ 置信度
3. Lookalike人群扩展
├── 种子人群 → 特征提取 → 相似度计算 → 扩展人群
├── 算法：Embedding相似度 / 协同过滤
└── 应用：高价值用户种子→找到更多潜在高价值用户
4. 流失预警
├── 特征：RFM趋势/活跃度变化/客诉频率/竞品行为
├── 模型：XGBoost/LightGBM（每周更新）
├── 输出：30天流失概率 + 关键影响因子
└── 行动：概率>0.6触发挽留营销
5. LLM增强（2025-2026前沿）
├── 自然语言查询："过去30天在上海消费超过5000元的女性用户有多少？"
├── 洞察生成：AI自动分析数据并生成文字洞察报告
└── 策略建议：基于画像数据建议最优营销策略
Web3关联
CDP与Web3的交叉：
1. 链上行为作为CDP数据源
├── 用户的链上交易行为可以作为标签
├── DeFi用户/NFT收藏家/DAO参与者 → 标签
└── Web3原生CDP（如Ceramic/Lens Profile）
2. 去中心化身份（DID）对CDP的挑战
├── 用户控制自己的数据（而非企业控制）
├── 选择性披露（只分享必要信息）
└── 可验证凭证（Verifiable Credentials）
3. 数据主权Token化
├── 用户的画像数据 → NFT/Token
├── 用户授权品牌使用 → 获得Token奖励
└── 数据DAO：集体管理个人数据
现实判断：2026年这些概念仍在早期探索阶段，
但GDPR/个保法推动的"用户数据主权"趋势，
与Web3的"自主身份"理念高度吻合。
今日思考
CDP的本质是解决一个简单但困难的问题：如何在正确的时间，通过正确的渠道，给正确的人，传达正确的信息？
这个问题的难度在于：(1)你要认识这个人（ID Mapping），(2)你要了解这个人（画像标签），(3)你要实时响应（实时计算），(4)你要合规地做（隐私保护）。
2025-2026年最重要的两个趋势：一是Composable CDP——不再重复存储数据，直接读数据仓库；二是隐私优先架构——GDPR累计罚款58.8亿欧元，EU AI Act 2026年8月生效，隐私合规不是"附加功能"而是"架构基础"。
面试题
Q1: CDP和DMP有什么区别？
简短回答：CDP基于第一方数据、持久化用户身份、支持实时个性化；DMP基于第三方Cookie数据、身份临时性、主要用于广告投放。随着Cookie废弃，DMP正在衰退，CDP成为主流。
详细回答：
| 维度 | CDP | DMP |
|---|---|---|
| 数据来源 | 第一方为主 | 第三方Cookie为主 |
| 用户身份 | 持久化OneID | 临时Cookie（90天） |
| 数据粒度 | 个体级别 | 群体/画像级别 |
| 实时性 | 实时+批量 | 批量为主 |
| 主要用途 | 全渠道个性化 | 程序化广告投放 |
| 2026现状 | 快速增长 | 因Cookie废弃而衰退 |
Q2: ID Mapping如何实现跨渠道识别？
简短回答：三层匹配——确定性匹配（手机号/邮箱，100%确定）→概率性匹配（设备/行为，80%+概率）→Identity Graph图算法（连通分量发现同一人的所有ID）。
详细回答：
- 确定性匹配：手机号/邮箱/身份证号直接匹配，准确率>95%
- 概率性匹配：设备ID/IP/行为模式组合计算匹配概率，ML模型
- Identity Graph：构建ID关联图，用连通分量/社区发现算法识别同一人
- 难点：同号多人（家庭共用）、一人多号、ID变化（换机/换号）
- 存储：图数据库（Neo4j/JanusGraph）存关系，Redis缓存热点查询
- 合规：所有匹配在用户授权范围内，符合个保法/GDPR要求
学习资源
- LinkFlow CDP科普：什么是CDP
- SelectDB: CDP画像业务应用场景
- CDP Data Governance Framework 2025
- Privacy Laws 2026 Guide
- GDPR Compliance Guide 2026
- 神策数据CDP解决方案
- 书籍推荐：《Customer Data Platforms》（Martin Kihn & Chris O'Hara）
明日预告
Day 90: 零售数据仓库设计 — 数据仓库是零售数字化的"大脑"。我们将深入数仓分层模型（ODS→DWD→DWS→ADS），零售核心指标体系，维度建模方法（星型/雪花型），以及指标中台设计，完成零售域深度学习的收官。