做电商平台的数据工作早晚都会被问到一个问题平台上那些高价值用户到底有多少能不能把他们都圈出来做个专属活动如果你翻了半天报表最后只能给出一句大概两三万吧那基本就说明标签体系这块是欠账的。这些年我陆陆续续参与过几套用户画像标签体系的建设从最开始拿Excel人工打标到后来上数仓、接算法模型折腾了不少弯路。这篇文章想把电商平台用户画像标签体系怎么搭这件事掰开揉碎讲清楚重点放在标签维度的拆分逻辑和落地实操上。适合数据产品经理、数据分析师、数据开发工程师以及所有需要把用户洞察变成可执行人群的同学参考。我默认你要是已经有一定数据基础但即使你对数仓不太熟只要把维度拆分的思路吃透也能在实际项目里少踩很多坑。下面我按从原则到执行的顺序来讲。1. 标签体系到底是干嘛的——先搞清楚它解决什么问题1.1 标签的本质是一台业务翻译器很多人一上来就急着列标签高活跃用户、高消费用户、喜欢运动品类……但真要问一句这些标签怎么算出来的凭什么这么算就答不上来了。标签体系的本质是把底层的用户行为数据翻译成业务方能直接理解、直接使用的人话。举个例子底层表里存的是user_id、order_id、pay_time、amount这类字段业务方看不懂也不关心。他们关心的是最近30天买过3次以上、客单价500元以上的人。标签就是在这两者之间搭一座桥把原始数据和业务语义绑在一起形成标准化的、可复用的已定义概念。这个翻译器做得成功与否通常看三件事第一口径是否统一同一个高价值用户在运营眼里和财务眼里必须是一个意思第二粒度是否清晰标签是打在用户身上还是打在订单上得先定死第三更新策略是否明确T1更新还是实时更新直接影响标签的使用场景。1.2 从看报表到直接圈人的关键一步没有标签体系之前业务想要一群人做活动流程大概是先提需求然后数据同学写SQL跑数导Excel再用Excel里的手机号去发短信。这个过程听起来没毛病但实际上每次都要来回对口径跑完数还得人工检查一遍有没有明显异常时间全耗在沟通上。有了标签体系之后运营在画像分析子系统里自己选条件——比如近30天有购买行为、客单价大于300、非高退款用户——点一下人群就出来了直接对接推送短信、弹窗、优惠券接口。这个环节的转变是整个数据驱动运营的基石。我印象很深的是第一次把标签体系交付给运营团队用的时候他们的第一反应是原来用户是能被条件筛出来的不是每次都得求你们写SQL。从这一刻起数据才真正从报表里走了出来变成了运营手里的武器。跟看报表相比标签体系解决的不仅是效率问题还有一个更重要的价值可沉淀、可组合、可复用。报表看完了就完了但标签会一直躺在那里今天用高活跃高消费圈一批人明天还能拿高活跃喜欢母婴再圈一批人。这才是标签体系比临时跑数高级的地方。2. 打地基标签的分层结构与数据底座怎么设计2.1 事实标签、规则标签、算法标签三层分工标签体系在工程落地时业内基本形成了一套共识标签要分三层——事实标签、规则标签、算法标签。我这几年在几个项目里都沿用了这个框架稳定性很好。标签层级计算方式典型例子更新时效事实标签直接来源于事实数据几乎不做加工性别、注册时间、最近一次下单时间实时或T1规则标签由业务规则定义多条件组合后计算高消费用户近90天消费金额前20%、流失预警用户30天未访问T1或小时级算法标签借助机器学习模型预测或聚类产生用户偏好预测、购买意愿评分、潜在高价值用户T1或周级事实标签好理解它就是数据是什么就存什么规则标签是目前应用最广的一层因为业务方可以通过配置规则自己定义人群灵活性最强算法标签是进阶玩法尤其在用户意图预测、商品偏好挖掘上能发现很多规则看不出来的用户。很多团队一上来就冲算法标签我觉得是顺序搞反了。规则标签没跑稳之前上算法你会发现模型训练完业务方根本不知道怎么用、怎么解释。先把规则标签做到覆盖率95%以上再逐步引入算法标签才是稳妥的路径。2.2 ID打通标签体系的任督二脉做标签体系最痛苦的事不是标签少而是同一个用户有多个ID未登录时的device_id、登录后的user_id、微信生态的union_id、订单里的手机号。如果这些ID打不通你会发现同一个用户身上会挂两套甚至三套互相矛盾的标签。ID映射这块我的建议是先做一个统一的ID-Mapping表把device_id、user_id、手机号、union_id都归一到一个主键上。主键的选择很关键业内常用user_id做核心但前提是你App内用户登录率要高如果登录率低就得考虑用设备ID做兜底主键灰度用户单独处理。一个实操中的细节ID映射不是一次性做完就完事的它是个持续更新的过程。用户卸载重装App之后device_id会变换手机号登录后关联也会断这些都需要每天跑批去修正映射关系。我见过有的团队ID打通率只有70%导致标签覆盖率上不去人群圈出来老是比预估少一截最后排查发现就是ID映射滞后。2.3 存储选型Hive打底、ClickHouse加速标签体系的数据量一般不会小——几千万用户几千个标签明细得存、结果也得存查询还要快。常规组合是数据仓库用Hive做离线计算产出标签结果后导入ClickHouse或Doris做交互式查询画像分析子系统直接查ClickHouse秒级返回。有人会问为什么不用RedisRedis适合做实时标签查询但像圈选500万用户这种批量分析场景Redis的key-value结构反而不合适。ClickHouse的列式存储和向量化计算特别适合这种对全量用户按几十个标签条件做过滤的场景。存储架构上我建议分三层明细层ODS和DWD保留用户行为明细不加工。汇总层DWS按用户维度做轻度汇总比如近30天订单数。标签层DIM单独一个库放打好的标签一张宽表一行一个用户。这个分层的好处是某一层出了问题可以单独回溯不会影响上游或下游。3. 电商标签维度怎么拆——一张表讲透八大维度3.1 通用维度盘点从基础属性到生命周期状态标签维度的拆分是建立标签体系最核心的环节。拆多了维护成本高运营也用不过来拆少了圈人筛条件的时候发现缺这缺那又得回头补。结合电商行业的常见需求我习惯把标签拆成八个维度来看。维度解决什么问题标签示例典型应用场景基础属性我是谁性别、年龄段、城市等级、会员等级新客欢迎语、地域性活动消费能力花得起多少钱近90天消费金额分档、客单价分档高价值用户定向回馈消费行为怎么花钱近30天购买频次、最近一次购买时间流失召回、复购刺激商品偏好喜欢买什么偏好类目TOP1、价格带偏好商品推荐、品类活动渠道行为从哪来、在哪个端活跃注册渠道、活跃设备平台、主力访问时段端内投放策略、Push策略内容互动跟平台互动有多深近7天浏览时长、收藏加购次数、评价频次内容场种草、直播预告生命周期现在处于哪个阶段新客、成长期、成熟期、衰退期、流失期分阶段运营策略营销敏感度怎么薅才有效优惠券核销率、价格敏感度优惠券门槛设计、活动强度控制每个维度下面的具体标签数量我建议控制在5到20个之间。太少不够用太多运营容易看花眼。实际操作里一般一个中型电商平台整套体系加到300个标签左右就够用了那种动辄上千个标签的多半是重复定义太多。3.2 生命周期标签最容易被忽视却又最该优先建设我想专门把生命周期维度拎出来说因为这是我见过被建设得最少、但又最重要的板块。原因很简单同样一个高消费用户刚注册一周的高消费和注册三年后的高消费运营手段完全不同——前者要重点维护防流失后者要推新品拉复购。生命周期状态的划分基本公式是最近一次行为时间 历史行为频次 注册时长。举个例子一个用户注册60天最近一次下单在7天内累计下单5次那基本可以划到成长期。如果一个用户注册200天最近一次访问已经超过45天那就要进流失预警了。这个维度的价值在于它天然就是一个分层工具。把用户按生命周期切好之后后续所有运营动作都有了时间轴上的锚点新客阶段推首单优惠成长期推品类拓展成熟期推会员升级衰退期推优惠券召回。做标签维度拆分的时候我强烈建议先把这个维度定下来它能让其他所有标签都活起来。3.3 消费行为维度RFM模型的标签化落地RFM模型Recency、Frequency、Monetary在电商圈几乎人人都知道但真正把它做成标签的却不多。原因在于很多人把RFM只是当做一个分层模型在用而没有把它拆成可组合的标签。实操里我习惯把RFM拆成三个独立的标签组R标签最近一次购买距今X天切成0-7天、8-30天、31-60天、60天以上几个档。F标签近90天购买次数切成1次、2-3次、4-6次、7次以上。M标签近90天消费金额按分位数切成低、中、高三档。拆开之后运营可以直接用R0到7天 F4到6次 M中这种组合圈人比直接用一个重要价值用户标签灵活太多。RFM三个维度拆开还有一个好处当你发现最近购买时间超过60天但历史消费金额很高的用户时你会意识到这里存在一个潜在召回机会而不是把这个用户简单地归为流失人群。这个思路也代表了标签体系设计的一个通用原则标签维度要拆到不能再拆的最小业务可理解单元让运营可以自由组合而不是替运营把结论定死。4. 从标签到人群画像分析子系统怎么落地4.1 标签组合圈选不止是简单的AND画像分析子系统的核心功能就是让运营通过勾选标签条件来创建人群。听起来简单实际上这里有几个不那么明显的问题。第一个问题是标签之间的运算是AND还是OR。比如圈高消费用户且近7天活跃这两个条件用AND没问题但如果是高消费用户且喜欢运动类目或喜欢数码类目就要支持括号和嵌套逻辑否则条件根本表达不出来。所以在设计圈选引擎时表达式要支持类似(A AND B) OR (C AND D)的解析底层语法树解析就得提前做好别等到运营来提需求才改。第二个问题是时间口径。同一个标签运营在4月1日圈近30天购买用户和在5月1日圈同样条件是同一批人吗大概率不是。所以人群创建时必须记录标签的取值版本和计算日期否则你连这批人是哪天圈出来的都说不清后续做活动效果回收都没法分析。第三个问题是人群快照。运营圈完人群之后这批人的名单要快照保存不能等到发推送的时候再实时跑一遍——因为用户行为是变的等你点击发送的时候人群已经跟当初圈的不一样了。这个细节看起来小但我在实际项目中遇到过不止一次圈了100万人发的时候只剩80万的尴尬。4.2 人群洞察用TGI看透人群特征只有圈人功能还不够运营圈完一群人之后通常会问一个问题这群人到底有什么特点这就是人群洞察要做的事。实操中常用的指标是TGITarget Group Index它衡量的是目标人群在某个特征上的倾向性计算公式很简单目标人群中具有某特征的占比 / 全量人群中具有某特征的占比 × 100。TGI大于100说明该特征在目标人群中更显著小于100说明不显著。举例全平台喜欢宠物类目的用户占20%而你圈出的高消费用户里有35%的人喜欢宠物类目TGI就是175。那这个信息就非常有用——你圈的高消费用户很可能是养宠人群后续做营销时可以优先考虑宠物周边的权益。画像分析子系统里可以把这个逻辑做成自动化的选一个人群系统自动计算该人群在所有标签上的TGI按降序输出TOP20显著特征。这个功能一上线运营对人群的理解会立刻上升一个层级甚至能发现很多你设标签时都没预料到的相关性。4.3 人群应用与效果回收打通触达链路标签体系建得再好如果人群导出之后还是要人工下载手机号、再去另一个系统上传那效率就打了个对折。成熟的做法是画像分析子系统直接对接触达渠道短信平台、Push推送、站内信、优惠券系统、广告投放DMP全部通过API接口推送人群包。我建议分两步走第一步先做人群一键导出先把人工成本降下来第二步再做人群API推送实现系统间自动对接。这里想提醒一句对接时一定要注意人群包的幂等性——同一个人群重复推送两次不能产生双倍触达。实现方式是在人群包层面加批次号所有下游渠道都按批次号做去重。效果回收是闭环的最后一环。每次活动的人群包、触达记录、后续转化行为都要回流到数据仓库最后产出活动效果报表触达了多少人、产生了多少订单、ROI是多少。这个过程看起来不起眼但它决定了标签体系能不能持续优化——哪个标签组合效果好哪个组合效果差全靠回收数据来验证。5. 标签生命周期管理权重、时效与冲突处理5.1 标签权重与优先级同一用户多个取值怎么办标签设计时有一个默认假设一个用户在一个标签上只有一个取值。但现实并不是这样。比如年龄这个标签用户注册时填的年龄和身份证校验出来的年龄不一致消费水平标签用户近30天低消费但近90天高消费算哪个这就涉及标签权重问题了。实操中两种处理方式一种是设置数据源优先级比如身份证校验的年龄 用户自填年龄 机器推算年龄按优先级取最高值另一种是时间衰减权重比如消费水平标签近30天的行为权重高于近90天这样能捕捉用户最近的变化。我比较推荐第二种思路尤其在行为类标签上。用最近的数据来表达最近的用户这个原则做标签体系时尤其重要。电商用户的消费习惯变化太快一个过去半年都在买母婴用品的用户最近可能已经转向了3C数码如果只按历史累计数据打标你就会一直把他当母婴人群运营转化率自然上不去。5.2 标签时效性不是所有标签都该每天更新标签更新频率要按用途区分这个很多人没想清楚。我把标签分成三类静态标签、准实时标签、实时标签。静态标签比如性别、注册渠道基本不变周级更新就够了。准实时标签比如近7天活跃近30天消费金额业务上允许T1延迟每天凌晨跑批更新。实时标签比如当前正在浏览的商品购物车内商品数这些都是为了实时推荐和实时营销服务的要分钟级或秒级更新。判断一个标签该用什么时效就一个原则业务决策的时效要求决定数据更新时效。运营做的是月度活动那你给他一个分钟级更新的标签不仅浪费计算资源还容易因为实时数据抖动引发误判。我见过有团队把所有标签都做成实时更新的最后ClickHouse集群被压垮了还查不出哪个标签在真正产生价值。5.3 标签冲突与下线机制标签体系建设超过半年之后你会发现标签数量增长很快随之而来的就是标签冲突。典型场景是运营A定义高活跃用户是近7天登录4次以上运营B定义的是近30天购买2次以上。两个标签同时存在名字还都差不多圈出来的人却完全不一样这就是冲突。解法是建立标签元数据中心每个标签都登记唯一的名称、业务定义、计算公式、口径负责人。在标签上线之前先做查重——如果新标签和已有标签的业务口径相似度超过一定阈值要求创建人确认是不是重复建设。这里需要说明一下查重不能通过标签名字做一定要通过口径描述做语义相似度对比否则名字不同但口径相同的标签还是会被创建出来。标签下线也一样重要。一个标签超过90天没有被任何人群圈选引用就自动进入下架提醒流程由负责人确认是归档还是删除。这样做一方面控制了标签总量另一方面也让标签库保持可读性——运营在圈人时面对300个标签和面对2000个标签选条件的效率完全不一样。6. 我踩过的几个坑每一个都是真金白银换来的6.1 埋点脏数据标签里的垃圾进、垃圾出第一次做用户活跃标签的时候上线之后发现数据异常得离谱某天活跃用户量突然暴涨30%。查了半天原因是App在一次版本升级后每次冷启动都会重复触发页面浏览埋点导致浏览UV虚高。这个坑几乎是所有标签体系建设者的必经之路。我的建议是标签开发之前先花两周时间做数据质量稽核。抽样100个用户手动核对他们的标签取值和原始行为日记是否一致。重点检查三个地方事件是否去重、渠道来源是否归一化、金额是否包含退款订单。这几项要是没理清楚后面建的所有标签都有可能偏而且偏了你根本不知道偏在哪。6.2 退款用户没排除高消费标签直接失真有个教训让我印象特别深。我们当时建高消费用户标签简单用近90天支付金额来定义。结果活动做完一复盘发现圈出来的人群里有不少用户的售后率特别高甚至有人是专门下单后退款、套取优惠券的羊毛党。后来花了很大力气把退款剔除出消费金额标签并单独建了高退款用户标签。这里想提醒一句消费类标签的计算支付金额和实付金额不一定都要用最好是支付金额做总量口径、实付金额做净值口径、退款金额做风险口径三个标签不要混在一起。这能同时满足经营分析和风险防范两个方向的需求。6.3 圈人SQL没去重一次活动触达量翻倍这件事说来惭愧但也挺典型。有一次做短信触达运营从画像系统里导了一批人群包然后又从另一个报表里导了一份近30天购买用户名单两拨人在执行时合并发给了短信服务商。结果两批名单里大量重复短信服务商按条数收费预算直接翻了一倍。根本原因在于标签圈选和报表导出两条链路没统一收口用户ID在存储时有的加密了、有的没加密导致对账对不上。解法是所有人群包统一走画像分析子系统一个出口并且对用户ID做统一的MD5映射任何下游系统接收到人群包时必须按主键去重。这个概念很简单但很多人不到账单翻倍的时候都意识不到要去落实。6.4 标签覆盖率低冷启动人群圈不出来新平台、新品类的冷启动阶段标签覆盖率低是常态。用户刚注册没有历史行为数据消费能力标签、偏好标签全是空的圈人时一筛就是一大片人被过滤掉剩下的人不够发一次活动。这种场景下的兜底方案是用替代标签做冷启动。比如用户没有购买行为那就用近7天浏览行为来近似画像用户没有商品类目偏好那就用所浏览商品所属类目来做偏好推断。数据时间窗口扩宽一点也能提升覆盖率比如从近30天扩到近90天虽然精准度会有所下降但至少能把人圈出来。另外一个更业务向的做法是在注册环节就埋好标签采集点引导用户填写生日、选择偏好类目、扫码绑定渠道。这些第一方数据在后续所有标签计算中都是非常宝贵的基础信息。结尾配置建议如果你正准备从零搭建一套电商平台的用户画像标签体系我的建议是先不要急着开发标签管理后台、画像分析子系统这些大件。第一步拉上运营、客服、商品团队开一次口径对齐会把高价值高活跃流失这些词在一个Excel里定义清楚。这份Excel就是标签体系最早的原型。第二步挑一个核心场景——比如30天未购买用户的召回——用SQL手工跑通一版把数据链路和口径验证一遍。第三步再把流程产品化。按这个顺序每一步都有明确产出不会陷在建设了大半年、业务方还没用上的困境里。标签体系的建设不是一个上线即结束的项目它在运营过程中会持续长出新的标签也会有旧的标签不断退役。让业务方真正用它然后根据使用反馈持续迭代这才是标签体系活着的状态。