公众号推文规则变了，点击上方 "数据社"关注, 设为星标
后台回复【加群】，申请加入数据学习交流群
大家好，我是一哥，今天给大家分享一篇标签体系如何建设的干货文章，欢迎转发收藏~
为什么要先介绍标签体系？
一个推荐系统效果好与坏最基本的保障、最基础的是什么？如果让我来回答，一定是标签体系。我这里说的标签主要是针对物料的，对于电商平台来说就是商品；对于音乐平台来说就是每一个首歌，对于新闻资讯平台来说就是每一条新闻。下一篇要介绍的是用户画像，画像中那些用户实时变化的兴趣点大都也是来自于标签体系，依据用户长期和短期行为中对于物料搜索、点击、收藏、评论、转发等事件，将物料的标签传导到用户画像上，就构成了用户的实时画像和离线画像中的各个动态维度。
标签体系概览
以京东的标签体系中的京东超市为例用思维导图来拆解，后面我们会详细的介绍如何构建标签体系。
这里对京东超市标签拆解粒度到三只松鼠年货大礼包的实体级别，实际上各个公司的标签体系大致都是如下构成
一、二、三级分类体系都很好理解，参考京东超市的拆解，相信大家就会明白。标签体系中实体标签和概念标签不好理解。
实体标签
必须是名词，且必须是唯一指代。
学术性的解释逼格高，但是不容易理解，回答下面的问题
老板问：苹果，是实体标签吗？
给你三秒钟思考
你回答：是！
老板说：错！
你懵逼：靠！为啥不是？
实体标签的要求：名词，且唯一指代。
苹果，是名词，但不是唯一指代，苹果 = 科技公司、手机、水果、牛仔裤
概念标签
难道我就不能用“苹果”了吗？当然可以用，只不过要给它另外起个名字：概念标签。
概念标签通常表示的是“一类”或“某种相似”的内容，例如
主题词
这里以之家的标签体系举例，要给买车用户推荐评测导购（一级）的文章，用户画像中车的品牌（二级）偏好太粗，而实体标签如奔驰GLC又太细，填补这中间的粒度空白，满足用户购车意图的画像，就加入“代步优选”的主题词，这样不仅保持了推荐的多样性，又不至于过分精准而导致的极度收敛。
以上大致介绍了一下标签体系，那么我们接下介绍一下如何构建标签体系以及其构建过程中应遵循的一些原则。
标签体系构建原则
原则一、放弃⼤而全的框架，以业务场景倒推标签需求
原则二、标签生成自助化，解决效率和沟通成本
原则三、有效的标签管理机制
分别解释以下为什么提炼出这三个原则，分别用于解决什么问题？
关于第一项原则：
每个公司的产品、运营、商务对标签的诉求有较大的差异，同时不同的运营团队的诉求也存在很大差异，⼤而全的标签框架实际是站在用户视角搭建的，但是标签的真正应用者是业务方，所以应该从业务视角来实现。
因此最佳的处理方式是，我们应该放弃顶层的用户抽象视角，针对各业务线或部门的诉求和实际的应用场景，分别将标签聚类起来提供给相应部门。
之家就是非常典型的情况，商业同学更关心用户的消费能力相关的标签；自驾游负责同学更关心用户的位置和出行相关的标签；车友圈的同学更关注用户的社交活跃相关的标签；所以不可能一套标签覆盖整个运营团队， 这种以业务场景倒推标签需求的方法，能够与业务场景贴合更紧密，可用性上升。
关于第二项原则：
1.标签生成的自助化能够让沟通成本降最低。前面讲到各业务线对标签的定义的理解不同，需要标签系统建设团队花费大量的时间沟通。如果能够让业务方自己定义规则，这必然是沟通成本最低的方式。
2.标签生成的自助化，可重复修改的规则，降低无效标签的堆积。业务一直在发展，如果规则一成不变则很难跟上业务节奏的变化。我曾拜访过一家电商，他们发现半年前定义“母婴客户群”的转化率一直在降低，因此根据实际情况重新修改和定义了“母婴客户群”规则，并命名为“母婴客户群（新）”，这时之前的规则是无效的，且会一直占据计算资源……诸如此类，如果支持规则重复修改的话，这一类无效标签就会大量地消失。
3.释放数据团队人力，释放业务团队的想象力。数据团队应该花较多的精力在企业的整个数据中台或新业务模型方面，而不是处理各业务线的标签诉求和标签维护上，自动化的标签生成能够极大限度地节省人力和释放团队想象力。
关于第三项原则：
1.规则及元信息维护：标签相关的规则和元信息要尽可能的暴露给使用者，让使用者在使用的时候，能清楚知道标签的规则是什么、创建者是谁、维护者是谁、标签的更新频率周期等，而不是没有规则，或者将规则存在标签建设团队内部的一个 word 文档中。
2.调度机制及信息同步：标签之间有一些关联，标签之间的链条断裂，是否有个调度机制或者信息同步机制让大家的工作不被影响。
3.高效统一的输出接口：将所有的业务信息和用户数据信息汇总在一起，有统一的输出接口，改变之前需要针对不同的业务系统开发不同接口的情况。
我们回顾标签体系构建的三原则，本质上是解决了价值、手段、可持续性三方面的问题：以业务场景倒推需求，让业务方用起来作为最终目标，让标签系统价值得以实现；标签生成的自助化，它解决的是我们用什么样的手段去实现价值；有效的标签管理机制，意味着一套标签体系能否可持续性地在一家企业里面运作下去。
总之，对企业最重要的是：一套标签系统能不能在业务上用起来，能不能覆盖更广泛的需求，而不是一个大而全的框架。
标签体系构建的方法
标签体系的实施架构
标签体系架构可以分为三个部分：数据加工层，数据服务层，数据应用层。每个层面面向用户对象不一样，处理事务有所不同。层级越往下，与业务的耦合度就越小。层级越往上，业务关联性就越强
以某电商公司为例
数据加工层。数据加工层收集，清洗和提取来处理数据。M公司有多个产品线：电商交易，电子书阅读，金融支付，智能硬件等等。每个产品线的业务数据又是分属在不同位置。为了搭建完善的用户标签体系，需要尽可能汇总最大范围内的数据。同时每个产品线的也要集合所有端的数据，比如：App，web，微信，其它第三方合作渠道。
收集了所有数据之后，需要经过清洗：去重，去刷单数据，去无效数据，去异常数据等等。然后再是提取特征数据，这部分就要根据产品和运营人员提的业务数据要求来做就好。
数据业务层。数据加工层为业务层提供最基础数据能力，提供数据原材料。业务层属于公共资源层，并不归属某个产品或业务线。它主要用来维护整个标签体系，集中在一个地方来进行管理。
在这一层，运营人员和产品能够参与进来，提出业务要求：将原材料进行切割。主要完成以下核心任务：
定义业务方需要的标签。
创建标签实例。
执行业务标签实例，提供相应数据。
数据应用层。应用层的任务是赋予产品和运营人员标签的工具能力，聚合业务数据，转化为用户的枪火弹药，提供数据应用服务。
业务方能够根据自己的需求来使用，共享业务标签，但彼此业务又互不影响。实践中可应用到以下几块：
智能营销
Feed流推荐
个性化消息push
标签体系的设计
1.业务梳理
以业务需求为导向，可以按下面的思路来梳理标签体系：
有哪些产品线？产品线有哪些来源渠道？一一列出。
每个产品线有哪些业务对象？比如用户，商品。
最后再根据对象聚合业务，每个对象涉及哪些业务？每个业务下哪些业务数据和用户行为？
结果类似如下：
2.标签分类
按业务需求梳理了业务数据后，可以继续按照业务产出对象的属性来进行分类，主要目的：
方便管理标签，便于维护和扩展。
结构清晰，展示标签之间的关联关系。
为标签建模提供子集。方便独立计算某个标签下的属性偏好或者权重。
梳理标签分类时，尽可能按照MECE原则，相互独立，完全穷尽。每一个子集的组合都能覆盖到父集所有数据。标签深度控制在四级比较合适，方便管理，到了第四级就是具体的标签实例。
3.标签的模型
按数据的实效性来看，标签可分为
静态属性标签。长期甚至永远都不会发生改变。比如性别，出生日期，这些数据都是既定的事实，几乎不会改变。
动态属性标签。存在有效期，需要定期地更新，保证标签的有效性。比如用户的购买力，用户的活跃情况。
从数据提取维度来看，标签数据又可以分为类型。
事实标签。既定事实，从原始数据中提取。比如通过用户设置获取性别，通过实名认证获取生日，星座等信息。
模型标签。没有对应数据，需要定义规则，建立模型来计算得出标签实例。比如支付偏好度。
预测标签。参考已有事实数据，来预测用户的行为或偏好。比如用户a的历史购物行为与群体A相似，使用协同过滤算法，预测用户a也会喜欢某件物品。
4.标签的处理
为什么要从两个维度来对标签区分？这是为了方便用户标签的进一步处理。
静态动态的划分是面向业务维度，便于运营人员理解业务。这一点能帮助他们：
理解标签体系的设计。
表达自己的需求。
事实标签，模型标签，预测标签是面向数据处理维度，便于技术人员理解标签模块功能分类，帮助他们：
设计合理数据处理单元，相互独立，协同处理。
标签的及时更新及数据响应的效率。
以上面的标签图表为例，面临以下问题：
属性信息缺失怎么办？比如，现实中总有用户未设置用户性别，那怎么才能知道用户的性别呢？
行为属性，消费属性的标签能不能灵活设置？比如，活跃运营中需要做A/B test，不能将品牌偏好规则写死，怎么办？
既有的属性创建不了我想要的标签？比如，用户消费能力需要综合结合多项业务的数据才合理，如何解决？
模型标签的定义解决的就是从无到有的问题。建立模型，计算用户相应属性匹配度。现实中，事实标签也存在数据缺失情况。
比如用户性别未知，但是可以根据用户浏览商品，购买商品的历史行为来计算性别偏好度。当用户购买的女性化妆品和内衣较多，偏好值趋近于性别女，即可以推断用户性别为女。
模型计算规则的开放解决的是标签灵活配置的问题。运营人员能够根据自己的需求，灵活更改标签实例的定义规则。比如图表中支付频度实例的规则定义，可以做到：
时间的开放。支持时间任意选择：昨天，前天，近x天，自定义某段时间等等。
支付笔数的开放。大于，等于，小于某个值，或者在某两个值区间。
标签的组合解决就是标签扩展的问题。除了原有属性的规则定义，还可以使用对多个标签进行组合，创建新的复合型标签。比如定义用户的消费能力等级。
标签最终呈现的形态要满足两个需求：
标签的最小颗粒度要触达到具体业务事实数据，同时支持对应标签实例的规则自定义。
不同的标签可以相互自由组合为新的标签，同时支持标签间的关系，权重自定义。
- END -
历史好文推荐
从0到1搭建大数据平台之计算存储系统
从0到1搭建大数据平台之调度系统
从0到1搭建大数据平台之数据采集系统
如何从0到1搭建大数据平台

                

文末有福利～
（本文整理自 2020 线上增长大会 GrowingIO 徐主峰演讲内容）
大家好，我是 GrowingIO 企业事业部总经理徐主峰，自 2015 年加入 GrowingIO 以来，陆续服务了唯品会、汉光百货、喜茶、蜜芽宝贝等众多品牌零售企业。
我们发现，近一年来，很多零售行业客户都从一味关注流量和订单转化率的提升，逐渐过渡到以用户为视角的精细化运营。今天就围绕「搭建客户数据平台，助力零售企业数据化转型」为大家展开主题分享。
1，挑战之下，零售行业的新增长机会
突如其来的疫情对零售行业产生了很大的影响，用户减少的同时，受经济大环境的影响，用户的购买力也随之下降。
虽然疫情使很多零售企业的营收大幅下降，但像百果园、三只松鼠等零售企业，营收却不降反增；还有生鲜、商超等行业的线上营收占比，相比去年同期，几乎翻了一倍。
可以说，这次疫情对于已经初步完成数据化转型的零售企业来说，反而是一次机会。
目前，国内很多零售企业都在探索数据化转型的路上做了大量工作，但随着逐渐进入到数据化能力建设的深水区，基本都会遇到以下 4 大挑战：
1.数据化的思维意识不强
传统零售企业大多只关注业务数据，对数据化的思维理解比较单一。但随着整个行业的发展，零售企业在对数据化思维重要性的认知上已经达成共识，并已做好数据化转型的思想准备。
2.缺少数据化的工具
拥有数据化的工具，对传统零售企业来说具有一定的门槛，自研数据工具不太现实，但市场上能提供完整数据运营解决方案的厂商并不多，而且相应的采购和建设成本偏高。
3.未构建系统的数据化流程
零售业的数据化升级，要求对原有业务流程进行数据化改造，这需要企业真正下定决心才能推行。
4.缺少有经验的数据化团队
打造数据化团队需要长期的投入和成本。但随着行业数据化认知的升级，对懂数据、会数据的人才的需求量会逐渐增大。
以上4个挑战相互关联，不能期望单独解决某个问题。整个企业需要螺旋式地、循序渐进地加速数字化转型。
2，零售企业数据化建设“两步走”
那么，零售企业如何顺利地进行数据化转型呢？如图所示，GrowingIO 将之分为两个阶段：
数据化 1.0 阶段：构建数字化的经营分析体系
1.0 阶段的核心目标是要用数据来描述目前业务的运营状况，进而提升流量和订单的转化。
比如，活动运营，要用数据来优化和提升运营策略；站内流量分发，要用数据来提升站内的转化效率；同时要对商品、SKU进行分析，从整体上提升用户在站内的使用体验。
数据化 2.0 阶段：构建用户生命周期的数据运营
到 2.0 阶段，我们的目光就可以从流量和订单转移到用户身上，关键在于构建基于用户生命周期的运营能力。
一般，我们可以把用户分为新用户、老用户、会员用户、超级用户和流失用户。在不同的用户生命周期，用户运营的核心目标都是不一样的。
比如，从新用户到老用户，我们关注的是新用户首购的转化；从老用户到会员用户，我们关注的是通过推动老用户不断地复购来建立忠诚度；从会员用户到超级用户，我们关注的是提升用户对品牌的认知和价值共鸣；对于流失用户，我们关注的是用户召回。
这两个阶段相辅相成，我们在 2.0 阶段的每个用户生命周期运营目标下，都有可以实践和融入 1.0 阶段数字化经营分析所构建的能力。二者互相结合，共同放大运营空间和运营潜力。
在服务客户的这五年中，GrowingIO 还总结和梳理另外一套完整、可落地的不同阶段路径的建设和规划。
1.0 阶段，我们核心关注的还是流量与订单的转化，从站外获取流量、到站内分发流量，再到购买转化率的提升。
这个阶段，我们主要需要两类工具，一类是做站外流量获取的分析工具，另一类是做站内产品优化的分析工具。
2.0 阶段，我们开始关心超级用户的打造，核心围绕用户数据采集和沉淀、用户标签体系建设以及用户运营平台的建设，构建用户精细化运营的能力。
这个阶段，我们主要需要两类工具，一类是支持自动化运营策略落地的用户运营平台，另一类是进行用户数据采集、聚合以及构建标签体系的客户数据平台（CDP）。
3，GrowingIO 完整解决方案，帮助企业实现数据化增长
基于以上思考的指导下，GrowingIO 逐渐构建了一套“增长平台+业务咨询+培训赋能”数据化增长的完整解决方案，帮助和陪伴我们的客户逐渐跨越数据化转型过程中遇到的各种挑战。
增长平台是软件部分，包括客户数据平台（CDP）、产品分析、智能运营和获客分析；
业务咨询服务是以指标体系梳理搭建、标签体系梳理搭建、用户运营场景咨询实施、产品优化建议等为核心服务内容的咨询服务；
培训赋能是以增长大会、增长学院、增长工作坊为主传播数据运营方法论的培训服务。
在整套增长解决方案中，核心是增长平台下的 4 个产品。上图中，蓝色的是数据平台的部分，是我们的客户数据平台（CDP）；橙红色的是数据应用部分，分别为获客分析、产品分析和智能运营。
关于数据平台：
数据平台主要分为三层：数据采集层、数据处理层和基础能力层。
数据采集层的核心是采集零售企业用户各平台上的数据，以及企业内部各业务系统的数据。
数据采集层支持采集的数据主要有三类：用户行为数据、交易数据和 CRM 数据。这三类数据基本满足和支撑零售客户做用户运营的数据需求。其中，体量最大、细节最丰富、处理难度最大的是用户行为数据。
在数据处理层与基础能力层，我们把数据模型、标签计算和用户计算这些基础能力整合在一起，支撑上层各种应用的数据需求。
关于数据应用：
在数据应用的层面，我们提供了三个产品：获客分析，产品分析和智能运营。
获客分析是帮助客户的市场部门，评估渠道的投放效率，优化投放 ROI。
产品分析是面向客户的产品部门和数据部门，帮助客户做站内用户转化效率的优化并提升用户体验等。
智能运营是帮助客户的运营部门，自动化落地精细化的运营策略。
4，客户数据平台（CDP），为数据化转型奠定基础
通过以上的架构讲解可以看出，在实际落地数据化转型的过程中，客户数据平台是优化投放 ROI 、提升站内用户转化、实现精细化运营的基础和关键。
但客户数据平台（CDP）的搭建并非易事，GrowingIO 服务的很多客户在合作前都表示，数据难以采集、难以处理、难以应用等，非常头痛。具体体现在以下 4 点：
1.数据处理能力不足
- 数据来源分散、类型复杂，难以采集和聚合
- 用户行为数据量大，细节丰富，碎片化程度高
2.数据体系缺乏规范
- 数据/指标零散，缺乏统一的数据指标体系据
-数据系统点状支持，没法系统化、规模化、自动化
3.跨部门协作难，开发工作量大
- 手工取数，流程长、效果差
-无法支撑数据化运营策略
- 营销工具无法快速响应策略变化
4.不能支撑个性化、自动化的运营需求
- 业务标签不够丰富，分析不够深入，调用费时费力
- 个性化运营需求难以满足
- 营销活动效果难以实时反馈，随时调整策略
- 缺乏用户唯一标识，基于用户生命周期的分析断裂
为了更好地帮助客户解决以上问题，GrowingIO 在设计 CDP 产品时制定了三原则：
1.高效集成原则。我们支持服务端、客户端、数据系统接口等多个数据来源的数据采集和数据对接能力。
2. 智能处理原则。当数据进入到客户数据平台之后，我们会通过统一的 ID mapping 能力，对用户建立同一用户 ID 并打通各来源数据，构成用户标签系统和用户画像系统的数据基础。
3. 灵活运用原则。我们搭建的客户数据平台，可以无缝使用 GrowingIO 其他数据应用产品，包括产品分析、智能运营和获客分析等，同时可以私有化部署在企业内部，灵活地和企业自建应用打通，并支持企业内部应用的自定义开发。
基于这三个原则，GrowingIO  已经为包括零售、保险、汽车等多家企业搭建了客户数据平台。客户们一致认为，GrowingIO 增长平台对它们的数据化转型帮助很大：
1. 跨平台、跨访问，建立统一用户 ID
以 GrowingIO 某汽车行业头部企业客户为例。
该客户有 30 多个用户服务系统，其中 20 多个是核心用户服务系统。这些系统在服务用户的过程中涉及到多端以及多个平台，像微信、小程序、网站等。另外，该企业还拥有多个子品牌。
面对这样一个多系统、多平台、多品牌的情况，客户需要找到一个高效的方法，把所有用户服务数据整合到一起，并构建一个完整的用户服务体系，从而实现数据化运营。
经过在市场上同类产品的多方对比，该客户选择 GrowingIO 客户数据平台（CDP），将所有跨平台访问的用户数据打通，构建统一的数据基础，并一站式承载所有的用户服务数据。满足了客户服务部门在日常服务过程中，统一用户数据，高效运营的需求。
2. 强大的标签计算能力，支撑精细化用户运营
以 GrowingIO 某零售电商行业头部企业客户为例。
GrowingIO 为客户规划了一套完整的用户运营方案。
但落地这套策略，建立在相对完善的用户数据，以及标签和分群的计算能力的基础上。
为帮助客户构建数据基础，GrowingIO 将客户数据平台部署到客户内部。整合用户数据的同时，为运营部门提供标签和分群的能力，再对接到客户内部的运营系统，对实际运营活动提供支撑。
帮助客户顺利实现了依据用户生命周期的不同阶段，匹配相应的运营策略，成功落地了完整用户运营方案，活跃用户数与转化率均有明显的增长。
3．构建更完整的用户画像，提升对用户的认知
以 GrowingIO 某地产行业头部企业客户为例。
地产行业的用户转化周期特别长，房地产经纪人大多仅凭自己的经验完成用户转化。在整个转化周期中，让经纪人通过数据，可以准确了解用户在不同阶段的购买意愿、购买偏好等，对于提升成交率十分重要。
通过搭建客户数据平台，GrowingIO 采集用户在线上所有关于房源浏览、查看的情况，定位用户的购房偏好、判断用户在不同阶段下的购买意愿等，建立用户 360 度画像。
有了用户画像后，房地产经纪人可以在关键时间点洞察用户需求、制定更好的销售策略，促成最终购买转化。
最后，我们再回到增长平台的整体架构上来，把客户数据平台和数据应用结合起来，总结一下。
在这个架构下，GrowingIO 在数据应用层会采集和产生数据，这个数据经过沉淀可以汇总到客户数据平台中，同时客户数据平台对数据进行加工处理，进行价值放大，反哺数据应用，形成价值闭环，从而帮助零售企业客户完成数据化建设的升级，并赋予企业数据运营落地的能力。
这是 GrowingIO 构建增长平台，以及其中的核心产品——客户数据平台的目标，也是 GrowingIO 希望能够给客户带来的价值。
今天的分享就到这里，谢谢大家。
关于 GrowingIO 客户数据平台（ CDP )
GrowingIO 客户数据平台（CDP）通过整合跨平台、多类型数据，帮助企业构建以用户为视角的数据池，搭建用户标签和画像系统，提供从数据采集、整合、分析到自动化运营的一站式用户运营闭环，发掘业务增长点，快速落地企业数据化转型。
点击 此处 领取 15 天免费试用！

一、内容
【文件】命名包含变量

audiowrite(sprintf(‘mic_%d_%d.wav’,ii,pp),YY,fs);

【文件】c文件写入

stringName = [‘fileNameNum’,’.c’]

%stringName = [sprintf(‘mic_%d_%d.wav’,ii,pp)];

dlmwrite(stringName,codeNum);%codeNum是变量数据

【文件】c文件读取

stringName = [‘fileNameNum’,’.c’];

I_Code = 1;

stringName2 = [‘dateICode_’,num2str(I_Code),’.c’];

codeNum = dlmread(stringName);

【画图】变量做标题

stringName = [sprintf(‘mic_%d_%d.wav’,ii,pp)];

title(stringName);
二、实验
close all;
clear all;
clc;
ii = 1;
pp = 2;
sprintName = [sprintf('mic%d%d.c',ii,pp)];
code1 = (randi([0;1],1,100)-0.5)*2; % 1  -1序列
code2 = (randi([0;1],1,100)-0.5)*2; % 1  -1序列
figure
plot(code1);hold on
plot(code2);%249757
xlim([-10,110]);
ylim([-1.5,1.5]);
title(sprintName);

输出情况


三、绘图

这里是我个人写的一个demo:
里面是把“stationId”加入在了url后面
说实话这个我是在网上找资料查出来的
具体为什么可以这样用，我也不是很清楚
希望能有大神赐教一二
这里是效果图