最后更新于： 2024年5月12日

在互联网行业，想必大家或多或少都听过“用户标签”这个词。作为产品经理，我有幸接触过一些相关系统，在最近一份工作中还有机会亲手从0到1构建了一个（最小可用的）标签系统，本文简单记录下这个过程。

1、什么是用户标签

咱这里就不抄那些专业术语了，直接来大白话解释下。

先明确下，标签不仅仅适用于“用户”，还可以是其他实体对象（订单、商品、供应商等等），或者业务关系（如客户预约行为）。本文只讨论用户标签。

我们实现一个业务系统，记录最基本的用户数据时，会有诸如性别、年龄、注册时间等信息，以多个字段和字段值形式存放到数据库中。

有一天，客服同学来说，她们想在接待客户咨询的过程中，手动标记某些客户为“常投诉客户”，以便下次其他客服同事看到这个标记时打起精神应付客户。你说，没问题，加个字段的事（客户投诉行为：常投诉客户），再简单不过。

又有一天，运营同学来说，他们想统计一下客户下单频次数据，对客户进行分类，方便后续针对不同下单频次的客户进行有针对性的运营。你说，没问题，加个字段的事（客户下单频次：高频下单用户、中频下单用户、低频下单用户），再简单不过。

过了几天，广告部门的同事来说，收到一批客户投诉，说咱们App上广告太多了，需要人工给这批人屏蔽广告，得有个办法标识这些客户。你说，没问题，加个字段的事（是否屏蔽广告：是、否），再简单不过。

以上种种需求场景，确实都可以简单粗暴通过加字段实现。不过，字段加多了之后，你开始觉得不对劲：这样下去用户表的字段无限膨胀，不好维护了哇。

经过一番搜索，你了解到，可以用“标签”这玩意来统一处理以上需求场景，会更加高效、有序。

客户投诉行为、客户下单频次、是否屏蔽广告这几个理解为“标签名”。相应的字段值/枚举值，就是“标签值”。

我们日常习惯笼统说“标签”，但从产研实现系统的角度看，需要明确区分标签名和标签值。

2、标签有哪些类型（数据特性）？

从不同角度来理解标签，你会发现差异还是挺大的。

按标签的数据生成方式，标签可以分为：

• 事实标签/统计类标签：如性别、出生年月等，在数据库中一般可以直接获取或者简单计算得到
• 模型标签/规则类标签：如“高频下单客户”需要根据业务规则进行更多的加工计算得到（举例：过去30天下单次数超过10次，定义为高频）
• 预测标签/算法类标签：如“可能感兴趣的商品”、“预计复购可能性”等，是经过特定的算法规则推断出来的

按标签的数据更新频率，标签可以分为：

• 静态标签：打上了就不再更新，如性别信息
• 动态标签：随时间或其他因素推移，标签值会改变，如用户的“常购买商品”可能会变化

按用户某个标签名下是否能有多个标签值，标签可以分为：

• 单值标签：如性别（你总不能说一个用户有多个性别吧，除非你是在阿美莉卡？）
• 多值标签：如用户的“常购买商品”（统计用户最近3个月购买次数最多的5个sku）

理解好标签的数据特性，有助于我们在实现标签系统的过程中，处理一些功能实现的细节问题。

3、标签的数据来源

既然叫“用户标签”了，那么最基本的一些用户信息，如性别等，可以在用户注册时得到，或者后续引导用户填写相关信息。这些都可以直接加工转为标签数据。

在实际业务场景中，我们更多会使用自有的业务数据，如订单数据来生成标签。如，运营同事很喜欢根据客户下单金额、次数来区分不同的标签。

如果有做客户端的埋点采集，那么这些数据也可以用来做标签，如通过计算指定前端页面的浏览行为来创建一个叫做“高频浏览客户”的标签。

除了以上场景，还有手动打标签的场景，如人工指定一批客户名单打上某个标签，或者是在客服/运营的工作界面提供手动打标签的功能入口。

4、标签值的数据类型区分

为啥要对标签值进行数据类型区分？因为后续使用中，实现前端界面交互时，所展示的标签名下可用标签值的筛选逻辑条件是不一样的，需要根据标签值的数据类型来判断和区分。举例：

• 有些标签值是可以做数学逻辑运算的，有些不能；
• 有些标签值是表示日期的，需要配合特定的前端组件来使用。

一般来说，我们会对标签值数据类型大致划分如下：

• 枚举型：即可用标签值必须事先逐一配置好，典型如性别（先配置好男、女作为值）
• 数值型：可以或者说是有需要做数学逻辑运算的数据。如累计下单金额、年龄、页面访问次数等。
• 文本型：如“用户热搜词”，你没办法穷举用户可能在你的网站上搜索的词汇吧？也没必要事先枚举。
• 日期型：年月日时分秒，如用户出生日期。我看业界的某些用户标签系统，有的会区分得更细，分为日期型（年月日）和时间型（时分秒）。
• 布尔型：0或者1（0为False，1为True）。此类型在埋点分析事件场景比较常用，其他场景很少用到。

5、标签值枚举的问题

大部分人理解的标签值，都是可以且必须事先配置好枚举值供选择的。

举个例子，“性别”标签名下，会有什么枚举值可以用呢？

• 男
• 女

如果不先配置好枚举值，你在打标签时突然传入一个性别为“其他”，系统逻辑上就不好搞了。

所以这里其实隐含一个逻辑：枚举型的标签，在打标时只能从已有的枚举值来取数，不能自定义写入标签值实例。

这里引出一个很细分的场景：某些枚举值非常多，如“省市区”信息，难道我还得手动录入一个完整的省市区表不成？

其实不用，因为类似枚举值，一般来说研发已经单独维护了一份码表。

稍微处理下，允许标签系统能够选择这些码表即可，表示从后者自动获取数据来源作为枚举值，无需手动再录入一份枚举值，如下图所示（截图源自网易数帆官网）：

6、标签的状态管理

标签也是会有生命周期的，随着公司业务的发展，某个阶段会用的标签，后续可能就废弃不用了。

为此，我们需要实现对标签的状态管理，简单说就是上下线的管理。

只有上线状态的标签才能正常被调用去打标。已下线的标签，默认无法在前端界面的标签筛选功能中被查到，查看标签场景（如用户详情页）最好也做隐藏。

7、标签目录树（业务分类）

想象一下你有几百个标签（名），你平时要如何有序维护？

这就牵扯到如何对标签进行业务分类的问题。

如果公司是多业务线的，建议区分公共标签以及按业务线划分出一级分类。

如果没有多业务线，则根据公司实际业务场景划分就好了。如简单划分为用户属性标签、消费行为标签、售后行为标签等大类。

从方便使用的角度出发，不建议做太多层级的分类，控制在三层以内即可，没必要分得太细。大部分时候我们习惯直接搜索标签名来定位，目录树只是为了方便归类检索。

注意：标签归到哪个目录树下，这个信息是可以根据需要进行调整的，并非一成不变。

8、标签到底是如何打上去的？

前面说了那么多理论知识，看到这里，如果你是标签系统的使用者，你肯定会很想问：你到底能提供一个什么界面让我直观地看看，这些标签是如何做出来的？

按照我过去的几个类似项目经验，做一个用户标签系统，大致可以分为两个阶段：

阶段1：纯脚本维护

一来，很多公司研发资源有限，一上来就要搞一个大而全的用户标签系统，不太现实，不如先问业务方想要什么标签，我们让研发通过数据库给你手动加工出来，先用着就行。

二来，除非业务方非常熟悉标签体系的玩法，一开始就能明确给出要什么标签，否则，产研很难在初期就将标签系统可能用到的数据源都梳理出来，形成比较完善的界面化配置功能。

在这个阶段，可以理解为研发只是实现了标签系统的基本后端逻辑（不含打标签的具体业务逻辑），但不提供功能界面。

阶段2：前端可配置化创建

当业务方已经能在实际业务中把第一批标签玩得很溜了，公司业务也相对稳定了，此时可以考虑将标签可能用到的数据源做梳理，进行适当的归类，形成可配置化功能界面，类似下图的效果（图片截取自字节跳动火山引擎文档中心）：

9、标签的使用

9.1 技术角度使用

标签系统作为一个相对独立的应用，需要对外提供多种能力（接口形式），包括但不限于：

• 基础标签库查询（标签分类+标签名+枚举标签值）
• 为指定用户增删改标签
• 查询指定用户名下已有的标签实例

标签系统接口的设计，有个点值得提一下：接口需要能支持传参记录“备注”信息，如在客服手动标注的场景中，可以默认传参备注为“手动打标”。

如果是做成中台类型的系统，严格来说，还要记录是哪个下游系统调用了接口，并在打标时记录到日志中。

9.2 业务角度使用

有非常多的场景都能用到用户标签，以下仅列举常用的几个。

• 客服：第三方客服聊天工具一般都可以嵌入自定义页面用于展示企业自有业务信息，此处可以加上手动打标的功能入口，如用于标记某些客户为“恶意投诉用户”等
• 营销：新用户注册未下单，打上标签，根据此标签推送新人优惠券
• 风控：有故意退款、薅羊毛等客户，打上标签，后续在敏感环节进行拦截（如大额下单）
• 广告：根据预定义的标签展示个性化广告

10、内部系统CRM客户详情如何展示标签

大部分公司都会有个内部系统可以看客户详情信息，我们需要找个合适的地方来展示客户名下的标签数据。

展示标签名和标签值的比较简单，参考如下（网上随便截的图）：

我想提的是，最好有个标签变动日志的入口可以看（谁在何时修改了什么标签）。变动日志至少包含以下信息：

• 变更类型：新增、删除
• 变更标签名
• 变更标签值
• 表更时间
• 备注
• 操作人

11、标签的更新时效与数据留存问题

大部分情况下，D+1离线标签更新已经足够业务使用了，尤其是某些数据量特别大的公司，全量更新一次标签计算量是很大，也很耗时。

有些人可能会想，能否做成实时更新的标签？例如用户做了某个操作，我就立即给TA实时打一个标签。不是不能做，只是有没有必要的问题，很多时候得问一句，有必要这么实时么？

另外，在D+1更新的情况下，每天都会刷新一次标签数据，那之前的历史数据是否要保留一份呢？考虑到有观察标签变动趋势的诉求，可以将用户标签实例设置一个保存期限，如保留最近7天或者14天的数据。

12、听说能做组合标签？

例如，用户性别为男，下单频次为高，根据这两个标签，组合出一个新标签：男性高频下单用户。这种方式是否可行？

上面这个问题，其实是混淆了标签和“人群”的区别。标签更适合单一维度、简单业务条件的描述。如果你想要构建一个非常复杂的条件来输出一个标签，不如用“人群”或者叫“用户圈选分群”方式来实现。

13、讲讲RFM标签呗？

RFM算是一个比较复杂的标签细分应用，要详细介绍的话不是一篇文章就能搞定的。

But，市面上已经有很多RFM相关的文章了，我感觉没必要重复写，我只提一下我做过的RMF标签项目中，得到的一些经验/教训：

• R指的是最近一次下单距今时间，取全量数据（一般不会为R限制统计区间），F和M都必须明确指定统计周期，如最近30天；
• 新注册用户的消费行为与老用户差别比较大，个人建议对新老用户区分处理；
• 市面上流行的典型8个分类RFM标签，实际使用时，可以做精简，选一些重要的标签去打即可，其他不太重要的，直接打为“其他价值用户”/ “低价值用户”;
• RFM覆盖人群或者说取数范围是：使用R、F、M原始值均有数据的用户作为数据源。

14、总结

以上主要是从产品功能实现的角度，描述了一个用户标签系统是如何构建的。

市面上有不少优秀的第三方系统，支持管理用户标签，但在实践中，公司基本都会自己做一套标签系统，因为这确实是很核心的数据应用，有很多数据源没办法强行套用在第三方系统上。

用户标签可以单独使用，但实际上，更多的公司同时还会做“人群”系统，此时，标签还能作为人群的重要数据来源之一，详情参考《（产品经理视角）人群圈选/用户分群与用户画像系统》。

我在做这个系统的过程中，参考了一本很不错的书，也推荐给感兴趣者：《标签类目体系：面向业务的数据资产设计方法论》by 季乐乐/任寅姿。

另外，我还大量参考了神策、字节跳动火山引擎的官方文档，在此也得表示下感谢哈。