浅谈用户画像的系统化

共 3582字，需浏览 8分钟

· 2020-11-11

浅谈用户画像的系统化

|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标签权重计算，或者是基于向量的相似度计算，或者是标签的组合计算，等等。

总结一下做标签的分类和方法：基于规则的实时和离线计算、基于规则的规则运算、基于算法的分类计算，以及最后基于已算好标签的权重、相似度与组合计算，最后再考虑如何存储、计算和查询标签，做好系统调度与性能调优，技术路线就清晰了起来。有了完整的做标签的思路，我们就可以选择合适的架构，来逐步扩大标签开发的范围，例如设计规则平台，让运营同学加入进来；例如做好机器学习的工程化，让样本集标准与准确度评价系统起来。

工程化的前提是梳理清楚全链路的规则，通过技术努力降低开发的门槛，最后推广让更多的人加入进来。