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

用戶畫像標籤體系

​ 用戶畫像的核心在於給用戶「打標籤」,每個標籤一般是人爲規定的特徵標識,用高度精煉的特徵描述一類人,例如年齡、性別、興趣偏好等,不一樣的標籤經過結構化的數據體系整合,就可與組合出不一樣的用戶畫像。前端

​ 梳理標籤體系是實現用戶畫像過程當中最基礎、也是最核心的工做,後續的建模、數據倉庫搭建都會依賴於標籤體系。mysql

​ 爲何須要梳理標籤體系,由於不一樣的企業作用戶畫像有不一樣的戰略目的,廣告公司作用戶畫像是爲精準廣告服務,電商作用戶畫像是爲用戶購買更多商品,內容平臺作用戶畫像是推薦用戶更感興趣的內容提高流量再變現,金融行業作用戶畫像是爲了尋找到目標客戶的同時作好風險的控制。算法

​ 因此第一步,咱們要結合所在的行業,業務去分析咱們用戶畫像的目的。這其實就是戰略,咱們要經過戰略去指引咱們最終的方向。sql

對於電商企業來講,可能最重要的兩個問題就是:cookie

現有用戶- 個人現存用戶是誰?爲何買個人產品?他們有什麼偏好?哪些用戶價值最高?app

潛在客戶- 個人潛在用戶在哪兒?他們喜歡什麼?哪些渠道能找到他們?獲客成本是多少?機器學習

而對於金融企業,還要加上一條:學習

用戶風險—用戶的收入能力怎麼樣?他們是否有過貸款或者信用卡的逾期?他們的徵信有問題嗎?大數據

咱們作用戶畫像的目的也就是根據咱們指定的戰略方向最終去解決這些問題。ui

在梳理標籤的過程還要緊密的結合咱們的數據,不能脫離了數據去空想,固然若是是咱們必需要的數據,咱們可能須要想辦法去獲取這些數據,這就是數據採集的問題,咱們以後會深刻的討論。

先展現兩種常見的標籤體系,隨後咱們將按步驟創建咱們的標籤體系。

電商類標籤體系

能夠看到電商類的標籤體系,更關注用戶的屬性,行爲等等信息。那麼咱們須要的數據也就來源於用戶可提供的基本信息,以及用戶的行爲信息,這些咱們能夠經過埋點獲取,而用戶的訂單狀況也是很是的重要的標籤。

金融類標籤體系

對於金融行業,最明顯的區別是增長了用戶的價值和用戶風險的信息。這些信息在用戶申請貸款時通常均可以提供,還有不少信息須要經過徵信獲取。

最終,不論是電商仍是金融或者其餘領域,咱們均可以經過數據對用戶進行畫像,最終創建標籤體系,影響咱們的業務,最終實現戰略目的。

下面咱們來具體看一下如何一步步的分析創建總體標籤體系。

標籤的維度與類型

在咱們創建用戶標籤時,首先要明確基於哪一種維度去創建標籤。

通常除了基於用戶維度(userid)創建用戶標籤體系外,還有基於設備維度(cookieid)創建相應的標籤體系,當用戶沒有登陸設備時,就須要這個維度。固然這兩個維度還能夠進行關聯。

而二者的關聯就是須要ID-Mapping算法來解決,這也是一個很是複雜的算法。更多的時候咱們仍是以用戶的惟一標識來創建用戶畫像。

而標籤也分爲不少種類型,這裏參照常見的分類方式,

從對用戶打標籤的方式來看,通常分爲三種類型:一、基於統計類的標籤;二、基於規則類的標籤、三、基於挖掘類的標籤。下面咱們介紹這三種類型標籤的區別:

  • 統計類標籤:這類標籤是最爲基礎也最爲常見的標籤類型,例如對於某個用戶來講,他的性別、年齡、城市、星座、近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存儲的字段如圖所示,在頁面上提供編輯等功能,在開發標籤的過程當中,就能夠控制標籤的使用了。

這樣,咱們的標籤體系已經根據實際的業務狀況創建起來了,在明確了標籤體系之後,也就明確了咱們的業務支撐,從下一章開始咱們將正式開始搭建大數據集羣,接入數據,進行標籤開發,未完待續~

參考文獻

《用戶畫像:方法論與工程化解決方案》

更多實時數據分析相關博文與科技資訊,歡迎關注 「實時流式計算」

相關文章
相關標籤/搜索