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