这是POINT小数点的第 395 篇文章
点点写在前面：
数据驱动未来已经是大家共识，而数据中台作为数据科技时代重要的基础设施，如何实现数据驱动还需要不懈努力。本篇作者Eva是用户画像和个性化推荐部门算法负责人，由她的角度告诉你如何使用用户标签建设让数据产生价值。一起来了解叭
近十年，大数据、云计算、AI发展如火如荼，随之也伴随着许多问题。众所周知，数据建设需要耗费巨额的成本，然而，真正能将这些数据转化为价值的公司并不在多数。绝大多公司在数据建设方面每年一投就是上千万甚至上亿，而在数据价值转化能力方面却极其匮乏。数据建设大多经历以下三个阶段：
— 1 —
数据应用成长篇
公司在创建数据团队之初，首要考虑的就是寻觅一位数据团队的Leader，而该岗位的候选者通常是技术领域的专家。诚然，聘请一位资深技术管理者优势在于，可以利用其精湛的专业能力，快速组建一支优秀的技术团队，搭建出一套完善的技术架构，并基于此迅速产生可见的"结果"。大家要注意，这里用的是"结果"而非从"成果"—— Data 1.0。
然而，随着企业在数据方面投入越多，企业其他部门的数据诉求增加。一个技术管理人员如果没有转变思路，过于沉迷于已有的技术架构的话，很可能会让整个团队在数据价值化的道路上停滞不前。技术和业务的鸿沟与日俱增，技术人员认为业务方不知道前沿技术的发展，业务方认为技术方不懂业务现状，空谈技术解决方案。这种现象发展到后期，各部门会出现畸形的组织结构，即各个部门都设置有自己的数据团队，直到最后将这个数据中心架空了。数据中心最终不能为业务服务，不能发挥其作用，结局可想而知。这是作为数据中心的最大悲哀，同时也是公司的悲哀—— Data 2.0。
让我们来扒拉一下，前面两个阶段最容易出现的问题：
数据口径不一致。每次出月报、季报、年报时，数据部门和业务部门都会提前很长时间核对数据口径。口径不一致，数据来源不一致，数据表更新不及时都会影响到数据一致性问题。
数据需求日益增加，需求响应速度慢，灵活度低。作为数据人员，很多人都会有这种感受，每天接大量的报表需求，几乎每个需求方都会说自己的需求很急，一个报表需求从开发到结束的至少耗费2-3天。并且，这种报表开发的思路可复用性差，比如我们用PowerBI或者tableau开发了一套报表需求，但因为数据源不同，数据处理方式不同，底层的逻辑基本要重写。
报表价值难以体现。相比过去，现如今任何一家成熟的数据部门，利用ETL数据处理工具、数据仓库以及可视化工具，报表的开发速度已经有了明显的改善。然而，越来越多的公司领导明白(数量不等于质量)。静态的报表往往不能直接作用于业务，大多数报表开发完之后，短时间业务方会来看看数据，但后期价值直线下降，这种类型报表开发耗时、耗力、还耗资源。
业务线多而复杂，数据整合困难。比如一家银行，划分成存款业务，取款业务，支付，信贷，等多业务线。各业务线数据分散在各端，难以将数据整合、加工并最终加以利用。
资源利用效率低。有的公司在各个部门都设有数据团队，甚至各个部门的数据团队建设都非常齐全。这样做的好处是，每个部门都会有专业团队负责某项业务。对于一家业务间没有往来的公司，这种组织形式是没有问题的。但是，对于一家业务复杂，同一个用户在该公司开设多个业务的公司，尤其是在交叉业务分析和用户价值挖掘时，割裂的数据底层建设会极大程度降低公司对数据的利用率。同时，重复设置数据团队，往往会导致一份数据有多个拷贝，导致资源浪费。
需求链路复杂，沟通成本高。从数据需求产生到落地，往往要通过产品或运营、数据分析师、算法工程师、技术、测试等不同人之间的协作。每个不同需求，因其涉及的环节不同、内容不同，对应不同岗位的不同人员。因此，很多时候在"找人"这个事情上已经很不容易。尤其是当你遇到一个组织结构复杂+离职率高的公司，这个问题就感觉是个死循环。每次做需求就要面临这个庞大而不稳定的组织带给你的种种不确定性。
— 2 —
数据中台的崛起
就在这样的形势下，企业意识到建立“数据中台”重要性。数据中台 是一套可持续”让企业的数据用起来”的机制，是一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建的一套持续不断把数据变成资产服务于业务的机制。
所以，数据中台不再停留在工具和产品层面，但不等同工具和产品不重要，而是建立在工具和产品基础上，站在企业战略、组织、一站式工具等多方面、更全方位的思考问题。最后，将整个数据盘活，服务于实实在在的业务。
上述这张图看，可能很多同学仍旧不能很好的理解，下面我们就将中台建设中，一部分重要数据建设拎出来——画像标签，来解释数据中台是如何利用数据为业务产生价值的。
— 3 —
数据中台之画像标签
传统数仓是围绕着各个业务而定，基于某个主题域，如交易、支付、信贷、社交等主题域创建。这导致很难当企业想从全方位了解一个客户信息时，需要通过各种关联才能满足业务的需要，使用成本相当高，分析效率也非常低。然而，通过了解和分析客户的全面数据，是多个业务的共同需求，这些都是通过建设360画像标签来满足各方业务的需求。标签数据层需要做以下工作：
3.1 ID-Mapping
所谓ID-Mapping，就是对不同业务中(ID不同)同一个对象进行打通。以便让产品和运营能够站在”上帝”的视角看用户，了解每个用户在使用产品生命周期全过程。诸如：用户从哪里来？什么时间，什么地点喜欢打开APP？喜欢做什么？喜欢谈论什么？最近需要什么……
ID-Mapping，首先要通过ID-ID之间两两关系得到，通过两两关系表，再将多种关系关联起来(SuperID)，这里的ID通常有：身份证、手机号、邮箱账号、IMEI、通行证账号、交易账号等。在建立关系表时，有的时候两两关系并不是确定不变的，而是带有置信度的。比如，因为业务上一个手机号可以登录多个通行证账号。再比如，一个通行证账号可以登录不同交易账号的场景。以上情况我们无法确保ID-ID关系是一对一的关系。这样，在使用不同跨ID画像的时候，我们就要明确使用场景。有的使用场景，对ID的匹配精准的要求非常严格，比如，需要对用户总资产做统计并且显示在用户资金账户上。而有的场景则不需要完全匹配，比如说，内容推荐的场景。
此外，ID-Mapping还可以用在反欺诈场景中。假设我们发现一个身份ID与其他很多账号有着“盘根错节，剪不断理还乱”的关系，很可能这就是一个问题ID。
3.2 标签管理
标签 是站在＂人＂，＂物＂，“关系” 层面，通过一定的逻辑将数据处理成机器或者业务能够理解的数据。按照计算方式不同，标签又可以分为统计类标签，规则类标签，模型类标签和预测类标签。按照一定的业务需求、人工规则或者AI赋能，将晦涩难用的数据转化成业务可理解、可用的数据资产。
标签管理 主要包括：标签元数据管理，调度管理，标签类目管理等方面内容。这里我们重点说一下调度管理和类目管理。调度管理是对每个标签生成的任务进行管理。一个任务可以生成多个标签，但一个标签只能由一个任务产生。建立标签任务的时候，要考虑数据源，来自相同数据源的标签可以放在同一个任务中进行。在执行任务的过程中，需要考虑源数据执行完成的时间和速度。而对于标签的标签(二次标签，即基于标签生成的标签)，我们不仅需要考虑源数据执行完成的时间和速度，还要考虑该二次标签所依赖的标签生成的时间。
标签类目管理，是标签体系建设重要环节。就如同一本书的索引，一个良好的类目管理可以方便业务迅速准确的定位自己想要的标签。标签类目管理设计方式不唯一，不同的公司因业务不同，所关心的用户群体和用户特征是不一样的。
3.3 标签服务
无论是用户画像标签还是物品画像标签，都是通过标签服务创造价值的。如果标签只是被生产出来，而不能为企业服务，那么和数据库中的数据一样都将会是一潭死水，终无一用。
标签服务主要体现在：标签分析、人群圈定、精准营销、反欺诈、客户关系管理系统、个性化推荐等多个方面，下面我们举例说明如何用标签打造产品运营闭环。
— 4 —
利用标签打造产品运营闭环
某家公司一季度运营目标是提高GMV，一季度总预算是100w。运营策略初步是希望通过提高目标用户群体复购来实现，活动手段是发放优惠券。经过商议，大家决定第一个迭代目标用户群体暂时选定为购买意愿高且购买能力强的用户作为本次目标用户群。通过调整优惠券券发放时间和查看发放结果来逐渐调整策略。
策略需要考虑的问题：
给谁发放？
什么时候发放？
优惠券优惠程度如何设定？9折？8.5折？满减？
活动效果如何？
— 5 —
总结
画像标签在数据中台建设中发挥着怎样的作用？又是如何促进数据价值化？
通过账号打通，连接各个域的数据，打造更全面的标签数据。规划全域数据，统一口径，减少沟通成本。
采用先进的AI技术给数据赋能，将输出结果直接作用于业务。比如将用户分群结果，流失预判的结果直接用于精细化运营，将个性化推荐的结果直接应用于推荐当中。
从“人”和“物”层面出发，更细粒度进行业务分析洞察，挖掘用户潜在价值，分析用户各个阶段遇到的问题，促进产品功能改进。
打造基于标签的自助化平台，为业务提供标签字典，标签维度自助分析，并且提供标签圈人(可根据业务需求分群对用户自行分群)等功能。为数据业务化，业务资产化，资产服务化奠定基础。
通过各种API接口为公司各部门输出数据结果，而不是中间数据，减少服务器消耗，降低成本。
画像标签服务还可以连接业务平台，如将分群后结果输出到运营平台直接使用，并通过运营平台反馈数据再进行分析，调整解决方案，从而形成运营闭环。
END
加入POINT.
长按扫码添加小夏微信
数据 | 社区 | 职场 | 比赛
POINT.小数点用户画像运营课程( 第六期)正式预售
点击图片加入
支持一下，嗑干货！
扫一扫
1083
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
