1. 程式人生 > >使用者畫像標籤體系——從零開始搭建實時使用者畫像(三)

使用者畫像標籤體系——從零開始搭建實時使用者畫像(三)

![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105555935-1646899007.png) # 使用者畫像標籤體系 ​ 使用者畫像的核心在於給使用者“打標籤”,每一個標籤通常是人為規定的特徵標識,用高度精煉的特徵描述一類人,例如年齡、性別、興趣偏好等,不同的標籤通過結構化的資料體系整合,就可與組合出不同的使用者畫像。 ​ 梳理標籤體系是實現使用者畫像過程中最基礎、也是最核心的工作,後續的建模、資料倉庫搭建都會依賴於標籤體系。 ​ 為什麼需要梳理標籤體系,因為不同的企業做使用者畫像有不同的戰略目的,廣告公司做使用者畫像是為精準廣告服務,電商做使用者畫像是為使用者購買更多商品,內容平臺做使用者畫像是推薦使用者更感興趣的內容提升流量再變現,金融行業做使用者畫像是為了尋找到目標客戶的同時做好風險的控制。 ​ 所以第一步,我們要結合所在的行業,業務去分析我們使用者畫像的目的。這其實就是戰略,我們要通過戰略去指引我們最終的方向。 ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105613653-1666121078.png) 對於電商企業來說,可能最重要的兩個問題就是: **現有使用者- 我的現存使用者是誰?為什麼買我的產品?他們有什麼偏好?哪些使用者價值最高?** **潛在客戶- 我的潛在使用者在哪兒?他們喜歡什麼?哪些渠道能找到他們?獲客成本是多少?** 而對於金融企業,還要加上一條: **使用者風險—使用者的收入能力怎麼樣?他們是否有過貸款或者信用卡的逾期?他們的徵信有問題嗎?** 我們做使用者畫像的目的也就是根據我們指定的戰略方向最終去解決這些問題。 在梳理標籤的過程還要緊密的結合我們的資料,不能脫離了資料去空想,當然如果是我們必須要的資料,我們可能需要想辦法去獲取這些資料,這就是資料採集的問題,我們之後會深入的討論。 先展示兩種常見的標籤體系,隨後我們將按步驟建立我們的標籤體系。 ## 電商類標籤體系 ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105623222-401775809.png) 可以看到電商類的標籤體系,更關注使用者的屬性,行為等等資訊。那麼我們需要的資料也就來源於使用者可提供的基本資訊,以及使用者的行為資訊,這些我們可以通過埋點獲取,而使用者的訂單情況也是非常的重要的標籤。 ## 金融類標籤體系 ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105629676-109169983.png) 對於金融行業,最明顯的區別是增加了使用者的價值和使用者風險的資訊。這些資訊在使用者申請貸款時一般都可以提供,還有很多資訊需要通過徵信獲取。 最終,不管是電商還是金融或者其他領域,我們都可以通過資料對使用者進行畫像,最終建立標籤體系,影響我們的業務,最終實現戰略目的。 下面我們來具體看一下如何一步步的分析建立整體標籤體系。 # 標籤的維度與型別 在我們建立使用者標籤時,首先要明確基於哪種維度去建立標籤。 一般除了基於使用者維度(userid)建立使用者標籤體系外,還有基於裝置維度(cookieid)建立相應的標籤體系,當用戶沒有登入裝置時,就需要這個維度。當然這兩個維度還可以進行關聯。 而兩者的關聯就是需要ID-Mapping演算法來解決,這也是一個非常複雜的演算法。更多的時候我們還是以使用者的唯一標識來建立使用者畫像。 而標籤也分為很多種型別,這裡參照常見的分類方式, 從對使用者打標籤的方式來看,一般分為三種類型:1、基於統計類的標籤;2、基於規則類的標籤、3、基於挖掘類的標籤。下面我們介紹這三種類型標籤的區別: - 統計類標籤:這類標籤是最為基礎也最為常見的標籤型別,例如對於某個使用者來說,他的性別、年齡、城市、星座、近7日活躍時長、近7日活躍天數、近7日活躍次數等欄位可以從使用者註冊資料、使用者訪問、消費類資料中統計得出。該類標籤構成了使用者畫像的基礎; - 規則類標籤:該類標籤基於使用者行為及確定的規則產生。例如對平臺上“消費活躍”使用者這一口徑的定義為近30天交易次數>=2。在實際開發畫像的過程中,由於運營人員對業務更為熟悉、而資料人員對資料的結構、分佈、特徵更為熟悉,因此規則類標籤的規則確定由運營人員和資料人員共同協商確定; - 機器學習挖掘類標籤:該類標籤通過資料探勘產生,應用在對使用者的某些屬性或某些行為進行預測判斷。例如根據一個使用者的行為習慣判斷該使用者是男性還是女性,根據一個使用者的消費習慣判斷其對某商品的偏好程度。該類標籤需要通過演算法挖掘產生。 標籤的型別是對標籤的一個區分,方便我們瞭解標籤是在資料處理的哪個階段產生的,也更方便我們管理。 # 標籤分級分類 標籤需要進行分級分類的管理,一方面使得標籤更加的清晰有條件,另一方面也方便我們對標籤進行儲存查詢,也就是管理標籤。 ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105639396-691987758.png) 使用者畫像體系和標籤分類從兩個不同角度來梳理標籤,使用者畫像體系偏戰略和應用,標籤分類偏管理和技術實現側。 把標籤分成不同的層級和類別,一是方便管理數千個標籤,讓散亂的標籤體系化;二是維度並不孤立,標籤之間互有關聯;三可以為標籤建模提供標籤子集。 梳理某類別的子分類時,儘可能的遵循MECE原則(相互獨立、完全窮盡),尤其是一些有關使用者分類的,要能覆蓋所有使用者,但又不交叉。比如:使用者活躍度的劃分為核心使用者、活躍使用者、新使用者、老使用者、流失使用者,使用者消費能力分為超強、強、中、弱,這樣按照給定的規則每個使用者都有分到不同的組裡。 # 標籤命名 標籤的命名也是為了我們可以對標籤進行統一的管理,也更好識別出是什麼標籤。 ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105645434-603169954.png) 這是一種非常好的命名方式,解釋如下: 標籤主題:用於刻畫屬於那種型別的標籤,如使用者屬性、使用者行為、使用者消費、風險控制等多種型別,可用A、B、C、D等 字母表示各標籤主題;  標籤型別:標籤型別可劃為分型別和統計型這兩種型別,其中分型別用於刻畫使用者屬於哪種型別,如是男是女、是否是會員、 是否已流失等標籤,統計型標籤用於刻畫統計使用者的某些行為次數,如歷史購買金額、優惠券使用次數、近30日登陸次數等 標籤,這類標籤都需要對應一個使用者相應行為的權重次數;  開發方式:開發方式可分為統計型開發和演算法型開發兩大開發方式。其中統計型開發可直接從資料倉庫中各主題表建模加工 而成,演算法型開發需要對資料做機器學習的演算法處理得到相應的標籤;  是否互斥標籤:對應同一級類目下(如一級標籤、二級標籤),各標籤之間的關係是否為互斥,可將標籤劃分為互斥關係和 非互斥關係。例如對於男、女標籤就是互斥關係,同一個使用者不是被打上男性標籤就是女性標籤,對於高活躍、中活躍、低 活躍標籤也是互斥關係;  使用者維度:用於刻畫該標籤是打在使用者唯一標識(userid)上,還是打在使用者使用的裝置(cookieid)上。可用U、C等字 母分別標識userid和cookieid維度。 最終形成得標籤示例: 對於使用者是男是女這個標籤,標籤主題是使用者屬性,標籤型別屬於分型別,開發方式為統計型,為互斥關係,使用者 維度為userid。這樣給男性使用者打上標籤“A111U001_001”,女性使用者打上標籤“A111U001_002”,其中 “A111U”為上面介紹的命名方式,“001”為一級標籤的id,後面對於使用者屬性維度的其他一級標籤可用“002”、 “003”等方式追加命名,“_”後面的“001”和“002”為該一級標籤下的標籤明細,如果是劃分高、中、低活躍 使用者的,對應一級標籤下的明細可劃分為“001”、“002”、“003”。 ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105654958-1714653117.png) # 標籤儲存與管理 ## Hive與Druid數倉儲存標籤計算結果集 因為資料非常大,所以跑標籤出來的結果必須要通過hive和druid數倉引擎來完成。 在資料倉庫的建模過程中,主要是事實表和維度表的開發。 事實表依據業務來開發,描述業務的過程,可以理解為我們對原始資料做ETL整理後業務事實。 而維度表就是我們最終形成的使用者維度,維度表是實時變化的,逐漸的建立起使用者的畫像。 **比如使用者維度標籤:** 首先我們根據之前討論的使用者指標體系,將使用者按照人口,行為,消費等等建立相關中間表,注意表的命名。 ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105720710-1635651863.png) 第一張人口屬性表: ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105726615-858881118.png) 同樣的,其他的也按這種方式進行儲存,這種屬性類的計算很容易篩選出來。 然後,我們將使用者的標籤查詢出來,彙總到使用者身上: ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105733156-89860187.png) 終端使用者的標籤就形成了 ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105740288-1771557414.png) 當然,對於複雜的規則和演算法類標籤,就需要在計算中間表時做更復雜的計算,我們需要在Flink裡解決這些複雜的計算,未來開發中我們會詳細的討論,這一部分先根據標籤體系把相應的表結構都設計出來。 ## Mysql儲存標籤元資料 Mysql對於小資料量的讀寫速度更快,也更適合我們對標籤定義,管理。我們也可以在前端開發標籤的管理頁面。 ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200528105747475-1085446796.png) 我們在mysql儲存的欄位如圖所示,在頁面上提供編輯等功能,在開發標籤的過程中,就可以控制標籤的使用了。 這樣,我們的標籤體系已經根據實際的業務情況建立起來了,在明確了標籤體系以後,也就明確了我們的業務支撐,從下一章開始我們將正式開始搭建大資料叢集,接入資料,進行標籤開發,未完待續~ **參考文獻** **《使用者畫像:方法論與工程化解決方案》** 更多實時資料分析相關博文與科技資訊,歡迎關注 “實時流式計算” ![](https://img2020.cnblogs.com/blog/1089984/202005/1089984-20200511083216576-14373893