1.背景作为二手电商交易领域的领头羊，转转在过去的几年里，用户数量和业务量都在快速增长。为了更好地服务于用户，并不断壮大，产品运营的战略战术也会随之发生变化。创业初期，产品一般立足于粗放式运营，力求快速获取用户、推广产品、引领赛道。业内也曾传出产品三宝：弹窗、浮层、引导；运营三宝：短信、推送、红包。但到了中后期，企业将面临的三大问题分别是降本增效、持续增长和用户体验。因此，基于数据的精细化运营成为大家的必然选择，而用户画像平台正是帮助商家进行精细化运营的助力。其中，构建灵活、全面、高效的标签体系是工作的重中之重。本文从标签画像系统建设的需求出发，阐述转转在用户画像平台建设过程中的思考与实践。2、什么是用户画像？用户画像是指根据用户属性、用户偏好、生活习惯、用户行为等信息抽象出来的带标签的用户模型。通俗地说，就是给用户打标签，标签是通过分析用户信息得到的高度精细化的特征标识。通过标注，可以使用一些高度泛化和易于理解的特征来描述用户，可以使人们更容易理解用户，便于计算和处理。简单来说，就是对用户某个维度的描述。对于一群用户来说，为了让业务做的更好，我们想知道他们的很多特性。比如我现在有10万元的活动预算，那么这笔钱应该花在哪里呢？针对这个问题，我们希望对于给定的用户群体，能够知道他们的商业价值，并且能够很好的描述他们的商业价值。要知道哪些人才是我们要服务的重点对象，下图是对一个用户的洞察，通过标签处理我们可以观察到用户的一些特征属性。3、洞察标签画像应用场景中的用户特征：用户标签辅助用户分析和用户洞察，可以帮助业务人员快速对用户有一个认知，进而发现其中的显着特征，从而获得一些业务灵感.增强数据分析：标签还可以丰富数据的维度。对我们的业务数据进行更深入的对比分析，从分析和洞察中得到启发后，可以辅助业务的落地。精细化运营：一方面可以将用户群进行更细粒度的分组，让运营由粗放型向精细化转变，利用多种不同的手段、不同的渠道触达，如短信、推送、邮件等，带动或召回用户，达到事半功倍的效果。4.转转用户画像平台的实践4.1系统结构图上图介绍了用户画像平台的系统结构图。按照大模块，一共有6个模块，标签模块、人群计算模块、用户群像分析模块、用户运营模块、用户洞察模块、权限管理模块。下面介绍标签画像的构建过程。4.2标签画像构建原则我们构建用户画像平台的目的有两个：一是要从业务场景出发，解决实际业务问题。用户画像的原因是为了获取新用户，提升用户体验，或者挽回流失的用户等，有明确的商业目标。基于用户画像信息做产品设计，需要清楚地知道用户长什么样，有什么行为特征和属性，才能针对用户设计产品或开展营销活动。一个普遍的误解是，人像维度的数据越多越好，人像数据越丰富越好。在画像上花了不少功夫，发现只剩下用户画像，离业务很远，没办法直接支撑业务运营，投入大回报小。可以说得不偿失。有鉴于此，我们画像的维度和设计原则都是由业务需求紧密驱动的。4.3标签类型及规则我们认为，作为一个标签平台，需要具备非常灵活的标签创建能力，以适应不断变化的业务需求。具体来说，我们根据标签的场景和特点将其分为两类。通用标签通用标签是一些用户的基本属性。比如年龄、性别、城市、出生日期等业务标签和业务标签主要按照几大业务线进行分类，包括与业务行为相关的标签，比如累计下单数、历史单级类别、B2C用户业务链接等。为了更好地描述和定义标签，我们将标签分为四个层次，粒度从上到下逐渐变小。标签的定义和命名也是按照四个层次进行的。规则为一级标签名_二级标签名_三级标签名_标签值（四级标签）。例如最近30天活跃时间段标签，最终定义形式为商家标签_B2C_最近30天活跃时间段_12点-20点，其中12点-20点'clock是我们标签的一个值，也是一个四级标签。根据标签的计算方法，我们将标签分为事实标签、统计标签和预测标签。事实标签：对原始业务数据和埋点数据进行统计分析得到。例如，用户累计下单数是根据一段时间内用户下单的累计数据量统计得出的。模型标签：模型标签是基于事实标签，通过在事实标签和业务问题之间建立模型，进行模型分析得到的。比如兴趣标签，最感兴趣的分类。预测标签：通过算法建模，预测用户的一些特征，如年龄、性别、学历、婚姻等。兴趣类标签的计算过程：预测类标签的一般流程：4.4标签制作与处理标签制作原理标签的生产和加工应满足以下原则：可扩展的标签创建规则我们需要非常灵活和可扩展的标签规则定义，以满足用户业务场景变化引起的标签规则的变化。因此，我们开发了一套标签模板。各个标签的规则可以通过配置模板来实现。模板支持可视化配置相关参数，支持随时更改模板规则。如果需要更改标签计算规则和参数，只需要更改模板SQL即可。能。而且，一个标签可以用于一个标签，也可以用于多个标签，大大降低了用户创建标签的门槛，方便我们管理标签规则。支持亿级用户的标签制作，可以在相对有限的资源条件下，支持具有较大用户基数的标签制作，对计算或存储的优化要求较高。对于系统架构，平台的可扩展性和适应性会要求比较高。标签数据每天更新。对于企业，我们的通用标签每天都会更新。标签的计算将在每天早上通过调度平台进行。由于标签所依赖的上游表的输出时间是不确定的，所以标签的计算会以上游业务表为准。为了计算输出情况，标签计算模块会检测相关的依赖表。如果监控到依赖表计算完成，则计算label。最后更新计算结果。标签数据的来源标签计算中使用的数据主要分为两部分，一部分是业务数据，比如订单；另一部分是用户行为数据，产品曝光事件。创建标签前需要提前清洗相关业务数据或埋点数据。标签模板开发我们设计了一套标签计算SQL模板，支持可视化创建配置模板。模板创建完成后，用户无需关心标签的底层计算规则，只需要通过页面配置相关业务属性条件即可。模板类型包括属性过滤模板和上传文件模板。属性过滤模板用于过滤特定属性的用户集合，例如过滤浏览产品5次的男性用户。上传文件就是直接上传用户特征属性集。用户集上传后，会放在某个hive表的某个partition下。我们可以在计算的时候用SQL把这些用户提取出来。用户属性集操作标签计算涉及多个属性计算。例如，需要计算浏览商品10次并下单但未付款的用户。然后需要收集并计算浏览该产品10次的用户集合和下单但未付款的用户集合。每个属性模板代表一个用户集，这些用户集之间的操作就是集合操作。我们这里支持完备集操作：交集、并集、求反，并且支持多级嵌套。为此，我们设计了一个简单的逻辑表达式来表示用户设置的逻辑。比如我们要的用户集（下图中蓝色部分）是买过或看过手机的男性，排除卖家。那么这个的逻辑表达就是：在实际使用中，表达中不会出现中文，而是使用集合ID（也就是上面说的tag字段）。为了解析方便，每个集合都用括号括起来，一个逻辑表达式中的每个节点只能有两个子节点，或者没有子节点。我们需要收集每个用户的所有标签。这里我们把这个标签用到的所有模板组合在一起，然后按xxid分组，收集每个用户的所有标签。我们用UDF实现了这个逻辑表达式的执行引擎。将用户的标签列表和逻辑表达式传入UDF，判断用户是否是我们想要的。执行引擎会先将逻辑表达式解析成一棵树（会缓存起来避免重复解析），类似于抽象语法树，然后遍历树进行解释和执行。逻辑运算中的一个优化是短路运算，即执行完一部分运算后，可以得到整个表达式的值，剩下的部分不需要计算。例如，如果“与运算”中有一个假，则结果为假，如果“或运算”中有一个真，则结果为真。解析树如下：通过自定义UDF函数，我们解决了各种用户集和计算的问题，满足了不同业务场景下不同用户属性的标签计算。如何创建标签我们使用标签SQL模板作为标签计算的基石。创建标签时，我们支持4种类型的标签。枚举标签和分组标签都是使用SQL模板实现的，用户不需要懂SQL。上传标签是直接上传用户的ID数据。自定义SQL满足了用户在某些情况下需要编写SQL来定义标签的需求。4.5标签存储设计由于我们的标签是根据离线数据计算出来的，所以所有的标签数据集都存储在Hive中。因为离线计算一般是按日调度的，所以底层表是按天分区存储的。每日标签存储一个分区。那么这个分区下的数据文件就是一个ORC文件。ORC文件用于利用ORC列存储来节省存储空间。如下图：数据模型表tag模型表将所有用户token/uid与用户的标签名称和值关联起来，形成详细的数据集，并增加平台和用户ID字段，区分转账和查找好机平台端用户。用户ID类型用于标识用户身份是注册后生成的uid还是token。同时，为了快速检索单个标签的数据，我们使用标签id作为分区来提高查询单个标签数据的效率。目前标签数据总量达到每天300亿条左右。为了减少存储和避免特殊字符，以及处理标签名称变化的问题，对标签数据存储表进行了标准化和约束。标签名称存储为英文名称，多级名称用下划线连接，同时开发了带有标签中文名称的维度表。当用户需要查询中文姓名时，使用关联的维度表进行查询。4.6用户洞察为了支持对单个用户的洞察分析，我们开发了单个用户查询标签画像和用户行为路径。单用户标签画像的思路是根据用户ID聚合所有标签明细数据，将聚合后的数据写入HbaseKV存储。设计Rowkey时，对用户uid进行字符串反转+hash(uid)运算，得到6位数字。针对HbaseRowkey查询热点问题，利用Hbase我们可以提供秒级的用户标签查询能力。同时将用户事件行为数据从Hive同步到Clickhouse，通过Clickhouse可以实现用户行为路径的查询和分析。之所以选择Clickhouse作为事件行为分析的组件，是因为Clickhouse是一个比较强大的OLAP引擎，在海量数据的场景下依然可以进行秒级响应的ad-hoc查询。下面展示了一个用户的单日时间序列行为路径。业务可以通过对路径的分析，更好地了解用户，优化运营方案。4.7用户分组计算用户分组是计算不同类型规则的标签，圈出满足一定特征和属性的用户。可以为这些用户制定运营计划。我们支持各种类型的圈子群，可以基于标签，比如20-40岁的男性用户，累计B2C支付订单为1个用户。也可以根据用户行为事件属性圈人，比如对进行商品比价行为事件的用户进行分组计算，事件属性为品牌。标签数据和行为数据都是Hive宽表，结合开发的UDF函数，支持and、or、not三种运算和多层规则嵌套计算场景。这是一个简单的示例代码：selectxidfrom(SELECTxid,'1670502093000'astag_exfromtablewherelabel_name=xxxandlabel_value=xxxunionallselectxid,'1670502131570'astag_ex,fromtablewherelabel_name=xxxandlabel_value=xxx)groupbyxidhavinggroup_c(collect_set(tag_ex),'((1664348724964)&(1664348724974))')尝试基于Clickhouse计算人群从上面用Hive计算的思路，我们先过滤掉不同标签的用户集，然后对多组用户id进行操作。那么这种操作就可以直接用位图来操作了。所以我们使用Clickhouse的BitMap特性来计算，计算效率比HiveSQL快很多。使用Clickhouse计算人群有几个步骤：在用户标签hive表中为用户ID生成一个全局唯一的mappingId。这个mappingId是一个整数。例如，如果用户设备ID为abc，则生成的mappingId为123。将用户id->mappingId映射写入HbaseKV存储。生成包含mappingId、标签名称和标签值的Hive表。使用Spark将mappingId标签表同步到Clickhouse的位图表中。人群是通过ClickhousebitMap函数计算的。简化的Clickhouse表：CREATETABLEuser_labels(label_nameString,label_valueStringuserIdsAggregateFunction(groupBitmap,UInt64))ENGINE=MergeTreePARTITIONbylabel_name,label_valueORDERBYlabel_name,label_valueClickhouse计算人口示例SQL:bitmapAnd((selectgroupBitmapping_MergeState(dt='2022-12-01'andlabel_name='XXX'andlabel_value='XXX'groupbylabel_name,label_value),(selectgroupBitmapState(abs(mapping_id))fromtablewheredt='2022-12-01'andlabel_name='XXX'andlabel_value='XXX'))使用Clickhouse计算分组时间可以达到秒级，比HiveSQL快很多，但是由于tag数据量大，已经达到百亿级，bitMap会耗时较长当分组规则配置的特别复杂，另外业务需要下载器对数据进行细化，按照我们的方案，通过Clickhouse计算后，还需要查询Hbase来查询t与mappingId关联的令牌。当数据量很大时，会出现一些性能或稳定性问题，所以Clickhouse的聚类计算还在探索中。4.8ID-MAPPING目前转转APP、找良记APP、小程序登录状态的uid和非登录状态的token是分散的，无法识别同一用户或设备，各用户标识端未连接。在收集和积累用户信息和行为信息后，为了建立更完善的标签体系，更完整的用户画像，支持更多的数据应用场景，需要关联各端ID，连接尽可能多的用户数据可能的。这提供了更全面和准确的分析。通过ID-MAPPING，建立全域下统一、标准、高精度、高时效的OneID数据模型。允许各端标识信息授权获取设备标识信息。OneID用户识别规则-场景抽象识别规则OneID模型设计表结构示例适用范围：集团全球5未来规划标签画像未来规划：支持实时标注。由于业务运营对标签输出失败的要求更高，未来我们会从业务场景出发，对一些标签进行实时标注。系统架构将支持离线和实时标签计算。离线标签架构面临更大的挑战。与智能运营规划平台无缝对接。目前标签画像和运营方案平台比较分离，产品形态也没有完全融合，用户使用不是很顺畅。未来将与运营计划平台更紧密对接，更好地助力业务。6总结以上主要针对转转用户标签画像的构建实践，主要从标签构建、标签生产加工、存储设计、用户洞察、用户分组和ID-MAPPING等几个方面阐述一些经验和思考。在实践过程中，也会遇到一些问题。未来，我们将继续优化标签画像的产品和结构，更好地助力业务。
