浅谈用户画像的系统化
浅谈用户画像的系统化
|0x00 如何理解用户画像
最近跟朋友聊天,谈起了35岁危机,我的观点是:35岁没什么大不了的,我多学点金融知识,以后转行做金融去;朋友的观点是,转行可不是说说就行,不是说你了解一个行业,就可以去工作的,你要深入理解背后的商业逻辑。随后,举了一个例子:“什么是用户画像,用户画像如何应用?”
这个问题,对于做数据研发的我来说,简直不要太简单。我拍拍胸脯,说道:“用户画像不就是给用户打标签嘛”,比如一个平台的用户,我可以按照如下的方式描述:
性别:女; 年龄:30; 婚姻:未婚; 职位:都市白领; 公司:小型私募; 个性:宅、网购、小资; 星座:白羊; 地址:XXX ……
这就是一种典型用户画像,通过我们从各个渠道采集的数据,来对人群做各种属性的划分,便于广告主投放广告。
随后,朋友问了几个典型的业务场景,让我来提供一下解决方案:
我是一家化妆品公司,定位国产新潮流,应该推荐给哪些人群? 我是一家做数码的商家,希望提高产品的ROI,我应该在双十一的时候给用户怎样的优惠券? 我是一家做成熟日用品公司,希望针对流失的用户,做一次分析,得到挽留用户的方法。
显然,我刚才那一顿噼里啪啦的回答,无法解决这些问题。这时候,朋友说,刚才的那些“标签”还是有用的,但显然无法上升到“画像”的地步,我们应该这样描述我们的用户:
26-35岁女性用户; 客单价较高,平均为100元; 平均消费周期是7天; 消费潜力有望达到150元阶段。
这个时候,基于一些对用户的描述,来圈选广告投放人群,显然就比刚才单纯的画像好很多。
紧接着,核心观点抛出来了:“我们在淘宝搜索东西的时候,基于品类的搜索,依然是延续的工业体系的思路,也就是所有商品都是标准化的。但在互联网场景下,标准化显然已经难以适用,如何用个性化的标签来对用户进行分类,才是用户画像的真正用意。对了,冯提莫的那句‘你说你喜欢森女系,而我多了一个G’是什么意思,悟透了吗?”
|0x01 数据的指标体系
回家之后,经过一番学习,知识有了进一步的精进。比如用户画像,其准确定义是:“通过收集用户的社会属性、消费习惯 、偏好特征等各个维度的数据,进而对用户或产品特征数据进行刻画,并对这些特征进行分析、统计,挖掘潜在价值信息,从而抽象出用户的信息全貌。”简单理解,就是做一批专门针对用户的统计指标,而这些指标并非基于客观事实来统计,而是基于一定的规则。
按照标签的类型,我们可以简单分为统计类型、规则类型及算法类型三类。统计类型即数仓同学每天面对的统计场景,是最为常见和基础的类型,比如PV、最近N天等逻辑;而规则类型是基于一些特定的分析场景产生的,比如在某个平台上的活跃度(最近N天的扩展应用),需要分析师与运营同学一同制定;而算法规则则是通过机器学习的方法,让机器来判断人的喜好。
除了规则类型面向的是特定的运营场景,其他的两种类型,做过数据的同学都能够大致明白,这些方法,其实很容易“标准化”起来,而“标准化”的基础,就是我们要建立明确的数据指标体系。
互联网场景下的数据指标体系,除了基于用户ID做统计之外,还需要针对用户浏览网页时的Cookie与使用手机的设备ID进行统计,而对应的标签维度,也可以分为用户属性类、用户行为类、用户消费类、风险控制类、用户偏好类、营销场景类、商圈细分类、用户分层类及业务专用类,等等类型。为了便于管理这么多的指标,以及对指标进行统一的管理,我们会比较倾向于通过一定的规则,来确定每个指标的命名方法,而不是任由开发人员定义。
例如在维度建模的理论上中,指标 = 原子指标+时间周期+修饰词,比如最近7天冰箱的订单量,但在用户画像标签下,我们需要更加细分这种方法,因为虽然都叫“订单量”,但是基于用户的订单量与基于商家的订单量,甚至是基于节日的订单量,是完全不同的涵义。
这里给出一个特定场景的指标体系规则:
标签主题 + 用户维度 + 标签类型 + 一级归类 + 二级归类 。
标签主题是上文提到的大场景,用户维度是指基于userid或者cookieid或者utdid,标签类型是统计型、规则型或者算法型,一级归类是行为大类,比如购买、下单等,而二级归类就可以自由发挥,去定义不同的细分场景。
看起来统计的粒度非常繁杂,一个指标往往有特别长的命名,但当企业规模足够大的时候,几十万上百万的指标,只有通过更细的分类,才能进行有效的管理。
|0x02 工程化的方法
理解了用户画像的商业逻辑与指标体系后,下一步就是考虑工程化的方法了。因为技术的资源是可以穷尽的,但商业的需求是无穷无尽的,如何用有限的资源支持无限的需求,就是数据技术团队的价值所在了。
工程化除去常规的大数据架构之外,还需要考虑画像数据的存储、画像数据的标准化开发(不同场景分开计算)、画像数据的产品服务等场景。
在数据的存储上,就需要考虑通过哪种引擎进行存储。因为不同标签的计算方式可能截然不同,有一些经过简单的加工就可以使用,比如统计型下的计数类,一部分需要经过复杂的规则加工,比如算法类,还有一些需要经过复杂加工且需要实时查询的。对于简单类型的实时数据,直接用流式计算引擎,比如Flink加工即可;如果是复杂标签的处理,通过HBase这一类的基于Key做存储的引擎,也能做到比较好的处理;而最后一类,则需要考虑OLAP的实施引擎,比如Clickhouse。
不同场景的标准化开发比较复杂,这里拆开来说:
第一类是统计类标签,用于描述客观现实,如最近N天的PUV等,基于维度建模理论做即可。但这一类有一些特殊情况,即部分标签是需要实时生成的,需要用到流式计算引擎,由于维度建模倾向于SQL的方式来运作,因此用Flink这种提供SQL能力的引擎最为合适。
第二类是规则类标签,由于运营的强业务属性,很多时候需要做一些技巧上的设定,比如用户搜索了100种商品,其中60种是母婴类,结合性别,那么我们就可以打上“宝妈”、“宝爸”的标签。
第三类是算法类标签,基于文本分词+机器学习的思路,通过一批人工标准好的训练样本集,丢给机器做分类即可,这里做好准确度的评价体系。
做好上述基础的标签开发工作后,还需要考虑对标签之间的关系做加工,比如基于TF-IDF标签权重计算,或者是基于向量的相似度计算,或者是标签的组合计算,等等。
总结一下做标签的分类和方法:基于规则的实时和离线计算、基于规则的规则运算、基于算法的分类计算,以及最后基于已算好标签的权重、相似度与组合计算,最后再考虑如何存储、计算和查询标签,做好系统调度与性能调优,技术路线就清晰了起来。有了完整的做标签的思路,我们就可以选择合适的架构,来逐步扩大标签开发的范围,例如设计规则平台,让运营同学加入进来;例如做好机器学习的工程化,让样本集标准与准确度评价系统起来。
工程化的前提是梳理清楚全链路的规则,通过技术努力降低开发的门槛,最后推广让更多的人加入进来。
|0xFF 方法论的产品化
既然我们花了如此大的代价让用户画像体系化,就一定要配合靠谱的产品将结果输出出去,如果无法打通系统与业务之间的链接,很容易产生“技术无用”的尴尬场景。
那么产品化的道路上,我们需要考虑哪些场景,以及如何运用呢?
首先是“圈人运营”的功能,比如基于画像选好人群后,我们下一步就是要对接营销系统,搜索广告也好、信息流广告也好、短信也好、邮件也好,在打通已有能力的基础上,提供一键推送的设计,对外赋能精准营销的能力。
其次是“人群跟踪”的能力,例如商家能够基于已有的用户画像,做核心用户群体的变化监控,及时发现新的标签,从而推导可能发生的热点事件与风险事件,及时做出相应的反应,比如推送个优惠券、或者像杜蕾斯那样打个内涵广告,等等。
再次是“数据分析”的诉求,这一点主要面向内部的运营、产品及BI使用,从多个维度、多个角度等分析当前企业用户群体的特征,漏斗分析、渠道分析、商品分析、人群分析,等等,从更广阔的的范围上提供企业的经营决策支持。
最后是“推荐系统”的支持,这一点面向企业的开发人群,例如搜索引擎可以根据用户的标签信息做千人千面的结果推荐,风控部门能够基于用户标签做相应的模型输入,等等。
当然,虽然现在有Tableau、QuickBI等快速搭建报表平台的组件,但一些功能性的产品诉求,比如流程设计、即时通信等,仍需要工程团队的定制化开发。
其实很多时候,产品化无法解决一切问题,通用的能力与定制化的需求之间,也存在着非常多的改进空间。如果不能一步到位,那就先想清楚为什么,再考虑如何做,最后动手去实现它。