最后更新于： 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）人群解决方案

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

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