身份证|金融小程序活体检测：转化率提升30%的案例( 三 )

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