對于一個成熟產(chǎn)品，我們在網(wǎng)上創(chuàng)建的任何UGC信息都會被審核，只是審核的方式各不相同，對審核速度的感知也不一樣。本文對“降低審核延時”方面的內(nèi)容進行了分析，一起來看一下吧。

18 年畢業(yè)，從畢業(yè)至今一直從事產(chǎn)品工作，工作的一部分一直和風(fēng)控相關(guān)，只是不全是風(fēng)控，以及不同時間段工作重點不同，做過包括直播風(fēng)控、登錄注冊風(fēng)控、審核體系搭建、生態(tài)治理、內(nèi)容治理、內(nèi)容安全、反作弊、風(fēng)控中臺等工作。

想結(jié)合著自己做過的、用過的、見過的、搜集資料研究過的總結(jié)成經(jīng)驗，在不泄露公司機密的前提下，盡量詳細(xì)的寫成系列文章。不只是復(fù)盤概念和框架，可能會是些具體的策略和直接可用的經(jīng)驗。

一方面作為自己總結(jié)經(jīng)驗，以后更熟悉的運用。另一方面可以為行業(yè)做一些貢獻，畢竟，風(fēng)控行業(yè)容易涉及公司機密、邏輯太隱藏，比較難能從公開資料學(xué)習(xí)到直接可用的經(jīng)驗。

打算先圍繞曾經(jīng)的 OKR 展開，即我做過的事項展開來寫，先以各個小點切入，然后再放入整個風(fēng)控框架中去，最終會形成下圖的框架（未完全按風(fēng)控架構(gòu)的邏輯梳理）。

今天先聊一個問題，降低審核延時。

一、審核

非相關(guān)專業(yè)的人不一定很清楚，對于一個成熟產(chǎn)品，我們在網(wǎng)上創(chuàng)建的任何 UGC 信息都會被審核，包括頭像昵稱、簽名，微信發(fā)布音頻/視頻/文件/圖片/文本，微博、小紅書發(fā)布動態(tài)，B 站發(fā)布視頻等都無一例外。

只是由于機審/人審、先發(fā)后審/先審后發(fā)、隱性處罰/降低分發(fā)等導(dǎo)致我們不知道自己被審核了。

二、目標(biāo)：審核速度滿意度

我們團隊有一個體驗型的指標(biāo)，審核速度滿意度，即用戶對所發(fā)布內(nèi)容被審核時間長短的滿意度，這個指標(biāo)會影響生產(chǎn)者生產(chǎn)體驗，進而影響他們留存。

一些人拿到這個指標(biāo)可能就開始著手思考怎么降低審核延時了，但這是一個主觀性的指標(biāo)，最主要的是讓用戶感覺很快，而不只是在絕對值上做到真的很快。

三、用戶不感覺到慢（感官）

我們產(chǎn)品原來在用戶發(fā)布的內(nèi)容上有一個狀態(tài)，用戶能看到自己的內(nèi)容處于「審核中」，所以會覺得慢。權(quán)衡利弊后，將審核狀態(tài)去掉，讓用戶對審核無感知。

注：不一定所有都適合去掉，得根據(jù)自己業(yè)務(wù)決定，例如我前司，是設(shè)計師上傳自己的作品，然后被審核，這個就不適合去掉審核狀態(tài)。

四、縮短審核延時（絕對值）

在去掉審核狀態(tài)后，開始縮短審核延時絕對值，但也并不一定是需要針對所有用戶統(tǒng)一縮短。

1. 降低部分用戶延時

可以優(yōu)先降低有被快速被審核需求的人的延時。

我們產(chǎn)品雖然不直接展示審核狀態(tài)，但未經(jīng)審核的內(nèi)容依然不支持分享，用戶在分享時依然會提示，當(dāng)前作品正在審核中。所以可知，無分享需求的人對審核是無感知的，需要分享的人才知道審核的存在。

注：此為考慮安全原因，若未經(jīng)審核的內(nèi)容被分享出去，依然可能出現(xiàn)安全問題。

例如某紅書就存在這個風(fēng)險點，不管發(fā)布的任何東西，發(fā)布成功即可立即分享（未過機審，且和賬號無關(guān)，我用新注冊的賬號發(fā)布確定違規(guī)的文本+違規(guī)圖片測試過），可查看小圖、部分文本，此時存在風(fēng)險的內(nèi)容已經(jīng)被傳播出去（讀者朋友可以自行測試，但溫馨提示，紅線類內(nèi)容不可隨意亂試）。

但不知道他們是否是為了便于用戶分享，是在考慮了風(fēng)險和收益后，接受這種低概率風(fēng)險存在的。下圖內(nèi)容還處于審核中，但可分享至微信，依然可看到部分文字和圖片。

所以，我們可以針對不同渠道來源、不同等級、不同信用分、不同標(biāo)簽等調(diào)整審核優(yōu)先級。

例如，有分享需求的用戶，高優(yōu)先級審核（具體判斷有分享需求的用戶，可根據(jù)自己產(chǎn)品來判斷，這涉及具體邏輯，不適合展開寫了）。

例如，無延時需求的內(nèi)容，低優(yōu)先級審核，如運營賬號發(fā)布的內(nèi)容（即使是公司內(nèi)部員工，不同人對風(fēng)險的把控、專業(yè)度也是不一樣的，即使是運營人員發(fā)布，也有可能會觸及風(fēng)險點，也需要被審核）。

2. 降低全體用戶延時

對于我們，延時長和短，只是相差了大約 10min。對平臺分發(fā)幾乎無影響，對用戶消費幾乎無影響，對審核無感知的用戶也無影響。所以解決其他全體用戶的延時已經(jīng)相對沒那么重要了，這里可簡單提下我們用過的一些策略，對于其他產(chǎn)品可能有幫助。

1）基于數(shù)據(jù)分析發(fā)現(xiàn)當(dāng)前延時的主要原因

——例如出現(xiàn)生產(chǎn)波峰，導(dǎo)致審核出現(xiàn)積壓，則可調(diào)整人力安排。

——例如審核人員在審核列表上看了上百條后，才操作一次通過，導(dǎo)致大量內(nèi)容已經(jīng)被審核人員判斷為通過，只是還未在界面上操作，導(dǎo)致內(nèi)容一直處于審核中，則結(jié)合審核效率和審核延時綜合考慮，將頁面展示內(nèi)容縮小到一定值。

——例如細(xì)化機審策略、優(yōu)化機審的算法模型，提升召回率、準(zhǔn)確率，進而提升機審直接處理率，減少推到人審量級。

——例如待審列表中還包含用戶已刪除內(nèi)容，則將已刪除內(nèi)容從待審列表中踢出（用戶發(fā)布成功立馬刪除，所以也不必要再審核）。

2）設(shè)置兜底策略

當(dāng)延時≥一定值之后，則由先審后發(fā)流程，變?yōu)闄C審風(fēng)險較小但又推到人審的改為先發(fā)后審流程。避免一些系統(tǒng)或人為原因，影響線上用戶。

注：這需先評估對于你們平臺先發(fā)后審的風(fēng)險是否可接受。

3）設(shè)置對相關(guān)指標(biāo)的監(jiān)控

當(dāng)延時≥一定值的待審量也≥一定值之后，可預(yù)警，郵件/短信或其他方式通知到審核管理，排查是否哪里出了問題。

五、對滿意度提升效果

上面的這些策略大致從前到后，帶來的滿意度提升效果也是從強到弱。

還有很多細(xì)節(jié)、策略，以及如何思考的想詳細(xì)寫，但容易違反公司機密，還是不展開寫了。

最后，大家有啥關(guān)心的話題可在評論中提出，對于我知道的，且不泄露公司機密的前提下，盡量托盤而出。