金融小程序活体检测：转化率提升30%的案例

编辑导语：金融小程序活体认证该如何设计？本篇文章中，作者回顾消费金融授信流程以及介绍活体认证方式，结合这些知识后根据真实案例，分析讲解了金融小程序活体认证设计的知识，推荐想要学习金融小程序活体检测的群体阅读。

消费金融的授信流程通常由身份证认证、活体认证、表单录入、银行卡认证等步骤构成。

在上一篇文章 《转化率达九成的消费金融表单设计》 里，笔者分享了消费金融表单设计的经验总结，在这篇文章里继续分享关于活体检测的经验总结。

本文会先回顾消费金融授信流程以及介绍活体认证方式，再结合真实案例，来主要输出金融小程序活体认证设计的知识。

一、消费金融授信流程

在消费金融纯线上授信流程中，身份证认证和活体认证是搭配使用的，用于验证是本人实名申请，预防不法分子盗用他人身份来发起授信。具体步骤会因每个机构在获客转化、风控能力等方面的差异而不一样。

有的产品采用了先活体、再身份证的授信申请顺序。此时，在活体这个步骤做的是无源比对，因为没有拿到用户本人的实名信息。前端会调用第三方服务获取用户的清晰照片，等用户提交授信申请后，再由后台结合身份证照片作比对。这样做可以节省调用第三方接口的成本。

有的产品则采用了先身份证、再活体的顺序。这种情况下，一般是做实时校验。如果用户提供的身份证在公安数据库中查不到，或者命中了高风险名单，或者非身份证本人申请，系统就会实时拒绝。这种做法可以提前拒掉坏客户。

有的机构发挥自己在风控、资金等方面的优势，推出了预授信模式。比如，在分期乐微信小程序中，用户只需要同意授权手机号、输入身份信息和学历，就可以得到一个额度。即时出额度对机构的风控技术实力有很高的要求。

拿乐信来说，其研发的 “米霍克风控引擎系统”已支持授信场景最快只需耗时4毫秒出结果。如果风控实力不具备，则不宜采用这种模式。

在分期乐的预授信模式下，活体认证是放在了确认借款之后。这样有个好处是，先快速地给用户一个额度，然后再通过试算、绑卡增加用户的沉没成本。等到确认借钱后，用户已经有了较强的借到钱的期望，这时就不大会因动机不足而流失了。

二、活体认证技术方案

目前，市场上主流的活体检测供应商有：T家、M家、商汤、阿里云等等。

他们提供的活体检测方案有：静默活体、双角度活体、动作活体、数字活体、炫彩活体等。相对来说，炫彩活体是安全度较高、用户体验较好的检测方式。

三、实战案例

1. 需求背景

为了开发微信生态圈里的流量，公司于2021年3月上线了借钱微信小程序。在需求分析阶段，出于有利于通过微信平台审核的考虑，产品同学当时在活体认证这一步骤用了T家的人机互动SDK。

上线经营后，通过数据分析，发现T家的人机互动SDK不好用。借钱App的活体单步转化率约为85%，而借钱小程序的该步骤转化率仅有约50%。

而且，在借钱小程序获客转化漏斗中，活体认证是授信流程的第一步。这意味着，相比后续身份证认证等步骤，活体转化率低对大盘转化造成的漏损更大。因此，很有必要提高活体转化率。

2. 业务痛点

在线上借贷场景里，用户肯定没有做活体检测的需求，用户的根本需求是以令自己满意的价格和服务借到钱。活体认证是业务方为了反欺诈、确认是本人持身份证发起授信申请而提出的需求。既然活体检测不是用户的主动诉求，就更要优化这个功能的用户体验，以增加用户完成活体的可能性。

团队通过后台数据分析以及整理客服渠道反馈，发现T家人机互动视频小程序SDK有三个问题：

（1）成功率不稳定，有时较高，有时较低，分析是技术原因导致的。

（2）前端UI开发不支持定制化开发，个别页面容易劝退用户。

（3）个别交互不友好，活体检测失败时，展示红色感叹号，容易让用户误以为授信失败了。

因此，团队希望对借钱小程序的活体认证做一个迭代优化，争取把借钱小程序的活体转化率提高到80%以上。

注：活体单步转化率 =（完成活体用户数 / 注册成功用户数）*100%

3. 方案调研

产品同学调研了同业内一些产品的活体检测接入情况，以及大家平时用得多、对其活体功能评价不错的粤省事小程序。总体而言，市场上被接入最多的两个活体供应商是T家（5个）和M家（3个）。

从T家了解到的情况是：T家的一闪活体有行业类目要求，对消费金融行业客户要求有对应的牌照才能使用，而公司是非持牌消金机构，因此不满足使用的资质要求。它的动作活体和数字活体则在用户体验方面，没有通过公司内部的评估。

从M家了解到的情况是：M家的炫彩活体SDK（类似于T家的一闪活体）受微信生态限制，不支持在微信小程序接入；不推荐使用在金融业务场景使用静默活体；视频活体和双角度活体则是没有通过公司的用户体验评估。

除了用户体验和技术稳定性外，团队还有一个顾虑是：微信在生态治理一向有着比较严的要求，如果在微信小程序接入非T家的活体服务，可能不利于通过平台的审核，希望尽量能使用T家提供的解决方案。然而，公司不具备T家活体服务对牌照的要求。

于是，调研下来的结论是：没有找到合适的活体替代方案来做迭代。这个需求由此停滞了。

4. 项目突破

尽管该需求受客观条件限制而停滞了，但公司领导一直对活体转化率一直很关注，因此，产品和商务同学被迫继续寻找迭代方案。其间，产品同学在跟M家售前伙伴交流时，反复表达了数字活体不满足公司对用户体验的要求，推动M家的伙伴同步寻找解决方案。

在停滞了两个多月后，终于在九月份，团队从M家方面获知，经过他们的努力，M家raw炫彩活体可以以webview集成的方式在微信小程序接入。产品同学马上组织了开发同事进行论证，得出具备技术可行性的结论，就紧接着推进需求分析。

5. 需求分析

在需求分析阶段，由于这是借钱系列产品第一次接入炫彩活体，不确定其转化效果，所以，产品经理制定了分层试验的方案。用户登录成功后，前端读取分流数据配置，并按照根据客户尾号设定的规则进行分流。如果客户尾号命中了T家人机互动的值范围，前端页面就跳转到T家活体发起页；否则，就跳转到M家炫彩活体发起页。

对应地，产品同学梳理了数据埋点需求，提前跟开发沟通好要做哪些埋点，以便上线后收集到期望的数据，用于横向分析参照组与实验组的数据表现。

6. 开发测试

输出产品需求文档并通过评审后，就组织前、后端同事确定排期，以及进入开发、测试阶段。

这个需求在开发阶段的三个注意点是：

（1）前后端开发协同

接入新的活体检测方案，不只是前端更改界面，需要前、后端的系统协同，端到端跑起来，才能实现业务目标。

以往有新人在做方案设计时，考虑不全，只涉及了前端的优惠券派发功能，临上线时才发现大数据平台、标签系统等后端服务暂不支持，导致需求被迫延期，等到标签系统配套可以支持后再上线。

而在做活体认证迭代这个需求时，团队吸取以前的教训，在高年级同学的指导下，低年级同学把前、后端系统交互的时序图梳理了出来，并找了开发大佬确认，确保产品方案在技术层能跑得通。

（2）前端对接webrtc新技术

这次新接入的M家raw炫彩活体是通过webrtc通信的，而借钱系列产品以前接入的活体是基于其他技术的，新技术意味前端在开发联调时可能会遇到困难。

对比，产品同学提前跟M家商务沟通，请他们预留技术资源支持借钱小程序的活体迭代。后来，前端开发遇到问题时，两边及时进行电话会议，保障了项目进度。

这件事的启发是：产品同学不仅要能基于信息收集和分析提供可以产品化的方案，也要发挥自己的沟通能力、组织能力，整合组织内外的资源，去推动需求的落地。

（3）活体数据要用于风控

在活体认证这一步骤收集到的数据是要用后续的授信审批、征信审核的，因此，要再提一个数据存入数据库的需求。这是从以前做活体认证功能的经验总结。

如果是从0到1做活体认证功能，不一定能在刚起步时就把数据入库等支撑功能考虑周全，要刻意培养端到端的流程闭环思维，或者先做出MVP，后面再持续迭代。

概括来说，产品经理要提前把业务逻辑理顺、考虑全面，后面程序员写起代码来才会更顺手。并且，产品经理要做服务型合作伙伴，在开发遇到问题时，发挥自己的沟通能力、协调能力去帮助开发解决问题，而不是只会跟开发互怼。

7. 数据分析

在数据监控设计方面，团队选取了完件总体转化率和活体单步转化率作为主指标，来评估这次功能迭代的效果。

根据从后台数据库跑取的数据，在使用T家人机互动视频小程序SDK的对比组，借钱小程序的活体转化率平均为53.62%；而在使用M家炫彩活体的实验组，活体转化率平均为82.39%，比对比组高了28.77%。

使用T家人机互动时，对比组的完件转化率平均为30.13%；而使用M家炫彩活体时，实验组的完件转化率平均为36.43%。这说明，不只提升了活体检测单个功能的数据，也提高了借钱小程序的获客转化大盘指标。

这里指出一个在做效果评估时容易犯的错误：有些产品同学在分析诊断活体转化率时，可能只观察了该环节的转化率有没有提高。这是有问题的。

每个功能都是为了达到某个大盘目标而设计的，即使用户真的按照产品设计的思路完成了流程，是否又能实现当初产品设计的总体目标呢？我们在选取评估主指标时，不能只看所迭代功能的数据，也要观察该功能迭代对总体渗透或转化数据的提升效果。

四、复盘总结

复盘这个项目，笔者认为，团队做得比较好的三个地方是：

（1）公司大佬对用户体验的坚持。产品团队一度拿了体验没那么好的读数字活体去申请需求优先级评审，但大佬们无情地毙了。于是，团队被迫继续跟供应商磨。幸运的是，在合作伙伴的支持下，找到了合适的迭代方案。

（2）把前后端以及关联系统的逻辑理顺了，使这个需求开发和测试结束后，可以上线投入使用。

（3）在设计数据监控方案时，同时关注了完件总体转化率和活体单步转化率两个指标，确保单个功能的优化对于大盘总体指标提升是有价值的。

 

本文由 @小明 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议