教你如何最快入門用戶畫像

    你們可能常常會聽到用戶畫像這個詞，可是具體在作的時候又會以爲無從下手，或者認爲只是常規的標籤統計，這每每是一個誤區。本人在某互聯網企業從事了將近一年半的用戶畫像開發。從一個剛剛接觸用戶畫像的小菜鳥，到如今逐漸成長爲畫像開發的主力程序員，中間有許多的感覺與經驗想總結下來，分享給你們，你們也能夠討論討論。

用戶畫像的應用

    用戶畫像是目前數據挖掘當中比較容易入門的一個領域。它比較熱門的應用即是推薦，最近常說的千人千面的核心基礎即是構建人羣的畫像，經過人羣的不一樣畫像來作到個性化推薦。另外廣告也是很是須要用戶畫像的支持，經過個性化的廣告推送，也能夠提升廣告的點擊率，帶來更高的廣告收入。其次用戶畫像不少時候都是能夠作爲銷售的線索打包出售給特定的公司和合做夥伴來直接獲取利潤或者交換數據。

    若是咱們將一個用戶各方面的畫像整合起來使用，它的身份，性別，教育程度，學歷信息，收入大體範圍，購買力，經常使用位置等等標籤一目瞭然，一我的的總體形象就躍然紙上。你有時候會以爲隨着用戶畫像的技術的完善，用戶的隱私會愈來愈少。我目前供職的還僅僅只是一家中型互聯網公司，用戶量也並不是不少，對用戶的各類畫像挖掘就已經到了一個令我震驚的程度，阿里騰訊等大公司的用戶畫像只會作的更加完善。

用戶畫像初相識

    剛開始接觸用戶畫像並不是是個人意願，因此對用戶畫像徹底不瞭解就開始上手了。當時對用戶畫像僅有的直觀影響就是給用戶打標籤，好比一我的是男的仍是女的，有車仍是沒車，喜歡看什麼文章之類的。若是作過機器學習項目的話，會發現這個就是咱們平時本身提取的特徵。事實上剛開始作的話，成天即是寫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 便可。其餘機器學習的知識能夠一邊學習一邊上手。做爲一個程序員，其實我心裏一開始是很不喜歡用戶畫像這個崗位的，畢竟天天重複性的工做很容易讓人疲倦。但他確實也很是的重要，是整個數據挖掘方向最靠近業務的一個方向了。不少時候，深度學習也好機器學習也罷都離業務太遠了，有時候是沒法落地給公司帶來直接的產出，很是容易就被邊緣化了。而且在互聯網行業數據挖掘從業者的平均薪資也還不錯。那麼就經常會有一個問題，數據挖掘部門的總體人力成本很高，可是產出卻至關的低，對於整個公司來看其實也是一個很大的負擔。

   因此對於我我的來講的話，技術是很重要的，可是技術自己是沒有產出的，因此我要儘可能去想辦法讓個人技術有產出而且是能夠度量的。這點落在選擇公司的時候，我更多的也會考慮這個部門有沒有頗有前景的業務，再看這個部門的方向是不是感興趣的。這樣可以最大限度保證個人技術有落地，有產出，不至於被邊緣化，同時也能一直保持我對技術的熱情。