深度 | 用户画像的精细化迭代完全演练

18 评论 21599 浏览 197 收藏 30 分钟

这篇文章主要讲产品和运营角度的用户画像,希望看完后,解决你一切关于用户画像的疑问。

深入剖析用户画像

承接上篇《如何进行精准化的用户画像?》,现在的运营一般都会按用户生命周期设立了几个标签,比如:新用户、活跃用户、流失用户等等。这些标签是比较细分的,不过它真的是一个有效的好的标签吗?

答案是否定的!原因也很简单,因为这些标签都是滞后性的

聪明的运营都会设立一个这样的标签:最近一次活跃距今天数。这个比单纯的流失用户标签要好很多,因为他能凭此划分不同的距今天数,比如:设立30天、90天或者180天的时间节点。(如果用户有6个月没有活跃的话,那么天数就是180天。)

距今天数这样的标签就是最好的吗?当然也不是最好的!为什么呢?

因为用户是有差异的!

同样两个用户老王和老张,哪怕不活跃天数是相同的,我们也不能认为它们的流失可能性是相等的,毕竟关于流失的原因多种多样,不能单凭活跃天数加以预测。

而且,该问题在低频场景更严重。比如:旅游类的APP,即使是半年没有活跃也是正常的,毕竟不是谁天天都在旅游。

然后我们在看看流失用户这个概念,我们定义它不是为了设立一个高大上的系统,任何的公司,都无一例外地希望流失用户一开始就越少越好,然后才是如何挽回的问题。在这种业务前提下,预防性的减少流失用户显然比已经流失的标签更重要得多。

所以我们就知道,最好的标签的标签是用户流失概率,这才是最有用也是企业最应该关心的问题。

小结:

标签优先级排序:流失概率 > 距今消费天数 > 流失标签。

我们不要想当然地归纳一个齐全完备的体系,却忽略了画像的核心价值,这是顾此失彼啊!

必须要记住的是:用户画像一定得是某个商业目的下的用户标签的集合。

举个例子:

猜用户是男是女、有没有谈恋爱、哪里生人、准备剁手购物吗、喜欢什么、工资多少?探讨这些是没有多少意义的!

然而,是男是女如何影响消费决策的?工资多少影响怎样的消费能力?有没有谈恋爱会否带来新的营销和消费场景?剁手购物要如何做精准推荐?这些才是我们用户画像真正应该关心的问题!

这里需要强调的一点是:不是因为我有了用户画像,才能驱动和提高业务,而是为了驱动和提高业务,才需要去建立用户画像,这是很容易犯的因果倒置的错误!

用户标签的获得

用户画像的标签一般通过两种形式获得:

  1. 基于已有数据或者一定规则加工而来,流失标签和距今天数皆是如此。
  2. 基于已有的数据计算概率模型而来,这会用到机器学习和数据挖掘等内容,其中的概率是介于 0~1 之间的数值。

拿性别来举例:除非我们能直接获取用户的身份证信息,否则的话用户很少会填写性别。即使填写了,性别信息也不一定是准确的。所以你就能知道,网游中性别为女的扣脚大叔一抓一大把!

所以呢,这里就要增加一层推断用户真实性别的算法。

中国人的性别和名字是强相关的,像国庆利民、婷婷莹莹,很容易就能判断出来。算法中常用贝叶斯(用来描述两个条件概率之间的关系),通过已有的姓名性别库来预测新加入的用户的性别。

不过某种特殊情况下,不少姓名是中性的,即男女不是很容易分辨出来,像爱华这样的名字就可男可女。而且更特殊的情况,看上去是男性的名字也有可能是女性的。

像这种特殊情况就意味着特殊的概率,所以不能用非黑即白的二分法做计算。我们可以用概率来表示,即通过模型推断,国庆有95%的可能是男性姓名,表示为0.95;爱华有55%的可能是男性名,表示为0.55。

除此之外,模型会设立阈值,这也是为了方便之用。比如:将50%以上的概率默认为男性,以下默认为女性,不过业务部门的同学要清楚的是,用户标签的本质是0~1之间的概率值,而不是0和1两个值。

这里有个难点是什么呢?

我们都知道概率准确性的前提是数据源的准确,这里的数据源就是用户标签,然而用户标签往往是很难验证的!

比如:某位用户被标上学生的标签,但如果不是真的让他上传学籍证明的话,很难知道他是不是真的学生。在这种黑箱情况之下,我们针对学生用户进行的营销活动,效果好不好都受标签准确率的影响。无论是广告、推荐、精准营销等都会受到这个问题的影响。

学过中学概率的同学都知道:90%流失概率的用户和30%流失概率的用户相比有什么不同呢?

当然是前者比后者更有离开的可能性(虽然是模型建立出的预测值),然后我们会凭此设立运营策略。

所以我们就面临一个新的问题:如何选择概率的阈值才是合理的呢?

比如:我们想要挽回流失用户,选择80%以上概率的人群,还是60%呢?

答案在之前已经铺垫过了,要考虑具体的业务目标!

可以这么理解:挽回流失用户只是手段而不是目的,实际目的是通过挽回流失用户提高利润(当然了,提高利润是所有非公益组织的目的)。所以阈值的选择问题就迎刃而解了:我们可以计算在不同阈值下挽回用户的收入和成本,以此选择最优解。

推而广之,无论是推荐系统也好,广告系统也罢,虽然它们有更复杂的维度、标签和特征,但本质也是找出用户最近想不想买车、想不想旅游等这些用户意愿和需求。然后在最合适的时机把最合适的信息推送给用户,这就是获取最大的利益的法宝!

要知道的是,以上案例是经过简化的,实际的业务场景中会更复杂,比如:所说的姓名,除了生理上的性别有时还会建立消费模型上的性别标签,尤其是在电商和消费行业。

所以你就能看到有些人虽然是男性,但购物行为却是女性,这是一定要做出区分的。总之,一切的标签都要指向用户的行为预测!

那么,一个用户画像要怎样才能正确的建立起来呢?

从一个故事开始的用户画像

通过上文的描述我们知道,用户画像一定是基于业务模型的,或者说业务的目标就是用户画像的导向。所以业务部门如果连业务模型都没有想好的话,那么数据部门就只能巧妇难为无米之炊了。

当然数据部门也别闭门造车,这和做产品是一样的。如果连用户需求都没有理解透彻的话,就匆匆忙忙上线一个产品,无人问津是自然的了。

故事开篇

这里我们举个假设的例子,通过一步步地画像完善让大家更明白用户画像真实的建立过程!

故事背景

老王是一家互联网创业公司的核心人员,产品主营绿色健康沙拉。有一天,这家公司推出了 APP 专卖各式各样的沙拉服务,现在需要建立用户画像来做运营指导。

故事分析

公司现阶段在业务层面毫无疑问是更关注营销和销售,即如何将沙拉卖得更多更好?

梳理的运营流程

老王先是将顾客按是否购买过沙拉,划分成潜在用户和新用户。潜在用户是注册过APP但还没有下单的用户;而新用户是只购买过一次沙拉的用户。除此以外还有老用户,即消费了两次及以上的用户。

这里我们用JSON格式表示一个简易的用户画像:

{

“ID”: 123456,

“姓名”: “Chance”,

“消费”: {

“消费标签”: “潜在用户”
}
}

番外:JSON

JSON(JavaScript Object Notation,JS 对象简谱)是一种轻量级的数据交换格式。现在服务端和客户端的数据交换所采用的几乎都是JSON格式,它的格式固定且操作简单,不知道的同学还是建议了解下。

为什么独立出新用户标签呢?

因为老王的沙拉针对未消费的用户会有新人红包进行引导消费,不过这也带来了新用户消费一次后不再消费的问题(很多用户就是为了占红包的便宜才来的,红包没有了他们就走了),所以就更需要进行潜在用户、新用户、老用户的划分。

如果你是一个有追求的运营人员的话,那么划分老用户也还是不够的,这里还得继续用户分层才行。

传统的分层用RFM三个维度衡量,沙拉的客单价比较固定,F和M取一个就够用了。老王现在计算不同消费档次的用户留存度差异,譬如:某时间段内消费达XX元的用户,在未来时间段是否依旧消费。

番外:RFM模型

它是衡量客户价值和客户创利能力的重要工具和手段,在众多的客户关系管理(CRM)的分析模式中,RFM模型是被广泛提到的。该机械模型通过一个客户的最近一次消费(Recency)、消费频率(Frequency)以及消费金额(Monetary) 3项指标来描述该客户的价值状况。

像沙拉这类餐饮是高频消费,应该选择一个较窄的时间窗口才行,对于统计365天内的消费意义不大。

还有一点需要注意的是:沙拉在不同季节的销量是有差异的,冬天沙拉肯定卖的不如夏天,所以要综合考虑消费分布情况。

我们暂时这样规定:30天内消费200元以上为VIP用户,那么老王的生意如果特别好,就可以按照这样的思路继续划分超级VIP。并且这种标签往往需要配合业务实现,例如:VIP有赠送果汁、可乐,具有优先配送的权益等。而对于非VIP人群,我们需要激励该部分用户,并想尽各种方法往VIP发展。

画像属性收集

对于画像的人口统计属性,老王靠用户填写订单上的收货人姓名来收集。像籍贯年龄这些对沙拉生意没有特别大帮助的属性,我们可以不用重点关注。

用户地址可以通过收货地的设立规则判断,比如:某个地址出现X次的话,则可以将其认为常用地址。然后再依据送货地在写字楼还是学校,推算出用户是白领还是学生。

这样老王就可以针对不同属性的人群,采取不同的运营策略。

(1)学生群体

考虑到7、8月份是暑假,所以老王提前预估到校园地区的销售额会下降。而当9月开学季,则又能对返校学生进行召回。

(2)白领相关的群体

这部分用户更关注消费体验,对价格敏感是次要的。所以如果平台女用户的消费占比高的话,老王就可以主打减肥功能的沙拉,然后以包月套餐的形式提高销量。

下面是该阶段下的用户画像格式:

{

“ID”: 123456,

“姓名”: “Chance”,

“性别”: “男”,

“社会属性”: {

“常用地址”: {

“常用地址1”: {

“地理名称”: “北京市海淀区XXX”,

“经纬度”: “ABC.CBA”,

“类型”: “居住区”

},

“常用地址2”: {

“地理名称”: “北京市朝阳区XXX”,

“经纬度”: “CBD.DBC”,

“类型”: “商业区”

}

},

“职业”: {

“职业标签”: “白领”,

“概率”: 0.97

}

},

“消费”: {

“消费标签”: “VIP用户”,

“30天内消费金额”: “245元”,

“30天内消费次数”: “8次”

}

}

如果单以一家沙拉店来看,老王的用户画像已经很不错了,但他还是焦头烂额,因为用户流失率开始上升了,这可怎么办?

首先我们要意识到用户流失有各种各样的原因:比如对手老李沙拉的竞争品影响、沙拉的口味影响、性价比的影响、甚至老王够不够帅等的影响。

用户流失一直是一个难以预测的问题,想要准确地预测,可以尝试用机器学习进行建模。

番外:机器建模

技术方面暂且不提,我用大白话给大家解释一下:所谓的建模,其实就是建立一个复杂的方程组,只不过通常情况下的建模是通过算法工程师手动建立的。但是随着数据结构的越发复杂,通常来讲的建模方式已经越来越困难了,于是人们想着用机器自动完成建模,于是机器学习建模方式诞生了!

机器建模就是通过海量的数据喂养,让机器自己学会怎么建立模型。这样的模型通常来讲复杂无比,而且建模的过程和数据源质量强相关,所以就有了我们经常听见的数据清洗、过滤等。

好了,科普完毕,好像把机器学习说的玄乎其玄。不过再复杂它也是个方程组,那么毫无疑问它的本质就是找到两个或者几个变量之间的关系。所以呢,我们最好通过这种方式找到用户开始不消费的时间点之前的关键因素,可以是行为,也可以是属性。如果成功,我们就能更好地根据现有数据来预测用户流失。

很有可能你得到的结果是这样的:

  • 用户给过差评,用户有可能流失;
  • 用户历史窗口内消费频次低,用户有可能流失;
  • 用户历史窗口内消费金额少,用户有可能流失;
  • 用户历史窗口内打开APP次数少,用户有可能流失;
  • 用户的性别差异,用户有可能流失;
  • 用户等餐时间长,用户有可能流失;
  • 餐饮的季度因素,用户有可能流失。

用户太矫情了有木有…

这时我们就可以依据业务挑选可能影响业务的特征,然后提交给数据组去尝试预测流失。不过需要注意的是,这些用户行为并不能反应真实的情况。

为什么呢?不是说好了可以更好的预测的吗?

因为流失用户的行为,是一个变化的过程。比如:我虽然曾经消费过很多次,但是突然吃腻了,于是流失。这就像爱着爱着突然觉得累了腻了,然后高喊着“只在乎曾经拥有”的嘹亮口号玩命分手。这事儿谁能说得准呢~

要知道,单位时间段内的消费忠诚度是梯度下降的。所以为了更好地描述变化过程,我们可以将时间窗口细分成多个等距段。比如:前30-20天、前20-10天、前10天内,这种切分可以比前30天内可以更好地表达下降趋势,也可以更好的预测流失。

从老王的思路看,流失是可以通过用户行为的细节进行预判的。机器学习的建模虽然依赖于统计手段,但也离不开业务洞察。所以,用户画像建立在业务模型上,这个道理被再次证明。

不管怎么说,流失概率的建立解决了老王的心头之患。在提前发现并降低流失用户,然后挽回流失用户的手段推行一段时间后,老王发现流失用户确实减少了很多,不过成本却提高了,因为挽回用户也是要花不少钱的啊。

亏本可怎么行!老王忿忿不平,于是他决定只挽回有价值的用户。那种拿了红包才消费的用户不要也罢,真爱粉才贴心啊!

于是他配合消费档次进行区别对待,虽然流失用户的数量没有控制好,但是利润却提高了不少,这也算目的达到了。

我们能够发现,上述用户画像没有一个标签是脱离于业务场景之外的。而且基于业务场景,我们甚至还能想象出更多用户画像的玩法。比如:沙拉有不同的口味,蔬果鸡肉海鲜。

用户的口味偏好可以用矩阵分解,模糊聚类或者多分类的问题计算,也以0~1之间的数字表示喜好程度。当然还有价格偏好,即价格敏感度。

于是用户画像就变成了这样:

{

“ID”: 123456,

“姓名”: “Chance”,

“性别”: “男”,

“社会属性”: {

“常用地址”: {

“常用地址1”: {

“地理名称”: “北京市海淀区XXX”,

“经纬度”: “ABC.CBA”,

“类型”: “居住区”

},

“常用地址2”: {

“地理名称”: “北京市朝阳区XXX”,

“经纬度”: “CBD.DBC”,

“类型”: “商业区”

}

},

“职业”: {

“职业标签”: “白领”,

“概率”: 0.97

}

},

“消费”: {

“消费标签”: “VIP用户”,

“30天内消费金额”: “245元”,

“30天内消费次数”: 8,

“流失概率”: 0.21,

“价格敏感”: 0.72,

“优惠敏感”: 0.51,

“首次消费时间”: “2018.06.01”,

“最后消费时间”: “2019.07.02”

},

“行为”: {

“行为标签”: “活跃”,

“30天内登场次数”: 12,

“30天内评价次数”: 9,

“30天内退货次数”: 0,

“口味偏好”: {

“蔬菜沙拉”: 0.35,

“水果沙拉”: 0.62,

“海鲜沙拉”: 0.81

}

}

}

接下来再深入想一下业务场景,比如:某个办公地点每天都有5、6笔的订单,并且分属不同的客户不同的时段,那么外卖小哥得送个5、6次,这对人力成本是很大的浪费。

这时,运营就可以在后台分析相关的数据,然后以团购或拼单的形式促成订单合并。这样销售额的利润或许会下降,但是外卖的人力成本也节约了不少。(这是用画像作为数据分析的依据)

相信通过老王的故事,你已经对用户画像的建立有了一个重新的认识!

用户画像的数据来源

下图为一种常规的用户画像计算引擎示意图,虽然用户画像是一个最终的整体结果,但是它是由各个子画像综合计算而来的。这些子画像作为中间结果并不会被删除,而是作为重要的画像解释和应用数据保存下来。

拿视频推荐来说,子画像包括演员偏好画像、导演偏好画像、电影风格偏好画像,以及用户的基本属性等。

需要注意的是:属性相对于其他子画像更加不易变化,因此在图中并没有特别强调该部分画像更新模块。

用户注册等基本属性信息往往用于刻画相对静态的画像,而丰富的大量的用户行为日志,则是用于捕捉动态画像的重要数据来源。

  • 从数据的角度看:用户画像就是一个对原始数据二次计算重构后的新数据,对计算增加了负担,对存储也增加了负担。所以一开始必须经过逻辑设计,从而才能确定数据结构方面的设计。
  • 从可视化的角度来看:不同于以往的传统统计模式(如某个视频某个月的观看童按时间轴统计图),用户画像可能会开启一个以用户为核心牵引的新的入口呈现模式,如下图所示。

每个标签单击进去都是详细记录和细节,从抽象到细节逐步去体现用户画像数据结构,而这对于服务商来说,更加直观和更有帮助。

用户画像的架构

不同业务的画像标签体系并不一致,这需要数据和运营有目的性的提炼。用户画像一般按业务属性划分成多个类别模块,除了常见的人口统计、社会属性外,还有用户消费画像、用户行为画像、用户兴趣画像等。

具体的画像还得看产品的形态,比如:金融领域,还会有风险画像,包括征信、违约、洗钱、还款能力、保险黑名单等。电商领域还会有商品的类目偏好、品类偏好、品牌偏好等。

画一个架构倒是不难,难的是了解每个标签背后的业务逻辑和相关落地方式。而至于算法嘛,我们后续单独成文详谈。

从数据流向和加工来看,用户画像包含了上下级的递进关系。以上文的流失系数举例来说,它是通过建模得出的,所以依赖于用户早期的历史行为。而用户早期的历史行为,即10天内的消费金额、消费次数、登录次数等,本身也是一个标签,它们是通过原始的明细数据获得的。

上图列举了标签的加工和计算过程,这很好理解。最上层的策略标签是针对业务的落地,运营人员可以通过多个标签的组合形成一个用户群组,这样就非常方便执行。

不用多说,公司越大则用户画像越复杂。现在做个假设,如果某家主打内容分发的公司进入了全新的视频领域,那么用户画像的结构也是需要改变的。至少要既有内容相关的标签,也要有视频相关的标签,而且两者是并行且关联的。

比如:老王在内容标签下是重度使用者,而在视频标签下是轻度使用者。老张很久没打开内容APP有流失的风险,但在视频产品的使用时长上却很忠诚。凡此种种,看的是灵活的应用。当然了,姓名、性别等这类人口统计标签是通用的。

基于营销和消费相关的标签,比如:新用户、老用户、用户的流失和忠诚、用户的消费水平和频率等,都是构成 CRM(客户关系管理;用户/会员管理运营平台)的基础。

它的作用在于:将数据化的标签转换成产品运营策略。不同的标签对应不同的用户群体,自然就对应着不同的营销手段。

另外,CRM的结构中也会包含各类触达用户的常用渠道,比如:短信、邮件、推送等。同时也会包含CMS(内容管理系统),执行人员可以通过其快速地配置活动页、活动通道、优惠券等,然后靠营销活动拉动数据。

现在做个假设,老王的沙拉业务如果要是做大的话,那么运营平台就会以图中的结构搭建。那么老王可以在CRM中组合标签,然后新用户、老用户、流失用户的数据借助BI监控,最后通过CMS系统配置红包、优惠等等,通过短消息或推送Push触达用户端。

到现在我们知道,好的用户画像系统,既是数据生态体系,也是业务和运营的生态体系,它是一门复杂的交叉领域。

路漫漫其修远兮,吾将上下而画像。至此,用户画像的部分就暂时写到这里。

作者:百祝,公众号:常思行

本文由 @常思行 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 非常有价值的文章,已打赏支持

    回复
  2. 看了许多关于用户画像的文章,这篇写的最好,帮助很大,感谢。

    回复
    1. 非常同意,真的够系统了!

      来自北京 回复
  3. mark

    回复
  4. 系统化的一篇,看上上一篇追过来看下一篇,两篇加了起来应该就能对“用户画像”知其然再知其所以然了,具体要怎么去“画像”就要靠自己了,感觉通用的方法论已经讲的很透彻了,老王的例子还有JSON的演示很是具象,从一个小模型放大到大的系统,适合不同阶段、规模的产品学习,当然大的平台应该都是有了较为全面的数据系统,数据有了就看怎么用怎么调整了。

    来自上海 回复
  5. 好像百川写的那篇,非常之像。不过也挺好的。

    来自北京 回复
  6. 嗯,分手那段,我觉得是真的,你就老实交代了吧!23333

    回复
  7. 分享prd最好

    回复
  8. 接下来该写什么啦,可以预告一下,收藏了

    回复
  9. 深度好文

    回复
  10. 老兄用户画像到底应该如何正确使用呢?

    来自广东 回复
  11. 厉害👍学习了逻辑性非常的强

    回复
  12. 真的是干货,厉害,微信公众号已关注

    来自北京 回复
    1. 感谢支持 😉

      来自北京 回复
  13. 感谢楼主~最喜欢看干货了

    来自浙江 回复
    1. 😉

      来自北京 回复
  14. 厉害

    来自重庆 回复
    1. 😉

      来自北京 回复