本文主要梳理 CDP 常见的使用场景以及 CDP 系统数据接入的一些探查和治理工作。
一、数据整合以及 id 打通
1. 业务场景介绍：数据整合和 id 打通的目的和必要性
在数据爆发式增长的现代社会，数据的量级越来越大且分散在各处，形成了一个个数据孤岛，一家企业的不同部门可能都有不同的数据分析需求，那么可能就存在很多烟囱式的开发与存储，在企业数据应用的层面上来讲其实是定义模糊且耗费成本的。那么 One Data & One Service 的数据整合就显得非常有必要，能够打破数据壁垒（比如统一各个订单系统的订单系统），统一分析口径和维度（比如统一不同部门之间的商品编码格式），减少数据分析成本，为企业级的数据分析赋能，以便于让数据真正的变成资产。
在数据整合过程中还有一个非常基本且必要的操作，那就是 id mapping，id mapping 广义上是指用户身份的 id 打通，用于整合用户多处信息，便于生成一份比较完整的用户画像，更好的指导营销活动。比如用户在小程序留下了手机号这个身份 id，如果企业官网上或者其它合作方也能获得用户手机号并进行打通，那么从小程序的行为和其它合作方以及官网上的行为数据来看，我们对用户就有了一个更大的视角，可以根据用户的一些行为在小程序上进行合适的营销活动。
2. id 打通方式以及步骤
一般打通方式有三种：全关联打通、第一优先级 id 唯一 和 高优先级 id 唯一三种方式
三种方式对应不同的业务场景，可以根据业务场景选择不同的打通方式。
全关联打通：没有 id 优先级的概念，常用于媒介领域。因为媒介获取的都是匿名id，营销对象也是设备id，而设备 id 是唯一的，不会存在过度营销的现象。
第一优先级 id 唯一：某些企业会设定主 id，一个 superid 只能对应一个主 id，一个主 id 也只能对应一个 superid，那么可能存在一个子 id 对应多个 superid 的情况和一个用户对应多个superid的情况：
例如肯德基的主id是手机号，且一个用户有一部手机，双卡双待，且两个手机号均绑定了肯德基会员，在线下门店被WIFI探针收集到了MAC地址，那么该MAC地址会绑定在两个手机号上。
应用场景：肯德基计算线下门店访客的方式是有手机号优先统计手机号，没手机号统计MAC地址，一个用户有多个手机号就算作两个访客，且不知道用户常用手机号，所以发送营销短信不介意发送同一用户的多个手机号。那么这种场景适用于第一优先级 id 唯一打通。
高优先级 id 唯一：每个 id 只能且只能绑定一个高优先级 id，当前一高优先级出现多个时，比如 openid1 绑定了 mobile1，次日 openid1 绑定了 mobile2，此时解绑旧的绑定关系，根据最新绑定事件更新绑定关系，可以减少无效绑定，避免过度营销。这种方式适用于身份 id 较多，且有 id 优先级之分，id 绑定关系是一对一或者存在一对多但是想避免过度营销的业务场景。
2.1 元数据梳理
元数据可以分为技术元数据和业务元数据，都是帮我们理解数据的业务含义的。技术元数据包括字段名称、字段长度、数据库表结构等。数据传输描述之类的数据血缘，业务元数据包括业务名称、业务定义、业务描述等。那综合在一起就可以整理为数据库表的 ER 图以及数据字典。
2.2 身份 id 确认以及 确认 id 打通优先级
元数据梳理完之后身份id的种类就体现出来了，一般会有手机号、openid、unionid、各业务系统的会员id等，然后就可以根据业务场景选择 id 打通方式了，一般 CDP 的身份id种类都很多，且都注重避免过度营销，所以一般都会选择高优先级 id 唯一的方式进行打通 。
可以定义id名称、业务含义以及正则表达式，比如手机号的正则表达为：^1[0-9]{10}$，可以对无效的身份id进行过滤。
2.3 数据接入之目标表的要求
在数据接入和清洗之前非常重要的步骤是了解目标表的数据要求，这样才能有针对性的清洗来源表，清洗成目标表要求的格式。
数据模型目前分为4类：身份 ID 模型、订单模型、行为模型、属性模型以及维度模型。即CDP将消费者的数据分成了属性、订单、行为以及相关维度四个部分，除了订单之外的消费者行为都可以归类到行为模型，例如获取使用优惠券、获取使用积分以及小程序、公众号上的行为（关注、取关、点击、浏览事件）等。
订单模型和行为模型支持混合身份id，即模型中存在身份id类型字段以区分身份id字段的类型。
订单模型目前技术上要求必填的字段只有订单主键和身份id，技术上必填是指如果是空值ETL会过滤掉该记录，但是系统配置字段的约束值不会过滤订单记录。如果订单编号没有重复且填充率100%的话，可以作为订单主键，否则需要根据实际情况加工出一个能标识每一笔订单且不会重复的主键字段。业务上必填的字段例如订单状态、下单时间等字段可以根据场景需要来定，如果源数据数据有缺失，可以进行整合清洗，例如下单时间缺失的可以用付款时间代替等。因为订单需要主键的标识，一般清洗成订单主表、订单子表、退单主表、退单子表四张表数据接入而后进行ETL，支持根据主键更新数据。
关于订单模型目标表字段的分类以及设计可以参考另一篇《数仓设计之订单模型》。
行为模型是记录用户在什么时候在哪里做了什么事情的数据集合，“哪里”对应行为模型的“行为触点”，“什么时候”对应行为模型的“行为时间”，“用户”对应“身份id”，“什么事情”对应“行为标识”，四种元素缺一不可，共同组成了行为模型的ETL过滤规则。数据接入可以分多个数据集映射，不支持根据主键更新。
属性模型是用户身份id以及用户身份属性的字段合集，需要从ods进行ETL到属性模型，且属性字段的约束值会过滤行记录。支持属性归一，即可根据业务优先级/实际填充率，将多个属性字段合并成一个新的属性字段，例如有两个数据源的性别字段，在同一用户性别冲突的情况下信任哪个数据源的性别，或者有多个标签字段，将其组合成一个标签数组字段。
维度模型是和订单模型搭配使用的一套维度合集，可创建多个维度，模型包括例如店铺、品牌、商品等目标对象的一系列描述性信息字段。单独创建维度模型是为了减少数据冗余，便于数据更新。可在创建数据标签、人群、360画像时和订单模型搭配使用。
2.4 数据探查以及清洗
了解了目标表的数据要求之后便可以进行数据探查和清洗。
关于订单模型需要注意的有以下几点：
2.4.1 为了在解析器即（标签、人群以及360画像）便于筛选，需要明确状态类字段的枚举值对应的业务含义并在订单属性字段进行约束值的配置；对于多订单系统的状态值也需要进行统一mapping
2.4.2 对于没有主键或现有标识有重复的订单数据源，看看能不能对字段进行组合生成订单的唯一标识，也便于后续的数据更新
2.4.3 另外就是数据类型的问题，看看是否有数据不符合业务上数据类型的定义，根据实际情况进行转换
2.4.4 最后就是订单属性的设计了，可以按需创建，对于源业务系统存在的订单属性字段一般是要全部覆盖到的，以便后续进行分析
关于行为模型需要注意的点：
2.4.5 看看行为触点以及行为标识是否能完全覆盖所有行为事件，用户id 和 行为时间的填充率也需要保证
2.5 数据接入以及验证
一般从以下几个方面进行数据验证：
- 有主键的查看主键是否重复
- 查看枚举值是否和预设的一致，可以体现是否字段错列
- 查看身份id是否全部填充
- 查看数据行记录是否和源数据一致
- 查看总金额和总数量是否和源数据一致
- 抽样查看数据详情
一般验证之后问题的原因如下：
- 错列：需和源数据比对，定位错列字段，一般都是字段中和数据接入的分隔符冲突了或者映射规则错误
- 数据记录变少了：需关注必填字段是否存在空值从而行记录被过滤了或者是数据类型的设置和实际接入的数据类型不符被过滤了，另外还有可能是数据接入的数据集选择错误等原因
2.6 数据打通配置以及验证
id 打通需要进行两个步骤的配置：
2.6.1 superid的绑定：
即将所有消费者相关的订单以及行为数据表进行身份id的绑定，混合id以及固定id字段都可进行绑定
2.6.2 配置superid计算任务：
选择要进行superid计算的表，配置身份id打通的优先级，配置完成后将superid计算任务的默认规则打开，即开启计算
数据验证：一般分两个部分对打通后的目标表superid_all进行验证，即验证目标表是否包含了所有订单以及行为表中的身份id，可以对比下各个身份id的数量；还要验证目标表是否真的进行了打通，即查看有确定mapping关系的不同类型的身份id，在superid_all表中是否真的打通成同一个superid，可用superid的数量查验。注意superid_all表中并不会记录所有来源表的所有身份id，相同类型的身份id如果出现在不同事实表，superid_all表只会记录一个来源事实表。
二、数据标签
1. 标签的应用场景
以便在标签层级列表和人群画像更直观的查看用户分类特征
2. 标签的种类以及创建方式
2.1 规则自定义标签
标签分类：一个标签自定义一套规则，分类互斥。
时间范围：自定义选择。
数据范围：属性模型、行为模型、订单模型。
逻辑关系：且或单一，适用简单的标签逻辑。（适合行为和属性的简单筛选，比如 多乐士小程序且下过单的用户，特定渠道下过单的用户）
2.2 规则统计标签
标签分类：可离散数值，可按照区间分类
时间范围：自定义选择
数据范围：行为模型和订单模型
逻辑关系：事件只有且的关系，适合简单统计，例如：累计购买金额、最近一年的购买数量，最近一次购买金额等复杂标签不适合。
2.3 规则行为特征类标签
标签分类：事件属性作为标签值返回
时间范围：自定义选择
数据范围：行为模型和订单模型
逻辑关系：事件只有且的关系，行为特征可以根据频次、综合、数值最大最小、首次末次发生选择，例如筛选用户购买商品数量最多的渠道，但是也没有指标计算或者 行为特征筛选之后的指标分布，例如最近一次购买距今时长（时长按照区间分布）、最近一次购买渠道、商品数量购买最多的渠道等可以实现。
2.4 自定义sql标签
标签分类：一个用户只能被打上一个标签，可以返回 array 或者在 string拼接标签。
时间范围：自定义选择。
数据范围：属性模型、行为模型、订单模型。
逻辑关系：自定义逻辑，可以任意发挥。
三、人群创建
人群可以基于标签宽表、订单模型、行为模型以及属性模型创建，可以分发至不同渠道（本地下载、其他云服务器（SFTP、AWS、腾讯云、阿里云、minlo以及微伴（方便企微用户查看消费者标签））支持下游系统数据应用以及查看人群画像。人群还可以自动同步至ma进行营销推送，在创建人群时“导出”部分需要设置对应的身份id，例如短信渠道营销需要导出手机号，公众号渠道营销需要导出openid。
四、报表
模糊一点来说，CDP支持的报表分为以下几类：
- 洞察分析：可以自定义维度和指标（规则或者自定义sql），可以选择人群或者基于CDP全部人群查看不同维度组合的指标情况，是个可以灵活配置的报表入口
- 用户 360 画像：用户详情页可以自定义画像模版，包括属性（属性展示字段可选）、行为字段可筛选、标签、RFM的分类、AIPL的阶段；可以自定义搜索框的配置（搜索哪些字段，是否支持模糊搜索）、用户列表展示的字段和顺序；支持高级搜索即查询宽表与人群有交集的用户列表，也可另存为新的人群
- RFM 画像：按照三个维度展示消费者的消费潜力，可以自定义三个指标与对比的bench指标的计算逻辑
- AIPL 模型：可以自定义不同阶段的名称和逻辑，定义流转周期，系统会展示不同阶段的新增用户与流失用户与不同阶段的流转用户，支持人群导出用于针对性的营销，比如给流失用户发送挽留优惠券以激活，给忠实用户发送周年纪念礼以维护用户粘性等。
相关文章
