作者：閒魚技術-莫癲
1. 業務背景
閒魚直播業務上線後面臨的最大問題是增長問題。閒魚BI同學分析發現，對比短時觀看和長時觀看人群，發現兩部分人群有較明顯的興趣階段性差異。
業務希望在理解直播、主播和用戶的基礎根據興趣對頭部優質直播精準投放, 放大頭部主播馬太效應實現直播轉化和觀看時間的增長。
2. 目標
簡單概括需要達成兩個結果：
- 在三週內實現精準投放平臺，沉澱基礎運營平臺的基礎設施；
- 業務上保證頭部直播間場均轉化uv達成一定目標，轉換率得到明顯提升；
那麼單純藉助算法模型實現優質直播推薦，是否也可以達成業務上的目標？然後現實卻是，巧婦難為無米之炊。 直播上線時間短, 播放和觀看場次有限, 使得模型的訓練沒有足夠的樣本直接去理解用戶對直播的興趣, 平臺也未對主播直播內容做強控實現內容的結構化。那麼就需要將運營對直播領域經驗與BI分析、算法結合， 在理解用戶、直播和直播間的基礎上，實現對直播間到興趣人群的投放，並沉澱平臺化能力。
3. 實現方案
給興趣人群投放實時直播間的第一步是要實現對人的理解，包括C端用戶以及主播的理解，其次是直播的理解。理解的結果最終會以興趣人群、主播人群的方式與頁面資源位關聯，形成人（用戶）貨（直播）場（資源位）的初步匹配。
用戶的理解依賴於用戶的特徵數據，包括閒魚用戶基礎特徵，搜索、瀏覽、發佈、交易等商品相關行為記錄，互動行為特徵和用戶興趣標籤特徵等。這些特徵對實時性要求不高，大部分特徵通過離線計算產出，後續通過離線計算方式對不同數據來源的特徵歸一化。
用戶所有特徵會同步到人群圈選平臺，通過交併差的方式實現人群圈選，進行人群預覽和導出。
平臺整體設計
圈選的人群數據是以userId和人群Id的映射表方式保存離線，與投放的配置進行聯合後得到<用戶, 資源位, 主播>的關聯關係，而後關係數據會同步到圖數據庫Igraph，提供給算法在線推薦時查詢關聯直播實現按興趣推薦和曝光。受限的是整體的曝光流量有額度的，算法會基於模型，在有限PV額度內對在線直播間實現較優的選擇。
下面詳細闡述是怎麼實現用戶理解和直播間投放的。
用戶理解
對用戶理解的常規特徵生產不是個難事, 而用戶的興趣標籤需要針對閒魚用戶從零開始, 彌補這方面能力的缺失。 興趣標籤主要是通過分析用戶歷史行為產生的行為文本，找出其與領域標籤涉及到詞組的關聯性。 包含如圖商品和帖子的各類行為文本，目前數據在逐漸補充中。
運營會整理不同領域的關鍵詞詞組作為輸入, 匹配到關聯度高的用戶關聯上領域標籤特徵。 要實現興趣標籤的產出, 要解決三個問題: 存儲、檢索和相關度計算。 
興趣標籤產出（方案一）
如圖方案一是最初設想方案, 整體流程如下:
- 關鍵詞結構化: BI同學完成行為文本明細的處理, 包括數據源歸一、去重和UDF處理分詞, 並根據關鍵詞頻次和預設權重算分。 輸出結構化後的用戶行為文本明細, 包括用戶ID、實體ID、關鍵詞列表和關鍵詞對應的分值列表；
- 打標規則DSL化：對運營輸入的行業興趣關鍵詞組進行分詞後轉成數據庫可執行的DSL；
- 興趣用戶DUMP: 執行DSL檢索出與輸入關鍵詞匹配的結構化行為文本, 進行用戶去重, 完成用戶興趣標籤關聯；
- 人群圈選: 基於用戶興趣標籤和其它特徵數據做交併差後導出最終人群, 該步驟是在二方人群圈選平臺進行；
整個方案是可行的, 而且具備很好的靈活性, 離線部分可不斷完善和豐富結構化行為文本, 工程測專注於DSL可視化優化和整個數據流的流轉提效, 整個平臺可以良性迭代進化。 但是該方案確難以實行, 主要存在以下問題:
- 能給的工期短, 要求2到3周完成所有鏈路功能上線並支撐業務驗證, 實現該方案是幾乎不可能的；
- 存儲成本巨大, 測算大概需要30PB的在線存儲資源, 這對於一個未驗證價值的業務來數也是不可能申請到的；
有同學也許很快發現, 從文本結構化到檢索特定興趣用戶的過程不就是一個可以用搜索引擎實現的業務場景嗎？ 最大的問題仍然是預算問題, 搭建搜索引擎也是個不小的成本，而且從搜索引擎dump大量數據存在著嚴重的性能問題，同時也無法支持BI同學在整個流程中進行優化。 
搜索引擎基本流程
在線方案是比較理想的, 可以實現運營利用自己的行業經驗自助完成興趣標籤關聯和人群圈選。由於上述客觀條件限制, 最終我們選擇了離線關聯用戶和興趣標籤的方式, 快速接入部分興趣標籤, 而後逐步推進在線方案的方式。 這裡得益於BI同學全面的能力, 完成了“離線搜索引擎”, 以及未雨綢繆沉澱了部分用戶興趣標籤。 這樣整體方案就是這樣的：
- 離線處理非結構化文本，通過去重、分詞和算法得到結構化文本（該步驟與方案一相同）；
- 整理領域標籤關聯的關鍵詞詞組
- 離線計算方式檢索匹配關鍵詞詞組的用戶
方案二的最大弊端就是通用性沒方案一高，每個興趣標籤的產出需要BI開發，只能滿足T+1的實時性。但也一些優點，離線存儲成本低，離線計算可支持自定義複雜UDF。離線部分更詳細的介紹可以參考數據團隊的興趣標籤體系實現介紹。
興趣標籤產出（方案二）
投放實現
投放分為離線和在線兩部分, 運營維護的投放配置存儲在RDB (關係型數據庫), 需要同步到數據倉庫, 離線計算完成用戶與興趣主播關係關聯, 形成<用戶,興趣主播列表>關係。 關聯的數據同步到在線圖關係數據庫, 提供算法在興趣主播中推薦。 整個數據鏈路需要自動流轉, 儘可能及時:
- 在線配置無法做到實時同步到離線, 目前每一個小時調度一次, 達到準時時要求；
- 離線任務之間通過依賴任務驅動, 基本能滿足準實時行要求，並每次全量更新“用戶主播興趣關係”新增新分區，同時增加與新分區時間一致的done分區；
- 離線數據同步到在線圖數據庫是基於數據交換組件, 會定時檢查離線表done分區, 有新done分區則會通過同步消息機制進行對應相同時間分區的全量數據更新；
4. 首頁效果
在三週不到的時間，完整鏈路的平臺實現並上線，運營人群圈選、投放配置可在分鐘級內完成上線。
對部分領域的頭部直播在首頁進行試投放後，效果明顯：
- 所有頭部直播間，UV點擊數遠超目標；
- 對比大盤，試投放大部分領域PV和UV的點擊轉化率得到顯著提升，最高達到倍數提升；
5. 展望
整個項目由於時間比較短, 實現的是興趣直播投放功能的最小集合, 以支持快速驗證並得到較好反饋和結果。在此雛形上，未來會逐漸完善和豐富其能力：
- 在對接BI興趣標籤的基礎上, 需要不斷豐富對接興趣標籤等各維度的特徵數據能力，同時支持運營同學自助產出通用興趣標籤以及其它特徵；
- 豐富對資源位的投放能力支持，並具備多維度AB方案和多指標通用報表分析能力。能支持更多業務的快速嘗試、快速反饋和快速調整；
- 沉澱和抽象出核心鏈路, 不侷限於支持直播業務, 可以平臺化支持更多的社區和非社區業務。同時在理解用戶興趣的基礎, 更好的支持理解內容, 實現內容結構化, 實現用戶和興趣內容的低成本運營；
~~