用户画像系统搭建思路
“本篇文章主要讲解精细化运营中不可或缺的核心功能——用户画像系统,并将介绍如何从 0 到 1 的进行系统的搭建,思路和功能点的设计。”
一、数据分析的本质是什么
首先,我们需要自己明确一个问题的答案,就是数据分析的本质是什么?数据分析的本质是获得信息和知识,从而在判断和决策中使用。我们设计林林总总的分析模型、可视化方案,实际上都是为了得到一个最好的方法进行信息的展示。
当我们通过数据分析,得到了信息和知识后,最后都是需要落地的,这个落地的操作可能是我们改进了自己的产品,也可能是我们在运营中优化了策略……
从目标上划分,数据分析又可以分为三类:描述式分析、预测式分析和决策式分析。
- 描述式分析:将数据信息进行整合,选择一个最优的可视化方案,进行事实的陈述;
- 预测式分析:通过已有的沉淀数据,进行后续的预测,预测式分析是有探索性,他的目标是辅助我们的判断;
- 决策式分析:通过对比、实验等手段,直接反应情况,给出明确的好坏,从而直接进行决策。
所以说,一个分析系统,至少要包含描述式分析的能力,这样信息的获取是不成问题。再进阶就是增加预测式和决策式的分析能力,让分析师可以更高效、更准确的解决问题。
二、什么是画像系统
什么是画像系统?画像系统是一个以用户为分析对象,通过各种方法将用户信息进行展示,提供给分析人员全面、准确并具有指导意义的信息,从而优化运营的策略。
画像系统最为核心的三个能力,分别是:信息的加工生产能力、信息的分析展示能力和信息的传递能力。我们将其比作一次烹饪流程:信息加工生产就是我们的原材料,他决定了我们可以做哪些菜;信息的分析展示就是我们做出来的菜,技巧、顺序都会影响我们的菜品口感;信息的传递是我们最后装菜的容器,如果没有盘子,菜品也就无法被品尝。
画像系统可以做什么?掌握用户特征,更好的进行用户群选定,提升运营效果。
三、如何搭建画像系统
抓住画像系统最核心的三个能力,我们的搭建思路也围绕这三点进行展开。分别是:内容生产、画像分析和对外输出。
数据的采集、加工和生产:
数据的采集可以参考市面上主流的大数据平台进行数据的采集和治理即可。通过埋点的方式,我们需要将用户在产品中的行为进行记录上报。尽可能准确、全面的采集核心链路的数据。
数据的的加工和生产,实际上就是我们标签体系的搭建。文章后半段会单独讲述如何搭建一个标签体系。
在实际的操作中,还需再额外考虑几个点:
历史的记录:因为我们在为用户画像做数据储备,所以在预想范围内是无法避免对一个用户的历史状态进行分析的。我们需要在每次标签的加工时,考虑到历史数据的备份存储。
灵活的更新:同时数据的更新机制,可以提供不仅仅只有调度器调度一种,还可以使用触发型的数据更新,用以满足更多的业务场景。
丰富的配置:如果系统的面向对象是我们的业务人员,那么随着产品的发展,标签的规则修改在所难免。那么如果能做到快速响应,顺应业务的变化,就是需要考虑的一个问题。
多视角的分析模型:
分析模型是画像系统中的精髓所在。从分析的体量划分,分为群体和单体;从分析的状态划分,分为静态和动态;从分析的路径划分,分为探索分析和目标倒推。
群体和单体:
群体分析,也就是我们平常说的用户群画像,用户群画像承载的目标是:体现人群的特征。我们由浅入深的来思考,如何完成这个目标。
首先,我们要把基础的信息展示出来。
- 人群的体量:人群数、占全部用户的占比等信息,反应人群的规模
- 人群的基础构成:人群中新老用户占比
- 人群的标签分布:人群中,标签值的分布占比,反应人群标签值的分布情况,如人群中「性别:男」占比为 70%,那么认为人群中男性较多
- 人群的行为指标:人群完成指定指标的总次数、人均次数等
有了以上的基础信息,我们就可以对人群情况有一个基础的的认知,了解他们的构成和他们的习惯。光有基础的认知是不够的,我们还需要知道人群的特征,这个特征是要有差异化的、突出的、显著的。普遍的分析方法中,会引入 TGI 指数(目标群体指数)来进行人群的特征判断。
我们引入一个对照组,默认的可以是全体用户,也可以是「最近 7 日活跃用户」。
人群中标签值的 TGI 指数:用来反映人群中该标签是否是一个突出的特征,按照 TGI 指数进行排序,我们就可以得到这个群体与对照组最大的差异点在哪里
单体分析,也就是单个用户画像,单个用户画像承载的目标是:描绘出单个用户的使用轨迹以及属性特征。
这个分为两个部分,在我们分析单个用户时,通过观察行为轨迹来探索用户的偏好和特征,通过已有的属性标签全面的观察总结性的特征信息。
- 用户的行为序列:按照时序展示用户的每个行为触发情况
- 用户的标签分布:展示一个用户身上的标签情况,并额外展示标签的变更记录和在整体的分布情况
静态和动态:
静态分析,即我们将人群选择后,通过增减维度、变换视角来进行人群信息的展示,从而获得信息。静态分析的目标是,得到一个人群的当前状态,当前特征,然后用于运营。
动态分析,人群演进,引入时间的概念,由于我们提前准备好了标签的历史数据,那么我们就可以在这里应用。选定人群后,可以向前或向后进行演进,观察同一个人群中标签的迁移情况。这个在我们做运营活动后,观察活动效果的作用上体现尤为明显。
探索分析和目标倒推:
探索分析是个正向的分析过程,探索观察这个用户群中的特征以及行为情况,来获取我们想要的信息和知识。
目标倒推,智能预测,是我们从目标出发,提前判断出人群的特性。我们使用用户画像,获取信息和知识,最后的目标是为了进行运营。运营的目标可能是完成某个活动或者是个多维立体的指标,那么如果我们能在运营之前,就先预测到这个群体与目标是否相匹配,就会规避一些效果不理想的风险。
高效稳定的对外输出:
在我们生成了用户画像后,接下来落地的场景就是我们需要去应用这个人群或者特征了。这里主要有两个场景,第一个是使用人群包,第二个是使用人群的特征。
人群包的使用上,系统中应考虑提供多种高效的对接方式。由于应用场景的不同,人群包中携带的特征属性等也可能不尽相同。
人群的特征使用上,应考虑到应用场景。大部分都是需要支持高 QPS 查询的在线服务。尽可能快速的响应,返回一个用户身上的标签情况。
同时,设计完善的通知机制,当人群计算完成、标签计算完成的状态,可以快速被获取到。
四、如何搭建自己的标签体系
搭建一个标签体系,可以从我们的使用场景里入手。既然我们的目标是来做精细化运营,那么我们的搭建也应该围绕着精细化运营的方法进行拆解。简单的概括就是「自上而下的需求梳理」和「自下而上的体系构建」。
自上而下的需求梳理
自上而下的需求梳理,可以拆解为几个步骤:运营的目标、运营的方案、人群的拆解。
在我们做精细化运营时,是有一个或者多个预期的目标的(比如:支付订单),同时业务也有核心指标(比如:页面通过率),那么为了达成这个目标者指标,我们需要进行运营方案的制定。
制定方案时,第一步就是指标拆解,比如「提高盈利额」可以拆解成「提高客单价」「提高客群数量」,提高客群数量又可以二次拆解成「提高页面通过率」「提高 App 启动人数」。当我们把指标进行拆解后,我们自然就知道了需要做哪些事情了,同时我们将场景带入,也就知道需要对哪些人做哪些运营干预。
比如「提高页面通过率」,我们就需要再次进行人群的拆解:新老用户的通过率不同,不同偏好的用户通过率不同,不同目标的用户通过率不同……在拆解的过程中,我们就会发现:做这个运营活动,我们需要「新老用户标签」「用户偏好标签」「访问目标标签」……
于是,标签的体系的需求梳理工作,就顺理成章的完成了。
自下而上的体系构建
当我们有了希望创建的标签清单,先别急着创建,我们还需要进行一次数据的梳理和抽象。
我们会发现,很多业务标签的定义会有部分重叠,比如:「新老用户」「活跃用户」都会使用最近访问的时间进行判断。类似这样的情况还应该会有很多,这里给出一个比较通过用的解决办法。
第一步 事实标签的搭建:
首先,理解什么叫事实标签。用户的属性、用户的行为指标这些归类为事实标签,在事实标签中,只会描述「什么时间」「做了几次」这类真实反映事实的情况。
事实标签主要的作用,就是用来做行为的概括和描述,并且为更加上层的标签打下数据基础(元标签)。由于事实标签只描述事实,所以他们的稳定性极高,不会随业务指标的改变而变化。
第二步 模型标签的搭建:
模型标签是基于自己的业务判断,或者大数据分析,综合多个维度产生的标签。举个业内最通用的例子,应该就是 RFM 模型的标签了。最近一次消费时间 Recency,消费频率Frequency,消费金额 Monetary,这三个指标都可以使用事实标签进行描述。
所以,模型标签很依赖业务的判断。当然,我们也可以很自由的修改切割方案,所以模型标签是结合了业务经验,再加上一些主观判断得到的一个可以反映用户特征的标记。他的稳定性一般,因为偶尔会结合不同的产品周期和客群的演变而进行调优。
第三步 用户群标签的搭建:
当我们有了事实标签和模型标签后,其实已经可以开始进行精细化运营了。但是对于某些特定的场景,我们可以固化下来一些有特征的用户群,比如:高价值流失客群(使用「消费能力」「最近一次访问时间」「消费意愿」……构成)。
这类标签更加贴合业务,甚至还有一定的时效性和周期性,有些甚至直接和活动挂钩。用户群标签更加贴合业务场景,基本是不稳定的,会随着业务的变化、运营策略的调整而新增或修改。
总结
本文主要提供了一个画像系统的搭建思路,并从应用的场景反向推出大致需要提供哪些分析功能和模块。难免有些疏漏的情况,请各位结合自己的业务情况进行补充,随着业务的发展和技术的进步,也会有更多的分析方法加入进来。
系统的搭建,最终都是为了完成目标而服务,所以,在我们引入新功能的时候,需要三思一下,这个功能,能不能很好的帮我完成这个目标?如果答案是肯定的,那么这个功能就是有价值的。
作者:宋宋,神策数据产品经理。
本文由@请叫我宋宋 原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自Unsplash, 基于CC0协议
这文章写的也太范了,什么都说了等于什么都没说,搜点不完全等于完全不搜点,很符合我对神策这个产品不好用的刻板印象(已经2024年了 神策还是一直这么难用)
谢谢
讲的很易懂
我觉得很有用~
已经讲的很系统了
感觉说的太范了,能不能分享具体实施的例子,尤其如何从日志数据表到一层层的建立标签体系的文档和举例
确实太泛了,没什么工程实践
可以加微信认识下吗?
对小白能有个大概的认知
感觉说的太范了
785474747570138885877747487图片7
http://www.51smt.cn