大家可能經常會聽到用戶畫像這個詞，但是具體在做的時候又會覺得無從下手，或者認為只是常規的標簽統計，這往往是一個誤區。本人在某互聯網企業從事了將近一年半的用戶畫像開發。從一個剛剛接觸用戶畫像的小菜鳥，到現在逐漸成長為畫像開發的主力程序員，中間有許多的感受與經驗想總結下來，分享給大家，大家也可以討論討論。
用戶畫像的應用
用戶畫像是目前數據挖掘當中比較容易入門的一個領域。它比較熱門的應用便是推薦，最近常說的千人千面的核心基礎便是構建人群的畫像，通過人群的不同畫像來做到個性化推薦。另外廣告也是非常需要用戶畫像的支持，通過個性化的廣告推送，也可以提高廣告的點擊率，帶來更高的廣告收入。其次用戶畫像很多時候都是可以做為銷售的線索打包出售給特定的公司和合作伙伴來直接獲取利潤或者交換數據。
如果我們將一個用戶各方面的畫像整合起來使用，它的身份，性別，教育程度，學歷信息，收入大致范圍，購買力，常用位置等等標簽一目了然，一個人的整體形象就躍然紙上。你有時候會覺得隨着用戶畫像的技術的完善，用戶的隱私會越來越少。我目前供職的還僅僅只是一家中型互聯網公司，用戶量也並非很多，對用戶的各種畫像挖掘就已經到了一個令我震驚的程度，阿里騰訊等大公司的用戶畫像只會做的更加完善。
用戶畫像初相識
剛開始接觸用戶畫像並非是我的意願，所以對用戶畫像完全不了解就開始上手了。當時對用戶畫像僅有的直觀影響就是給用戶打標簽，比如一個人是男的還是女的，有車還是沒車，喜歡看什么文章之類的。如果做過機器學習項目的話，會發現這個就是我們平時自己提取的特征。事實上剛開始做的話，整天便是寫sql，從數據倉庫以及各種數據來源提取數據，按照一定的處理邏輯來規整數據，最后處理的數據以HIVE 表的形式存到 HDFS，Hbase，Redis。不同的是，我們在某個項目提取的特征只會用於這個項目，一般不會用於其他的地方。但是用戶畫像的一個基本要求畫像必須是可以通用的。就需要有一系列的規范來保證每個字段必須是可解釋的，HIVE 表的命名是有意義，數據的輸出是規范一致的。一切的一切都應該是有文檔來記錄以保證畫像的通用性。
用戶畫像的基本前提
用戶畫像最重要的其實就是用戶了，有人說這個就是廢話。其實不是的，我們做用戶畫像需要獲取這個用戶在我們公司網站 pc端，app，m端(在手機端登錄公司的網站)所有的數據。只有獲取了這個用戶在我們公司所有的數據，我們才能獲取這個用戶在我們公司最完整的畫像，否則這個用戶的畫像就是有失偏頗的，不會那么准。這個問題完全可以通過非技術的手段來解決，比如用一個標志來標識用戶在 pc端，app,和 m端的訪問行為，這個標志一般就是我們所說的公司賬號。有些公司是強賬號體系，比如騰訊的qq號，阿里的淘寶賬戶，微博的微博賬戶，所以這些公司的用戶畫像天然就可以做的比較好。但是大部分公司都沒有這種強賬號體系，厲害如百度迄今也沒有自己的強賬號體系。所以百度掉隊不是沒有原因的。
那么那些沒有自己強賬號體系的公司是不是就沒法開發出自己的用戶畫像體系呢？其實也是可以折衷的，那就是用戶連線。通過各種連接信息，將同一個用戶來自pc端的 cookie，app端的device_id，m端的cookie 數據連接在一起。判斷一個公司的用戶畫像水平基本可以通過用戶連線這一塊了解個大概，這個也是每個用戶畫像部門最核心的算法之一。但是通過用戶連線來做的畫像准確率畢竟比不上有強賬號體系的公司。主要是是因為連線的覆蓋率和准確率一般是矛盾的，如果連線的覆蓋率低了，雖然准確率高了，但是連的用戶少了，比如就連線100個用戶，對整體畫像的准確率不會有明顯的提升。如果連線的覆蓋率上去了，准確率往往會下降，你連線連一堆錯的，還不如不連線。這中間的折衷往往是取決於業務本身的需求。
用戶畫像的類別
用戶畫像一般是分為兩類的。一類是實時用戶畫像，這類畫像的處理邏輯一般都很簡單，要求迅速響應，實時處理。數據從kafaka過來，通過storm 等實時開源框架處理之后存入redis 當中。
第二類便是離線用戶畫像，這類用戶畫像是把當天業務方需要的用戶畫像提前算好，然后供給業務方使用。由於對數據的時效性要求不是那么的高，可以使用較復雜的處理邏輯或者各種離線機器學習模型來保證畫像的准確性。數據一般存在HDFS 和 Hbase 里面。
離線用戶畫像的一般處理邏輯
離線的用戶畫像的數據來源一般是來自采集或者數據倉庫。如果是某些特殊數據的話，可能得先經過反作弊團隊的預處理，比如淘寶的刷單行為，某些品類異常的瀏覽行為等等。我們利用sql 從這些數據源獲取到我們需要的數據以后，首先經過用戶連線將同一個用戶的行為全部連線到一起，然后利用 mapreduce 按照一定的處理邏輯進行處理。處理完的結果可以和歷史的數據進行合並 插入到當天的分區表當中去或者存入到 hbase 當中。整體而言處理的邏輯是比較的清晰的。
圖一 ：用戶畫像處理的一般邏輯
可能有同學會好奇？那么倉庫的數據是從哪里來的。其實都是來自我們日常在這個公司網站點擊，瀏覽，購買，評論等行為。這些數據由公司的前端埋點以后，會不斷的由采集收到倉庫進行整理，整理成當天的流量日志。大部分的畫像標簽的數據源都是流量日志。
用戶畫像的體系建設
單個的用戶畫像很好做，但用戶畫像真正想發揮用途，必須得建立起自己的體系來。這樣才能對一個用戶進行全方面的描述。打包賣給別人的話，也更加值錢。初步來看用戶畫像的體系建設應該包括幾個方面
-
- 標簽系統的頂層設計，具體就是我們這個標簽系統系統需要為哪些業務方服務，需要涵蓋哪些類別，需要做哪些標簽
- 標簽系統的維度系統建設，我們的畫像對外輸出，如果只是輸出中文的話，不大好用，有時候也不大好處理，就需要我們將標簽的輸出的值數值化，維度化。整個標簽系統的值都可以通過一個統一的數值系統或者向量系統來進行描述。
- 標簽開發規范，這個是保證標簽代碼的可維護性，易讀性。
- 標簽系統的可擴展性，由於很多業務方都需要根據自己的需求來定制化標簽，就要求我們的標簽系統應該是可擴展的，外部業務方自己定制的標簽如果符合我們標簽的維度系統以及開發規范，就應該是可以擴展進我們本身的標簽系統的，供給全公司使用。
- 標簽對外平台的開發，所有的標簽最好只能有一個統一的輸出口徑對外輸出，這樣就可以切實保證只有符合我們標簽開發規范的標簽接入其中，同時也能做好標簽系統的權限管理。
用戶畫像當前的困境
目前大部分用戶畫像都是基於統計的方法來做的，這種方法的優點是基礎准確率比較高，但是整體的覆蓋率不會很高。比如我要在一個購物網站做用戶感興趣的商品的畫像。如果我使用基於統計的方法利用用戶在購物網站 pc，m，app端的點擊，瀏覽，下單，購買等一系列用戶行為來對用戶打標簽，只能夠得到用戶關於她／他 已經點擊，瀏覽，下單，購買的商品的畫像。但是其他商品，我雖然沒有點擊，不代表我對這些商品沒有興趣，可是基於統計的方法無法推廣到這些用戶沒用點擊，瀏覽，下單，購買的商品。
基於統計的方法無法進行更深層次的推廣，也就是缺乏我們常說的泛化能力，只會死讀書，不會舉一反三。我們更多的會通過使用機器學習或者其他算法來嘗試解決這個問題。遺憾的是對於業界來說，這種標簽占整個用戶畫像體系的比例也不會很高。因為這種標簽做的費時費力，而且效果不一定好。有一個很關鍵的原因，我們舉一個例子來嘗試說明一下。比如某個汽車網站想預測用戶有車無車，很多時候該汽車網站通過和4s店合作等等途徑能夠獲取到只有哪些用戶確切有車。我們在預測的時候，可以把這些有車的用戶當作正樣本來處理。問題在於我們找不到確切無車的用戶，相當於找不到負樣本。
一般的做法是我們把流量日志當中那些不是確切有車的的用戶都當作無車用戶來看，也就是當做負樣本來看。但是這個只能說明這些用戶只是在該公司的數據庫里是沒有買車的，他現實生活中可能是有車的，但是該公司並不清楚這一點。這樣做的后果就是負樣本里面參入了正樣本，更可怕的是參入的比例有時候我們也不大好估計。這種情況就會導致模型在訓練的時候准確率下降。
這樣看來很多基於機器學習的算法其實都有樣本標注的問題，對於這類標注的問題，一方面我們可以通過其他不同的數據來源，相互驗證來保證標注的數據盡量准確。一方面可以考慮一下無監督的學習算法比如聚類算法來解決這個問題。但是目前來看，還不大清楚有沒有其他比較實用的方式來解決這類問題。
總結
從數據挖掘的不同方向來看的話，用戶畫像應該是最好入門的一個方向之一。它對技術人員的要求是會sql和mapreduce 即可。其他機器學習的知識可以一邊學習一邊上手。作為一個程序員，其實我內心一開始是很不喜歡用戶畫像這個崗位的，畢竟每天重復性的工作很容易讓人疲倦。但他確實也非常的重要，是整個數據挖掘方向最靠近業務的一個方向了。很多時候，深度學習也好機器學習也罷都離業務太遠了，有時候是無法落地給公司帶來直接的產出，非常容易就被邊緣化了。並且在互聯網行業數據挖掘從業者的平均薪資也還不錯。那么就常常會有一個問題，數據挖掘部門的整體人力成本很高，但是產出卻相當的低，對於整個公司來看其實也是一個很大的負擔。
所以對於我個人來說的話，技術是很重要的，但是技術本身是沒有產出的，所以我要盡量去想辦法讓我的技術有產出並且是可以度量的。這點落在選擇公司的時候，我更多的也會考慮這個部門有沒有很有前景的業務，再看這個部門的方向是否是感興趣的。這樣能夠最大限度保證我的技術有落地，有產出，不至於被邊緣化，同時也能一直保持我對技術的熱情。