推薦系統(tǒng)之標簽體系

為什么要先介紹標簽體系?



老板問:蘋果,是實體標簽嗎? 給你三秒鐘思考 你回答:是! 老板說:錯! 你懵逼:靠!為啥不是?

難道我就不能用“蘋果”了嗎?當然可以用,只不過要給它另外起個名字:概念標簽。

這里以之家的標簽體系舉例,要給買車用戶推薦評測導(dǎo)購(一級)的文章,用戶畫像中車的品牌(二級)偏好太粗,而實體標簽如奔馳GLC又太細,填補這中間的粒度空白,滿足用戶購車意圖的畫像,就加入“代步優(yōu)選”的主題詞,這樣不僅保持了推薦的多樣性,又不至于過分精準而導(dǎo)致的極度收斂。

原則一、放棄?而全的框架,以業(yè)務(wù)場景倒推標簽需求

定義業(yè)務(wù)方需要的標簽 創(chuàng)建標簽實例 執(zhí)行業(yè)務(wù)標簽實例,提供相應(yīng)數(shù)據(jù)
智能營銷 Feed流推薦 個性化消息push
1. 業(yè)務(wù)梳理
有哪些產(chǎn)品線?產(chǎn)品線有哪些來源渠道?一一列出 每個產(chǎn)品線有哪些業(yè)務(wù)對象?比如用戶,商品 最后再根據(jù)對象聚合業(yè)務(wù),每個對象涉及哪些業(yè)務(wù)?每個業(yè)務(wù)下哪些業(yè)務(wù)數(shù)據(jù)和用戶行為?

方便管理標簽,便于維護和擴展 結(jié)構(gòu)清晰,展示標簽之間的關(guān)聯(lián)關(guān)系 為標簽建模提供子集。方便獨立計算某個標簽下的屬性偏好或者權(quán)重

靜態(tài)屬性標簽。長期甚至永遠都不會發(fā)生改變。比如性別,出生日期,這些數(shù)據(jù)都是既定的事實,幾乎不會改變 動態(tài)屬性標簽。存在有效期,需要定期地更新,保證標簽的有效性。比如用戶的購買力,用戶的活躍情況
事實標簽。既定事實,從原始數(shù)據(jù)中提取。比如通過用戶設(shè)置獲取性別,通過實名認證獲取生日,星座等信息 模型標簽。沒有對應(yīng)數(shù)據(jù),需要定義規(guī)則,建立模型來計算得出標簽實例。比如支付偏好度 預(yù)測標簽。參考已有事實數(shù)據(jù),來預(yù)測用戶的行為或偏好。比如用戶a的歷史購物行為與群體A相似,使用協(xié)同過濾算法,預(yù)測用戶a也會喜歡某件物品

理解標簽體系的設(shè)計 表達自己的需求
設(shè)計合理數(shù)據(jù)處理單元,相互獨立,協(xié)同處理 標簽的及時更新及數(shù)據(jù)響應(yīng)的效率
屬性信息缺失怎么辦?比如,現(xiàn)實中總有用戶未設(shè)置用戶性別,那怎么才能知道用戶的性別呢? 行為屬性,消費屬性的標簽?zāi)懿荒莒`活設(shè)置?比如,活躍運營中需要做A/B test,不能將品牌偏好規(guī)則寫死,怎么辦? 既有的屬性創(chuàng)建不了我想要的標簽?比如,用戶消費能力需要綜合結(jié)合多項業(yè)務(wù)的數(shù)據(jù)才合理,如何解決?
時間的開放。支持時間任意選擇:昨天,前天,近x天,自定義某段時間等等 支付筆數(shù)的開放。大于,等于,小于某個值,或者在某兩個值區(qū)間
標簽的最小顆粒度要觸達到具體業(yè)務(wù)事實數(shù)據(jù),同時支持對應(yīng)標簽實例的規(guī)則自定義 不同的標簽可以相互自由組合為新的標簽,同時支持標簽間的關(guān)系,權(quán)重自定義
評論
圖片
表情

