用戶畫像基礎

文章作者：趙宏田資深大數據技術專家

內容來源：《用戶畫像方法論與工程化解決方案》

導讀： 在互聯網步入大數據時代後，用戶行爲給企業的產品和服務帶來了一系列的改變和重塑，其中最大的變化在於，用戶的一切行爲在企業面前是可“追溯”“分析”的。企業內保存了大量的原始數據和各種業務數據，這是企業經營活動的真實記錄，如何更加有效地利用這些數據進行分析和評估，成爲企業基於更大數據量背景的問題所在。隨着大數據技術的深入研究與應用，企業的關注點日益聚焦在如何利用大數據來爲精細化運營和精準營銷服務，而要做精細化運營，首先要建立本企業的用戶畫像。

畫像簡介

用戶畫像，即用戶信息標籤化，通過收集用戶的社會屬性、消費習慣、偏好特徵等各個維度的數據，進而對用戶或者產品特徵屬性進行刻畫，並對這些特徵進行分析、統計，挖掘潛在價值信息，從而抽象出用戶的信息全貌，如圖1-1所示。用戶畫像可看作企業應用大數據的根基，是定向廣告投放與個性化推薦的前置條件，爲數據驅動運營奠定了基礎。由此看來，如何從海量數據中挖掘出有價值的信息越發重要。

圖1-1 某用戶標籤化

大數據已經興起多年，其對於互聯網公司的應用來說已經如水、電、空氣對於人們的生活一樣，成爲不可或缺的重要組成部分。從基礎設施建設到應用層面，主要有數據平臺搭建及運維管理、數據倉庫開發、上層應用的統計分析、報表生成及可視化、用戶畫像建模、個性化推薦與精準營銷等應用方向。

很多公司在大數據基礎建設上投入很多，也做了不少報表，但業務部門覺得大數據和傳統報表沒什麼區別，也沒能體會大數據對業務有什麼幫助和價值，究其原因，其實是“數據靜止在數據倉庫，是死的”。

而用戶畫像可以幫助大數據“走出”數據倉庫，針對用戶進行個性化推薦、精準營銷、個性化服務等多樣化服務，是大數據落地應用的一個重要方向。數據應用體系的層級劃分如圖1-2所示。

圖1-2 數據應用體系的層級劃分

標籤類型：

用戶畫像建模其實就是對用戶“打標籤”，從對用戶打標籤的方式來看，一般分爲3種類型（如圖1-3所示）：①統計類標籤；②規則類標籤；③機器學習挖掘類標籤。

圖1-3 標籤類型

下面我們介紹這3種類型的標籤的區別：

① 統計類標籤

這類標籤是最爲基礎也最爲常見的標籤類型，例如，對於某個用戶來說，其性別、年齡、城市、星座、近7日活躍時長、近7日活躍天數、近7日活躍次數等字段可以從用戶註冊數據、用戶訪問、消費數據中統計得出。該類標籤構成了用戶畫像的基礎。

② 規則類標籤

該類標籤基於用戶行爲及確定的規則產生。例如，對平臺上“消費活躍”用戶這一口徑的定義爲“近30天交易次數≥2”。在實際開發畫像的過程中，由於運營人員對業務更爲熟悉，而數據人員對數據的結構、分佈、特徵更爲熟悉，因此規則類標籤的規則由運營人員和數據人員共同協商確定；

③ 機器學習挖掘類標籤

該類標籤通過機器學習挖掘產生，用於對用戶的某些屬性或某些行爲進行預測判斷。例如，根據一個用戶的行爲習慣判斷該用戶是男性還是女性、根據一個用戶的消費習慣判斷其對某商品的偏好程度。該類標籤需要通過算法挖掘產生。

在項目工程實踐中，一般統計類和規則類的標籤即可以滿足應用需求，在開發中佔有較大比例。機器學習挖掘類標籤多用於預測場景，如判斷用戶性別、用戶購買商品偏好、用戶流失意向等。一般地，機器學習標籤開發週期較長，開發成本較高，因此其開發所佔比例較小。

數據架構

在整個工程化方案中，系統依賴的基礎設施包括Spark、Hive、HBase、Airflow、MySQL、Redis、Elasticsearch。除去基礎設施外，系統主體還包括Spark Streaming、ETL、產品端3個重要組成部分。圖1-4所示是用戶畫像數倉架構圖，下面對其進行詳細介紹。

圖1-4 用戶畫像數倉架構

圖1-4下方虛線框中爲常見的數據倉庫ETL加工流程，也就是將每日的業務數據、日誌數據、埋點數據等經過ETL過程，加工到數據倉庫對應的ODS層、DW層、DM層中。

中間的虛線框即爲用戶畫像建模的主要環節，用戶畫像不是產生數據的源頭，而是對基於數據倉庫ODS層、DW層、DM層中與用戶相關數據的二次建模加工。在ETL過程中將用戶標籤計算結果寫入Hive，由於不同數據庫有不同的應用場景，後續需要進一步將數據同步到MySQL、HBase、Elasticsearch等數據庫中。

Hive：存儲用戶標籤計算結果、用戶人羣計算結果、用戶特徵庫計算結果。
MySQL：存儲標籤元數據，監控相關數據，導出到業務系統的數據。
HBase：存儲線上接口實時調用類數據。
Elasticsearch：支持海量數據的實時查詢分析，用於存儲用戶人羣計算、用戶羣透視分析所需的用戶標籤數據（由於用戶人羣計算、用戶羣透視分析的條件轉化成的SQL語句多條件嵌套較爲複雜，使用Impala執行也需花費大量時間）。

用戶標籤數據在Hive中加工完成後，部分標籤通過Sqoop同步到MySQL數據庫，提供用於BI報表展示的數據、多維透視分析數據、圈人服務數據；另一部分標籤同步到HBase數據庫用於產品的線上個性化推薦。

主要覆蓋模塊

搭建一套用戶畫像方案整體來說需要考慮8個模塊的建設，如圖1-5所示。

用戶畫像基礎：需要了解、明確用戶畫像是什麼，包含哪些模塊，數據倉庫架構是什麼樣子，開發流程，表結構設計，ETL設計等。這些都是框架，大方向的規劃，只有明確了方向後續才能做好項目的排期和人員投入預算。這對於評估每個開發階段重要指標和關鍵產出非常重要，重點可看1.4節。
數據指標體系：根據業務線梳理，包括用戶屬性、用戶行爲、用戶消費、風險控制等維度的指標體系。
標籤數據存儲：標籤相關數據可存儲在Hive、MySQL、HBase、Elasticsearch等數據庫中，不同存儲方式適用於不同的應用場景。
標籤數據開發：用戶畫像工程化的重點模塊，包含統計類、規則類、挖掘類、流式計算類標籤的開發，以及人羣計算功能的開發，打通畫像數據和各業務系統之間的通路，提供接口服務等開發內容。

圖1-5 用戶畫像主要覆蓋模塊

開發性能調優：標籤加工、人羣計算等腳本上線調度後，爲了縮短調度時間、保障數據的穩定性等，需要對開發的腳本進行迭代重構、調優。
作業流程調度：標籤加工、人羣計算、同步數據到業務系統、數據監控預警等腳本開發完成後，需要調度工具把整套流程調度起來。本書講解了Airflow這款開源ETL工具在調度畫像相關任務腳本上的應用。
用戶畫像產品化：爲了能讓用戶數據更好地服務於業務方，需要以產品化的形態應用在業務上。產品化的模塊主要包括標籤視圖、用戶標籤查詢、用戶分羣、透視分析等。
用戶畫像應用：畫像的應用場景包括用戶特徵分析、短信、郵件、站內信、Push消息的精準推送、客服針對用戶的不同話術、針對高價值用戶的極速退貨退款等VIP服務應用。

開發階段流程

本節主要介紹畫像系統開發上線的流程以及各階段的關鍵產出。

1. 開發上線流程

用戶畫像建設項目流程，如圖1-6所示。

圖1-6 用戶畫像建設項目流程

第一階段：目標解讀

在建立用戶畫像前，首先需要明確用戶畫像服務於企業的對象，再根據業務方需求，明確未來產品建設目標和用戶畫像分析之後的預期效果。

一般而言，用戶畫像的服務對象包括運營人員和數據分析人員。不同業務方對用戶畫像的需求有不同的側重點，就運營人員來說，他們需要分析用戶的特徵、定位用戶行爲偏好，做商品或內容的個性化推送以提高點擊轉化率，所以畫像的側重點就落在了用戶個人行爲偏好上；就數據分析人員來說，他們需要分析用戶行爲特徵，做好用戶的流失預警工作，還可根據用戶的消費偏好做更有針對性的精準營銷。

第二階段：任務分解與需求調研

經過第一階段的需求調研和目標解讀，我們已經明確了用戶畫像的服務對象與應用場景，接下來需要針對服務對象的需求側重點，結合產品現有業務體系和“數據字典”規約實體和標籤之間的關聯關係，明確分析維度。就後文將要介紹的案例而言，需要從用戶屬性畫像、用戶行爲畫像、用戶偏好畫像、用戶羣體偏好畫像等角度去進行業務建模。

第三階段：需求場景討論與明確

在本階段，數據運營人員需要根據與需求方的溝通結果，輸出產品用戶畫像需求文檔，在該文檔中明確畫像應用場景、最終開發出的標籤內容與應用方式，並就該文檔與需求方反覆溝通並確認無誤。

第四階段：應用場景與數據口徑確認

經過第三個階段明確了需求場景與最終實現的標籤維度、標籤類型後，數據運營人員需要結合業務與數據倉庫中已有的相關表，明確與各業務場景相關的數據口徑。在該階段中，數據運營方需要輸出產品用戶畫像開發文檔，該文檔需要明確應用場景、標籤開發的模型、涉及的數據庫與表以及應用實施流程。該文檔不需要再與運營方討論，只需面向數據運營團隊內部就開發實施流程達成一致意見即可。

第五階段：特徵選取與模型數據落表

本階段中數據分析挖掘人員需要根據前面明確的需求場景進行業務建模，寫好HQL邏輯，將相應的模型邏輯寫入臨時表中，並抽取數據校驗是否符合業務場景需求。

第六階段：線下模型數據驗收與測試

數據倉庫團隊的人員將相關數據落表後，設置定時調度任務，定期增量更新數據。數據運營人員需要驗收數倉加工的HQL邏輯是否符合需求，根據業務需求抽取表中數據查看其是否在合理範圍內，如果發現問題要及時反饋給數據倉庫人員調整代碼邏輯和行爲權重的數值。

第七階段：線上模型發佈與效果追蹤

經過第六階段，數據通過驗收之後，會通過Git進行版本管理，部署上線。使用Git進行版本管理，上線後通過持續追蹤標籤應用效果及業務方反饋，調整優化模型及相關權重配置。

2. 各階段關鍵產出

爲保證程序上線的準時性和穩定性，需要規劃好各階段的任務排期和關鍵產出。畫像體系的開發分爲幾個主要階段，包括前期指標體系梳理、用戶標籤開發、ETL調度開發、打通數據服務層、畫像產品端開發、面向業務方推廣應用、爲業務方提供營銷策略的解決方案等，如表1-1所示。

表1-1 用戶畫像項目各階段關鍵產出

標籤開發：根據業務需求和應用場景梳理標籤指標體系，調研業務上定義的數據口徑，確認數據來源，開發相應的標籤。標籤開發在整個畫像項目週期中佔有較大比重。
ETL調度開發：梳理需要調度的各任務之間的依賴關係，開發調度腳本及調度監控告警腳本，上線調度系統。
打通服務層接口：爲了讓畫像數據走出數據倉庫，應用到用戶身上，需要打通數據倉庫和各業務系統的接口。
畫像產品化：需要產品經理與業務人員、技術開發人員一起對接業務需求點和產品功能實現形式，畫產品原型，確定工作排期。Java Web端開發完成後，需要數據開發人員向對應的庫表中灌入數據。
開發調優：在畫像的數據和產品端搭建好架構、能提供穩定服務的基礎上，爲了讓調度任務執行起來更加高效、提供服務更加穩健，需要對標籤計算腳本、調度腳本、數據同步腳本等相關計算任務進行重構優化。
面向業務方推廣應用：用戶畫像最終的價值產出點是業務方應用畫像數據進行用戶分析，多渠道觸達運營用戶，分析ROI，提升用戶活躍度或營收。因此，面向業務人員推廣畫像系統的使用方式、提供針對具體業務場景的解決方案顯得尤爲重要。在該階段，相關人員需要撰寫畫像的使用文檔，提供業務支持。

畫像應用的落地

用戶畫像最終的價值還是要落地運行，爲業務帶來實際價值。這裏需要開發標籤的數據工程師和需求方相互協作，將標籤應用到業務中。否則開發完標籤後，數據還是隻停留在數據倉庫中，沒有爲業務決策帶來積極作用。

畫像開發過程中，還需要開發人員組織數據分析、運營、客服等團隊的人員進行畫像應用上的推廣。對於數據分析人員來說，可能會關注用戶畫像開發了哪些表、哪些字段以及字段的口徑定義；對運營、客服等業務人員來說，可能更關注用戶標籤定義的口徑，如何在Web端使用畫像產品進行分析、圈定用戶進行定向營銷，以及應用在業務上數據的準確性和及時性。

只有業務人員在日常工作中真正應用畫像數據、畫像產品，才能更好地推動畫像標籤的迭代優化，帶來流量提升和營收增長，產出業績價值。

某用戶畫像案例

這裏通過一個實踐案例來將大家更好地帶入實際開發畫像、應用畫像標籤的場景中。本節主要介紹案例背景及相關的元數據，以及開發標籤中可以設計的表結構樣式。

在本案例的開發工作中，基於Spark計算引擎，主要涉及的語言包括HiveQL、Python、Scala、Shell等。

1. 案例背景介紹

某圖書電商網站擁有超過千萬的網購用戶羣體，所售各品類圖書100餘萬種。用戶在平臺上可進行瀏覽、搜索、收藏、下單、購買等行爲。商城的運營需要解決兩個問題：一方面在企業產品線逐漸擴張、信息資源過載的背景下，如何在兼顧自身商業目標的同時更好地滿足消費者的需求，爲用戶帶來更個性化的購物體驗，通過內容的精準推薦，更好地提高用戶的點擊轉化率；另一方面在用戶規模不斷增長的背景下，運營方考慮建立用戶流失預警機制，及時識別將要流失的用戶羣體，採取運營措施挽回用戶。

商城自建立以來，數據倉庫中積累着大量的業務數據、日誌數據及埋點數據。如何充分挖掘沉澱在數據倉庫中的數據的價值，有效支持用戶畫像的建設，成爲當前的重要工作。

2. 相關元數據

在本案例中，可以獲取的數據按其類型分爲：業務類數據和用戶行爲數據。其中業務類數據是指用戶在平臺上下單、購買、收藏物品、貨物配送等與業務相關的數據；用戶行爲數據是指用戶搜索某條信息、訪問某個頁面、點擊某個按鈕、提交某個表單等通過操作行爲產生（在解析日誌的埋點表中）的數據。

涉及數據倉庫中的表主要包括用戶信息表、商品訂單表、圖書信息表、圖書類目表、App端日誌表、Web端日誌表、商品評論表等。下面就用戶畫像建模過程中會用到的一些數據表做詳細介紹。

① 用戶信息表

用戶信息表（見表1-2）存放有關用戶的各種信息，如用戶姓名、年齡、性別、電話號碼、歸屬地等信息。

表1-2 用戶信息表（dim.user_basic_info）

② 商品訂單表

商品訂單表（見表1-3）存放商品訂單的各類信息，包括訂單編號、用戶id、用戶姓名、訂單生成時間、訂單狀態等信息。

表1-3 商品訂單表（dw.order_info_fact）

③ 埋點日誌表

埋點日誌表（見表1-4）存放用戶訪問App時點擊相關控件的打點記錄。通過在客戶端做埋點，從日誌數據中解析出來。

表1-4 埋點日誌表（ods.page_event_log）

④ 訪問日誌表

訪問日誌表（見表1-5）存放用戶訪問App的相關信息及用戶的LBS相關信息，通過在客戶端埋點，從日誌數據中解析出來。

表1-5 訪問日誌表（ods.page_view_log）

⑤ 商品評論表

商品評論表（見表1-6）存放用戶對商品的評論信息。

表1-6 商品評論表（dw.book_comment）

⑥ 搜索日誌表

搜索日誌表（見表1-7）存放用戶在App端搜索相關的日誌數據。

表1-7 搜索日誌表（dw.app_search_log）

⑦ 用戶收藏表

用戶收藏表（見表1-8）記錄用戶收藏圖書的數據。

表1-8 用戶收藏表（dw.book_collection_df）

⑧ 購物車信息表

購物車信息表（見表1-9）記錄用戶將圖書加入購物車的數據。

表1-9 購物車信息表（dw.shopping_cart_df）

3. 畫像表結構設計

表結構設計也是畫像開發過程中需要解決的一個重要問題。

表結構設計的重點是要考慮存儲哪些信息、如何存儲（數據分區）、如何應用（如何抽取標籤）這3個方面的問題。

不同業務背景有不同的設計方式，這裏提供兩種設計思路：一是每日全量數據的表結構；二是每日增量數據的表結構。

Hive需要對輸入進行全盤掃描來滿足查詢條件，通過使用分區可以優化查詢。對於用戶標籤這種日加工數據，隨着時間的推移，分區數量的變動也是均勻的。

每日全量數據，即該表的日期分區中記錄着截止到當天的全量用戶數據。例如，“select count(*) from userprofile where data='20180701'”這條語句查詢的是userprofile表截止到2018年7月1日的全量用戶數據。日全量數據的優勢是方便查詢，缺點是不便於探查更細粒度的用戶行爲。

每日增量數據，即該表的日期分區中記錄着當日的用戶行爲數據。例如，同樣是“select count(*) from userprofile where data='20180701'”，這條語句查詢的是userprofile表在2018年7月1日記錄的當日用戶行爲數據。日增量數據可視爲ODS層的用戶行爲畫像，在應用時還需要基於該增量數據做進一步的建模加工。

下面詳細介紹這兩種表結構的設計方法。

① 日全量數據

日全量數據表中，在每天對應的日期分區中插入截止到當天爲止的全量數據，用戶進行查詢時，只需查詢最近一天的數據即可獲得最新全量數據。下面以一個具體的日全量表結構的例子來進行說明。

這裏userid表示用戶id，labelweight表示標籤權重，theme表示標籤歸屬的二級主題，labelid表示一個標籤id。通過“日期 +標籤歸屬的二級主題+標籤id”的方式進行分區，設置三個分區字段更便於開發和查詢數據。該表結構下的標籤權重僅考慮統計類型標籤的權重，如：歷史購買金額標籤對應的權重爲金額數量，用戶近30日訪問天數爲對應的天數，該權重值的計算未考慮較爲複雜的用戶行爲次數、行爲類型、行爲距今時間等複雜情況。

通過表名末尾追加“_all”的規範化命名形式，可直觀看出這是一張日全量表。

例如，對於主題類型爲“會員”的標籤，插入“20190101”日的全量數據，可通過語句：

insert overwrite table dw. userprofile_userlabel_all partition(data_date= '20190101', theme= 'member', labelid='ATTRITUBE_U_05_001') 來實現。

查詢截止到“20190101”日的被打上會員標籤的用戶量，可通過語句：

select count(distinct userid) from dw.userprofile_userlabel_all where data_date='20190101' 來實現。

② 日增量數據

日增量數據表，即在每天的日期分區中插入當天業務運行產生的數據，用戶進行查詢時通過限制查詢的日期範圍，就可以找出在特定時間範圍內被打上特定標籤的用戶。下面以一個具體的日增量表結構的例子來說明。

這裏，labelid表示標籤名稱；cookieid表示用戶id；act_cnt表示用戶當日行爲次數，如用戶當日瀏覽某三級品類商品3次，則打上次數爲3；tag_type_id爲標籤類型,如母嬰、3C、數碼等不同類型；act_type_id表示行爲類型，如瀏覽、搜索、收藏、下單等行爲。分區方式爲按日期分區，插入當日數據。

通過表名末尾追加“_append”的規範化命名形式，可直觀看出這是一張日增量表。

例如，某用戶在“20180701”日瀏覽某3C電子商品4次（act_cnt），即給該用戶（userid）打上商品對應的三級品類標籤（tagid），標籤類型（tag_type_id）爲3C電子商品，行爲類型（act_type_id）爲瀏覽。這裏可以通過對標籤類型和行爲類型兩個字段配置維度表的方式，對數據進行管理。例如對於行爲類型（act_type_id）字段，可以設定1爲購買行爲、2爲瀏覽行爲、3爲收藏行爲等，在行爲標籤表中以數值定義用戶行爲類型，在維度表中維護每個數值對應的具體含義。

該日增量數據表可視爲ODS層用戶行爲標籤明細。在查詢過程中，例如對於某用戶id爲001的用戶，查詢其在“20180701”日到“20180707”日被打上的標籤，可通過命令：

select * from dw.userprofile_act_feature_append where userid = '001' and data_date>='20180701' and data_date<= '20180707' 查詢。

該日增量的表結構記錄了用戶每天的行爲帶來的標籤，但未計算打在用戶身上標籤的權重，計算權重時還需做進一步建模加工。標籤權重算法詳見4.6節的內容。

③ 關於寬表設計

用戶畫像表結構如何設計，沒有一定要遵循的固定的格式，符合業務需要、能滿足應用即可。下面通過兩個寬表設計的案例，提供另一種解決方案的思路。

用戶屬性寬表設計（見表1-10），主要記錄用戶基本屬性信息。

表1-10 用戶屬性寬表設計

用戶日活躍寬表設計（見表1-11），主要記錄用戶每天訪問的信息。

表1-11 用戶日活躍寬表設計

定性類畫像

本書重點講解如何運用大數據定量刻畫用戶畫像，然而對於用戶的刻畫除了定量維度外，定性刻畫也是常見手段。定性類畫像多見於用戶研究等運營類崗位，通過電話調研、網絡調研問卷、當面深入訪談、網上第三方權威數據等方式收集用戶信息，幫助其理解用戶。這種定性類調研相比大數據定量刻畫用戶來說，可以更精確地瞭解用戶需求和行爲特徵，但這個樣本量是有限的，得出的結論也不一定能代表大部分用戶的觀點。

通過制定調研問卷表，我們可以收集用戶基本信息以及設置一個或多個場景，專訪用戶或網絡回收調研問卷，在分析問卷數據後獲取用戶的畫像特徵。目前市場上“問卷星”等第三方問卷調查平臺可提供用戶問卷設計、鏈接發放、採集數據和信息、調研結果分析等一系列功能，如圖1-7所示。

圖1-7 某調研問卷示例（截圖自“問卷星”）

根據回收的調研問卷，可結合統計數據進一步分析用戶畫像特徵（如圖1-8所示）。

圖1-8 回收的調研問卷（截圖自“問卷星”）

小結

本文主要介紹了用戶畫像的一些基礎知識，包括畫像的簡介、標籤類型、整個畫像系統的數據架構，開發畫像系統主要覆蓋的8個模塊，以及開發過程中的各階段關鍵產出。初步介紹了畫像系統的輪廓概貌，幫助讀者對於如何設計畫像系統、開發週期、畫像的應用方式等有宏觀的初步的瞭解。

——本文摘自機械工業出版社華章圖書

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

作者介紹：

趙宏田，資深大數據技術專家。擅長Hadoop、Spark等大數據技術，以及業務數據分析、數據倉庫開發、爬蟲、用戶畫像系統搭建等。著有暢銷書《數據化運營：系統方法與實踐案例》《用戶畫像：方法論與工程化解決方案》。

在文末分享、點贊、在看，給個三連擊唄~~

贈書活動

福利時間： 本期活動爲大家帶來 5 本正版新書。在文末留言區留言談談你對 用戶畫像 的看法， 2020年8月6日20點前 ，我們將在評論點贊超過 5 的留言中選取 5 個最有意思的評論，贈送正版圖書1本。贈書由機械工業出版社華章公司提供，在此表示感謝。注：等不及的小夥伴也可以點擊下面的購買按鈕直接拿下哦。