
在客户数据平台(CDP)建设中,最容易被低估的不是“能不能接入数据”,而是接入后的数据能否形成稳定链路:身份能否统一、标签能否计算、人群能否圈选、触达结果能否回流。
如果只把 App、小程序、Web、CRM、订单和会员数据集中到一个表里,系统更像数据仓库的一个客户主题域。要让 CDP 真正进入业务流程,需要在架构上补齐 OneID、标签、人群和事件回流几个模块。
CDP 的底层通常会维护一张统一客户表,用来承接多端身份归并后的结果。一个简化的数据结构可以这样设计:
CREATE TABLE cdp_user_profile (
gio_id STRING,
user_id STRING,
union_id STRING,
mobile_hash STRING,
device_id STRING,
first_seen_time TIMESTAMP,
last_seen_time TIMESTAMP,
profile_version BIGINT
);这里的关键不是字段数量,而是主键治理策略。gio_id 或内部统一 ID 需要承接不同来源的身份标识,并记录版本,避免后续 ID 合并、拆分和更新时影响历史分析结果。
OneID 解析不能只靠简单的手机号匹配。实际项目中,设备 ID、账号 ID、UnionID、手机号、会员 ID 和订单 ID 的可信度不同,需要区分确定关系和弱关系。
一个常见做法是建立身份映射表:
CREATE TABLE cdp_identity_map (
id_type STRING,
id_value STRING,
gio_id STRING,
confidence INT,
source_system STRING,
updated_at TIMESTAMP
);手机号、会员 ID、登录账号通常可以作为高置信关系;设备 ID、Cookie、匿名访问标识则更适合作为辅助关系。这样做的好处是,后续在路径分析、标签计算和人群圈选时,可以明确知道当前客户画像的可信边界。
标签不是静态字段。比如“近 30 天高活跃”“最近 7 天浏览过会员权益页”“有复购倾向但未完成下单”,都需要依赖行为事件和业务数据持续计算。
以“近 30 天活跃且未购买”的标签为例,可以抽象成:
SELECT
gio_id,
CASE
WHEN active_days_30d >= 5 AND paid_order_30d = 0 THEN 1
ELSE 0
END AS tag_active_not_paid
FROM user_behavior_summary;工程上还需要记录标签口径、更新时间、依赖数据源和失效规则。否则平台里会出现大量“看起来有用、业务不敢用”的标签。
业务团队实际使用 CDP 时,很少只用单一标签。更常见的是组合条件:
因此,人群圈选模块需要支持交集、并集、排除、时间窗口和行为次数条件。底层可以使用列式存储、倒排索引或 Bitmap 来提升查询效率,避免每次圈人都依赖数据工程师临时写 SQL。
CDP 如果只负责圈选人群,链路仍然是不完整的。人群进入短信、企微、App Push、邮件或其他触点后,触达结果需要重新回到分析体系中。
回流事件可以设计成统一格式:
{
"event_name": "campaign_convert",
"gio_id": "u_1024",
"campaign_id": "c_202606",
"channel": "app_push",
"event_time": "2026-06-02T14:30:00+08:00",
"properties": {
"step": "paid_order",
"amount": 199
}
}这样才能继续分析打开、点击、转化、复购和留存变化。否则运营动作虽然发生了,但无法判断这次触达是否真的改善了业务结果。
在产品落地层面,GrowingIO 的链路可以作为一个实现样例:通过增长分析定位路径、漏斗、留存和渠道问题,再通过客户数据平台沉淀 OneID、标签和人群,最后连接智能运营完成触达和复盘。
这类架构的重点不是多部署一个系统,而是让客户数据在采集、分析、标签、人群、触达和回流之间形成闭环。对会员运营、私域运营和精细化增长团队来说,CDP 的价值也不只是存储客户资料,而是让数据持续进入业务动作。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。