共计 4714 个字符，预计需要花费 12 分钟才能阅读完成。
本文次要梳理 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 模型：能够自定义不同阶段的名称和逻辑，定义流转周期，零碎会展现不同阶段的新增用户与散失用户与不同阶段的流转用户，反对人群导出用于针对性的营销，比方给散失用户发送挽留优惠券以激活，给忠诚用户发送周年纪念礼以保护用户粘性等。