一号店用户画像分析系统实践

推荐会员: tutu 所属分类: 行业精选 发布时间: 2016-01-27 13:10

电子商务是互联网应用中发展期最早且模式最为成熟的商业模式,其用户和业务所带来的数据规模不断扩大,如何从大数据获取更大的价值?如何开发出真正贴合用户实际需求的推荐系统?1月9日,在七牛云主办的架构师实践日——瞩目电商:从架构开发到系统优化专场沙龙,一号店架构师王富平为大家一一解答了这些问题。以下是他的演讲实录。

在开场之前,我想先引用梵高的一句话:“我想强调的是,同一个人有多样的自画像。与其追求照相般的相似性,不如深入地发掘相似处”。下图是是当时梵高比较得意时的画像,戴了礼帽,穿了西服,但那时耳朵已经割掉了。我觉得作为一个好的架构师,要有艺术家的精神。时至今日架构发生了很多变化,新语言在不断出现,我觉得没必要把思维停留在某一个方面。

用户画像的定义

用户画像定义使用标签来量化用户特性属性,达到描述用户的目的。用户画像的难点就是数据源,因为你要拿到足够多足够全的数据很不容易,所以要与业务结合,比如说这个人在30天内购买了你的商品,这就是一个标签,但是如果你不参与开发这个系统,你不会想到有这个标签。然后是动态更新,一个人是不断变化的,就像梵高一样,他不同时期的自画像也是不一样的。

假设现有用户画像有姓名、地域两个属性,你将如何使用?

最简单的分析不同性别的群体特征,做特定营销。分析广州、北京、客户的群体特征,分析90后、80后的群体特征。其实这里面有共同点,就是说分类和聚类。京东也好、淘宝也好、一号店也好,我不可能真的每一个用户生成一套推荐方案,我们都是把人分成了一万个类,或者一千个类,我们把你划分到某一个类别里面,在那个类别里面做一个推荐。而且群体特征往往更能反映你的个人喜好,就是说其实人与人之间是有共同点的,也是有异同点的。

分类—聚类:迈出个性化的第一步,用户画像的应用开始

1号店建立用户画像的初衷是来自于《千人千面》项目,简而言之:分析不同群体特征,针对群体进行推荐调整,典型的群体有小区、学校公司等。下图是2015年9月份转化率的数据。我们覆盖面也比较大,目前差不多355家公司,591个行业,覆盖293个城市的4.26万个小区。

1号店从零开始打造了自己的用户画像系统,包含了用户标签画像、用户偏好画像。经历了全量版画像、Storm版实时画像、电商用户标签画像等演进和完善的过程。在两年的时间里,遇到了性能瓶颈、数据质量评估、用户标签的膨胀、画像在精准化营销等应用场景的摸索,一步步成长,在推荐系统发挥了巨大作用。

用户标签画像

我们的用户标签包含基本特征、社会身份、顾客用户生命周期、类目偏好等等。比如说你怎么判断一个人是不是对女装感兴趣,假设我们有一个类目就是女装,那很好办,如果你购买都是女装,那会认为你这个人对女装比较感兴趣。如下图所示。

挑战

我们期间遇到了两方面的挑战:

1.亿级画像系统实践和应用

2.记录和存储亿级用户的画像,支持和扩展不断增加的维度和偏好,毫秒级的更新,支撑个公司性化推荐、广告投放和精细化营销等产品

怎么做到的

1.用户画像算法模型不断优化

2.引入Storm等实时技术

3.主题推荐标签、用户命名实体等新增标签补充进画像

4.HBase的离线和在线分离、Hbase的KV读和Solr的批量读分离、region热点监控和切分

5.数据流不断优化

6.数据存储改进

第一版画像现状

偏好系统包括类目偏好和导购属性偏好两个部分,第一版的偏好系统接口调用数每天达千万次,主要服务于推荐栏位和EMD,但改变的偏好系统存在性能低下,偏好得分分布不合理等问题:

1.运行一次全量的数据更新太慢

2.用户的偏好得分数据分布不合理,得分呈多波峰分布,且在6.0、8.0区间的得分数目几乎为0

3.用户强偏好和弱偏好的阈值界限未有明显规定

4.用户未产生新的行为,兴趣偏好分值将不会发生变化(未按时间进行衰减)

新版画像系统流程

这个很简单,就是大家都能想到的离线和在线,离线要基于用户的行为,产品的信息进行打分,要得到一个个人的偏好,前端提供一个接口,基本上是这样子。

画像模型优化1

关于算法模型做了一些优化,第一个优化就是得分,通过操作得分使它的偏好更有区分性,历史行为应有衰减。你这个得分假设永远是叠加的,这也是有问题的,因为你一个月之前或者一年之前所有的行为,如果现在还影响着你的得分,会有不准确性,所以会有一个历史的衰减得分。偏好得分分布应与用户对类目的权重分布一致,关键是对数据的处理,还有怎么样去调整你的模型。

偏好画像的得分应满足三个条件:

用户在此类目或导购属性上的操作越多,得分越高

用户对类目或导购属性的喜好程度不同,可以通过偏好得分区间体现

用户的历史行为应有衰减

对于类目偏好,需先将用户对类目偏好离散化提高某些场景性能,最简单的行为可划分为两档【喜欢|一般】。

参数调整原则:

衰减系数的设置满足两个月衰减一半

(结合用户在不同类目下的购买周期,见下页)

各类行为权重之间的比例设置等同于用户各种行为数目的比例

偏好得分分布应与用户对类目的权重分布一致

画像模型优化2

然后有一个购买周期的问题,就是说不同的东西会有一个购买周期的,比如说牙膏多久前买的,牛奶多久前买的,这些东西的周期性是比较强的。后面会有一个实时推荐,根据用户的行为进行算分,根据各个类目的偏好进行一个实时推荐。

主题标签,比如说吃货,比如说爱吃零食的女性,算是吃货范围。还有数码极客,就是通过主题划分人。具体的方法我就不多讲,就是通过你购买的东西进行分类。下图是用户不同类目的购买周期。

主题推荐标签

主题和标签的映射关系如下:

使用标签表中的关键词列表,结合商品的评论、标题数据给商品打标签。

商品打标签公式为:

用户打标签公式为:

HBase的离线和在线分离

讲一下HBase,我们拿了很多开源的东西。我想问一下CAP大家都了解吧,一个数据库你只能获取两个特性。这边我们采用了离线和在线的方式,把可用性提上去。如下图所示。

Solr解决批处理选人

我们还有一个选人机制,就是用户画像的另一个场景,既然你有用户的各种信息了,那么对于其他业务,比如说广告业务,比如说促销业务他们提供了一个需求,就是选人,是基于Solr做的一个选人中心。如下图所示。

调优相关表,提高读写性能

根据画像表每一台机器的热点,迁移或者切分。

数据流优化

guid和userid的对应关系中,滤掉公用电脑和黄牛账户(全国有20万左右人从事刷单产业链)。为了进一步提高离线部分的计算速度,牺牲算法精确性,用户的行为权重计算亦可以增量计算:

设Wh为用户对某个类目的历史行为权重,Wc为用户最新一天的行为权重,则总的行为权重

Wt = λWh + Wc,  0<λ<1

如果采用上述方法,则不必遍历用户的所有的行为数据,每次更新时,只需遍历一天的数据即可。

优化数据存储

用户行为和行为统计表HBase替换为Hive,最后的画像表保留为HBase。考虑到类目偏好使用比较频繁,而导购属性偏好数据量远大于类目偏好,解耦来将两者分开存储。

类目偏好离线数据结构-Hive

全量数据过滤

全量数据过滤,就是类目偏好离线的全量数据进行过滤之后,导入在线部分,主要优化就是刚才讲的模型优化。过滤原则:

每个用户的偏好类目数量小于一个固定值

用户偏好得分大于下限,该下限可假设用户当天在某个类目只有一个加车行为,然后带入模型反推出来

导购属性偏好离线的全量数据进行过滤之后,导入在线部分。过滤原则:

属性偏好大于一个固定的下限

属性值的数量小于一个上限

属性值偏好大于一个固定下限

主要优化和改进点

主要优化和改进如下图所示。

长期兴趣和短期偏好解耦

类目和属性不同画像偏好解耦

尝试与未来

我们曾经想做实时画像,但我们并没有那么做,我们做的是实时推荐,为什么不做呢?因为这些算法不太好算,比如说算一个衰减周期,你要根据30天的编号算一个你当前类目的变化,你要拿30天的数据,这样的算法压力就很重。未来想做就是使用HBase镜像双集群,ApacheLgnite+HBase。

我们也做了一些有趣的东西,就是一些排行榜,对某些大学做一些排行榜的排名,实际上根据大学的特定群体我们已经做了推荐,这个东西其实还蛮好玩的。

一些启示

1.提炼出该案例(或项目)的哲理、方法论。

2.算法准确度、数据规模、更新速度相互制衡,提高某些指标,必须牺牲其他指标。

3.一个系统遇到性能瓶颈的时候,跳出系统本身,了解业务,根据业务解耦,以满足不同场景。

4.数据流各个环节都可能出错,自动化检查各个节点的中间数据,考虑降级和延迟环境。

5.系统的演进是个长期的过程,系统的分分合合和业务量有关,防止过度架构浪费资源。

6.不同版本开发的时候,适度换些开发者,融入新的思路,避免思维定式。

7.标签体系的管理规范比技术本身更重要,否则大部分标签会沉睡,后面基本用不到。

8.数据驱动,通过观察和研究数据,对数据有一定的敏感度,产生新的用户画像数据。

 

来源:http://www.jianshu.com/p/e3742a684a9a

关键词:

版权声明:本站原创和会员推荐转载文章,仅供学习交流使用,不会用于任何商业用途,转载本站文章请注明来源、原文链接和作者,否则产生的任何版权纠纷与本站无关,如果有文章侵犯到原作者的权益,请您与我们联系删除或者进行授权,联系邮箱:service@datagold.com.cn。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据