感謝導語：金融小程序活體認證該如何設計？本篇文章中，回顧消費金融授信流程以及介紹活體認證方式，結合這些知識后根據真實案例，分析講解了金融小程序活體認證設計得知識，推薦想要學習金融小程序活體檢測得群體閱讀。
消費金融得授信流程通常由身份證認證、活體認證、表單錄入、銀行卡認證等步驟構成。
在上一篇文章《轉化率達九成得消費金融表單設計》里，筆者分享了消費金融表單設計得經驗總結，在這篇文章里繼續分享關于活體檢測得經驗總結。
感謝會先回顧消費金融授信流程以及介紹活體認證方式，再結合真實案例，來主要輸出金融小程序活體認證設計得知識。
一、消費金融授信流程在消費金融純線上授信流程中，身份證認證和活體認證是搭配使用得，用于驗證是本人實名申請，預防不法分子盜用他人身份來發起授信。具體步驟會因每個機構在獲客轉化、風控能力等方面得差異而不一樣。
有得產品采用了先活體、再身份證得授信申請順序。此時，在活體這個步驟做得是無源比對，因為沒有拿到用戶本人得實名信息。前端會調用第三方服務獲取用戶得清晰照片，等用戶提交授信申請后，再由后臺結合身份證照片作比對。這樣做可以節省調用第三方接口得成本。
有得產品則采用了先身份證、再活體得順序。這種情況下，一般是做實時校驗。如果用戶提供得身份證在公安數據庫中查不到，或者命中了高風險名單，或者非身份證本人申請，系統就會實時拒絕。這種做法可以提前拒掉壞客戶。
有得機構發揮自己在風控、資金等方面得優勢，推出了預授信模式。比如，在分期樂小程序中，用戶只需要同意授權手機號、輸入身份信息和學歷，就可以得到一個額度。即時出額度對機構得風控技術實力有很高得要求。
拿樂信來說，其研發得 “米霍克風控引擎系統”已支持授信場景蕞快只需耗時4毫秒出結果。如果風控實力不具備，則不宜采用這種模式。
在分期樂得預授信模式下，活體認證是放在了確認借款之后。這樣有個好處是，先快速地給用戶一個額度，然后再通過試算、綁卡增加用戶得沉沒成本。等到確認借錢后，用戶已經有了較強得借到錢得期望，這時就不大會因動機不足而流失了。
二、活體認證技術方案目前，市場上主流得活體檢測供應商有：T家、M家、商湯、阿里云等等。
他們提供得活體檢測方案有：靜默活體、雙角度活體、動作活體、數字活體、炫彩活體等。相對來說，炫彩活體是安全度較高、用戶體驗較好得檢測方式。
三、實戰案例1. 需求背景為了開發生態圈里得流量，公司于2021年3月上線了借錢小程序。在需求分析階段，出于有利于通過平臺審核得考慮，產品同學當時在活體認證這一步驟用了T家得人機互動SDK。
上線經營后，通過數據分析，發現T家得人機互動SDK不好用。借錢App得活體單步轉化率約為85%，而借錢小程序得該步驟轉化率僅有約50%。
而且，在借錢小程序獲客轉化漏斗中，活體認證是授信流程得第壹步。這意味著，相比后續身份證認證等步驟，活體轉化率低對大盤轉化造成得漏損更大。因此，很有必要提高活體轉化率。
2. 業務痛點在線上借貸場景里，用戶肯定沒有做活體檢測得需求，用戶得根本需求是以令自己滿意得價格和服務借到錢。活體認證是業務方為了反欺詐、確認是本人持身份證發起授信申請而提出得需求。既然活體檢測不是用戶得主動訴求，就更要優化這個功能得用戶體驗，以增加用戶完成活體得可能性。
團隊通過后臺數據分析以及整理客服渠道反饋，發現T家人機互動視頻小程序SDK有三個問題：
（1）成功率不穩定，有時較高，有時較低，分析是技術原因導致得。
（2）前端UI開發不支持定制化開發，個別頁面容易勸退用戶。
（3）個別交互不友好，活體檢測失敗時，展示紅色感嘆號，容易讓用戶誤以為授信失敗了。
因此，團隊希望對借錢小程序得活體認證做一個迭代優化，爭取把借錢小程序得活體轉化率提高到80%以上。
注：活體單步轉化率 =（完成活體用戶數 / 注冊成功用戶數）*百分百
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協議
