(产品经理视角)人群圈选/用户分群与用户画像系统

最后更新于: 2024年5月17日

很多人搞不清用户标签、用户分群(人群圈选)与用户画像的关系,本文就来掰扯一下。

1、人群不就是组合标签么?

参考前文《(产品经理视角)如何设计一个用户标签系统》,标签是单一维度、简单业务条件的描述,如一个客户的性别是男,这就是一个典型的标签实例。

人群,则是用更复杂的条件来定义出一群人,如“性别为女、且最近30天下单频次为低频、且历史累计下单金额超过XX元”。

我和研发讨论过标签和人群的实现方案问题,他们一直纠结:其实人群不就是更复杂一点的标签么,为何要单独做人群,统一用标签处理不就行了?

从纯技术实现角度,似乎这么理解也没毛病。我把所有业务条件都打成标签,然后用多个标签组合成一个新的标签,不就行了?

但,实际的业务场景是更复杂的。标签这个孱弱的身子,大概率应付不了运营同学的折磨。

举个栗子。运营同学和你说,TA想要一个标签,条件为:过去90天内在小程序下过单但是在App没下过单的客户且这个客户历史上曾经在App下过单。目的是对App的流失用户做召回推送。

为了实现上面这个标签,你得加工出3个独立标签:

  • 过去90天内在小程序下过单的客户
  • 过去90天内在App没下过单的客户
  • 历史上曾经在App下过单的客户

然后做一次取交集的运算,将完全符合以上3个标签条件的客户,打上一个新标签。

以上操作,有没有什么问题?

当然有了。首先,标签一般是离线D+1生成的,你需要提前生成。其次,等上面这3个基础标签做出来后,你还要做一次交集运算,这本身也是需要耗费时间的。再次,如果我们用这种方式持续制作所谓组合标签,那用户名下的标签表也会无限膨胀,不利于维护。

所以,哪怕是只从技术实现角度考虑,我们也推荐,再抽象出一个叫做“人群”的东西,和标签区分出来。

2、人群到底要如何构建?

按照每个公司的实际业务情况和研发的实现方案,人群可以用不同方式来实现。

1)简单粗暴的方案:基于标签构建人群

前面已经提过类似思路了,就是我先做出一批标签待选,然后用交集/并集/差集等运算逻辑组合出一个人群。

这种方案的特点就是简单,但不够灵活,因为并非所有业务条件都适合做成标签,不然标签表会一直膨胀。

2)更灵活的方案:基于“事件”模型构建人群

事件模型(Event模型)是业界很常用的一个数据模型,一个Event就是描述:一个用户(或其他主体)在某个时间点、某个地方,以某种方式完成了某个具体的事情。

例如,将下单行为处理为一个Event,那么我们就可以使用这个事件的多个变量灵活来筛选条件:下单时间、下单次数、下单金额、购买什么商品等。

以上面提过的标签“过去90天内在小程序下过单的客户”为例,对应这里的Event,就是设置下单时间为“过去90天”、下单渠道为“小程序”,有做过这个动作的客户即可被圈选出来。

如果有多个Event,则使用交集/并集/差集等运算逻辑处理这多个Event之间的关系即可,效果类似下图:

3)完美的方案:多数据源自由组合条件

我看过的多数人群圈选系统,一般会同时提供用户标签、用户属性、用户行为(即“事件”)等多种类型的数据源供圈选,类似下图效果(截图来自微盟CDP产品文档):

如果你是技术人员,看到上面这张图,估计会开始思考:这些是不同来源的数据,咋统一处理?这,就是技术实现的问题了,本文不做探讨哈。

除了以上按照业务条件来生成人群,还有以下两个方式也很常用:

  • 手动上传用户ID/手机号生成人群
  • 对已生成的人群进行交集/并集/差集逻辑运算,生成新的人群

3、人群的更新时效与数据留存问题

D+1更新人群是很常见的做法。大部分人群系统会区分为:

  • 静态人群/只算一次
  • 动态人群/例行计算

在动态计算的人群定义中,经常会用到相对时间,如“过去30天”。按照D+1产出数据的话,这个相对时间也会动态取值,人群数据就能持续更新。

类似标签系统,人群系统的历史数据也要做个限制,不能无限期保留。可以将人群分群结果实例设置一个保存期限,如保留最近7天或者14天的数据。

4、人群的业务使用场景

和标签类似,人群的使用场景是很丰富的。大致可以分为两大类:

  • 广告
  • 消息触达(营销推送)

5、人群系统如何对接下游系统

如果你参考过业界某些CDP系统关于人群的功能设计,会发现,他们经常需要将人群“发布”或者“推送”给下游系统使用,这是咋回事呢?

实际上,你看到的上述操作,更多是为了广告系统使用人群来做适配设计。市面上单独售卖的CDP系统,将人群推送给百度广告、巨量引擎、腾讯广告等平台时,前提是已经在后台对接了相应广告账户。

如果不考虑广告系统适配的一些细节功能,我们可以设想一下,一个通用的人群系统,如何将数据传给下游系统呢?无非就两个方式:

  • 发布到一个共用的、中间的数据存储层,后续由下游业务系统自己去取数据
  • 直接在人群系统内,选择要发布的目标下游业务系统名称

如果是公司内部系统使用,还可以更灵活一些。人群系统开放接口,下游系统(如消息推送系统)在自己的功能界面内,通过接口来实现前端的人群查询和选择效果。

6、人群的ID类型问题

一般情况下我们会使用自有的客户id来触达到客户,如给客户直接送优惠券,只需要知道客户id即可执行。

在某些场景,我们需要知道客户手机号,如短信推送场景。这时候我们希望人群系统给出的数据包内有手机号信息。

如果你做过企微生态的推送,你需要的是企微外部联系人id(external userid),那人群系统给到的数据最好是以external userid形式呈现。

考虑到以上场景,可以在创建人群时就明确想要的人群ID类型,或者是在通用的人群生成后,在发布/推送到下游系统环节,指定想要的人群ID类型。

以上功能实现,前提是企业内部已经实现了One ID,或者说ID Mapping,即不同形式的客户身份/ID的关联、映射。

7、如何理解用户画像?

一句话解释:画像是人群叠加了分析维度的结果。

在使用各种数据源得到一个人群后,我们可以指定1个或多个维度来分析这个人群。

举例:线上举办了一次促销活动,将参加这次活动的人纳入一个人群。我们想分析一下,这个人群有什么特征,方便以后更有针对性地举办促销活动。我们可能会想分析人群的性别组成、年龄分布、累计下单金额分布等。这个分析结果就是所谓的用户画像,大致呈现效果如下图:

用户属性、用户标签、用户行为(即事件)都可以用做人群的分析维度,形成最终的用户画像。

8、实例解释标签和人群的使用区别

可能看完上面的一大堆文字后,你还是对标签和人群的区别有点模糊,那咱们还是用一个比较好理解的案例来解释下。

假设有这么一个业务需求:对累计下单金额超过50元的用户发送一批优惠券。分别用标签和人群,如何实现?

1)标签解决方案

首先,创建一个数值型的标签名为“用户累计下单金额”,D+1更新所有用户的这个标签值。

其次,改造下游业务系统。如,在发送优惠券的活动配置页面,需要实现这么一个功能:选择标签(名)后,可以有个下拉框,选择数学运算符(大于等于小于),再填写一个具体的数字(50)。这表示,从标签系统调用接口获取数据后,再进行一次过滤,计算出累计下单金额超过50元的用户列表,然后才能发送券。

上面这个方案,有什么问题?标签的使用方,可能需要自行实现较为复杂的逻辑计算层,明显不合理,无法开箱即用。尤其是当数据量很大时,需要等很久才能算出想要的客户名单。

这种做法比较笨重,但,也不是不能用,比较适合做一些临时、定制的业务场景。

那,如果就是要用标签来实现呢,有没有其他办法?

有,可以对标签系统的功能进行迭代,允许为数值型的标签,配置标签值分层,类似下图效果(截图自神策官方文档):

以此处的标签名“用户累计下单金额”为例,如50元(含)以下分一个层,50元以上分一个层。那么这个标签下的用户就会自动分到对应层级。也就是说,我们不采用原始累计消费金额打标签值,而是采用这个分层(名)来打标签值。

按照上述方式稍加改进后,优惠券发送活动层可以直接拿到累计消费金额在50元以上的用户名单,而不用额外做一次计算。

但,问题依然存在:“用户累计下单金额”这个数值型标签的分层标准,可能会经常调整,也许过两天运营会来和你说他们要计算“50元 < 累计消费金额在 < 100元”的客户,还是比较麻烦。

2)人群解决方案

在本方案中,使用已有的标签“用户累计下单金额”来构建一个人群,通过为此标签配置数学运算符,将计算过程在人群系统中实现,最后得到的是一个最终明确多少人的人群包。业务系统只需要拿到这个包,去发券就行了,不用自行再算一遍,因为人群系统已经帮你算好有多少人了。

从以上两个方案的对比,我们可以看出:对于复杂业务条件的客户筛选需求,用户标签很大程度上是为了创建人群而做的基础数据准备,使用人群来圈选客户,预先计算好最终客户名单,对下游系统更友好。

发表回复

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