UGC信息審核——如何降低審核延時

8 評論 8935 瀏覽 100 收藏 10 分鐘

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

18 年畢業,從畢業至今一直從事產品工作,工作的一部分一直和風控相關,只是不全是風控,以及不同時間段工作重點不同,做過包括直播風控、登錄注冊風控、審核體系搭建、生態治理、內容治理、內容安全、反作弊、風控中臺等工作。

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

一方面作為自己總結經驗,以后更熟悉的運用。另一方面可以為行業做一些貢獻,畢竟,風控行業容易涉及公司機密、邏輯太隱藏,比較難能從公開資料學習到直接可用的經驗。

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

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

一、審核

非相關專業的人不一定很清楚,對于一個成熟產品,我們在網上創建的任何 UGC 信息都會被審核,包括頭像昵稱、簽名,微信發布音頻/視頻/文件/圖片/文本,微博、小紅書發布動態,B 站發布視頻等都無一例外。

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

二、目標:審核速度滿意度

我們團隊有一個體驗型的指標,審核速度滿意度,即用戶對所發布內容被審核時間長短的滿意度,這個指標會影響生產者生產體驗,進而影響他們留存。

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

三、用戶不感覺到慢(感官)

我們產品原來在用戶發布的內容上有一個狀態,用戶能看到自己的內容處于「審核中」,所以會覺得慢。權衡利弊后,將審核狀態去掉,讓用戶對審核無感知。

注:不一定所有都適合去掉,得根據自己業務決定,例如我前司,是設計師上傳自己的作品,然后被審核,這個就不適合去掉審核狀態。

四、縮短審核延時(絕對值)

在去掉審核狀態后,開始縮短審核延時絕對值,但也并不一定是需要針對所有用戶統一縮短。

1. 降低部分用戶延時

可以優先降低有被快速被審核需求的人的延時。

我們產品雖然不直接展示審核狀態,但未經審核的內容依然不支持分享,用戶在分享時依然會提示,當前作品正在審核中。所以可知,無分享需求的人對審核是無感知的,需要分享的人才知道審核的存在。

注:此為考慮安全原因,若未經審核的內容被分享出去,依然可能出現安全問題。

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

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

所以,我們可以針對不同渠道來源、不同等級、不同信用分、不同標簽等調整審核優先級。

例如,有分享需求的用戶,高優先級審核(具體判斷有分享需求的用戶,可根據自己產品來判斷,這涉及具體邏輯,不適合展開寫了)。

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

2. 降低全體用戶延時

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

1)基于數據分析發現當前延時的主要原因

——例如出現生產波峰,導致審核出現積壓,則可調整人力安排。

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

——例如細化機審策略、優化機審的算法模型,提升召回率、準確率,進而提升機審直接處理率,減少推到人審量級。

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

2)設置兜底策略

當延時≥一定值之后,則由先審后發流程,變為機審風險較小但又推到人審的改為先發后審流程。避免一些系統或人為原因,影響線上用戶。

注:這需先評估對于你們平臺先發后審的風險是否可接受。

3)設置對相關指標的監控

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

五、對滿意度提升效果

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

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

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

本文由 @Aaron 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 好奇,你們的滿意度指標是怎么獲取的,看nps數據嗎

    來自湖北 回復
  2. 大佬看到 也可以加個微信聊聊哈!18600809134

    來自上海 回復
  3. 我這遇到一個問題:審核員每天都搶一些低?;蛞恍┖唵魏脤彽年犃袑徍?,一些高位隊列總是放到最后湊量,容易造成積壓。針對上面問題最近在思考派單模式,類似打車或者外賣的派單邏輯,就是審核隊列待審內容按照隊列優先級和積壓情況進行混排,審核人員進入審核頁面按照以上隊列優先級領取待審內容,無法自己指定隊列審核。 以上問題想請教下大佬,你這邊有什么可以借鑒的經驗或解決思路嗎。感謝了~~~

    來自上海 回復
    1. 自動派單,根據待審任務的剩余審核時間做動態排序;可惜我們的研發說計算量太大,暫時沒做…

      來自北京 回復
    2. 嗯嗯 響應時間做為一個策略權重項了,整體多個通道打亂排序,附加一些權重策略,先進先出,高權重優先分發

      來自上海 回復
    3. 研發不給力的話可以讓審核組長或者管理人員給每個列表根據以往case 平均審核時長及難易程度配置權重,分配審核員每日專列表審核,輪流進行。靈活配置如臨時病假等。管理人員實時監控業務池積壓和延遲,突然出現某列表爆量,動態分配審核員。月底根據每列表審核量×權重計算最終審核量核算績效。

      來自天津 回復
  4. 我有幾個違規收審核的問題咨詢,但是不太方便直接在評論中文,是否可以加好友溝通下v:hdd5664

    來自湖北 回復
  5. 人力崗投入成本大,在細節上更需要一些奇思妙想。提升用戶體驗重中之重,用的好滿意度高產品知名度也會隨之上升。

    來自山西 回復