在企业的许多业务上，标签都有着广泛的应用，那么，怎么做好标签体系的设计搭建？这篇文章里，作者复盘了公司标签体系应用中常出现的问题与原因，并梳理了标签体系设计搭建的相关内容，一起来看一下。
我们通常说打标签的时候，多少带有一点贬义的色彩。打标签一般与刻板印象相连，仅凭某些行为/动作/状态对人或事物下判断，给人或事物增加了某种属性。
在大数据的世界中，标签应用非常广泛。标签是用户画像的基础，可以通过标签刻画用户特征。可以通过标签进行客户分群，实现精准化营销和个性化投放。
按用途分类，一般常见的分类是基础信息标签、用户行为标签、业务偏好标签。
按时效分类，分为T+1标签和准实时标签。
按主体分类，标签主体可以是人（用户），也可以是企业（客户）或其他主体，需要看不同公司的业务情况而定。
这里涉及到打标主体ID的识别，人和企业可能有多种ID，比如同样是个体用户，ID类型有phone手机号、openid、unionid、设备号、公司业务ID等。同样是企业客户，ID类型有统一社会信用代码、企业名称、纳税号、公司业务ID等。
在某些场景下，数据情况仅支持某一类型的ID打标，但使用场景可能会用到其他类型的ID。是否可以把不同类型的ID打通，实现全维度的打标？这就会用到ID-Mapping技术，有些公司也称为One Entity。
标签在公司业务上有着非常广泛的应用。
在聊标签体系设计搭建之前，我们先复盘看看公司标签体系应用中常出现的一些问题和原因，思考下在后续标签体系设计的过程中可以怎么避免。
a.标签元数据维护不够细致，业务通过标签元数据文档查找可用标签时，无法确定是否满足使用场景。【标签是什么、怎么用】
原因是标签元数据维护颗粒度较粗，即使标签命名相同，不同业务对标签口径的理解也可能不一样，此时如果业务口径只有简单一两句话，业务无法判断此标签是否能用于其业务场景。没有技术口径，需要开发查看代码确定业务的问题。这里的沟通成本很高，需要花费很多时间进行标签逻辑的回看和确认。
在标签体系设计过程中，元数据维护上应该有详细的业务口径和技术口径，且统一标签的命名规范。
b.标签分类复杂且有近义，业务无法通过标签目录找到想用的标签/找不到已存在的可用标签，重复提已有标签的加工需求。【标签在哪里】
原因一是标签目录设计没做好，在标签体系设计之初，就应该规划好标签的分级分类。二是在标签需求实现过程中复核缺位，导致近义分类膨胀。
在标签体系设计过程中，应该提供标签目录树的功能，能查看目前标签的分级分类并进行调整。由于标签投产后，元数据也会被下游业务系统应用。调整标签元数据需要考虑对下游的影响，标签和分类需要解耦，标签分类的调整不能影响标签的正常使用。
另外是标签管理办法的细化和标签管理员的职责。建设标签全生命周期管理体系，按照需求评审——开发投产——标签核验——生产启用——变更——下线的不同阶段进行管理，在评审和核验阶段需要进行标签需求方和管理员进行复核。定期review最新的标签分类并进行梳理，对相近分类进行合并调整。
c.标签加工后客群试算数量和业务手工跑的/预期不一致。【标签数据不对】
原因是标签数据质量问题，在标签投产后没有进行核验。需要查看标签加工取数表的数据是否出现异常，比如没有正常推送。需要复核标签技术口径是否和需求业务口径一致。
d.标签投产后业务没有使用过，很多僵尸标签。【标签没人用】
需要进行标签生命周期管理，一定时间段内没有业务使用过的标签，进行标签下线处理，减少计算和存储资源的浪费。
除了以上列的常见问题，还有一些其他的情况。下面标签体系设计搭建，尝试回答上面的常见问题。
这里把标签体系设计分为：数据源层、元数据层、标签加工层、标签服务层、标签全生命周期管理。
标签加工的数据源包括业务数据、埋点数据、日志数据和第三方数据。
元数据是对标签信息的刻画，是对标签对象的属性描述，对业务是否能理解标签口径、正确使用和发挥标签商业价值，具有重要作用。业务在提标签需求的时候，最重要的就是明确标签的元数据信息，这也是开发加工标签的基础。
标签元数据需要涵盖的字段包括：
开发按照业务需求上的标签元数据信息进行标签的加工处理。完成标签加工作业后，会落到中间结果表，通过id-mapping进行融合，最终落到标签结果查询表中。
这里回到前文第一点标签是什么，我们提到不同打标主体有不同的ID类型。用户的ID类型就有phone手机号、openid、unionid、公司业务ID、设备号（设备号又分为IDFA、IMEI）等。企业（客户）的ID类型有统一社会信用代码、企业名称、纳税号、公司业务ID等。
不同类型主体ID的数据如果无法识别为同一个对象/主体，就无法把不同ID的数据进行打通。如果没有一个统一的ID进行关联，不同类型孤立的ID之间的数据无法打通。需要建立一个公司内部的全局id。
以企业标签举例，标签需求中取数源表是企业名称，但打标主体需要为统一社会信用代码，这时候需要通过id-mapping的技术把同一主体下的不同id进行串联。需要一个公司内部的全局id，将完成业务认证的不同类型的id数据源进行收拢。
如通过不同的号码底表获取了全局id A 对应的phone数据，通过企业微信的底表获取了全局id A对应的unionid数据，此时就可以通过全局id 进行关联，触达客户A的方式有识别到的手机号和微信客户信息，对于同一个客户不同渠道的精准触达很有帮助。获得客户一个渠道的ID，可以识别出其他渠道的ID进行触客。
这里特别提一下设备号，设备号指的是智能设备如手机、平板电脑等的唯一标识符。一般广告精准投放用的就是设备号包。一个客户可能拥有多台手机或者平板电脑，现在市面上没有厂商会提供手机号和设备号之间的精准匹配，只会通过包对包的服务提供。也要关注设备号过期的问题，按照现在用户手机和平板替换的速度，考虑以半年/年的频率更新设备号信息的获取。
这里回到前文第二点标签用途，我们了解标签有客户画像、客群管理、客群试算等不同的使用场景，在金融、零售等不同行业都有非常广泛的应用。标签需要配合服务组件才能大规模应用在业务场景中，通过标准的服务提供，降低重复开发的成本，最大程度复用现有组件，更好地发挥数据价值和保障服务稳定。
1）用户画像
用户画像是用户标签的聚合，单个标签反映的是用户部分的信息，多个标签反映用户整体全貌。用途是支持业务和运营人员进行用户分析、价值判断、策略制定。画像服务可以支持下游业务应用系统送入单个/批量的客户主体ID和需要查询的标签ID，返回对应客户的具体画像信息。
2）客群管理
一群客户ID称为客群。客群可以通过单个标签或者多个标签组合筛选得出。常与用户画像结合，用途是根据业务需求，筛选出满足业务条件的客户，用于广告投放精准营销、个性化推荐、线上运营等场景。
在通过标签筛选客群的服务上，需要考虑是否支持不同主体类型标签的交并，是否支持不同时效标签的交并。如需支持业务在筛选客群后计算客群数量，需要支持客群试算的能力。如需支持业务判断某个/批量的客户是否属于特定客群，需要支持判断客户是否属于分群的能力。
3）标签管理
标签服务提供给下游业务系统使用时，需要提供标签元数据查询服务，包括标签元数据列表，标签目录等。
标签生命周期管理也是标签体系的一部分，更多是管理办法和责任分工的内容。
标签的全生命周期可以划分为标签需求提出及评审——标签开发测试投产——标签核验——标签启用——标签变更——标签下线。
标签作为一种数据资产，全生命周期的管理是数据资产的管理。需要关注的是全生命周期不同阶段对应的标签状态、不同阶段关联方需要进行什么操作、从什么节点开始标签正式启用、往后节点状态变更对业务使用的影响和处理方案、状态之间的递进和回退场景等。更多在之后数据资产管理的文章中进行展开。这里简单提两点。
标签需求提出及评审：
a.提标签需求之前，需要先查看标签元数据，是否有同样业务含义的标签已经上线，当标签数量达到一定程度的时候，寻找标签就会出现困难。避免因为分类、叫法不一致，而让业务发起重复的标签需求。
b.明确标签使用场景，用于客户画像点查，还是标签客群筛选，还是其他用途。
c.标签需求模板，制定工作的SOP，在标签需求提出阶段提供需求模板，关键字段包括标签分类、标签名称、标签业务含义、标签更新频率、枚举值、数据类型等上述4.2元数据层提及的字段。
标签下线：
标签下线的情景分为两种，一种是在标签启用一段时间后，发现数据质量有问题/口径需要调整，进行临时下线操作；二是标签超过一段时间没有任何使用，成为僵尸标签，为了避免计算和存储资源浪费进行永久标签下线。第一种情景需要注意对标签下游应用的影响，在画像查询返回和客群筛选管理中应该如何处理。
本文由 @RfSr 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。