一、 用戶畫像的用途
1. 推薦 通過人群的不同畫像來做到個性化推薦。
2. 廣告 通過個性化的廣告推送，也可以提高廣告的點擊率，帶來更高的廣告收入。
3. 銷售 做為銷售的線索打包出售給特定的公司和合作伙伴來直接獲取利潤或者交換數據。
二、 用戶畫像的分析范疇
1. BI分析：寫sql，從數據倉庫以及各種數據來源提取數據，按照一定的處理邏輯來規整數據，最后處理的數據以HIVE 表的形式存到 HDFS，Hbase，Redis 大部分用戶畫像都是基於統計的方法來做的，這種方法的優點是基礎准確率比較高，但是整體的覆蓋率不會很高。
2. 算法分析：使用機器學習或者其他算法來嘗試解決問題，進行更深層次的推廣。遺憾的是對於業界來說，這種標簽占整個用戶畫像體系的比例也不會很高。因為這種標簽做的費時費力，而且效果不一定好。
3. 非結構化分析：文本nlp、 圖像等類型可使用深度學習。
三、 用戶畫像建模流程圖
四、 用戶數據准備
用戶畫像的數據來源一般是來自采集或者數據倉庫，大部分的畫像標簽的數據源都是流量日志。其中包括網絡日志數據，用戶行為數據，網站交易數據等。
如果公司沒有自己強賬號體系，要進行用戶連線。通過各種連接信息，將同一個用戶來自pc端的 cookie，app端的device_id，m端的cookie 數據連接在一起。用戶連線這一塊也是每個用戶畫像部門最核心的算法之一
例如：銀行數據
五、 標簽體系構建
1. 標簽分類
靜態標簽
人口屬性
動態標簽（有時限）
興趣愛好 消費意向 商業人口屬性 行為屬性 CRM 等
交叉標簽
2. 標簽分級
3. 標簽體系類型
1) 結構化標簽體系：標簽樹過深則不利於處理 不宜過深
2) 半結構標簽體系：結合一些描述標簽
3) 非結構化標簽：不方便檢索 常用於搜索
六、 用戶畫像分類
1. 根據范圍
分為 個人畫像 群體畫像
2. 根據是否實時
實時用戶畫像:這類畫像的處理邏輯一般都很簡單，要求迅速響應，實時處理。數據從kafaka過來，通過storm 等實時開源框架處理之后存入redis 當中。
離線用戶畫像:這類用戶畫像是把當天業務方需要的用戶畫像提前算好，然后供給業務方使用。由於對數據的時效性要求不是那么的高，可以使用較復雜的處理邏輯或者各種離線機器學習模型來保證畫像的准確性。數據一般存在HDFS 和 Hbase 里面。
七、 模型規則
優先要將用戶數據進行規整處理，轉化為相同維度的特征向量，之后可進行機器學習算法處理，包含文本挖掘，自然語言處理，機器學習算法等 常用如：關聯性分析 RFM模型，建立眾多模型，最終要形成用戶體系。
八、 用戶畫像的體系建設
1. 標簽系統的頂層設計
具體就是我們這個標簽系統系統需要為哪些業務方服務，需要涵蓋哪些類別，需要做哪些標簽
2. 標簽系統的維度系統建設
我們的畫像對外輸出，如果只是輸出中文的話，不大好用，有時候也不大好處理，就需要我們將標簽的輸出的值數值化，維度化。整個標簽系統的值都可以通過一個統一的數值系統或者向量系統來進行描述。
3. 標簽開發規范，這個是保證標簽代碼的可維護性，易讀性
有一系列的規范來保證每個字段必須是可解釋的，HIVE 表的命名是有意義，數據的輸出是規范一致的。一切的一切都應該是有文檔來記錄以保證畫像的通用性。
4. 標簽系統的可擴展性
由於很多業務方都需要根據自己的需求來定制化標簽，就要求我們的標簽系統應該是可擴展的，外部業務方自己定制的標簽如果符合我們標簽的維度系統以及開發規范，就應該是可以擴展進我們本身的標簽系統的，供給全公司使用。
5. 標簽對外平台的開發，所有的標簽最好只能有一個統一的輸出口徑對外輸出
這樣就可以切實保證只有符合我們標簽開發規范的標簽接入其中，同時也能做好標簽系統的權限管理。
九、 應用技術
1. 原始數據存儲
Hadoop
2. 計算
Spark SQL
SQL類型的統計信息分析用戶是否可以被打上標簽
如：APP、瀏覽A產品超過10次以上
一般需要過濾數據 過濾標准如：瀏覽a產品pv/用戶當天瀏覽所有產品瀏覽pv匯總。
spark mlib 貝葉斯算法預測類標簽
違約概率，性別概率
標簽加概率 提取數據時可根據概率范圍篩選
3. 用戶畫像存儲
hbase或（mongoDB）
標簽達到上千 不適合存在數據庫 一般存在hbase或（mongoDB）
存儲格式如： Key:用戶id cf ：sport:nba:0.9 movie:action 0.8
Es
檢索(hbase mongodb api比較慢)
十、 銀行案例
銀行應用用戶畫像時，營銷增值效果時比較差，但是降低成本效果比較明顯。