转转用户画像平台实践-六虎

1. 布景

转转作为二手电商买卖范畴的领军者，随着这几年的高速发展，用户数和事务量都急剧增长，为了更好的服务用户，并继续增长，产品运营的战略战术也会随之发生改变。在创业前期产品一般以粗放式运营为主，力求快速获取用户、推行产品，领跑赛道。业界也曾流传着这样的段子，产品有三宝：弹窗、浮层、加引导；运营有三宝：短信、push、加红包。然而到了中后期公司都会面临的三大问题是降本提效、继续增长、用户体会，所以依据数据的精细化运营成了咱们的必然选择，而用户画像渠道是帮助事务进行精细化运营的辅佐工具，这其中，建造灵敏、全面、高效的标签体系是工作的重中之重。本文就从标签画像体系建造的需求动身，论述转转在建造用户画像渠道进程中的考虑和实践。

2. 什么是用户画像

用户画像是指依据用户的特点、用户偏好、生活习惯、用户行为等信息而笼统出来的标签化用户模型。通俗说便是给用户打标签，而标签是经过对用户信息剖析而来的高度精粹的特征标识。经过打标签能够利用一些高度概括、容易了解的特征来描绘用户，能够让人更容易了解用户，而且能够便利核算处理。简略说，便是对用户的某个维度特征的描绘。对一群用户而言，咱们为了能让事务做的更好，就想知道他们的许多特征。比方说，我现在有个10万块钱的活动预算，那这个钱应该会集花在哪里呢？针对这个问题，咱们希望对给定的用户集体，能知道他们的商业价值，对他们的商业价值有一个很好的描绘。知道里边哪些人才是咱们重点要服务的目标, 如下图是对一个用户的洞悉，咱们经过标签的加工能够观察到一个用户的一些特征特点。

3. 标签画像的运用场景

用户特征洞悉：

辅佐用户剖析和用户洞悉，用户标签能够帮助事务人员快速的对用户有一个认知，然后发现里边明显的特征，获得一些商业创意。

增强数据剖析：

标签还能够丰厚数据的维度。对咱们的事务数据，有更深层次的对比剖析，而剖析洞悉得到的创意今后，能够辅佐事务落地。

精细化运营：

一方面，能够将用户集体，切割成更细粒度的群组，使得运营从粗放化到精细化，用多种不同的手法，不同的渠道去触达，比方说短信、推送、邮件等等，关于用户进行驱动或召回，然后到达事半功倍的效果。

4. 转转用户画像渠道的实践

4.1 体系结构图

上图介绍了用户画像渠道的体系结构图，按大的模块总共有6大模块，标签模块，人群核算模块，用户群画像剖析模块，用户运营模块，用户洞悉模块，以及权限管理模块。下面介绍一下标签画像的构建进程。

4.2 标签画像的构建准则

咱们建造用户画像渠道的意图有2个：

必须从事务场景动身，处理实践的事务问题，之所以进行用户画像要么是获取新用户，或许是提升用户体会，或许是挽回流失用户等有清晰的事务目标。
依据用户画像的信息做产品规划，必须要清楚知道用户长什么样子，有什么行为特征和特点，这样才干为用户规划产品或开展营销活动。一般常见的错误想法是画像维度的数据越多越好，画像数据越丰厚越好，费了很大的力气进行画像后，却发现只剩余了用户画像，和事务相差甚远，没有办法直接支撑事务运营，投入精力巨大但是回报微小，能够说因小失大。鉴于此，咱们的画像的维度和规划准则都是紧紧跟着事务需求去推动。

4.3 标签类型和规矩

咱们认为首先作为一个标签渠道，它需求具有十分灵敏的标签创立的才能，然后才干适应不断改变的事务需求。具体来说，咱们依据标签的场景和特征把标签分成了两个大类。

通用标签 通用标签是一些用户的根本特点。比方年纪，性别，城市，出世时代等。
事务标签 而事务标签是首要是依照转转几大事务线来分类，包括了与事务行为有关的标签，比方累计下单订单数，前史下单一级品类，B2C用户事务环节等。

为了更好的描绘和界说标签，咱们将标签分为四个层级，从上到下粒度逐步变小，而标签的界说和命名也是依照四个层级来进行，规矩为一级标签称号_二级标签称号_三级标签称号_标签值(四级标签)。

比方近30天活泼时间段这个标签，最终的界说方法是事务标签_B2C_近30天活泼时间段_12点-20点，其中12点-20点为咱们标签的一个值,也是四级标签。

依照标签的核算方法咱们把标签分为现实标签、统计标签和猜测标签。

现实标签：是经过关于原始事务数据、埋点数据进行统计剖析而来的，比方用户累计下单数，是依据用户一段时间内累计下单的数据量做的统计。

模型标签：模型标签是以现实标签为根底，经过构建现实标签与事务问题之间的模型，进行模型剖析得到。比方爱好类标签，最感爱好的品类。

猜测标签：经过算法建模猜测该用户的一些特征，比方年纪、性别、学历、婚姻等。

爱好类标签的核算进程:

猜测类标签的一般流程：

4.4 标签的出产加工

标签出产准则

标签的出产和加工要满意一下几个准则:

可扩展的标签创立规矩 咱们需求有十分灵敏可扩展的标签的规矩的界说，以满意用户事务场景改变导致的标签规矩改变。所以咱们开发了一套标签模板，每个标签的规矩能够经过装备模板来实现，模板支撑可视化装备相关的参数，支撑随时改变模板规矩，假如需求更改标签核算规矩和参数，只需求更改模板SQL即可。而且一个模板既能够被用来一个标签上，也能够复用到多个标签了，大大降低了用户创立标签的门槛，一同有利于咱们管理标签规矩。
支撑亿级用户的标签出产 在相对比较有限资源条件下，能够支撑相对比较大的用户基数的标签出产，需求对核算或许存储方面有比较高的优化，关于体系架构来说，渠道的伸缩性和这种适应性都会要求相对高一些。
标签数据按天更新 关于事务，咱们一般的标签是按天更新的，每天清晨会经过调度渠道进行标签的核算，由于标签所依靠的上游表的产出的时间不定，标签核算会依据上游事务表的产出状况来核算，标签核算模块会检测相关依靠的表。假如监控到依靠表现已核算完结，则开始核算这个标签。最终更新核算成果。

标签数据来历

转转标签核算所运用的数据首要分为2部分，一部分是事务数据，比方订单；一部分是用户行为数据，产品曝光事情。标签在创立前需求提前把相关事务数据或许埋点数据清洗好。

标签的模板的开发

咱们规划了一套标签核算SQL模板，并支撑可视化创立装备模板。创立好模板后用户不必关怀标签的底层核算规矩，只需求经过页面将相关的事务特点条件装备好就能够了。

模板类型有特点挑选模板和上传文件模板。特点挑选模板用于挑选特定特点的用户集，比方挑选男性，阅读产品次数为5次的用户。上传文件是直接将特性特点的用户集上传，用户集上传之后会放到某个hive表的一个分区下，咱们核算时用SQL取出这些用户即可。

用户特点调集运算

标签核算时会涉及到多种特点核算，比方要核算阅读产品10次且下单未付出的用户。那就需求调集运算阅读产品10次的用户集和下单未付出的用户集。每个特点模板代表的都是一个用户集，这些用户集之间的运算便是调集运算。咱们这儿支撑完好的调集运算：交、并、非，一同支撑多级嵌套。为此，咱们规划了一个简略的逻辑表达式，用来表明用户设置的逻辑。比方，咱们想要的用户集（下图蓝色部分）是买过手机或看过手机的男性，并排除掉卖家。

那这个的逻辑表达式便是：

实践运用的时分表达式中不会有中文，会用调集ID来代替（便是前面说的tag字段）。为了便利解析，每个调集都用括号包裹了起来，逻辑表达式中每个节点只能有两个子节点，或许没有子节点。

咱们需求搜集到每个用户的一切tag，这儿咱们把这个标签用到的一切模板union all 到一同，然后group by xxid，搜集到每个用户的一切tag。

咱们用UDF实现了这个逻辑表达式的履行引擎。将用户的tag列表和逻辑表达式传入UDF，就能够判断用户是不是咱们想要的用户了。履行引擎会先将逻辑表达式解析为一棵树（会缓存，避免重复解析），类似于笼统语法树，然后遍历这颗树，做解说履行。逻辑运算中有个优化便是短路运算，即做一部分运算之后就能够得到整个表达式的值，剩余部分不需求再核算。比方，“与运算”中有一个false，成果便是false，“或运算”中有一个true，成果便是true。解析得到的树如下：

经过自界说UDF函数，咱们处理了多种用户集和运算的问题，满意了用户不同事务场景不同用户特点的标签核算。

标签的创立方法

咱们运用标签SQL模板作为标签核算的基石，在创立标签时支撑4中标签类型，其中枚举标签和分组标签都运用SQL模板来实现，用户不需求了解SQL。

上传标签是能够直接上传用户的ID数据。自界说SQL满意在一些状况下用户自己写SQL来界说标签。

4.5 标签的存储规划

由于咱们的标签是依据离线数据核算的，一切标签数据集都存放在Hive中，由于离线核算一般是按天调度，所以底层表依照天作为分区来存储，每日的标签存一个分区。然后这个partition下面的数据文件为ORC文件，选用ORC文件是为了利用ORC的列式存储,节省存储空间。如下图所示：

数据模型表

标签模型表将一切的用户token/uid和用户的标签名和值相关起来，形成明细数据集，并增加渠道和用户ID字段，用来区分转转和找靓机渠道侧的用户。

用户ID类型用来标识用户身份标识是注册后生成的uid仍是设置token。一同为了快速检索单个标签的数据，咱们将标签id作为分区，提高查询单个标签数据的功率。现在每日标签全量数据达300亿左右，为了削减存储以及避免特殊字符，应对标签称号改变问题，对标签数据存储表做了规范约束，标签称号存储为英文称号，多级称号之间由下划线连接，一同开发了标签中文名的维表，当用户需求查询中文称号时，相关维表进行查询。

4.6 用户洞悉

为了支撑对单个用户的洞悉剖析，开发了查询单用户的标签画像和用户行为途径。单用户标签画像的思路将一切的标签明细数据依据用户ID聚合,聚合后的数据写入Hbase KV存储，规划Rowkey时，对用户uid做字符串反转+hash(uid)运算后取6位，来处理Hbase Rowkey查询热点的问题，运用Hbase咱们能够供给秒级的用户标签查询才能。

一同将用户事情行为数据从Hive同步到Clickhouse, 经过Clickhouse实现对用户行为途径的查询剖析。只所以选择Clickhouse作为事情行为剖析的组件，是考虑到Clickhouse的是一个比较强大的OLAP引擎，在海量数据的场景下依然能够做到秒级响应的即席查询。

下面展示的一个用户单日按时间序列的行为途径，事务经过对途径的剖析能够帮助更好的了解用户，更好的优化运营方案。

4.7 用户分群核算

用户分群是将不同类型规矩的标签进行运算，圈出符合某些特征特点的用户，能够针对这部分用户来做运营方案。咱们支撑多种类型圈群，能够依据标签圈人，比方年纪为20-40岁的男性用户且累计B2C付出订单为1单的用户。也能够依据用户行为事情特点来圈人，比方对进行产品比价行为事情且事情特点为品牌的用户进行分群核算。标签数据和行为数据都是Hive宽表，结合开发的UDF函数，支撑且、或、非三种运算和多层规矩嵌套核算场景。下面是简略的示例代码：

    select
    xid
from
    (
        SELECT
            xid,
            '1670502093000' as tag_ex
        from
            table
        where
            label_name = xxx
            and label_value = xxx
        union
        all
        select
            xid,
            '1670502131570' as tag_ex,
        from
            table
        where
            label_name = xxx
            and label_value = xxx
    )
group by
    xid
having
    group_c (
        collect_set(tag_ex),
        '((1664348724964)&(1664348724974))'
    )

依据Clickhouse的人群核算测验

从上面用Hive核算的思路来看，咱们是先挑选出来不同标签的用户调集，再进行多个调集的用户id的运算。那这种运算刚好能够运用bitmap来运算。所以咱们借助于Clickhouse的BitMap特性来核算，核算功率要比HiveSQL快许多。运用Clickhouse核算人群分几个过程：

将用户标签hive表中的用户id都生成一个大局唯一的mappingId,这个mappingId是整数，比方用户设备id为abc, 生成一个123的mappingId。
将用户id->mappingId映射写入Hbase KV 存储。
生成一张包括mappingId,标签称号，标签值的Hive表。
运用Spark将mappingId标签表同步到Clickhouse的bitmap表。
经过Clickhouse bitMap函数来核算人群。

简化后的Clickhouse表:

CREATE TABLE user_labels
(
    label_name String,
    label_value String 
    userIds AggregateFunction(groupBitmap, UInt64)
)
ENGINE = MergeTree
PARTITION by label_name,label_value
ORDER BY label_name,label_value

Clickhouse核算人群示例SQL:

bitmapAnd (
    (
        select
            groupBitmapMergeState(mapping_id)
        from
            table
        where
            dt = '2022-12-01'
            and label_name = 'XXX'
            and label_value = 'XXX'
        group by
            label_name,
            label_value
    ),
    (
        select
            groupBitmapState(abs(mapping_id))
        from
           table
        where
            dt = '2022-12-01'
            and label_name = 'XXX'
            and label_value = 'XXX'
    )
)

运用Clickhouse核算分群的时间能够到达秒级，比HiveSQL要快许多。但由于咱们的标签数据量很大，现在已到达百亿等级，当分群规矩装备的特别复杂时，bitMap也会耗时较长，再加上事务需求下载人去明细数据，依照咱们的方案，经过Clickhouse核算后还需求查询Hbase把mappingId相关的token查询出来，当数据量很大的时分会有一些功能或安稳性问题，所以现在针关于Clickhouse的分群核算还在探究中。

4.8 ID-MAPPING

当前转转APP、找靓机APP和小程序登录状况的uid和未登录状况的token是散乱的，无法辨认同一个用户或设备，各端用户标识并没有打通。在搜集和堆集用户信息与行为信息之后，为了树立更完善的标签体系、更完好的用户画像、支撑更多的数据运用场景，要将各端的ID 相关起来，尽可能地将用户的数据打通，然后供给更加全面精确的剖析。经过ID-MAPPING咱们树立全域下的统一的、规范的、高精确率、高时效性的OneID数据模型。

各端标识信息,在授权的状况下允许获取到的设备标识信息。

OneID用户辨认规矩-场景笼统

辨认规矩

OneID模型规划

表结构示例效果域：集团全域

5 未来规划

对标签画像未来的规划：

支撑实时标签。随着事务运营对标签的产出失效有更高的要求，未来咱们会以事务场景动身，对部分标签进行实时打标，体系架构会一同支撑离线和实时标签的核算，这对咱们现在的纯离线标签架构有更大的挑战。
和智能运营方案渠道无缝打通。现在标签画像和运营方案渠道是相对分裂的，在产品形态上并没有完全的交融，用户运用起来也不是很顺畅，未来会更加严密的跟运营方案渠道打通，更好的助力事务。

6 总结

以上首要是针对转转用户标签画像的建造实践，首要从标签的构建，标签的出产加工，存储规划，用户洞悉，用户分群以及ID-MAPPING等几个方面论述了一些经历和考虑。在实践的进程中也会遇到一些问题，未来会继续优化标签画像产品和架构，为事务更好的助力。

转转研制中心及业界小伙伴们的技能学习沟通渠道，定期共享一线的实战经历及业界前沿的技能论题。关注大众号「转转技能」（综合性）、「大转转FE」（专心于FE）、「转转QA」（专心于QA），更多干货实践，欢迎沟通共享~

转转用户画像平台实践