用户画像在风控实战中的应用

在日常的风控实战中，经常会有业务部门的同学提问：

• 业务中的黑产用户 / 羊毛用户是谁？他们长什么样子？
• 他们是怎么进来的？进来之后又去了哪里？
• 风控会不会误拦？误拦之后的客诉怎么去处理？
• ……

围绕这些实战问题，我们需要借助【用户画像】这个产品，来做详细的解释。

一、画像包括哪些内容

网上其实对这个问题做了很多的介绍，只不过大家使用的场景不同，所以对于画像的定义和使用方法也不尽相同。

简单来说：画像就是一个人的wiki百科，在这个百科中，介绍了用户的来历、身份介绍、做了什么事情、在某些业务场景下的成就或者比较“有名”的事情。

只不过，繁杂的文字，对于平台或者运营而言，阅读和理解成本过高，所以又在该百科基础上，做了标签的提炼，因此出现了用户标签体系。目前市面上看到的用户画像，其实大部分是用户标签库。

用户标签库的构建程度，代表着平台对用户的认知程度。

风控场景下，平台往往会通过以下几个维度来建设：

1. 基础维度

这个维度比较大，包括用户的身份子维度、设备子维度、支付子维度、手机号子维度等，在这些子维度下去构建标签；

• 身份子维度：年龄、性别、地区、姓名、实名记录、扩散关联等；
• 支付子维度：渠道、支付方式、扩散关联等；
• 手机号子维度：是否小号、是否接码号、是否二次放号、风险等级、扩散关联等；
• 设备子维度：虚拟设备、设备root、设备篡改、常用设备等。

扩散关联，一般是指以该维度为主体，基于关系图谱，查看该主体的周边关联度数，比如关联设备数、关联账号数、关联支付账号数、关联订单数等。

2. 行为维度

主要基于用户在APP中的埋点数据和请求数据，来制定用户的行为轨迹，并基于行为轨迹，提炼用户的风险标签。

• 切换频次：近N天设备切换频次、近N天IP切换频次（geoHash、POI）、近N天时速异常切换等；
• 数据缺失：完整路径缺失率、请求参数缺失率、关联因子异常（例如UA、IP、设备信息等）；
• APP速度：近N天机器行为（频次和时间间隔接近）、近N天用户CV时间过短等；
• ……

3. 订单维度

主要跟交易相关，重点查看交易链路上的维度标签：

• 占库存：下单率、完单率、SKU商品等；
• 羊毛下单：打折（低价）商品的占比、平台贡献度（带来的收入 – 支出）等；
• 联合刷单：同一商家的占比、低价商品的占比等；
• 虚假交易：收货地址的真实性、地址中带有特殊编号的占比、无完整或实际轨迹的占比、接单完单时效过快的占比等。

4. 资金维度

主要在提现环节，大部分的平台基本在提现环节做了同人认证，即资金只能进入账号本人账户。因此这里主要做监控为主，监控短期内资金规模、大额资金的占比、提现账号的数量等。

二、画像解决了什么问题

画像的构建是否成功，是否满足业务场景的诉求，需要在实际应用中提现出来。这里从三个方向来验证画像：

1. 策略规则的生命管理

风险运营同学对风险的感知和作案方式的还原，风险策略同学对风险用户群体的定位和特征的提炼，线上部署了相应的攻防策略规则。

但所谓“道高一尺魔高一丈”，黑产的攻击手法不断的变换，原有的策略规则会进入相应的“失效期”。而感知到这一变化，可借助画像的标签内容进行水位的统计展示，以此来快速感知到。

例如：恶意占库存场景，可以查看下单率超过一定阈值用户的占比，与之前的正常占比进行比较，来感知到规则是否正在失效。

2. 单用户的风险下探

集中在客诉场景，C端用户被拦截后发起客诉，运营同学需要对风控拦截做出相应的解释，即对拦截的规则进行解释。

注意，上面讲到风控画像主要是标签库，规则依赖标签库，如果仍然是以标签库进行解释，那么意味着规则必须100%准确，太难了。

所以，在画像中，仍然需要构建风险的下探链路。构建的思路是基于用户实际发生的业务数据、行为数据、订单数据，进行反向的验证。

例如：切换设备频次过高和时速异常被拦截，那么在画像中则以详细列表的方式展示用户近N天的登录记录（因为切设备就要重新登录），在登录记录中列出设备的IMEI、设备指纹、经纬度、和登录时间，以这些数据来帮助运营进行定性。

因此，画像要支持用户风险标签的提炼，同时还要支持对于这些标签的解释。

3. 用户群组的挖掘

风险的攻防，不是单一用户的攻防，而是群体的攻防和管控，而群体中的用户表现，往往是具有相似度的。

画像是单一用户的标签集，此时可通过标签集的相似度对相似用户进行挖掘。

当然，必须承认，准确率不高，比如：下单率低，很多小姐姐只看不买，太正常了。因此往往是多个维度相加来做相似度挖掘。同时再借助关系图谱，将用户之间的强关联属性提炼出来，一个简单的群组就产生了。

而此时用户的标签，则会上升到群组，形成群组的标签，群组画像。

三、构建画像中的难点

1. 标签的实时性

画像中的标签，多则几千个，少则也有几百个，如果全部要求实时或者离线，前者造成计算资源的浪费，后者造成线上风险的漏过。

在这里，则采取一个原则来进行分类：标签的增益，即该标签在风险中的影响力 + 标签本身的动态性。

标签本身的动态性：一般是指标签的更新频率，例如身份信息，基本是不会变的；用户近30分钟的切换设备数量，这种是30分钟要重新统计的。

标签在风险中的影响力：举个例子，30分钟内用户切换设备超过3个，这个不能定义为用户有风险；30分钟内用户切换了虚拟设备超过3个，这个可以认定为用户有风险。因此前者的实时性要求不高，但后者就要求实时。

因此，在实战中，跟风控规则强关联的，往往是实时性要求高的。

2. 标签的完整度

是否所有的用户，标签体系都要建设成一样的，比如活跃用户和刚注册的新户是否一样？

这里，需要借助一个分类思想：业务场景 – 用户角色 – 用户价值 – 用户风险度，将此定义为一个空间，每往下走一级，则建设的标签内容就不一样。这个方式，有助于后续不断枚举并迭代补充遗漏的信息维度。

3. 标签的区分度

实际上，不是每个标签都会被用到，也不是每个标签都能代表用户，也就是无效标签。往往建设一个标签，用该标签对用户进行分层，无论是阈值多少，发现动不动就是80%+的用户被圈在一起，这就代表该标签是无效的。

这里有一个小的检验方式，即通过该标签 + 风险阈值，将用户进行白户、黑户、灰户的分层，如果其实现的比例接近1:8:1，则代表该标签具有一定的区分度。

当然，像年龄、城市、性别这些基础中的基础标签，是不能使用这种方式的。

四、总结

其实，用户画像实际上不只有一种，上面的观点论述，更多还是在账号维度出发，给到大家的更多是一个方法论的介绍。在实战中，还有设备画像、IP画像、手机号画像、订单画像等多种风险画像。

画像这个产品，从早期的满足业务需求下进行创建标签，到庞大标签库下的创建变量，未来的方向希望是能够自出创造标签给到业务方使用。

而在创造标签这个方向上，对于风控团队而言，除了需要加强自身的风险挖掘能力之外，还需要工程侧提供一套标准的、快捷的验证标签的产品流程，后续将会为大家介绍下这套流程的构建方式。

本文作者 @话多的熊仔 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！