作者：巨人电商

用户运营如何搭建用户标签？

POST TIME:2021-08-20

构建用户标签其实是一件很简单的事情，分三步即可：收集需求、构建标签框架、填充数据，这是一套通顺的逻辑链条。

标签系统，在企业中已不是什么“高大上”的说辞。然而让用户标签价值真正落地企业不多，就像“青少年谈性”，有一段话形容得再贴切不过：

“everyone talks about it, nobody really knows how to do it, everyonethinks everyone else is doing it, so everyone claims they are doing it。”（每个人都在说，不知道谁做了，每个人认为另外人在做，所以每个人都声称自己在做……）

今天我的分享主要包括四方面：

搭建标签系统，企业中究竟谁在做？
看似简单的“标签系统搭建”的三步走
“大功告成”后逐渐暴露的问题
破局的三种方式

一、搭建标签系统，企业中究竟谁在做？

在一家企业中，各职能角色更多的关心“能不能使用标签”，而很少关心“该由谁做标签的建设者”。事实上，绝大多数企业标签的建设最终是由企业的一个支撑部门来完成，比如是技术部门或者是数据部门。

二、看似简单的“标签系统搭建”的三步走

乍一想，构建用户标签是很简单的事情。简单说，正如“把大象装进冰箱”三步即可：收集需求——构建标签框架——填充数据，下面详细介绍。

第一步是“需求收集”

构建企业的标签系统，支撑部门会把“全公司的所有的需求”都扛在了肩上，因此第一步是收集全公司的需求。市场、运营、产品和技术等对标签诉求差异很大。

比如，市场同学关注用户的整体画像，更看中“结果”，如他们希望了解“渠道属性”，知道哪些渠道投放后用户转化效果会更好；运营同学则希望了解更为精准的数据，据此来构建用户分群，实现用户的个性化推荐，如给“消费超过 1000 元的用户”推荐某个活动；产品同学则关注千人千面的个性化页面展示；技术同学追求调取数据的便捷性，希望各职能线将所有数据放在一个平台上，形成统一的用户信息管理平台，而不是每次开发一个新需求，都要去不同的业务系统调取数据……

当然，这只是企业内部需求多样性的缩影。事实上，因为在企业中标签需求方众多，即便同样是产品同学，对标签的理解和需求也是千差万别的。

第二步是“抽象”

面对收集到的“琳琅满目”的需求，“抽象”是让标签体系满足多业务线需求的必需步骤，需要抽象成一个标签框架，这是一个极大的挑战，因此大部分企业的标签系统的初始框架是一个很庞大的系统。在初始框架中，通常会包括：人口统计学信息、用户个人档案、业务数据沉淀、业务方标记信息、策略类计算标记等。

这里我重点解释下“策略类计算标记”。我们给用户打标签，很多时候不是依赖用户的填写的信息或者采集到的基础维度的信息，而是会包含策略计算的标签，比如我们给“启动 APP 但七天未注册”的用户打上“高流失风险”的标签，这就是定义的一个策略标签。

第三步是在标签框架中“填充数据”

数据的来源通常包括：用户填写、行为数据、业务端数据、策略规则、外部补充等。

其中“行为数据”这一来源中，用户分群是常用的数据分析模型，比如筛出“半年内看过宫斗剧五部以上”的用户群体，并给该群体打上“宫斗迷”的标签；“外部补充”不单是购买数据库这种补充数据的方式，对大企业、大集团来讲，多业务线经常会涉及到数据的不断交流和互相补充。

三、“大功告成”后逐渐暴露的问题

整体看来，从收集需求——构建标签框架——填充数据，这是一套很通畅的逻辑链条。许多企业都能做到这一步，但这一步就意味着大功告成了吗？实际上，在企业走访的过程中，我发现大家会有各种各样的问题，以下几种更为典型。

1. 标签的定义解释

通常，标签系统建设团队定义一个标签名为“高价值用户”，各业务线基于自身对该群体的差异化需求，对“高价值用户”存在理解偏差和应用差异，标签系统建设团队需要花费较多时间来讲解标签的定义，而经常给某业务线同学解释清楚后，又发现不符合其实际需求……

2. 更新维护

标签是不断更新的，标签之间存在一定的相互交叉与依赖，且系统背后有一定的逻辑关系，而业务方对此并不理解，经常诧异：昨天的标签数据为什么没有跑出来，跑出来的是空值……在应用的时候存在各种顾虑。

3. 新增需求

“高中低价值用户分得太粗，我要⼀个介于中高之间的标签……”类似这种需求会很多，标签系统建设团队会因此排期过满。

举个例子。在一次银行客户的拜访过程中，客户向我咨询“开发一个新的标签需要多久？”对我们来说，建一个新标签是很简单的事情，修改规则并跑几分钟数据就出来了。而事实上，该银行客户从提出用户分群的想法，到与数据部门沟通并确认需求，再经过排期开发，全过程竟长达一个月。

为什么这么久？客户解释：数据部门作为后端支撑部门，在话语体系上是无法和业务口同学直接沟通，比如“高贷款潜力”用户可能对数据部门是较为陌生的概念。因此双方在沟通过程中，需要沟通至每个字段、取值、运算规则等，在明确后又可能因为研发资源不足而需要排期……

4. 需求冲突

抽象出来的标签框架是符合全企业业务线的需求的，比如定位启动 APP 后七天没有注册的用户是“高流失风险”用户，有的业务线却认为“当天没有下单就是高流失风险用户”，因此建议标签系统建设团队修改标签，但修改标签会影响其他业务线对标签的使用。

5. 数据输出

比如运营团队会根据用户分群进行个性化推荐，而推送系统也需要一些标签，这会造成一定的复杂度。

基于以上问题，标签系统建设团队一直会扛着来自各种业务线的压力，虽然花费较大精力完成的标签系统，在内部却被反馈用不起来。

四、破局的三种方式

过去十年中，我几乎一直在做 C 端的产品设计和运营管理，也有短暂的 B 端经验，工作中会涉及标签系统，针对以上情况，我考虑三种比较可行的破局方法：

1. 放弃⼤而全的框架，以业务场景倒推标签需求

前面讲到产品、运营、产品等对标签的诉求有较大的差异，同时不同的运营团队的诉求也存在很大差异，⼤而全的标签框架实际是站在用户视角搭建的，但是标签的真正应用者是业务方，所以应该从业务视角来实现。

因此最佳的处理方式是，我们应该放弃顶层的用户抽象视角，针对各业务线或部门的诉求和实际的应用场景，分别将标签聚类起来提供给相应部门。

以某直播平台的消费者运营为例，其消费者运营分为两类：大 R 用户和普通用户，大 R 用户年消费从几万到上百万不等，而普通用户年消费在几百至几千元之间。运营团队对两类人群的运营思路完全不同，因此对标签的诉求也不同：针对大 R 用户，平台会为该群体提供一对一的服务，因此运营者需要了解大 R 的详细数据，比如他们的互动对象、关注主播类型等；而普通用户则通常采用用户分群的方式运营即可。因此，我们不可能用同一套标签覆盖整个运营团队，这种以业务场景倒推标签需求的方法，能够与业务场景贴合更紧密，可用性上升。

2. 标签生成自助化，解决效率和沟通成本

主要表现在三个方面。

（1）标签生成的自助化能够让沟通成本降最低。前面讲到各业务线对标签的定义的理解不同，需要标签系统建设团队花费大量的时间沟通。如果能够让业务方自己定义规则，这必然是沟通成本最低的方式。

（2）标签生成的自助化，可重复修改的规则，降低无效标签的堆积。业务一直在发展，如果规则一成不变则很难跟上业务节奏的变化。我曾拜访过一家电商，他们发现半年前定义“母婴客户群”的转化率一直在降低，因此根据实际情况重新修改和定义了“母婴客户群”规则，并命名为“母婴客户群（新）”，这时之前的规则是无效的，且会一直占据计算资源……诸如此类，如果支持规则重复修改的话，这一类无效标签就会大量地消失。

（3）释放数据团队人力，释放业务团队的想象力。数据团队应该花较多的精力在企业的整个数据中台或新业务模型方面，而不是处理各业务线的标签诉求和标签维护上，自动化的标签生成能够极大限度地节省人力和释放团队想象力。

举个例子。有一家线上健身 APP，是神策标签系统应用较为深度的企业，他们从标签的创建到推送动作完成的全程不超过半小时，这意味中，他们半小时内即可对一次推送活动的效果进行评估。他们曾给我讲过一个有趣的故事：公司针对白领推出一款腰椎修复的课程，基于用户分群筛出用户群体后，发现效果并不好，然后深入研究发现，此项课程容易坚持的群体特征是：BMI 指数较高的群体。于是团队重新创建了新的运营计划，最终取得较好的效果。

我们通过这个案例可以看到，一旦业务人员能够快捷地访问和创建标签后，这会赋予他们很大业务上的想象空间，让更多优质的运营场景落地。

3. 有效的标签管理机制

有效的标签管理机制主要表现在以下几个方面。

（1）规则及元信息维护：标签相关的规则和元信息要尽可能的暴露给使用者，让使用者在使用的时候，能清楚知道标签的规则是什么、创建者是谁、维护者是谁、标签的更新频率周期等，而不是没有规则，或者将规则存在标签建设团队内部的一个 word 文档中。

（2）调度机制及信息同步：标签之间有一些关联，标签之间的链条断裂，是否有个调度机制或者信息同步机制让大家的工作不被影响。

（3）高效统一的输出接口：将所有的业务信息和用户数据信息汇总在一起，有统一的输出接口，改变之前需要针对不同的业务系统开发不同接口的情况。

我们回顾三种破局方式，本质上是解决了价值、手段、可持续性三方面的问题：以业务场景倒推要求需求，让业务方用起来作为最终目标，让标签系统价值得以实现；标签生成的自助化，它解决的是我们用什么样的手段去实现价值；有效的标签管理机制，意味着一套标签体系能否可持续性地在一家企业里面运作下去。

总之，对企业最重要的是：一套标签系统能不能在业务上用起来，能不能覆盖更广泛的需求，而不是一个大而全的框架。