用户画像

从用户画像的数据架构谈需要掌握的大数据模块和开发语言

第一阶段：目标解读
　　在建立用户画像前，首先需要明确用户画像服务于企业的对象，根据业务方需求，未来产品建设目标和用户画像分析之后预期效果；
第二阶段：任务分解与需求调研
　　经过第一阶段的需求调研和目标解读，我们已经明确了用户画像的服务对象与应用场景，接下来需要针对服务对象的需求侧重点，
　　　　结合产品现有业务体系和“数据字典”规约实体和标签之间的关联关系，明确分析纬度；
第三阶段：需求场景讨论与明确
　　在本阶段，数据运营人员需要根据前面与需求方的沟通结果，输出《产品用户画像规划文档》，在该文档中明确画像应用场景、最终开发出的标签内容与应用方式 ，并就该份文档与需求方反复沟通确认无误。
第四阶段：应用场景与数据口径确认
　　经过第三个阶段明确了需求场景与最终实现的标签纬度、标签类型后，数据运营人员需要结合业务与数据仓库中已有的相关表，明确与各业务场景相关的数据口径。在该阶段中，数据运营方需要输出《产品用户画像实施文档》，该文档需要明确应用场景、标签开发的模型、涉及到的数据库与表，应用实施流程；
第五阶段：特征选取与模型数据落表
　　本阶段中数据分析挖掘人员需要根据前面明确的需求场景进行业务建模，写好HQL逻辑，将相应的模型逻辑写入临时表中，抽取数据校验是否符合业务场景需求。 
第六阶段：线下模型数据验收与测试
　　数据仓库团队的人员将相关数据落表后，设置定时调度任务，进行定期增量更新数据。数据运营人员需要验收数仓加工的HQL逻辑是否符合需求，根据业务需求抽取查看表中数据范围是否在合理范围内，如果发现问题及时反馈给数据仓库人员调整代码逻辑和行为权重的数值。
第七阶段：线上模型发布与效果追踪
　　经过第六阶段，数据通过验收之后，就可以将数据接口给到搜索、或技术团队部署上线了。上线后通过对用户点击转化行为的持续追踪，调整优化模型及相关权重配置。

1、数据分析
如何做数据调研、对于需求方提出的标签如何结合数据情况给出相应的解决方案；
…
2、用户画像工程化
用户标签体系中需要开发哪些标签；
这些标签的调度流是如何构成的；
如何对每天的调度作业进行监控；
哪些数据库可用于存储标签，为何用这些数据库进行存储；
…
3、业务知识
需要开发的标签服务于业务上的哪些应用
….
4、画像产品形态及如何服务与业务
画像产品化后包括哪些模块;
如何评价标签在业务上的应用效果;
…

日全量数据表中，每天对应的日期分区中插入截止到当天为止的全量数据，用户使用查询时，只需查询最近一天即可获得最新全量数据。

下面以一个具体的日全量表结构例子来做说明。

CREATE TABLE dw.userprofile_tag_userid (   
   tagid STRING COMMENT 'tagid',   
   userid STRING COMMENT 'userid',   
   tagweight STRING COMMENT 'tagweight', 
   reserve STRING COMMENT '预留' ) 
PARTITIONED BY (data_date STRING COMMENT '数据日期' ,tagtype STRING COMMENT '标签主题分类')

这里tagid表示标签名称，userid表示用户id，tagweight表示标签权重，reserve表示一个预留字段。

分区方式为（日期+标签主题）分区，设置两个分区字段更便于开发和查询数据。该表结构下的标签权重仅考虑统计类型标签的权重，如：历史购买金额标签对应的权重为金额数量，用户近30日访问天数为对应的天数，该权重值的计算未考虑较为复杂的用户行为次数、行为类型、行为距今时间等复杂情况。通过全连接的方式与前面每天的数据做join关联
例如，对于主题类型为“会员”的标签，插入‘20180701’日的全量数据，可通过语句：

insert overwrite table dw.userprofile_tag_userid partition(data_date=’20180701’, tagtype=’member’)

来实现。查询截止到20180701日的被打上会员标签的用户量，可通过语句：

select count(*) from dw.userprofile_tag_userid where data_date=’20180701’

来实现。

日增量数据表中，每天的日期分区中插入当天业务运行产生的数据，用户使用查询时需要限制查询的日期范围，可以找出在特定时间范围内被打上特定标签的用户。

下面以一个具体的日增量表结构例子来说明。

CREATE TABLE  dw.userprofile_useract_tag (   
   tagid STRING COMMENT '标签id',   
   userid STRING COMMENT '用户id',   
   act_cnt int COMMENT '行为次数',
   tag_type_id int COMMENT '标签类型编码'，
   act_type_id int COMMENT '行为类型编码') 
comment '用户画像-用户行为标签表’ PARTITIONED BY (data_date STRING COMMENT '数据日期')

这里tagid表示标签名称，userid表示用户id，act_cnt表示用户当日行为次数，如用户当日浏览某三级品类商品3次，则打上次数为3，tag_type_id为标签类型,如母婴、3C、数码等不同类型，act_type_id表示行为类型，如浏览、搜索、收藏、下单等行为。分区方式为按日期分区，插入当日数据。
例如，某用户在‘20180701’日浏览某3C电子商品4次（act_cnt），即给该用户（userid）打上商品对应的三级品类标签（tagid），标签类型（tag_type_id）为3C电子商品，行为类型（act_type_id）为浏览。这里可以通过对标签类型和行为类型两个字段以配置维度表的方式，对数据进行管理。例如对于行为类型（act_type_id）字段，可以设定1为购买行为、2为浏览行为、3为收藏行为等，在行为标签表中以数值定义用户行为类型，在维度表中维护每个数值对应的具体含义。

日增量的表结构设计参考维度：

用户标签指标体系

用户画像建模其实就是对用户进行打标签，从对用户打标签的方式来看，一般分为三种类型：

1、基于统计类的标签；2、基于规则类的标签、3、基于挖掘类的标签。下面我们介绍这三种类型标签的区别：

统计类标签：这类标签是最为基础也最为常见的标签类型，例如对于某个用户来说，他的性别、年龄、城市、星座、近7日活跃时长、近7日活跃天数、近7日活跃次数等字段可以从用户注册数据、用户访问、消费类数据中统计得出。该类标签构成了用户画像的基础；
规则类标签：该类标签基于用户行为及确定的规则产生。例如对平台上“消费活跃”用户这一口径的定义为近30天交易次数>=2。在实际开发画像的过程中，由于运营人员对业务更为熟悉、而数据人员对数据的结构、分布、特征更为熟悉，因此规则类标签的规则确定由运营人员和数据人员共同协商确定；
机器学习挖掘类标签：该类标签通过数据挖掘产生，应用在对用户的某些属性或某些行为进行预测判断。例如根据一个用户的行为习惯判断该用户是男性还是女性，根据一个用户的消费习惯判断其对某商品的偏好程度。该类标签需要通过算法挖掘产生。

在项目工程实践中，一般统计类和规则类的标签即可以满足应用需求，开发中占有较大比例。机器学习挖掘类标签多用于预测场景，如判断用户性别是男是女，判断用户购买商品偏好、判断用户流失意向等。一般地机器学习标签开发周期较长，耗费开发成本较大，因此其开发所占比例较小。

标签主题：用于刻画属于那种类型的标签，如用户属性、用户行为、用户消费、风险控制等多种类型，可用A、B、C、D等字母表示各标签主题；
标签类型：标签类型可划为分类型和统计型这两种类型，其中分类型用于刻画用户属于哪种类型，如是男是女、是否是会员、是否已流失等标签，统计型标签用于刻画统计用户的某些行为次数，如历史购买金额、优惠券使用次数、近30日登陆次数等标签，这类标签都需要对应一个用户相应行为的权重次数；
开发方式：开发方式可分为统计型开发和算法型开发两大开发方式。其中统计型开发可直接从数据仓库中各主题表建模加工而成，算法型开发需要对数据做机器学习的算法处理得到相应的标签；
是否互斥标签：对应同一级类目下（如一级标签、二级标签），各标签之间的关系是否为互斥，可将标签划分为互斥关系和非互斥关系。例如对于男、女标签就是互斥关系，同一个用户不是被打上男性标签就是女性标签，对于高活跃、中活跃、低活跃标签也是互斥关系；
用户维度：用于刻画该标签是打在用户唯一标识（userid）上，还是打在用户使用的设备（cookieid）上。可用U、C等字母分别标识userid和cookieid维度。

对于用户是男是女这个标签，标签主题是用户属性，标签类型属于分类型，开发方式为统计型，为互斥关系，用户维度为userid。这样给男性用户打上标签“A111U001_001”，女性用户打上标签“A111U001_002”，其中“A111U”为上面介绍的命名方式，“001”为一级标签的id，后面对于用户属性维度的其他一级标签可用“002”、“003”等方式追加命名，“_”后面的“001”和“002”为该一级标签下的标签明细，如果是划分高、中、低活跃用户的，对应一级标签下的明细可划分为“001”、“002”、“003”。