目錄

0. 相關文章鏈接

1. 用戶畫像是什么

1.1. 畫像簡介

1.2. 標簽型別

2. 資料架構

3. 主要覆寫模塊

4. 開發階段流程

4.1. 開發上線流程

4.2. 各階段關鍵產出

5. 畫像應用的落地

6. 案例展示

6.1. 案例背景介紹

6.2. 相關元資料

6.2.1. 用戶資訊表

6.2.2. 商品訂單表

6.2.3. 埋點日志表

6.2.4. 訪問日志表

6.2.5. 商品評論表

6.2.6. 搜索日志表

6.2.7. 用戶收藏表

6.2.8. 購物車資訊表

6.3. 畫像表結構設計

6.3.1. 日全量資料

6.3.2. 日增量資料

6.3.3. 關于寬表設計

7. 定性類畫像

注：此博文為根據 趙宏田 老師的 用戶畫像·方法論與工程化解決方案 一書讀后筆記而來，僅供學習使用

0. 相關文章鏈接

用戶畫像文章匯總

1. 用戶畫像是什么

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

1.1. 畫像簡介

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

大資料己經興起多年，其對于互聯網公司的應用來說己經如水、電、空氣對于人們的生活一樣，成為不可或缺的重要組成部分，從基礎設施建設到應用層面，主要有資料平臺搭建及運維管理、資料倉庫開發、上層應用的統計分析、報表生成及可視化、用戶畫像建模、個性化推薦與精準營銷等應用方向，
很多公司在大資料基礎建設上投入很多，也做了不少報表，但業務部門覺得大資料和傳統報表沒什么區別，也沒能體會大資料對業務有什么幫助和價值，究其原因，其實是“資料靜止在資料倉庫，是死的”，
而用戶畫像可以幫助大資料“走出”資料倉庫，針對用戶進行個性化推薦、精準營銷、個性化服務等多樣化服務，是大資料落地應用的一個重要方向，資料應用體系的層級劃分如下圖所示，

1.2. 標簽型別

用戶畫像建模其實就是對用戶 “打標簽” ，從對用戶打標簽的方式來看，可以分為如下三種：

1、統計類標簽
這類標簽是最為基礎也最為常見的標簽型別，例如，對于某個用戶來說，其性別、年齡、城市、星座、近7榷訓躍時長、近7榷訓躍天數、近7榷訓躍次數等欄位可以從用戶注冊資料、用戶訪問、消費資料中統計得出，該類標簽構成了用戶畫像的基礎，

2、規則類標簽
該類標簽基于用戶行為及確定的規則產生，例如，對平臺上“消費活躍”用戶這一口徑的定義為“近30天交易次數大于等于2”，在實際開發畫像的程序中，由于運營人員對業務更為熟悉，而資料人員對資料的結構、分布、特征更為熟悉，因此規則類標簽的規則由運營人員和資料人員共同協商確定，

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

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

2. 資料架構

在整個工程化方案中，系統依賴的基礎設施包括Spark、Hive、 HBase、Airflow、MySQL、Redis、Elasticsearch，除去基礎設施外， 系統主體還包括Spark Streaming、ETL、產品端3個重要組成部分，如下圖所示：

在上圖下方虛線框中為常見的資料倉庫ETL加工流程，也就是將每 日的業務資料、日志資料、埋點資料等經過ETL程序，加工到資料倉庫 對應的ODS層、DW層、DM層中，

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

• Hive：存盤用戶標簽計算結果、用戶人群計算結果、用戶特征庫計算結果，
• MySQL：存盤標簽元資料，監控相關資料，匯出到業務系統的資料，
• HBase：存盤線上介面實時呼叫類資料，
• Elasticserch：支持海量資料的實時查詢分析，用于存盤用戶人群計算、用戶群透視分析所需的用戶標簽資料（由于用戶人群計算、用戶群透視分析的條件轉化成的SQL陳述句多條件嵌套較為復雜，使用Impala執行也需花費大量時間），

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

3. 主要覆寫模塊

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

1. 用戶畫像基礎：需要了解、明確用戶畫像是什么，包含哪些模塊，資料倉庫架構是什么樣子，開發流程，表結構設計，ETL設計等，這些都是框架，大方向的規劃，只有明確了方向后續才能做好專案的排期和人員投入預算，這對于評估每個開發階段重要指標和關鍵產出非常重要，
2. 資料指標體系：根據業務線梳理，包括用戶屬性、用戶行為、用戶消費、風險控制等維度的指標體系，
3. 標簽資料存盤：標簽相關資料可存盤在Hive、MySQL、HBase、Elasticsearch等資料庫中，不同存盤方式適用于不同的應用場景，
4. 標簽資料開發：用戶畫像工程化的重點模塊，包含統計類、規則類、挖掘類、流式計算類標簽的開發，以及人群計算功能的開發，打通畫像資料和各業務系統之間的通路，提供介面服務等開發內容，
5. 開發性能調優：標簽加工、人群計算等腳本上線調度后，為了縮短調度時間、保障資料的穩定性等，需要對開發的腳本進行迭代重構、調優，
6. 作業流程調度：標簽加工、人群計算、同步資料到業務系統、資料監控預警等腳本開發完成后，需要調度工具把整套流程調度起來，
7. 用戶畫像產品化：為了能讓用戶資料更好地服務于業務方，需要以產品化的形態應用在業務上，產品化的模塊主要包括標簽視圖、用戶標簽查詢、用戶分群、透視分析等，
8. 用戶畫像應用：畫像的應用場景包括用戶特征分析、短信、郵件、站內信、Push訊息的精準推送、客服針對用戶的不同話術、針對高價值用戶的極速退貨退款等VIP服務應用，

4. 開發階段流程

4.1. 開發上線流程

第一階段：目標解讀

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

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

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

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

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

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

第四階段：應用場景與資料口徑確認

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

第五階段：特征選取與模型資料落表

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

第六階段：線下模型資料驗收與測驗

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

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

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

4.2. 各階段關鍵產出

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

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

5. 畫像應用的落地

用戶畫像最終的價值還是要落地運行，為業務帶來實際價值，這 里需要開發標簽的資料工程師和需求方相互協作，將標簽應用到業務中，否則開發完標簽后，資料還是只停留在資料倉庫中，沒有為業務決策帶來積極作用，
畫像開發程序中，還需要開發人員組織資料分析、運營、客服等團隊的人員進行畫像應用上的推廣，對于資料分析人員來說，可能會關注用戶畫像開發了哪些表、哪些欄位以及欄位的口徑定義；對運營、客服等業務人員來說，可能更關注用戶標簽定義的口徑，如何在 Web端使用畫像產品進行分析、圈定用戶進行定向營銷，以及應用在業 務上資料的準確性和及時性，
只有業務人員在日常作業中真正應用畫像資料、畫像產品，才能更好地推影片像標簽的迭代優化，帶來流量提升和營收增長，產出業績價值，

6. 案例展示

6.1. 案例背景介紹

某圖書電商網站擁有超過千萬的網購用戶群體，所售各品類圖書100余萬種，用戶在平臺上可進行瀏覽、搜索、收藏、下單、購買等行 為，商城的運營需要解決兩個問題：一方面在企業產品線逐漸擴張、 資訊資源過載的背景下，如何在兼顧自身商業目標的同時更好地滿足 消費者的需求，為用戶帶來更個性化的購物體驗，通過內容的精準推薦，更好地提高用戶的點擊轉化率；另一方面在用戶規模不斷增長的 背景下，運營方考慮建立用戶流失預警機制，及時識別將要流失的用 戶群體，采取運營措施挽回用戶，
商城自建立以來，資料倉庫中積累著大量的業務資料、日志資料 及埋點資料，如何充分挖掘沉淀在資料倉庫中的資料的價值，有效支 持用戶畫像的建設，成為當前的重要作業，

6.2. 相關元資料

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

涉及資料倉庫中的表主要包括用戶資訊表、商品訂單表、圖書信 息表、圖書類目表、App端日志表、web端日志表、商品評論表等，下面就用戶畫像建模程序中會用到的一些資料表做詳細介紹，

6.2.1. 用戶資訊表

用戶資訊表（如下表）存放有關用戶的各種資訊，如用戶姓名、 年齡、性別、電話號碼、歸屬地等資訊，

6.2.2. 商品訂單表

商品訂單表（如下表）存放商品訂單的各類資訊，包括訂單編 號、用戶id、用戶姓名、訂單生成時間、訂單狀態等資訊，

6.2.3. 埋點日志表

埋點日志表（如下表）存放用戶訪問App時點擊相關控制元件的打點記錄，通過在客戶端做埋點，從日志資料中決議出來，

6.2.4. 訪問日志表

訪問日志表（如下表）存放用戶訪問App的相關資訊及用戶的LBS 相關資訊，通過在客戶端埋點，從日志資料中決議出來，

6.2.5. 商品評論表

商品評論表（如下表）存放用戶對商品的評論資訊，

6.2.6. 搜索日志表

搜索日志表（如下表）存放用戶在App端搜索相關的日志資料，

6.2.7. 用戶收藏表

用戶收藏表（如下表）記錄用戶收藏圖書的資料，

6.2.8. 購物車資訊表

購物車資訊表（如下表）記錄用戶將圖書加入購物車的資料，

6.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層的用戶行為畫 像，在應用時還需要基于該增量資料做進一步的建模加工，

6.3.1. 日全量資料

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

CREATE TABLE dw.userprofile_attritube_all ( 
	'userid' string COMMENT 'userid', 
	'labelweight' string COMMENT '標簽權重'
)
COMMENT 'userid 用戶畫像資料'
PARTITIONED BY (
	data_date string COMMENT '資料日期',
	'theme' string COMMENT '二級主題',
	'labelid' string COMMENT '標簽 id'
)

這里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'來實作，

6.3.2. 日增量資料

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

CREATE TABLE dw.userprofile_act_feature_append (
	labelid STRING COMMENT '標簽 id',
	cookieid STRING COMMENT '用戶id',
	act_cnt int COMMENT '行為次數',
	tag_type_id int COMMENT '標簽型別編碼',
	act_type_id int COMMENT '行為型別編碼'
)
comment '用戶畫像-用戶行為標簽表'
PARTITIONED BY (data_date STRING COMMENT '資料 日期')

這里，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'查詢，

該日增量的表結構記錄了用戶每天的行為帶來的標簽，但未計算 打在用戶身上標簽的權重，計算權重時還需做進一步建模加工，

6.3.3. 關于寬表設計

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

用戶屬性寬表

用戶榷訓躍寬表設計

7. 定性類畫像

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

通過制定調研問卷表，我們可以收集用戶基本資訊以及設定一個 或多個場景，專訪用戶或網路回收調研問卷，在分析問卷資料后獲取 用戶的畫像特征，目前市場上“問卷星”等第三方問卷調查平臺可提 供用戶問卷設計、鏈接發放、采集資料和資訊、調研結果分析等一系列功能，如下圖所示，

根據回收的調研問卷，可結合統計資料進一步分析用戶畫像特征 ，如下圖所示：

注：再次宣告，此博文為根據 趙宏田 老師的 用戶畫像·方法論與工程化解決方案 一書讀后筆記而來，僅供學習使用

注：其他相關文章鏈接由此進 -> 用戶畫像文章匯總