推薦系統之標籤體系

爲什麼要先介紹標籤體系?

一個推薦系統效果好與壞最基本的保障、最基礎的是什麼?如果讓我來回答,一定是標籤體系。我這裏說的標籤主要是針對物料的,對於電商平臺來說就是商品;對於音樂平臺來說就是每一個首歌,對於新聞資訊平臺來說就是每一條新聞。下一篇要介紹的是用戶畫像,畫像中那些用戶實時變化的興趣點大都也是來自於標籤體系,依據用戶長期和短期行爲中對於物料搜索、點擊、收藏、評論、轉發等事件,將物料的標籤傳導到用戶畫像上,就構成了用戶的實時畫像和離線畫像中的各個動態維度。

標籤體系概覽

以京東的標籤體系中的京東超市爲例用思維導圖來拆解,後面我們會詳細的介紹如何構建標籤體系。

這裏對京東超市標籤拆解粒度到三隻松鼠年貨大禮包的實體級別,實際上各個公司的標籤體系大致都是如下構成

一、二、三級分類體系都很好理解,參考京東超市的拆解,相信大家就會明白。標籤體系中實體標籤和概念標籤不好理解。

實體標籤

必須是名詞,且必須是唯一指代。

學術性的解釋逼格高,但是不容易理解,回答下面的問題

  • 老闆問:蘋果,是實體標籤嗎?

  • 給你三秒鐘思考

  • 你回答:是!

  • 老闆說:錯!

  • 你懵逼:靠!爲啥不是?

實體標籤的要求:名詞,且唯一指代。

蘋果,是名詞,但不是唯一指代,蘋果 = 科技公司、手機、水果、牛仔褲

概念標籤

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

概念標籤通常表示的是“一類”或“某種相似”的內容,例如

主題詞

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

以上大致介紹了一下標籤體系,那麼我們接下介紹一下如何構建標籤體系以及其構建過程中應遵循的一些原則。


標籤體系構建原則

原則一、放棄⼤而全的框架,以業務場景倒推標籤需求

原則二、標籤生成自助化,解決效率和溝通成本

原則三、有效的標籤管理機制

分別解釋以下爲什麼提煉出這三個原則,分別用於解決什麼問題?

關於第一項原則:

每個公司的產品、運營、商務對標籤的訴求有較大的差異,同時不同的運營團隊的訴求也存在很大差異,⼤而全的標籤框架實際是站在用戶視角搭建的,但是標籤的真正應用者是業務方,所以應該從業務視角來實現。

因此最佳的處理方式是,我們應該放棄頂層的用戶抽象視角,針對各業務線或部門的訴求和實際的應用場景,分別將標籤聚類起來提供給相應部門。

之家就是非常典型的情況,商業同學更關心用戶的消費能力相關的標籤;自駕遊負責同學更關心用戶的位置和出行相關的標籤;車友圈的同學更關注用戶的社交活躍相關的標籤;所以不可能一套標籤覆蓋整個運營團隊, 這種以業務場景倒推標籤需求的方法,能夠與業務場景貼合更緊密,可用性上升。

關於第二項原則:

1.標籤生成的自助化能夠讓溝通成本降最低。前面講到各業務線對標籤的定義的理解不同,需要標籤系統建設團隊花費大量的時間溝通。如果能夠讓業務方自己定義規則,這必然是溝通成本最低的方式。

2.標籤生成的自助化,可重複修改的規則,降低無效標籤的堆積。業務一直在發展,如果規則一成不變則很難跟上業務節奏的變化。我曾拜訪過一家電商,他們發現半年前定義“母嬰客戶羣”的轉化率一直在降低,因此根據實際情況重新修改和定義了“母嬰客戶羣”規則,並命名爲“母嬰客戶羣(新)”,這時之前的規則是無效的,且會一直佔據計算資源……諸如此類,如果支持規則重複修改的話,這一類無效標籤就會大量地消失。

3.釋放數據團隊人力,釋放業務團隊的想象力。數據團隊應該花較多的精力在企業的整個數據中臺或新業務模型方面,而不是處理各業務線的標籤訴求和標籤維護上,自動化的標籤生成能夠極大限度地節省人力和釋放團隊想象力。

關於第三項原則:

1.規則及元信息維護:標籤相關的規則和元信息要儘可能的暴露給使用者,讓使用者在使用的時候,能清楚知道標籤的規則是什麼、創建者是誰、維護者是誰、標籤的更新頻率週期等,而不是沒有規則,或者將規則存在標籤建設團隊內部的一個 word 文檔中。

2.調度機制及信息同步:標籤之間有一些關聯,標籤之間的鏈條斷裂,是否有個調度機制或者信息同步機制讓大家的工作不被影響。

3.高效統一的輸出接口:將所有的業務信息和用戶數據信息彙總在一起,有統一的輸出接口,改變之前需要針對不同的業務系統開發不同接口的情況。

我們回顧標籤體系構建的三原則,本質上是解決了價值、手段、可持續性三方面的問題:以業務場景倒推需求,讓業務方用起來作爲最終目標,讓標籤系統價值得以實現;標籤生成的自助化,它解決的是我們用什麼樣的手段去實現價值;有效的標籤管理機制,意味着一套標籤體系能否可持續性地在一家企業裏面運作下去。

總之,對企業最重要的是:一套標籤系統能不能在業務上用起來,能不能覆蓋更廣泛的需求,而不是一個大而全的框架。


標籤體系構建的方法

標籤體系的實施架構

標籤體系架構可以分爲三個部分:數據加工層,數據服務層,數據應用層。每個層面面向用戶對象不一樣,處理事務有所不同。層級越往下,與業務的耦合度就越小。層級越往上,業務關聯性就越強

以某電商公司爲例

數據加工層。數據加工層收集,清洗和提取來處理數據。M公司有多個產品線:電商交易,電子書閱讀,金融支付,智能硬件等等。每個產品線的業務數據又是分屬在不同位置。爲了搭建完善的用戶標籤體系,需要儘可能彙總最大範圍內的數據。同時每個產品線的也要集合所有端的數據,比如:App,web,微信,其它第三方合作渠道。

收集了所有數據之後,需要經過清洗:去重,去刷單數據,去無效數據,去異常數據等等。然後再是提取特徵數據,這部分就要根據產品和運營人員提的業務數據要求來做就好。

數據業務層。數據加工層爲業務層提供最基礎數據能力,提供數據原材料。業務層屬於公共資源層,並不歸屬某個產品或業務線。它主要用來維護整個標籤體系,集中在一個地方來進行管理。

在這一層,運營人員和產品能夠參與進來,提出業務要求:將原材料進行切割。主要完成以下核心任務:

  • 定義業務方需要的標籤。

  • 創建標籤實例。

  • 執行業務標籤實例,提供相應數據。

數據應用層。應用層的任務是賦予產品和運營人員標籤的工具能力,聚合業務數據,轉化爲用戶的槍火彈藥,提供數據應用服務。

業務方能夠根據自己的需求來使用,共享業務標籤,但彼此業務又互不影響。實踐中可應用到以下幾塊:

  • 智能營銷

  • Feed流推薦

  • 個性化消息push

標籤體系的設計

1.業務梳理

以業務需求爲導向,可以按下面的思路來梳理標籤體系:

  • 有哪些產品線?產品線有哪些來源渠道?一一列出。

  • 每個產品線有哪些業務對象?比如用戶,商品。

  • 最後再根據對象聚合業務,每個對象涉及哪些業務?每個業務下哪些業務數據和用戶行爲?

結果類似如下:

2.標籤分類

按業務需求梳理了業務數據後,可以繼續按照業務產出對象的屬性來進行分類,主要目的:

  • 方便管理標籤,便於維護和擴展。

  • 結構清晰,展示標籤之間的關聯關係。

  • 爲標籤建模提供子集。方便獨立計算某個標籤下的屬性偏好或者權重。

梳理標籤分類時,儘可能按照MECE原則,相互獨立,完全窮盡。每一個子集的組合都能覆蓋到父集所有數據。標籤深度控制在四級比較合適,方便管理,到了第四級就是具體的標籤實例。

3.標籤的模型

按數據的實效性來看,標籤可分爲

  • 靜態屬性標籤。長期甚至永遠都不會發生改變。比如性別,出生日期,這些數據都是既定的事實,幾乎不會改變。

  • 動態屬性標籤。存在有效期,需要定期地更新,保證標籤的有效性。比如用戶的購買力,用戶的活躍情況。

從數據提取維度來看,標籤數據又可以分爲類型。

  • 事實標籤。既定事實,從原始數據中提取。比如通過用戶設置獲取性別,通過實名認證獲取生日,星座等信息。

  • 模型標籤。沒有對應數據,需要定義規則,建立模型來計算得出標籤實例。比如支付偏好度。

  • 預測標籤。參考已有事實數據,來預測用戶的行爲或偏好。比如用戶a的歷史購物行爲與羣體A相似,使用協同過濾算法,預測用戶a也會喜歡某件物品。

4.標籤的處理

爲什麼要從兩個維度來對標籤區分?這是爲了方便用戶標籤的進一步處理。

靜態動態的劃分是面向業務維度,便於運營人員理解業務。這一點能幫助他們:

  • 理解標籤體系的設計。

  • 表達自己的需求。

事實標籤,模型標籤,預測標籤是面向數據處理維度,便於技術人員理解標籤模塊功能分類,幫助他們:

  • 設計合理數據處理單元,相互獨立,協同處理。

  • 標籤的及時更新及數據響應的效率。

以上面的標籤圖表爲例,面臨以下問題:

  • 屬性信息缺失怎麼辦?比如,現實中總有用戶未設置用戶性別,那怎麼才能知道用戶的性別呢?

  • 行爲屬性,消費屬性的標籤能不能靈活設置?比如,活躍運營中需要做A/B test,不能將品牌偏好規則寫死,怎麼辦?

  • 既有的屬性創建不了我想要的標籤?比如,用戶消費能力需要綜合結合多項業務的數據才合理,如何解決?

模型標籤的定義解決的就是從無到有的問題。建立模型,計算用戶相應屬性匹配度。現實中,事實標籤也存在數據缺失情況。

比如用戶性別未知,但是可以根據用戶瀏覽商品,購買商品的歷史行爲來計算性別偏好度。當用戶購買的女性化妝品和內衣較多,偏好值趨近於性別女,即可以推斷用戶性別爲女。

模型計算規則的開放解決的是標籤靈活配置的問題。運營人員能夠根據自己的需求,靈活更改標籤實例的定義規則。比如圖表中支付頻度實例的規則定義,可以做到:

  • 時間的開放。支持時間任意選擇:昨天,前天,近x天,自定義某段時間等等。

  • 支付筆數的開放。大於,等於,小於某個值,或者在某兩個值區間。

標籤的組合解決就是標籤擴展的問題。除了原有屬性的規則定義,還可以使用對多個標籤進行組合,創建新的複合型標籤。比如定義用戶的消費能力等級。

標籤最終呈現的形態要滿足兩個需求:

  • 標籤的最小顆粒度要觸達到具體業務事實數據,同時支持對應標籤實例的規則自定義。

  • 不同的標籤可以相互自由組合爲新的標籤,同時支持標籤間的關係,權重自定義。

推薦閱讀:

基於Spark的大規模推薦系統特徵工程

基於Flink商品實時推薦系統項目

微信看一看:推薦系統用戶畫像構建指南

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章