關於用戶畫像產品構建和應用的幾點經驗

貝聊是一款提供給幼兒園使用的APP，兼具「工具屬性」、「社交屬性」和「資源屬性」，主要的用戶構成是家長和老師。APP裡面除了常見的工具屬性功能外，還有類似於微信朋友圈的動態發布功能，也有類似於小米論壇的貝聊社區討論模塊，更有類似於慕課網的孩子學習課程資源平台，等等；所以貝聊的數據對象、數據主題、數據類型、數據維度和數據關係都十分豐富，面對數據應用業務場景也很多。這種背景下，如何串聯起來各種應用場景、如何找到數據應用中心環節、如何構建彈性的數據產品體系、如何滿足業務靈活多變的數據需求，等等問題立馬就凸顯出來，十分尖銳。以一系列的畫像產品為核心，構建育兒大數據生態體系，串聯各類數據應用場景，是貝聊大數據提出的解決方案之一！

同時，因為貝聊用戶高活躍度的特點，所以用戶行為數據的增長几乎呈指數化上升，目前每月的高價值用戶行為數據規模增長量已是TB級。這些數據的積累為畫像產品的構建打下了重要基礎，也是畫像產品可行性論證的重要指標（數據規模、數據顆粒度、數據頻率、數據價值、數據有效性……）。

在這裡，我們暫不分享具體的技術細節（留給後面幾期文章），只跟大家聊一聊畫像產品的構建思路、組成架構、應用方案和一些值得注意的事項，拋磚引玉!這些都是偏向於宏觀的東西，但如果理不清這些東西，這個畫像產品是無法構建好的，畢竟業內尚未有公開的成體系的成熟、權威方案，各家各路都在探索。

畫像產品體系包括用戶畫像、內容畫像、消息畫像等等各個子畫像，不同對象就有不同的畫像，此文主要以用戶畫像為案例展開介紹，部分地方也會涉及到一些其他畫像。

一、 n追本溯源，應用為王

nn

畫像產品的構建好不好、全不全、彈性夠不夠，很多時候不是技術問題；關鍵就在於一開始應用的場景有沒有想好、想全、想細，其次就是對自家數據的價值剖析對不對。不同的應用思路，就會有不同的畫像產品形態；不同的數據價值，就決定了畫像產品能實現到什麼程度。提前想好這些，就會有前瞻性，畫像產品體系後期的整合就更有利，開發過程的節奏就更合理。

就貝聊來說，畫像產品的應用，主要聚焦在以下幾方面：

1、 n用戶分析/研究需要：

畫像產品需要提供單一用戶全景視圖，滿足單一用戶的行為細緻分析、用戶調研、發燒友使用習慣研究、活動籌備等方面需要；同時，需要提供用戶行為分析、用戶特徵洞察、用戶規模分析等系列報表，方便業務及時監控用戶數量變化、用戶行為變化、用戶特徵表現等等。

2、 n用戶運營和管理需要：

畫像產品需要提供用戶特徵標籤、用戶群體細分、用戶需求預測等方面結果，支撐用戶分層管理、用戶社群管理、用戶精細運營，甚至用戶個性化運營等各類用戶管理和運營業務需要。

3、 n精準廣告投放需要：

畫像產品需要結合用戶全景視圖、用戶標籤結果、推薦結果等各方面數據，提供一套能快速查詢、精準篩選的DSP廣告投放工具，支持商業部門靈活、精準廣告投放需要。

4、 n精準營銷/服務需要：

畫像產品的用戶全景視圖梳理是行為預警功能的基礎，方便服務類型的業務能根據用戶的行為變化，及時提供貼心周到的用戶關懷、挽留、激勵服務需要；同時用戶的標籤構建，需要覆蓋用戶的各類偏好、用戶的所屬地區等等，方能為公司的用戶獲取、營銷策劃提供支持。

5、 n產品/內容運營需要：

畫像產品需要提供諸如課程推薦、商品推薦、帖子推薦等個性化預測結果，以清單方式，提供給產品、內容運營團隊直接應用。

從應用訴求出發，提煉畫像產品的主要功能更加到位和實用，總的來說至少要有：用戶全景視圖、用戶研究報表、用戶特徵標籤、用戶推薦引擎等等！

二、 n產品功能，各自為政

nnnnnnnnnnnnnnnnnnnnnnnnnn畫像產品的主要組成模塊比較多（如下圖），每一個模塊都有很多的子功能，涉及的數據鏈路比較長，相互間依賴關係比較複雜。要保證畫像產品的穩定性，必須提前規劃好主要功能模塊，做到各模塊之間儘可能的各自為政，以免出現「一步錯、步步錯」或者「一著不慎、滿盤重構」的不利局面。

1、 n數據倉庫：

畫像產品的數據覆蓋面非常廣，數據計算任務非常多，幾乎聚攏了業務系統的所有數據。做畫像產品前，必須構建統一的數據倉庫，對數據集市按對象、主題、類型進行切分，提高後續鏈條的數據查詢、數據計算、數據存儲等效率。

經驗來說，畫像產品構建初期，數據倉庫也會進行幾次的重構才能最終穩定下來，主要是因為業務的快速變化引發數據主題的變化造成的；所以其他模塊要做到彈性兼容，以免數據底層重構，所有模塊都要重構。

2、 n用戶全景視圖：

數據倉庫構建後的用戶全景視圖的構建，技術上來說幾乎沒有難度，需要注意的地方是用戶全景視圖的構建不單單是用戶的個人信息、用戶的行為明細數據，還會包括用戶標籤的識別結果、用戶的推薦結果等等。同時，如果公司有明顯類型區分的用戶時候，用戶全景視圖是很難統一的，建議區別構建，會有意想不到的好處；例如貝聊就有家長、寶寶、老師、幼兒園等用戶對象，不同對象的行為和標籤等數據差異很大，全景視圖展示也無法統一；切開做後，再關聯，複雜度快速下降，實效很多。

另一個相對麻煩少許的地方就是用戶規模上去後、用戶行為數據沉澱量很大的情況下，允許的查詢方式和查詢條件又很多，數據查詢速度會比較慢。技術可選方案很多，各有利弊，這裡不做詳述！

3、 n標籤引擎構建：

用戶標籤是用戶畫像產品的核心組成部分，應用最靈活、應用面最廣、應用頻率最高。構建標籤引擎前，標籤體系的構建必須要確定清楚，並且要儘可能的設計好，否則以後應用起來很麻煩，重構成本也非常大。

上圖是貝聊的標籤體系劃分，不同的對象有不同的標籤分類體系（裡面還會分子目錄），例如用戶畫像：基本屬性主要囊括用戶個人信息方面的出來的標籤（如：地理、性別）；群體屬性主要囊括用戶在群體細分方面出來的標籤（例如大V、話題製造者）；行為屬性主要囊括用戶在行為表現和偏好方面的標籤（例如愛點贊、愛發圖）；綜合屬性主要囊括用戶在多方綜合後得出的標籤（例如生命周期、用戶價值）。以貝聊的實踐經驗，群體細分時候，千萬不要僵化思考，作繭自縛，不同的細分方向就會有不同的群體類型標籤出來，所以會有很多群體類型標籤！

關於用戶標籤的具體識別，目前很多公司經常喜歡利用數據挖掘模型進行識別（顯得高大上？），其實不然，有時費時費力效果還不好。用戶標籤的妙處就在於輕量化應用，像便簽一樣，隨手可用，生命周期不長、靈活度高、覆蓋面廣、容易理解、實用效率高才是重要的。僅僅依賴數據挖掘模型構（如，聚類演算法）建出來的標籤很難滿足現實需要，目前貝聊構建的用戶標籤已有幾百個，還在持續增加，下面談談貝聊的標籤識別經驗：

1） 基於規則型的人物特徵標籤識別技術

這類方法識別的標籤應該是最多的！主要應用於較為直觀或有清晰業務規則的人物標籤，例如地域所屬、家庭類型、年齡層等等。技術特點是直接有效靈活、計算複雜度低和可解釋度高，單個標籤涉及到的規則條件一般不超過3條，使用到的技術知識主要是數理統計類知識，例如基礎統計、數值分層、概率分布、均值分析、方差分析等等。

2） 基於模型類的人物特徵標籤識別技術

主要應用於通過簡單的規則條件之間組合無法有效識別的人物標籤，但是識別出來的標籤價值非常大，一般作為基礎應用類型標籤，標籤的生命周期很長，例如行為偏好、性別預測、群體細分等等。

基於模型類的標籤技術特點是綜合程度高、複雜程度高；絕大部分標籤需要先有針對性地構建相應的挖掘指標體系，依託經典數學演算法或模型進行多指標間的綜合計算方能得到特徵標籤，常常需要多種演算法一起組合來建模。其中涉及到的經典演算法技術主要有熵值法、層次分析法（處理模型權重問題），聚類分析等（處理分類和歸集問題），回歸分析、時間序列等（處理預測等問題），等等。

3） 基於演算法型的人物特徵標籤識別技術

主要應用於特定類場景或特定類數據的人物標籤識別。例如應用卷積神經網路和機器學習演算法技術對孩子在幼兒園的活動參與圖片進行識別，判斷圖片中幼兒周圍的同伴數量，以此推斷幼兒的社交活躍情況和性格（例如：活躍型、孤僻型等等）。

基於專類演算法的標籤技術特點是專業性強、針對性強、聚焦度高，部分場景下能批量輸出一系列的人物標籤。其中涉及到的專業技術主要有圖像識別技術、音視頻分析技術、文本分析技術等等，演算法層主要有神經網路、機器學習、社群發現演算法、語義分析演算法等等。

4、 n推薦引擎構建：

目前業內已經有很多的推薦演算法在應用，效果參差不齊，作者認為最大的問題在於很多人過度依賴演算法解決問題，試圖用一套演算法解決所有推薦問題，而不是把推薦當做一套引擎（或系統）來做。每一套演算法背後都有一套推薦思想和邏輯在驅動，例如協同過濾演算法背後的思想就是物以類聚或人以群分。但是每個演算法都有自己的適用領域，只能解決自己領域內的推薦問題，例如很多推薦演算法都存在冷啟動問題（新用戶沒有數據怎麼推薦？），這是沒法調和的，所以強行適用就造成了一種尷尬，推薦的還沒有猜的准。

要想推薦的准，我們必須放開思路，從多演算法組合的思路出發，各自演算法解決各自領域問題。以貝聊的實踐經驗來看，推薦的思想就是「演算法組合+策略組合」，這套思想非常靈活，原理上演算法和策略都可以無限載入和刪除。

1） n推薦演算法引擎

主要容載各個推薦演算法，每個推薦演算法輸出自己的推薦結果以及得分；每個演算法聚焦自己推薦問題領域的結果準確性，有些是解決新用戶推薦問題的，有些是解決特殊場景推薦問題的，有些是解決業務依賴推薦問題的，不一一詳述，以作者的經驗，一般推薦組合中會有一套演算法是重磅的、作為演算法組合的母機！

推薦演算法組合，關鍵要點是要解決好各演算法推薦結果的得分量級一致性，意思是各演算法的推薦結果得分要有可對比性，這個不難，不做詳述。

2） n推薦策略引擎

主要容載各個推薦策略，需要區分不同的用戶群體，每個群體適用不同的演算法（通過權重分配），群體的劃分，可以通過用戶標籤來指定（可以通過開發一個工具，打通策略引擎和標籤引擎，進行快速配置推薦策略）。每條策略一定要有效期，否則無法進行策略的生命周期管理，有些策略生命周期很短的，例如節日期間的推薦策略，一般只適用這個節日前、中兩個階段，過了就要過期了。

3） n演算法權重自分配機制

對具體用戶來說，每條策略的各演算法組合的權重是不同的，可以在配置策略的時候根據經驗主觀敲定，這種方法不利的地方，是無法及時有效的跟隨用戶的行為和需求變化（人是善變的！），作者偏好採用權重自分配調節機制。

作者的實踐經驗是，可以根據推薦的效果進行權重的自調節，例如新聞推薦：如果用戶對演算法組合中的一個演算法的推薦結果不感冒（點擊率低），則這個演算法分配的權重自動降低一點（分配到效果好的演算法上面去），經過一段時間後，該用戶的推薦策略的演算法權重分配就會穩定下來，並且可以自動化動態調整（跟隨用戶行為變化而變化），不用人為干預！

以上這些是貝聊構建畫像產品主要模塊實踐過程中積累的一點小小的經驗，權當拋磚引玉，跟大家一起交流和討論！