58标签体系建设实践

智源社区1年前 (2023)发布智源社区

312 0 0

58标签体系建设实践

导读本篇主要介绍 58 标签体系建设实践，主要包含痛点及标签建设方案、标签体系、标签管理平台三个模块。

今天的介绍会围绕下面四点展开：

1. 痛点及标签建设方案

2. 标签体系

3. 标签管理平台

4. 小结

分享嘉宾｜陈丽媛

编辑整理｜李同学

出品社区｜DataFun

痛点及标签建设方案

我们先思考一个问题，业务在怎样的发展阶段时，需要建设标签体系？

1.怎样的业务发展阶段，需要建设标签体系？

不同规模、不同业务阶段的企业，对数据体系的需求不一样，并不是所有企业都有必要建设标签体系。

业务在起步阶段和初期增长阶段，粗放式的投放也能带来较好的增长和转化，业务的诉求更倾向于有数可看。

在增长转成熟阶段，随着流量红利的消失，增长乏力的情况下，运营人员开始探索以精细化运营的方式来提高 ROI，考虑在合适的时间、给合适的人群、推荐合适的内容，从而提升用户体验并带来转化。数据建设不仅需要满足自助取数分析，也逐渐需要建设一些用户标签表，满足初期精细化运营的需要。

并且随着各业务开始开展精细化运营，标签体系的建设会逐步完善，数据团队也会建设标签平台来提升标签接入的效率和标签质量。

那建设标签过程中，会遇到什么问题？有何解决方案？

2.标签建设过程中的问题及方案

在标签体系建设的不同阶段，会遇到一系列的问题：

起步阶段：数据质量与数据应用矛盾

在标签起步阶段，数据开发同学主要精力在于快速支持运营的标签需求，缺乏标签数据建设规范、应用规范等设计。运营人员在标签应用时，存在标签含义和逻辑不清晰、标签覆盖率不高、部分算法标签的准确率低等问题，导致运营人员不敢用，或是花较多时间去咨询，费时费力。

增长阶段：标签权限管控与灵活便捷的矛盾

而随着各业务线都在提标签需求，标签使用者越来越多，标签的应用出口也随之增多。对业务人员而言，标签属于业务资产，在运营过程中，需控制触达用户的频次和方式，过多或是不当触达本业务用户会损害用户体验，给业务线带来损失。例如58车的业务希望做流量增长，希望交叉招聘用户做营销活动，如圈选招聘7日活跃用户，每天持续触达车的落地页；这样势必会引起招聘业务运营的反对，车业务每天触达招聘的用户，影响用户体验。

因而需要划分不同业务标签的归属，以及标签权限审批。但增加权限审批又会带来新的问题，增加了审批后，每次运营想要使用标签，都得找业务负责人审批，有时还需拉群沟通来申请权限，标签使用效率、便捷度大大降低。

成熟阶段：标签价值与成本的矛盾

数据平台上的标签越来越多，开发上线了几千个标签，占用了较多服务器存储与计算资源，但平台上真正在投入使用的标签只有几百个。如何合理的评估标签的价值？如何提升高价值标签的使用率，下线低价值标签？

因而标签建设需要构建结构化、场景化、系统化的解决方案。

3.标签体系建设方案

58 大数据平台支撑了租房、新房、招聘、新车、到家等十几条业务线数据，数据覆盖了 58 APP、安居客 APP、小程序等多个终端，业务线较多，对接流程较为复杂。因而 58 在建设标签体系时，采用组织协同+平台建设+运营的方法。

组织协同层，大数据团队主要负责跟各业务线需求的对接、通用标签开发、标签平台能力的建设等；业务数据团队负责自助接入业务标签；运营团队负责提出需求以及标签权限审批。

平台建设层，主要建设标签管理与分析平台，包含 ID 建模、标签建模、数仓规范、元数据管理、权限管理、标签评估、标签推荐等能力。

在运营层，目前是由大数据团队统一梳理各业务线的标签应用情况，形成精细化运营应用案例集，供各业务线参考学习。

这里需要注意的是，在不同阶段，大数据建设标签体系的侧重点有所不同。

在起步阶段和增长阶段主要目标是提效，需要不断提升标签质量，保障标签的可用性；建设合理的标签权限管控、标签推荐能力，提升标签使用的易用性。

在成熟阶段主要目标是保障标签应用价值增长的同时，进行成本管控，做好标签全生命周期管理，评估标签价值，及时下线无用标签，释放服务器存储与计算资源。

4.标签建设架构

在数据采集层，接入埋点数据、业务系统的表数据、日志数据，以及第三方数据，如个推数据，跨越多个端、各个业务线，打破数据孤岛。

在数据存储与计算层，建设数仓建模、用户/客户/企业 ID 体系建模、标签体系建模规范，并支持数据的离线和实时同步。

在标签平台层，建设标签全生命周期管理，包含标签的接入生产、标签挖掘、元数据管理、标签下线、权限审批；以及标签评估分析能力，包含标签评分、标签推荐等能力。

这里需要注意的是：

尽可能全的采集数据，对用户画像的刻画，十分依赖标签数据的覆盖率，若是都采不到数据，何谈刻画画像？这也就比较依赖企业前期数仓的建设，需要规范 ods、dwd、dws、ads 层的建设，将各个业务线的数据归拢至数据中台，尽可能全的利用好企业内部的数据；若是企业内部的数据不足的情况下，可考虑购买第三方数据，进一步提升标签覆盖率。
采集数据会涉及多端，如 app、pc、小程序，以及涉及多业务，如房产、招聘等，要想尽可能的关联多方数据，需进行ID体系的打通，包含userid（账号）、telep（手机号）、imei（原生 Android 标识）、idfa（原生苹果标识）、oaid（匿名设备标识）、openid（微信小程序标识）等

标签体系

1.标签建设痛点及方案

标签数据越建越多，运营人员在使用时，会存在以下问题：

标签分类不清晰，找不到对应标签。例如房产、招聘等十几个业务线的标签混在一起，用户、客户企业的标签也混在一起，难以查找。

标签建设时凭感觉，较多标签无实际使用场景，上线后无人用。例如建设“房产–浏览商圈个数”标签，最开始产品侧认为在做精细运营时，可以圈选浏览商圈较多的用户群，对其做触达转化。但后续发现，在实际运营过程中，到不了这么细的场景，这类标签从上线以来就无人使用。

58 的标签体系建设，以结构化、场景化的方式建设，保障标签建设的可拓展性、业务使用的易用性，以及应用价值。

2.标签结构化

标签结构化建设，按实体对象划分，划分为用户、客户、企业、帖子等实体对象。若是电商类业务，较常划分的是买家、卖家、商品；外卖业务，常划分为用户、商户、骑手等。

按业务划分可划分为1+N的模式，即1个通用中台+N个业务的方式，例如划分为通用、房产、招聘、车、本地服务等。将用户的基础信息类划分在通用中，例如性别、年龄、预测倾向访问业务等，打通各个业务的数据源，提升标签的覆盖率和准确率；将业务线特有的数据归拢至各个业务，例如新房活跃用户、招聘活跃用户、二手车连接用户等，方便业务运营人员使用，以及方便后续做权限管控。

按标签类型，以用户标签为例，可划分为基础信息、行为偏好、个性化标签大类。基础信息标签，用于描述用户的基础属性，包含自然属性、社会属性、地理位置、设备信息等，例如常驻城市、设备型号、学历。

行为偏好类标签，主要通过洞察用户最近一段时间内的各类行为，如访问、收藏、电话、IM、付费等，进一步提炼出用户的需求。包含活跃行为、连接偏好、付费交易、用户分层等大类，例如用户的访问活跃度、买房意向用户、价格偏好等。

行为类标签在划分时，常见的问题是业务侧穷举用户行为路径上的埋点行为数据，都将其做成标签，例如浏览次数、浏览房源个数、收藏次数、IM次数、电话次数等，业务建设的出发点是好的，但业务运营实际使用时会遇到不知道怎么组合用、不知道用哪个标签的问题。

因而，在搭建好标签结构，保障标签结构上的可拓展性、分类清晰后，在开发具体标签时，需结合业务使用场景，以场景化的方式来建设。

3.标签场景化

场景化标签建设，主要是指从标签的实际使用场景切入，拆分相关运营模型，从运营策略来倒推需要建设哪些标签数据。

日常运营常用的业务分析模型有 OSM 模型、AARRR 模型、用户行为路径、用户分层、RFM模型等。

OSM 模型：即目标、策略、度量，例如在促付费的目标下，运营人员通过制定给潜在用户发送优惠券的方式，提升付费用户数。

AARRR：即获客、激活、留存、付费、推荐，不同的阶段对应有不一样的运营策略，对于成熟期的企业而言，各业务的运营重点更偏重于留存。

用户行为路径：是一种常用的用户分析方法，数据产品在梳理埋点、指标体系的时候会经常用到，当然标签体系的梳理也可采用该方法。不过注意点是统计用户访问APP、访问详情页、点击详情页、IM /电话点击、购买操作行为数据时，需结合运营目标（O）及策略（S），将其开发为标签（M)。

用户分层：很大程度上是AARRR与用户行为路径的结合体，划分为潜在用户、活跃用户、连接用户、付费用户。

RFM 模型：这是交易类业务下常用的客户模型，以最近消费时间、消费频次、消费金额3个指标，划分重要价值客户、一般价值客户、重要发展客户、一般发展客户、重要保持客户、一般保持客户、重要挽留客户、一般挽留客户 8 类群体。此处不做展开，详情可查看草帽小子之前写的《标签体系》。

在标签体系构建过程中，OSM 模型是基础，贯穿了构建标签的各个阶段，较为通用的 AARRR 模型、用户行为路径分析、用户分层模型；特定业务模式下常用的是 RFM 模型。

具体这些业务模型如何应用？我们先来看看实例。

4.场景化标签设计案例

业务背景：租房省心租是面向个人房东群体推出的VIP会员服务，租房运营人员希望促进个人房东购买省心租套餐，提升付费客户数。

整体目标是提升付费客户数，拆分至拉新、促转、留存/复购的子目标。

在拉新阶段需要扩曝光和提服务，运营策略，在租房首页活动位/首页加悬浮窗资源位，增加个性化租房首页活动位，针对“有出租需求的个人房东”展示省心租活动、曝光更多房东；同时进行push/短信推送，面向“房源上架 1、3、7、14 天但未出租成功的的个人房东”，推送消息

产品服务策略，增加房东推荐租客页面，提供“高意向租客、本房源浏览用户特征的价格偏好、户型偏好”等信息，并上线个人用户画像服务，包含个人意向价格、意向户型、7 日活跃、连接次数、租房目的等数据，帮助房东全方位了解租客。

促转化阶段，梳理省心租页面转化路径，包含曝光、服务浏览、提交订单、购买等；

在留存阶段，需促进客户升级套餐，针对购买基础版套餐用户群，推送高级套餐介绍/优势；促进客户续费、复购，服务期内提感知，机制推推送“新增推荐的租客”，提升房东对省心租服务的感知度；服务即将到期客户促续费；服务已到期客户召回。

整体策略构建、标签构建，以 OSM 模型为框架，划分 AARRR 模型中的拉新、促转、留存场景，结合用户行为路径分析方法，进一步得到所需构建的用户、客户、房源标签。

结构化设计标签，逻辑结构清晰，可拓展性强，但容易与业务脱节，不贴合业务实际使用场景；而场景化设计标签，贴合业务使用场景，使用率高，但比较零散，容易乱，因而需要采用“结构化+场景化”的设计方法。

5.58标签体系

58标签体系，依照结构化和场景化的建设原则，面向房产、招聘、车等各个业务，构建用户标签、客户标签、企业标签体系，建设了性别、职业、居住城市、浏览行为、价格偏好等上千个标签。

从标签结构上也可以看出，不同实体对象标签数量不同，例如企业标签应用场景较少，所需建设的数量也比较少，用户标签一般建设的比较多，其匹配的用户运营团队人员多、对应的运营活动也比较多。

梳理完用哪些标签后，接下来的建设重点就是标签开发。

6.标签开发类型

标签开发类型，一般是数据产品和开发人员关注的模块。标签按统计方式分，可分为事实标签、规则标签、算法标签；按更新频率来划分，可分为离线标签、实时标签；按数据类型分类，可分为数值、字符串、字符串数组等；按维度分类，可分为单维标签、多维标签。

事实类标签是用户画像最基础、最常见的标签，通常是基于原始数据清理后的归类，用于描述客观事实。例如，姓名、会员等级、终端类型、购买次数、购买金额等。

规则类标签，顾名思义，是基于确定的规则而产生。与事实类标签不同的是，规则类标签拥有更多的业务属性，其业务规则需与业务人员共同制定。例如，将“活跃用户”标签可定义为，“过去 30 天发生 a 行为 x 次”&“过去 30 天发生 b 行为 x 次”，进行综合评定。

算法类标签，基于现有事实及规则无法得出，导致标签的覆盖率低，业务使用价值就大大降低，这时需要运用决算法进行数据挖掘与训练，得出标签预测结果。

7.性别标签

例如性别标签，需要综合使用 58 底层的多个数据源，优先取身份认证数据，其次取用户填写的一些数据。

以上强认证的数据均没有的情况下，判断有 APP 列表的用户，基于相关特征，通过LR算法做分类预测。选取如用户 5 年内最新安装的 APP 列表、表现类二级偏好、手机型号、操作系统等特征，进行模型训练。预测的准确率达 86.94%，性别标签的覆盖率从 20%，提升至 74%。

但随着个保法的颁布，获取 APP 列表的数据逐渐下降，为进一步提升标签覆盖率，针对无法获取 APP 列表的用户性别预测，根据用户访问行为，针对 90 天内看帖量>= 5的人群，采用 LR 算法进行预测，特征使用用户看帖帖子内容，帖子标题，帖子一级表现类，帖子二级表现类。用帖子数据预测的准确率为 73.7%，标签覆盖率补充提升 5%。