最近学习了用户画像方面的内容,本文主要是学习《美团机器学习实践》的读书笔记。
什么是用户画像?
用户模型和用户画像的区别。用户模型是指真实用户的虚拟代表,在真实数据的基础上抽象处理的一个用户模型,是产品在描述用户需求时使用的概念。用户画像是从海量的用户数据中,建模抽象出每个用户的属性标签体系,这些属性通常要具有一定的商业价值。
具体来说用户画像要解决的问题就是从复杂,没有直接商业价值的数据中,通过清洗,挖掘,整理,生产出能直接指导商业运营的用户属性体系,比如人口属性,行为轨迹,用户分群,消费偏好等等,这些数据要有明确的层级划分和可理解性,所以用户画像也可以看作为数据标签化。我理解用户画像也是一种降维过程,要让大数据从数据仓库中出来,我们不能一股脑将所有数据给上层应用,而是提取出标签维度的数据给上层。
构建用户画像,第一步是要搞清楚需要构建什么样的标签,这是业务需求和数据实际情况一起决定的,尤其需要注意标签粒度,粒度太粗没有区分度,粒度太细会导致标签体系太大没通用性而且算法复杂度高。
用户画像的标签体系,通常可以使用树状图(思维导图)表示,体系通常分为多个大类(一级分类)。每个大类又分为多个小类(二级分类),下面还可以有深度不同的多级分类。
一级分类通常包括:人口属性,兴趣偏好,特征人群,用户分级,LBS属性,用户行为,业务标签等。
用户画像数据挖掘
画像数据挖掘架构
用户画像标签体系,从开发实现,通常分为两大类:经过策略统计分析(通过统计);经过机器学习模型预测。
用户画像数据通常涉及数据收集,数据清洗,特征生成,标签建模,预测计算,效果评估,线上应用,效果反馈,迭代优化过程。
数据收集
数据收集需要用到各种方式,内部日志数据,卖点上报数据,业务监控等方式,外部互联网公开数据,爬取数据,合作第三方数据。最终数据汇集到基于Hadoop生态的数据仓库。
特征计算
数据清洗后转为特征是很关键的一步,直接影响到最终的效果。这里主要工作是数据处理(异常值过滤,数据异构转同构),数据加工(统计,平滑,归一)。美团的做法:给出数据样本,自动扫描结构化的数据表(一般是Hive),根据一些相关性指标(相关系数,卡方,p值等),找到和样本标签强相关的数据列,稍作处理加入特征库。
特征库维护
生成特征后还要有一个统一管理的地方,方便新特征的收录,老特征的更新,下线,以及可视化特征统计指标。最重要的是,要有旁路系统,监控特征的波动情况,在质量存在风险是做预警。
机器学习模型
有特征库后,就需要对标签做机器学习建模。需要用算法完成:特征选择,模型训练,效果评估,预测。模型训练常用工具:spark MLib,sklearn,XGBoost,Tensorflow等。
应用接口
通过画像建模预测标签后,就需要考虑将标签上线,跟踪收益反馈。美团开发了TCS系统用来负责各种标签基于层级划分的收录,以及标签数量和质量监控。对于数据的使用,有两种模式:通过用户ID查询用户标签(UPS);给定用户属性的集合 ,圈出符合条件的一批用户(UTVS)
画像应用
最后就是将用户画像的标签应用到各个业务线,方向主要有:精细化运营,个性化推荐,商业分析,个性化展示等。
用户标识
现实生活中,一个人的身份证ID就可以标识一个人,用户画像过程中,业务通常用userID标识一个人。但是仅有业务内部的数据后续挖掘很低,而且通常需要用户登录态才能记录数据,另外很多人会注册多个ID。所以一般除了userID,我们还可以围绕deviceID,payaccount,公司其他业务ID一起来构成一个用户,来自一个用户的所有ID统一对应到一个唯一编号NPI(自然人)。
但是如果各种ID的数据汇总,数据量非常大,在计算连通图过程计算量很大。如果使用并查集算法难以做并行化,使用MapReduce求连通图方法,面对半径非常大的连通子图,会有迭代多次无法收敛的问题,美团采用了MapReduce的优化算法,Hash-to-min,可以将时间复杂度降到O(logN)
特征数据
在不同标签的开发过程中,很多数据特征是同样有效的,为了避免重复提取特征数据,在进行标签挖掘前,首先要进行用户特征库的规划和建设。
首先从整体上对用户数据进行梳理归类。用户数据大体上分为静态账号数据(注册时间,等级,信息填写等),LBS数据(活动区域等),以及动态行为数据(购买,浏览,收藏等)。然后再上述归类基础上对数据进行进一步划分。
数据样本
样本问题也是用户建模过程中的大问题,主要存在的问题是样本缺失,样本少,单样本等问题。针对这些问题,美团采用了找,转,试三种方式解决。
对于样本缺失(需要建模的标签很多,但是少数种类的标签有样本)可以通过各种路径“找”样本,通过问卷方式,内部员工数据,人工标注等;也可以通过“转”,将一些问题进行转换,比如用户偏好问题转换为预测问题,使用用户真实的点击作为标注,得到训练数据。
对于样本少的问题(由于样本获取成本搞,导致样本数少)和单样本问题(在一些场景下,只有正样本,没有负样本),主要是“试”,实验学术论文中实验效果好的算法。如自学习算法,直推式学习(transductive SVM)PU学习(One-Class-SVM/Biased-SVM/SPY/NB技术等)。
标签建模
标签建模除了设计算法模型的选择调优外还有大量的工程问题。基于Hadoop生态衍生出一系列大数据处理的工具和框架,以HDFS,HBase,MongoDB,RocksDB为代表的大数据存储能够头提供可扩展的海量存储。以MapReduce,Hive,Spark为代表的离线批量计算框架让海量数据计算成为可能。以Storm,spark-Streaming,Flink为代表的实时计算框架让大数据计算变得即时可得。
下图为用户画像数据仓库架构图
● Hive数据仓库ETL作业下方虚线框中为场景的数据仓库ETL加工流程,将每日的业务数据,日志数据,埋点数据等经过ETL过程,加工到数据仓库对应的ODS层,DW层,DM层中。
● Hive数据仓库用户画像主题建模:中间的虚线框即为用户画像建模的主要环节,会对基于数据仓库ODS层、DW层、DM层中与用户相关数据进行二次建模加工。
● 标签结果数据在应用端的存储:在用户画像主题建模过程中,会将用户标签计算结果写入Hive。
离线标签建模结构
下图为美团的离线标签建模系统结构图和流程图
以上标签生成平台是基于离线数据,有些业务是对实时场景更加关注,对于实时标签需求,spark,Hive离线系统为基础的框架无法保证实时性。美团针对此问题,开发了Flame实时标签建模系统。
实时标签建模结构
实时特征应该是根据用户行为实时产出的特征数据,用户行为数据来源广泛,美团统一使用kafka,将用户行为事件作为消息队列中的消息。kafka是一种高吞吐量的分布式消息系统,有很好的吞吐量。kafka消息的生产者来自各个业务,每个实时行为都作为一条消息写入队列。在消费端,美团在storm基础上,构建实时消息处理的拓扑,进行实时特征的生成。storm抽象了消息传递,自动将集群集群上并发处理流式计算。
实时标签从生产的角度分为两种:用户行为触发的标签和用户请求触发的标签。前者,生成入库后一段时间内标签不会变;后者,每次请求由于当前上下文等因素会导致标签值的变化。用户行为事件和系统请求调用没有直接关系,可以理解为标签是异步生成入库;请求触发的标签,可以理解为请求时同步计算出来的。
标签挖掘算法经验
上面介绍了美团的标签挖掘系统,他们还提供了特征处理和模型方面的经验
特征工程
特征提取主要是结合业务场景进行数据的格式化;特征监控用于特征质量的包装和模型效果的保障;特征处理用于异常特征的处理,垃圾特征的去除,潜在特征是挖掘。
模型使用
用户建模标签挖掘过程中会面临各种标签开发,这里会设计很多问题,如统计,语义分析,分类,回归,聚类等。不同的问题设计不同的模型,如聚类里的EM,Kmeans,GM;分类里的决策树,逻辑回归,贝叶斯,随机森林;关联规则里的Apriori,FP-Growth等。
根据美团的经验,XGBoost在多标签挖掘过程中想效果不错,LR+RF/LR+GBDT在整体效果不错,LR/SVM等简单线性模型性价比比较高。DNN再标签挖掘过程中效果不理想。
基于规则的标签挖掘
基于人工规则的标签挖掘优点是如果样本缺乏,但是先验知识多。
1. 样本明确的标签挖掘
我们可以根据已经获取的有标注的用户,对用户行为进行分析,利用监督学习模型,找出用户行为和标签的联系,对没有标注的用户进行预测。
2016年数据,对比xgboost在统计特征的数据集上效果最好。因为树模型高度非线性,能从样本中学习到高阶特征组合,是传统的线性模型做不到的。因子分解机在非高度稀疏的数据集上,只能学到二阶组合,实际效果不如简单的逻辑回归。深度学习需要深度的调参,不过这个是16年的数据,目前的深度学习应该有很大改进。
2. 小样本问题及单样本数据挖掘
有时我们只针对一批特定的用户进行推广,比如粉丝群,这里就存在小样本问题或者只有少数正样本。在挖掘这类人群标签的时候,准确率要重要于召回率。
解决方案:从少量已标注数据和无标注数据中学习成为Lu learning,从正样本和无标准数据中学习称为Pu learning。
Lu learning,最早的训练中运用未标注数据的方法是self training,主要思路是先对未标注的进行预测,然后将置信度高的加入训练,迭代到符合产出模型。
Pu learning有两种方式,直接法和两步法。直接法是对单样本直接建模,如V-SVM,one-class-SVM,biased-SVM等。两步法是通过转换最后将Pu learning转为普通分类问题。先从无标准数据中发现一些可靠的负样本,可以使用spy技术,IDNF技术,NB技术等,然后利用分类模型。
3. 用户实时标签挖掘
一种是根据购买或者点击等行为来量化;一种是将用户的显示反馈作为信号,将用户未来的点击和行为作为目标信号gt来预测。
用户画像应用
前面讨论了用户画像数据生产的建模方法,在实际应用中,必须真正通过工程方法将画像实时落地才算是真正实现了用户画像的价值。
从用户画像的应用场景来讲,用户可能通话用户标识来查询该用户的画像数据,也可以通过用户的画像数据来搜索满足条件的用户列表,深圳根据画像数据作为约束来定义人群,然后再人群基础上进一步做聚合分析,可视化展示等。
以美团推荐业务为例:推荐业务根据每个美团用户的画像进行个性化推荐,展示改用户可能感兴趣的团购单或者店铺。这里一个重要环节就是根据用户的唯一表示(uerID)查询该用户的画像,然后根据画像 进行不同推荐。
以美团推送业务为例:推送业务从美团海量用户中筛选出目标用户人群 ,向他们发送优惠券或者促销通知。这其中重要环节就是通过画像搜索人群。
根据这两类应用场景,美团分别构建了用户画像实时查询系统和人群画像分析系统。
用户画像实时查询系统
构建画像实时查询系统面临的挑战是数据量大,响应时间要求低和系统可用性要求高。面对这些挑战,美团从架构设计,存储选型,可靠性保证等方面进行设计。
架构设计
用户画像的标签有实时数据,也有离线数据。对于离线数据可以通过离线批处理,在低峰期灌入存储系统。存储系统提供查询就可以了。
但是对于实时标签数据,数据的写入需要保证实时性,就需要优化调整系统架构,让其满足实时标签需求。
Lambda架构思想
对于实时大数据系统,只使用实时计算框架(storm,spark-streaming等)很难对累计的大量历史数据回溯,所以需要将离线和实时数据进行合并来满足数据的时间完整性和实时性。
Lambda架构整合离线计算和实时计算,融合不变性,读写分离和复杂性隔离等一系列架构原色,可以方便集成Hadoop,Kafka,Storm,Spark,HBase等各类大数据组件。
Lambda架构将系统分为三层:批量数据层,实时数据层和服务层。
批量数据层进行离线批量数据处理,在最后一次运行时间之后的数据使用实时计算,这样就从数据层覆盖了所有时间范围。服务层读取批量和实时数据视图,以批量最近一次运行时间为界,将两者数据合并后,对外提供最终结果输出。
组件选型
Lambda架构的三层分级只是一种架构思想,我们可以根据业务需求,自己选择每层要用哪些组件实现,构建一套大数据处理查询系统。下图是美团用户查询系统的组件选型(其中Celler是美团自研KV存储系统,基于LevelDB,Squrrel基于Redis)
存储选型
1.硬件选择
一般,一次内存随机读取耗时几十纳秒,一次SSD硬盘随机读取耗时几十微妙,SATA机械盘随机读取耗时几十毫秒。但是价格也是成反比,内存价格昂贵,SSD硬盘和SATA机械盘,前者性能比后者高三个量级,但是价格只贵大约一倍。所以选择SSD性价比高一些。
2.SQL还是NoSQL
基于硬盘的存储组件有很多选择。我们首先来看,是选择传统的SQL家族,还是投靠大数据时代风靡的NoSQL阵营。
传统的关系型SQL数据库(RDBMS)对结构化的、非稀疏的数据的存储支持非常成熟稳定,而且对于锁和事务的支持使其在对于数据ACID ( Atomicity,原子性;Consistency,一致性;Isolation,隔离性;Durability,持久性)特性要求较高的场景应用广泛。但是,用户画像数据对于数据的一致性并没有强要求,对于数据的脏读容忍度很高,而且稀疏的数据结构也使得传统的关系型数据库无法满足对灵活性和扩展性的要求。
相比之下,NoSQL阵营里的众多组件对于画像查询的场景就非常适合。无论是HBase、Riak还是Tair,其基于LSM-Tree ( Log-Structured Merge Tree,日志结构合并树)结构的存储格式,使得写入操作在磁盘上是像日志一样顺序追加写入,保证了系统极高的写入吞吐量。与此同时,节省出来的磁盘IO便可以更多地分配给读取线程来使用,并且磁盘上的数据不断合并为有序结构,使得查询性能也非常优秀。
3.实践
美团自研了NoSQL存储Cellar,Cellar是一个分布式,基于RocksDB+MDB的双引擎数据库。和HBase.Riak类似,RocksDB也是基于LSM-Tree存储结构对数据进行持久化,具有强悍的 数据写入性能和数据查询性能,同时Cellar还引入了MDB全存储数据引擎来存储热点数据。
在实际应用过程中,为了进一步提升系统的吞吐量和极限负载能力,通过压力测试我们发现,如果整个存储集群性能达到极限,是由于Lambda三层架构中的实时数据视图的读取最先达到瓶颈。这是因为由于实时数据视图的覆盖率很低(时间跨度短),导致大量请求无法命中MDB,进而击穿缓存访问RocksDB磁盘数据。磁盘的访问量显然更容易达到瓶颈。为了解决这个问题,美团是引入了Squirrel来存储实时数据视图。Squirrel是美团自研的基于Redis的集群化解决方案,数据全部存储于内存中,不管命中率高低都能有极高的吞吐量。
4. 可靠性保证
用户画像是一个基础数据服务,往往处于后台调用链的最底层,所以其可靠性要求很高。美团采取了IDC多活备份,支持依赖熔断,支持多种降级策略等措施。
人群画像分析系统
上文介绍过,除了查询用户画像应用,还有一类应用是人群画像。人群画像分析系统的研究是为了满足根据用户画像标签条件,从海量用户中搜索符合条件的用户人群,并对该人群的标签进行聚合统计分析的需求,可以广泛应用在数据分析,定向营销,定向推送等业务。
系统设计
根据标签条件搜索人群,最直观的方法可以通过扫描全部用户的方式。基于Hadoop/Spark批处理框架强悍的批处理计算能力,这种效率不高但最直观的方式可以落地实现。但是无法满足秒级的实时搜索人群。
实时检索
如何提高检索的效率呢?特别是根据用户的属性反查用户这类问题、效率问题尤为重要。要解决这个问题,就是倒排索引大展身手的时候了。
倒排索引源于实际应用中需要根据属性的值来查找记录。这种索引表中的每一项都包括一个属性值和具有该属性值的各记录的地址。这种索引由于不是由记录来确定属性值,而是由属性值来确定记录的位置,因而称为倒排索引。
Elasticsearch是一个基于Apache Lucene的开源搜索引擎,具有如下特性:
分布式的实时文件存储,每个字段都被索引并可被搜索
分布式的实时分析搜索引擎
可以扩展到上百台服务器,处理PB级结构化或非结构化数据
Elasticsearch对大数据生态有着完善的支持,通过Spark2ES组件,可以方便的将标签数据批量灌入Elasticsearch集群中构建索引。美团针对实际情况对标签数据,Elasticsearch节点数,分片数,索引方式等各方面也都做了迭代优化。
线上应用
用户画像作为最重要的基础数据建设,在美团内部有广泛的应用。以下下是各个场景下的大致应用情况。
用户画像的应用主要有:经营分析,精准营销,个性化推荐等。
1. 经营分析
用户画像系统的标签数据通过API进入分析系统后,可以丰富分析数据的维度,支持进行多种业务对象的经营分析。
下面总结的是一些市场、运营、产品人员分析时会关注的指标:
1)流量分析
流量来源;
流量数量:UV、PV;
流量质量:浏览深度(UV、PV)、停留时长、来源转化、ROI(投资回报率,return on investment);
2)用户分析
用户数量:新用户数、老用户数、新/老用户数量比;
用户质量:新增用户数(App启动)、活跃用户数(App启动)、用户留存(App启动-App启动)、用户参与度、沉睡、客单价;
3)商品分析
商品动销:GMV、客单价、下单人数、取消购买人数、退货人数、各端复购率、购买频次分布、运营位购买转化;
商品品类:支付订单情况(次数、人数、趋势、复购)、访购情况、申请退货情况、取消订单情况、关注情况/;
4)订单分析
订单指标:总订单量、退款订单量、订单应付金额、订单实付金额、下单人数;
转化率指标:新增订单/访问UV、有效订单/访问UV;
5)渠道分析
用户活跃:
活跃用户:UV、PV
新增用户:注册量、注册同环比
用户质量:
留存:次日/7日/30日留存率
渠道收入:
订单:订单量、日均订单量、订单同环比
营收:付费金额、日均付费金额、金额同环比
用户:人均订单量、人均订单金额
6)产品分析
搜索功能:搜索人数/次数、搜索功能渗透率、搜索关键词;
关键路径漏斗等产品功能设计分析;
2. 精准营销
1)短信/邮件/push营销
日常生活中我们经常会从许多渠道接收到营销来的信息:一条关于红包到账的短信消息推送可能会促使用户打开已经很久没访问的App,一条关于心愿单里面图书降价的邮件消息推送可能会刺激用户打开推送链接直接下单购买。
具体有哪些类型的营销方式呢?
大致可以分为以下4类:
基于行为营销:产品浏览、加入购物车、门店扫码、订单取消、订单退货等;
基于位置营销:周边门店、周边活动、常去区域等;
基于节日营销:生日、春节、双十一、双十二、圣诞等;
基于会员营销:欢迎入会、卡券提醒、积分变更、等级变化、会员礼遇等;
2)客服话术
当我们在向某平台的客服部门投诉、咨询或反馈意见时,客服人员可以准确的说出我们在平台的购买情况,上一次咨询问题的处理结果等信息,针对性的提出解决方法,对于高价值用户提供VIP客服通道等专项服务。
3. 个性化推荐与服务
应用的运营者,可以通过个推用户画像中的性别、年龄段、兴趣爱好、浏览购买行为等标签,给用户推荐不同的内容;如今日头条上的个性化文章内容推荐、抖音上基于用户画像做的个性化视频内容推荐、淘宝上基于用户浏览行为等画像数据做的个性化商品推荐等。
参考:
网友评论