从0到1搭建用户标签体系：设计原则、建设流程与避坑指南

简介面向企业数据运营、会员运营、市场与商品团队以及CDP产品、数据分析从业者的专题资料聚焦如何从0到1构建并应用标签体系帮助读者厘清标签定义、体系框架、设计边界与业务落地路径。内容源自DataFunSummit 2023火山引擎专场围绕以数据为基础、贴合业务场景、借助群组寻求最优方案、兼顾组织架构与人员技能等思路展开并系统覆盖建设流程、5W2H目标分析、数据探查、主体规划、One ID、离线与实时标签、标签价值评估及电商、金融典型案例。包内为1个PDF文件约8.8MB适合作为商业资料、交互方案和模板素材查阅。已有211人学习可用于梳理标签类目、规划更新频率、设计圈群策略并复盘应用效果。1. 标签体系到底是什么从一个“给用户分类”的困惑说起整理衣柜的时候很多人会按季节分层、按场合分格找衣服很快也有人把所有衣服堆在一起旁边贴满便利贴写着“常穿”“上班穿”“去年买的”结果越贴越乱。标签体系要解决的就是后一种困境它关心的核心是“柜子怎么分层”而不是“再贴多少张便利贴”。通俗地说标签是人为规定的、高度精炼的用户特征标识比如“近30天有下单”“价格敏感”标签体系则是把这些标签长期组织起来、还能持续扩展的一套框架。搞懂这套框架你才会明白为什么有的团队标签越用越顺有的团队标签上千个运营却依然靠猜。2. 标签不是备注拆开看标签与标签体系的真实含义很多人第一次听到“标签”脑子里浮现的是给用户打备注——想到什么写什么随手一贴。真正的标签和随手备注的差别比想象中大得多。随手备注只对写的人有意义标签却要被一群人、跨部门、跨系统反复使用。这就决定了标签从一开始就得按“公共设施”的标准来设计而不是按“个人便签”的标准。2.1 标签的三条硬特征业务相关、人为精炼、提前设计第一条标签是与业务紧密相关的用户数据。注意“业务相关”这个限定。数据库里躺着的用户ID、时间戳、页面路径、设备型号都是数据但都不自动等于标签。它们要经过一层提炼变成“这个人最近很活跃”“这个人对价格敏感”这类能被业务直接拿去用的判断才算跨过了标签的门槛。一条标签如果没有任何业务动作会用到它那它就只是一个没人查的字段。第二条标签通常是人为规定的高度精炼的特征标识。“人为规定”这四个字很关键它意味着标签背后一定有人先定义了口径。什么叫“活跃”是7天登录一次算活跃还是30天内有三次下单算活跃这个定义不会从数据里自己长出来必须有人拍板。精炼则意味着标签的输出要短、要能直接读通常是一个词、一个区间、一个等级而不是一段描述。第三条标签通常提前设计好并且保持相对长期的存在。临时查一下“昨天有哪些用户点了按钮”那叫查询不叫标签。标签的价值恰恰在于它被提前想清楚、被固化下来然后被反复复用。反过来如果一条标签定义完第二周就没人用了说明它当初就不该被设计出来。把这三条放在一起看就能理解为什么标签不能靠“想到就加”来积累。它更像城市里的路牌得先有道路规划路牌才有意义路牌随便插只会让人更迷路。2.2 标签体系是一套组织方式先有货架再谈商品标签体系是标签的组织方式是一套可以长期使用并且适用性较强的框架它能把多种标签合理地组织起来便于高效使用和扩展。这句话里最容易被忽略的是“组织方式”和“扩展”两个词。组织方式决定了一个新标签做出来之后该放在哪里。常见的组织维度有基础属性、用户旅程、地理位置、购买兴趣这几类。运营想找“最近可能流失的人”会去用户旅程里翻想找“常驻某个城市的人”会去地理位置里翻。类目对了找标签就像在超市里按区域找货类目乱了几百个标签平铺在一个列表里搜索框之外的路径基本作废。扩展则决定了这套东西能活多久。业务是会变的今天做拉新明天做复购后天做会员分层。每来一个新业务方向就会长出一批新标签。如果框架没有预留位置新标签只能硬塞进旧类目塞到第三批的时候整个体系就名存实亡了。打个比方标签是书标签体系是索书号。只有几十本书的时候堆在桌上也能找到书到了一千本没有索书号找一本书的时间够你把这些书重新买一遍。2.3 没有体系的标签会变成什么样三个后果第一个后果是同名不同义。会员运营说的“活跃用户”可能指30天内登录过市场部门说的“活跃用户”可能指7天内有交互行为。两个团队各自建了一条叫“活跃用户”的标签报表一合并数字对不上然后开始互相怀疑对方的数据有问题。这种冲突不是技术问题是缺少统一口径造成的必然结果。第二个后果是无法复用。每次搞活动分析师临时写一段逻辑圈人活动结束这段逻辑就散落在聊天记录里。下个月做类似活动没人记得上次是怎么圈的只能重写一遍。临时逻辑永远停留在临时状态组织的经验也就永远沉淀不下来。第三个后果是无法扩展。新业务进来带进来一批新标签老类目放不下于是有人新建一个“其他”类目。半年后“其他”下面挂了两百个标签等于没有分类。2.4 一个可交付的标签长什么样五列清单判断一条标签是不是“可交付”最简单的办法是看它能不能填满下面这张表。填不满后面一定有人来追问。标签名所属类目标签类型更新频率口径定义近30天订单频次消费行为规则标签天级近30天成功订单数按0、1-2、3-9、10分段高价值客户客户价值业务标签周级近90天累计消费金额达到内部约定阈值活动响应度高营销响应算法标签周级近半年参与活动次数与到场率的综合评分“标签名”解决能不能被搜到“类目”解决放在哪里“类型”解决由谁来维护“更新频率”解决数据什么时候新鲜“口径定义”解决两个人吵架时听谁的。五列里最容易偷懒的是最后一列而它恰恰是后面返工成本最高的一列。3. 为什么“大而全”的标签体系一定会翻车四条设计思路做标签体系最典型的失败路径是一上来就列一张几百个标签的清单然后按清单去补数据。这条路看起来很有执行力实际上是在给未来攒债。真正可行的做法是先定几条设计原则让每一个标签都有明确的来处和去处。3.1 以数据为基础先看手里有什么牌再设计打法标签的原料是数据能加工出什么标签取决于手里有什么数据。常见的原料大致分三类数据类别典型内容能支撑的标签方向行为埋点自有触点实时抓取的数据、基础监测事件、默认参数与自定义参数、主ID与副ID、位置、事件、时间戳、自定义维度活跃度、访问偏好、触点偏好、实时意图属性数据用户ID属性、数仓画像、后台数据、本地数据基础画像、生命周期阶段、价值分层业务数据订单系统、客服系统、营销与风控系统消费能力、复购、投诉风险、履约偏好这张表最实用的地方是帮你提前判断某条标签“做不做得出来”。想做“复购率”得有订单数据想做“内容偏好”得有行为埋点。没有对应原料却硬要上标签最后只能靠人工填填一个月就没人填了。提示设计标签之前先做一次数据盘点把“有哪些数据域、哪些业务过程、哪些表、数据分布如何”写清楚比先画标签清单有用得多。3.2 以业务场景为锚点三个部门要的标签根本不是一回事不同企业的不同团队对标签的诉求差异极大。会员运营关心用户生命周期、消费能力这类全链路分析相关的标签市场部门更关心营销触点、交互行为相关的标签商品部门更关心人货匹配相关的标签。同一批用户在三个部门眼里是三种不同的画像。这就带来一个很现实的结论标签体系不能盲目追求大而全合适的做法是与各业务线、各部门的诉求和实际场景紧密结合让标签为业务目标服务。一个只有八十条标签、但每条都有人在用的体系价值远高于一个八百条标签、一半以上从没被搜过的体系。判断一条标签该不该做可以问一个很土的问题这条标签做出来之后谁会拿它去做什么动作如果答不上具体的动作比如“给这批人发券”“对这批人换推荐内容”“把这批人排除在投放之外”那这条标签大概率是给汇报材料准备的不是给业务准备的。3.3 群组与标签的分工不是所有数据都值得沉淀这是整套方法论里最省钱的一条。并非所有数据都要做成标签才能应用。对于临时触达或者探索性分析的内容用群组的方式解决就够了。比如对参加某次活动的人群发一条通知这种需求一次性、范围明确做成标签反而是浪费。真正值得沉淀的是从群组里挖出来的规律。举例来说一场活动结束后发现有一批人反复参加这时候可以给“频繁参与活动的人”打上“活动响应度高”的标签。有了这条标签后续优化活动方案时对响应度高的人群减少优惠券成本投放同样能达成效果钱就省下来了。群组是这一次的名单标签是下一次还能用的判断。这里还有个容易忽略的关系标签一般是分群的上游数据。先有标签圈选客群时就能直接组合标签不用每次重新理解原始表和事件字段。客户数据平台通常既支持基于原始数据基本属性、行为事件、业务数据构建群体也支持基于标签构建群体后者的门槛明显更低业务人员自己就能操作。3.4 结合组织架构和人员技能谁建、谁用、谁能改不同行业、不同公司的组织架构存在差异人员技能也不尽相同。同样一套标签体系在一个有专职数据团队的公司里可以做得精细在一个运营自己动手的公司里就必须做得简单。照搬别人的标签目录基本等于给自己找活干。设计时要同时兼顾合理性与灵活性。合理性指两件事标签生成的合理性以及使用场景的合理性。生成的合理性是说这条标签算得出来、算得准场景的合理性是说这条标签真的有人用。灵活性则体现在基础标签之上业务使用方可以灵活配置规则标签、业务标签、算法标签等。不必在前期就把所有规则定下来可以随着业务推进灵活调整、生成新的标签。这条原则的实际意义是别指望第一版标签体系就是最终版把框架留出扩展位比把内容一次填满重要。设计思路要回答的问题常见错误以数据为基础这条标签算得出来吗先列清单再找数据以业务场景为锚点谁会用、用来做什么动作追求大而全群组与标签分工这次的需求是一次性的还是可复用的把临时名单做成永久标签组织架构与技能谁来定义、谁来实现、谁能改照搬其他公司的目录4. 从0到1的六步流程标签体系是怎么一步步搭起来的设计思路解决“往哪个方向想”流程解决“先做什么后做什么”。整体链路可以概括成一条线数据接入、数据梳理、业务场景和流程梳理、客户生命周期、标签构建、标签管理。这条线不是一次走完就结束而是一个会反复回流的闭环。4.1 数据接入与梳理把散落的原料先归拢第一步是把基本属性、行为事件、业务单据和其他数据接进来。接入之后必须做梳理梳理的内容包括数据域、业务过程、数据表和数据分布目的是搞清楚基于这些数据到底能加工出哪些标签。这一步里最容易被低估的是身份打通。用户可能有好几个标识手机号、设备号、后台账号、订单里的收货人编号。ID优先级怎么定、主体之间怎么转换、ID之间是什么参考关系、多表怎么连接、脏数据怎么过滤、字符串怎么建索引这些问题不解决标签就会落到“半个人”身上——同一个人被算成三个或者三个人被合成一个。One ID 的生成策略要在这里定下来包括实时场景下的 One ID 处理。这件事的性价比极高身份没打通后面所有标签的覆盖率都会莫名其妙地偏低而你会以为是数据量不够。4.2 用5W2H把“这个标签要不要做”问清楚需求进来之后别急着开发先用一套固定的问法把需求拆开。维度要问的问题What这个场景是什么目的是什么Why为什么要构建这个标签Who由谁来构建这个标签更合适Where依靠什么模块完成群组可以吗When什么时候需要上线业务应用时间是什么时候How怎样构建这个标签用什么标签类型How much价值是什么其中“Where”这一问最容易被跳过也最能省钱很多需求用群组就能解决根本不需要走标签建设。而“Who”这一问决定了标签的维护责任业务方定义口径、数据方实现逻辑分工含糊的标签通常活不过三个月。4.3 标签内容与类目设计1-3层、3-30个的经验值需求收集完要做两件事设计标签内容设计标签类目。标签内容包含标签定义、标签类型、标签执行频率。这三项写清楚标签才算能被交接。标签类目方面一般建立1到3层就够层级再深运营点开三层已经不想找了。还有一个很实用的经验值一个子类目下建议不超过30个标签不少于3个标签。超过30个说明这个类目该拆了少于3个说明这个类目本身没有存在意义可以合并到相邻类目里。类目设计的同时要统一口径。像“活跃用户”“忠诚用户”这类词必须在内部达成共识而且要符合业务场景。客户生命周期常常被拿来当类目骨架比如潜在客户、沉睡客户、活跃客户、忠诚客户这一串阶段每个阶段对应一批标签。另外可以用二八法则确定标签体系的对象是围绕消费者建还是围绕商品建还是围绕车辆、内容建。对象选错后面所有标签都要重做。4.4 数据探查与主体规划人只是主体之一类目定完要回到数据侧做探查明确什么样的数据和标签相匹配包括用户基础属性数据、产品使用行为数据、用户业务订单数据以及其他补充数据。同时要处理脏数据过滤、字符串索引、多表连接这些工程细节。然后是最容易被忽略的一步规划主体。主体又称实体或对象通常可以被运营或洞察分析。常见的主体是“人”但多主体能力意味着除了人以外还可以是车、商户等并且支持构建多主体标签完成多主体分析与营销应用。以人和车为例两者的标签体系完全是两套东西主体标签方向具体内容举例人基础信息、触媒信息、留资信息性别、职业、常驻地曝光次数、点击次数金融方案、消费水平车基础信息、成交信息、保养信息车辆型号、车辆色系成交时间、成交地点保养套餐、保养时间当人和车同时成为主体时就出现了人车双中心的标签体系认知阶段看营销偏好和社交轨迹到店和试驾阶段看购车意向和潜客阶段信息订车买车阶段看消费信息交车之后看车辆使用和保养维护信息再往后是换购意向。一条业务链路走下来标签跟着阶段走主体跟着对象走。注意主体规划要在建设初期定下来。中途换主体等于把已建的标签全部重洗一遍代价远高于前期多花两天想清楚。4.5 标签加工与更新离线标签和实时标签怎么选进入加工环节可视化的标签构建方式通常有十余种业务人员可以自己搭建和管理标签体系不必每条都排期等开发。更新频率由三件事决定计算类型是离线还是实时更新类型是定时还是手动执行频率是天级、周级还是月级。离线标签适合口径相对固定、批量计算的场景比如基础信息、触媒信息、留资信息这类。下面是一段典型的离线标签加工逻辑-- 离线标签近30天订单频次分层 SELECT user_id, CASE WHEN order_cnt_30d 10 THEN 高频 -- 10单及以上 WHEN order_cnt_30d BETWEEN 3 AND 9 THEN 中频 WHEN order_cnt_30d BETWEEN 1 AND 2 THEN 低频 ELSE 沉默 -- 近30天无成功订单 END AS order_freq_label, -- 标签值直接给运营看 dt -- 分区日期决定天级更新 FROM dws_user_order_30d WHERE dt ${bizdate};这段逻辑里有三个关键点。CASE 分支对应的是标签值分段区间分段的边界要和业务方一起定不能由开发自己拍。输出用中文字符串而不是数字编码是为了让运营在界面上直接看懂省掉一次查对照表。分区字段 dt 决定了这条标签的更新节奏天级分区就是天级更新改成周级分区就是周级更新。实时标签则适合事件触发型的场景。典型用法有两种一是内容推荐场景制定人工推荐策略对实时变更的不同群体做差异化内容推荐调用平台判断用户是否属于某个实时分群再推荐不同内容二是新用户发券场景实时判断某用户是不是下单新用户满足条件就发对应的折扣券。// 实时判断是否属于下单新用户 function isNewPayer(event, profile) { // 条件一本次事件必须是下单成功事件 if (event.name ! order_paid) return false; // 条件二历史成功订单数为 0即此前从未下过单 return profile.paid_order_count 0; }这里的 event 是实时流入的事件对象name 是事件名profile 是该用户的历史画像paid_order_count 是历史成功订单数。两个条件同时成立才返回真返回真就触发发券。这类逻辑的特点是判断次数多、单次计算量小所以适合放在实时链路上而像“近90天累计消费金额”这种要扫大量历史数据的标签放在实时链路上只会把自己拖垮。4.6 标签价值评估六个指标决定一条标签留不留标签建完不是结束得定期评估。常用的评估维度有六个评估项看什么用来判断覆盖量标签覆盖人数与覆盖率标签的有效使用范围标签值分布各标签值的占比及随时间的变化标签是否失效或倾斜使用热度使用频次统计与相关性能指标标签是否有人用执行失败率任务执行失败的情况标签产出是否可靠关注度近7天、近14天的收藏次数与搜索次数标签是否被需要优化率再次编辑的次数标签是否还在调整这六项里最能直接砍成本的是“使用热度”和“覆盖量”。一条标签如果连续几个月没人搜、没人用覆盖率高也是负担——它每天都在消耗计算资源。而执行失败率高的标签更麻烦它会让人对整个标签体系产生不信任运营一旦发现某条标签不准后面所有标签他都会先怀疑一遍。5. 五个最容易搞混的概念标签、群组、指标到底差在哪概念混淆是标签体系落地时最常见的隐性成本。词用错了会议就会开成辩论赛。下面五个是初学者最容易混的。5.1 标签与群组一个是特征一个是名单易混点两者都能用来“圈人”看上去是一回事。为什么混在界面上标签能圈出人群群组本身也是一群人结果长得一模一样。怎么区分看它是不是可复用的判断。标签描述的是特征比如“活动响应度高”这个特征可以反复用来圈不同时间、不同活动的人群群组是一次性的名单比如“参加过3月那场活动的人”它回答的是“这一次是谁”。而且两者有上下游关系标签一般是分群的上游数据先有标签圈群组时才能直接组合标签不必每次重新理解原始表。5.2 标签与指标一个是形容词一个是数字易混点都从数据里算出来都能放在报表上。为什么混很多标签是从指标分出来的比如先算“近30天订单数”再分段成“高频、中频、低频”前后脚出现容易当成一件事。怎么区分指标回答“多少”标签回答“哪一类”。订单数是指标高频客户是标签。指标是连续的数值标签是离散的分类结果。做报表看趋势用指标做圈选和策略用标签。把指标直接当标签用界面上一列几百个不同数值运营没法拿它做决策。5.3 标签体系与数仓表结构一个面向业务一个面向存储易混点两者都在组织数据都分层。为什么混标签的底层确实存放在数仓里表名和字段名看起来就是标签名。怎么区分数仓表结构服务于“数据怎么存、怎么算”讲究范式、分区、血缘标签体系服务于“特征怎么被找到、被理解、被使用”讲究类目、口径、可读性。前者是后厨的备菜流程后者是菜单。菜单上的“招牌红烧肉”不需要知道后厨用哪个冷柜存放。5.4 离线标签与实时标签不是快慢是场景易混点以为实时标签是离线标签的升级版越快越好。为什么混“实时”这个词自带高级感容易被当成技术先进性指标。怎么区分看决策发生的时点。决策在批量执行前发生用离线标签比如一周一次的人群圈选、一次投放名单生成决策必须在事件发生的瞬间完成用实时标签比如用户刚下单就判断要不要发券。绝大多数标签用离线就够了为了“实时”而实时换来的往往是更高的成本和更难排查的问题。5.5 标签数量与标签质量大而全的陷阱易混点把标签数量当成体系成熟度的指标。为什么混汇报时数字好看几百条标签听起来比几十条更有分量。怎么区分看覆盖率、使用热度、关注度这几项。标签数量只是投入使用才是产出。一个类目下堆到三十条以上先想的是拆类目而不是继续加标签。真正健康的体系是每条标签都能说出谁在用、用来做什么动作。6. 什么时候该建标签体系什么时候先别碰判断标准其实不复杂看两件事这个需求会不会重复出现以及口径会不会被别人引用。如果只是办一场活动、发一次通知、做一次探索性分析用群组就够了。建标签要经过定义、开发、评估一整套流程为一次性需求走这一趟投入产出比很难看。反过来如果同一批口径被不同的人反复问、反复算每次都要重新对齐“活跃”到底指几天那这条标签就该沉淀下来了。你遇到的信号更合适的做法一次活动、一次触达、一次名单用群组别建标签同一个口径被三个以上的人问过沉淀成标签写清定义两个部门报表数字对不上先统一定义再谈技术同一个人被算成好几个先做身份打通标签往后放标签列表几百条但没人搜先做类目和搜索别再加标签业务方自己会配置规则开放可视化构建减少排期有两个场景我建议直接劝退。第一是身份还没打通就急着建标签这时候做出来的标签覆盖率天然偏低你会在数据质量上反复纠缠而问题根本不在标签层。第二是业务方连“拿到这批人之后要做什么动作”都说不清楚这种需求做出来通常只有一次寿命做完就沉底。真正适合启动的时机是业务已经跑通、动作已经明确只是每次都靠人工重复计算。这时候建标签等于把重复劳动一次性固化下来收益立刻可见。说个我自己踩过的坑。早些时候赶一场活动时间紧我直接把临时圈出来的群组升格成了标签口径那一栏随手写了句“近期活跃用户”没写具体天数。三个月后两个部门做复盘一个按7天算、一个按30天算数字差了将近一倍会开了两个小时最后只能回头把历史数据重洗一遍。从那以后我每次建标签都强制走一遍5W2H再把定义、类型、更新频率这三项写全才允许上线哪怕需求再急也不跳过。这套流程听起来慢实际是唯一能省下返工时间的办法。这份资料把从0到1的建设流程、类目设计的经验值、标签评估的六个维度整理成了一套可以对照使用的模板素材需要的时候拿去改改就能用希望帮到你。本文还有配套的精品资源点击获取