做一个系统的关键策略：标签系统

2025年7月1日·阅读约 7 分钟 Tag System Search Product Strategy

背景

这是美团 App 搜索场景下，用来管理和理解供给的标签系统。它给产品、运营、研发提供管理工具，最终为用户提供三种产品价值：标签召回、标签筛选和标签展示。

我是供给标签方向的产品经理。我的工作是调研头部搜索场景下用户对标签的兴趣和诉求，结合业务诉求和经营策略管理标签数据，并用这些数据建设标签召回扩充、用户筛选器和标签展示三块产品能力。

一个系统能不能做成，关键在于先做什么、为谁做、做到什么程度就能被用起来。下面是我在推进标签系统时用到的两条关键策略。

一、MVP 策略：先找到最高 ROI 的那一块

起点：一个大而全、却停滞的规划

最初有一个技术主导的规划：把用户看到的展示模版做成可组装的资源，像拼图一样搭出结果页。我深入了解之后发现，这个项目的目标主要放在能力重构上，较少考虑业务用户怎么用；重构范围又非常大而全，最终连配置模块的设计和现有逻辑的梳理都没完成，就陷入了停滞。

重新定位价值

我站在标签系统的视角思考：把结果页的各个模块组件化，要消耗大量研发资源，其中价值和 ROI 最高的部分在哪里？最能影响用户和关键决策人的点在哪里？我的结论是，这件事最大的价值在于快速、准确地承接业务需求并上线，进行实验验证并实现业务收益。其他方面，比如管理历史逻辑、给产研提效，都是相对次要的收益。

从需求池里定位 MVP

按这个逻辑，我梳理了需求池里的业务需求。因为项目目标是提效，所以我选出的是最高频、而且历史上已经验证过业务价值的需求，主要有三类：

标签召回：在某类搜索 query 下，扩充召回带有某种特征的供给。比如搜健身房时召回带"跑路赔付"保障的门店，搜餐馆时召回有停车场的，搜商品时召回 30 分钟内能送达的。这些都可以通过离线标签或在线接口标签，在召回和排序层做召回扩充、精准召回或过滤。
筛选器：在一部分 query 下，能识别出用户有泛化、平移或收敛的诉求，其中收敛是最大的诉求。
- 品类收敛。 用户搜"火锅"，收敛性换词的比例很高：搜索结果首屏实际只能展示 2–3 个商户，又叠加了用户的历史偏好，品类丰富度不够。把品类标签接入筛选器，能更精确地帮用户挑出合适品类的结果，提升搜索效率。
- 品牌收敛。 这也是收益很大的项目。食品、药品都是用户非常在意品牌的品类，实验时我们按品类、按 query 分别回收效果。这里有不少难点：啤酒、牛奶这类保鲜期短的品类，很多地区本地品牌卖得最好，筛选器必须根据本地的召回结果来展示；有些品类南北差异明显，比如月饼，南北方关注的是广式、苏式、京式还是鲜肉月饼，甚至还有不同馅料和包装，需要按地区和用户特征做算法排序。最终的实现是：运营配置尽量全的候选集，支持算法排序，并能分地区、分 query 调权或屏蔽；技术上根据召回结果展示筛选项，过滤掉没有结果的选项。
标签展示：在结果卡片上用角标、推荐理由、榜单等形式展示标签，帮用户在列表里快速判断、做决定。

推进顺序

一开始先做标签召回，目的是熟悉搜索链路，同时解决搜索体验问题。之后和设计团队一起做了用户调研，按业务价值的优先级逐步建设能力：先做筛选器的运营能力和策略优化，再做标签展示。

小结

大而全的重构很容易在"梳理现状"阶段就耗尽耐心和资源。先回答"谁会因为这个系统立刻受益"，再倒推最小可用范围，系统才有机会被用起来，再用真实的使用反过来驱动后续的能力建设。

二、分层策略：给标签做元数据管理

标签数据需要一套元数据管理机制。不同标签在用途上天然就不同，有的只适合召回、不适合展示，诸如此类。这套分层机制必须做好。

MVP 承接的三类需求正好对应标签的三种用途。三种用途对标签质量的要求不一样，所以每个标签都应该在元数据里标明自己能用在哪一层。下面用美团搜索里常见的场景整理成一张表：

	召回	筛选	展示
解决什么问题	用户的 query 没直接说出商户名或菜名，要把"意思对得上"的供给找出来	用户已经有明确的约束条件，想快速缩小范围	帮用户在结果列表里快速判断、做决定
适合的场景	泛需求、场景类 query，如"聚餐"“约会"“适合带娃”；长尾 query，结构化字段接不住的时候兜底	结果多、决策维度清楚的品类，如外卖按"免配送费"“30 分钟内”，到店按人均、距离、营业中	列表卡片的角标、推荐理由、榜单，如「回头客多」「近期热销」「必吃榜」
典型标签	评论挖掘出的场景标签（适合聚餐、环境安静），菜品和口味标签，同义词和品类映射	品类、品牌、价格区间、配送费、送达时间、营业状态、商圈	口碑标签、销量和复购、榜单、服务承诺（准时达、放心吃）
对标签的要求	语义相关即可，准确率要求中等，后面还有排序兜底；覆盖越广越好	取值离散、用户一看就懂；覆盖必须全，漏打会把店直接筛掉	准确率最高，要能对商家和用户解释；文案合规，不能用"最"“第一"这类绝对化表述
准召率要求	召回率优先，准确率 70–80% 即可，错的由排序过滤	准确率和召回率都要高，一般都在 95% 左右：错打会混进不符合条件的店，漏打会把符合条件的店筛掉	准确率优先，一般 95% 以上，敏感标签 98% 以上；召回率可以低，宁可不展示也不能展示错，但要配套运营工具兜底
不适合的情况	内部经营标签可以参与策略调控，但不能当作用户意图的依据	用户很少主动勾选的标签（如「新店」），覆盖率不够的标签	模型挖掘、准确率不稳的标签；「补贴商户」「高佣商户」这类内部标签

同一个标签，能不能用、用在哪，差别很大。 几个典型情况：

只能召回，不能展示。 「适合聚餐」是模型从评论里挖出来的，准确率大概七八成。拿它把相关的店召回来没问题，排序会再筛一遍；但如果直接在卡片上写"适合聚餐”，错的那两三成就成了对用户的误导，商家也会来申诉。
只能内部用，绝不能展示。 「补贴商户」「高佣商户」这类经营标签，可以参与召回和排序的策略调控，但一旦展示出去，就等于把平台的经营策略摆到了台面上。
能展示，但不适合做筛选器。 「新店」可以做成角标吸引点击，但很少有用户会专门勾选"只看新店”，放进筛选器只会占位置。
能做筛选器，但覆盖不全时不能开。 「免配送费」如果只覆盖了一半商户，用户勾选后会发现很多明明免配送费的店不见了，还不如不提供这个选项。

召回率低，要靠运营工具兜底。 展示标签为了保证准确率，模型阈值会卡得很严，必然有一部分本该打上的商家被漏掉。对商家来说，没打上「回头客多」这类标签就是实打实的流量损失，一定会来申诉。所以展示层除了模型，还要给运营准备一套客服工具：商家认为标签有问题、没给自己打上时，运营核实后可以尽快把标签上线，不用等模型下一次迭代。

所以元数据至少要记录这几项：适用层级（召回 / 筛选 / 展示 / 仅内部）、数据来源（商家填写、运营打标、模型挖掘）、准确率和覆盖率、更新频率、负责人，以及展示类标签的合规审核状态。

有了这套分层，新需求来了先查元数据：想用的标签够不够格用在这一层？够格就直接配置上线，不够格就知道该补准确率还是补覆盖率，不用每次都从头评估一遍。

回头看

回头看，这两条策略其实回答的是同一个问题：有限的资源先花在哪里。

先找价值，再谈能力。 停滞的拼图系统有技术方案，缺的是一个"谁会立刻受益"的答案。把目标从能力重构拉回到快速承接业务需求，MVP 才有了清楚的边界：只做最高频、已被验证过价值的召回、筛选、展示三类需求。
顺序本身就是策略。 先做召回，是为了熟悉链路、先解决体验问题；再通过用户调研排出筛选器和展示的优先级。每一步都为下一步积累认知和信任。
把"能不能用"变成数据。 标签的价值取决于每个标签有没有用在对的地方。用元数据把适用层级、准召率、来源都记录下来，判断就不再靠经验和反复评估；模型兜不住的地方，再用运营工具补上。

这套思路也适用于标签系统以外的场景。任何一个面向多方使用、又有历史包袱的数据或平台类产品，都可以先找最高 ROI 的使用场景做 MVP，再把"什么能用在哪里"沉淀成可查询的元数据。