趙宏田：用戶畫像場景與技術實現

分享嘉賓：趙宏田 大數據架構師

編輯整理：蘇麗萍 彩訊股份

出品平臺：DataFunTalk

**導讀：**感謝 DataFunTalk 和一個數據人的自留地的邀請，今天和大家分享的主題是用戶畫像的場景與技術實現方案。主要分三大部分：

• 用戶畫像常見應用場景

• 畫像產品功能

• 技術實現方案

01

常見應用場景

1. 畫像常見的應用場景

不同行業業務屬性不同，能採集到的數據源也不同，對畫像的應用場景有不同的需求，下面梳理互聯網 TOC、電商和安防等行業的畫像應用場景，提供畫像應用思路。

常見的 360 全息畫像，就是給一個人打完全部標籤之後，輸入 ID 可以返回這個人的全部標籤，看到這個人的全息畫像，然後基於標籤做個性化內容推送和消息推送，以及提供實時管控預警、專項場景分析。比如我們常見的事件分析、漏斗分析等數據分析模型，其實都是基於標籤和行爲數據，把數據模型產品化之後做成的特定場景分析，提供個性化的運營服務支持。

不同行業有不同側重點，主要源於不同行業採集到的數據源不同、不同行業的應用場景不一樣。

• 互聯網 toC 覆蓋範圍非常廣，能採集到數據包括用戶註冊身份信息、用戶強認證信息（比如身份證、銀行卡等）、用戶在 APP 站內的行爲數據、填寫表單的維度數據等。互聯網 toC 的場景化主要包括，給 C 端用戶推薦站內的內容資訊，向用戶推薦適合的個性化服務，SOP 標準化營銷流程。

• 電商也類似，主要基於用戶的註冊信息、站內行爲數據和基礎屬性數據爲用戶提供服務，常見的發短信、發郵件、APP 的消息彈窗等，以及給用戶提供個性化的 VIP 服務。

• 安防場景的很多，比如用戶的基礎身份信息、出行數據、人臉識別數據等，基於這些數據給每個人建安全的全息檔案畫像。安防有自己行業特性的分析場景，針對一些重點部位、人的行爲軌跡等等。也會有實時的安防布控，去告誡可能潛在風險的人員，做提前的預警管控。

• 互聯網金融服務，比如收集用戶的註冊信息、站內行爲數據、用戶的強行證明數據、用戶手機裝載的 APP 數據等，這些數據可以對每個人做 360 度畫像，以及管控潛在的風險賬號，比如多頭借貸，多次違約等等，還可以基於建立的畫像提供服務，包括評估個人還貸水平、違約等級等，根據評估來決定給用戶提供對應的運營策略。

上面講的比較概念化，下面詳細講解幾個具體場景。

① 互聯網 TOC——微信場景（1）

• 渠道活碼：用企業微信沉澱顧客，可以在每個渠道都附上帶活碼的渠道專屬二維碼，比如在自己的公衆號、朋友圈廣告、企業官網以及其他物料上都附上二維碼，將前來諮詢新來客戶都引進到企業微信，這些客戶會被隨機分配給某個員工，這樣既能保證員工工作的公平，又能避免單個號當日加人達到上限的情況。用戶在掃碼過程中會被自動打上標籤，標識渠道來源。

• 觸發歡迎語：給用戶打上標籤，標識渠道來源之後，可以觸發歡迎語。用戶掃碼添加企業成員後，自動推送指定消息，可以實現個性化推送一人一語，支持同一個碼不同員工推送回復不同的內容，幫助企業實現精細化運營，快速轉化。

• SOP 推送：SOP 是 Standard Operating Procedure（標準化的運營流程）。SOP 推送是微信私域運營的一個重要工具 / 手段，可以給不同類型的客戶在不同時間段推送不同的內容。比如基於給新加用戶打的標籤來實現定時推送個性化消息，當用戶掃描渠道碼後，打上線上新人標籤，後臺先配置好運營推送策略，定時推送內容拉動活躍。

② 互聯網 TOC——微信場景（2）

基於羣、基於個人的個性化 SOP 推送包括先給人或者給社羣打標籤。創建任務給不同標籤的人或者社羣推送不同的個性化內容。比如基於一些標籤創建某些定時任務，給某一批標籤的人或某一批標籤的羣做定時推送，維護整個社羣的活躍程度，以及促進用戶在不同階段的轉化。

這裏截圖了某 SCRM 廠商的功能宣傳頁，我們都知道 CRM 是客戶關係管理，SCRM 就是 Social CRM。

國內 SCRM 基本都是基於企業微信場景做的功能，常見場景：前期基於渠道活碼、裂變獲客、抽獎引流、自動標籤、自動回覆等的引流工作；後期基於標籤、基於來源渠道，做定製化的高效溝通；高效溝通完成之後，SCRM 去做智能化的定向營銷，比如 SOP 定向營銷、個性化的羣聊推送、個性化朋友圈。

在電商，零售，教育培訓等不同行業，都有基於微信場景的 SCRM 產品做一些行業的東西。這種也是基於用戶畫像、用戶標籤做的一種應用，這種應用的數據量級比較輕，基於單機的應用就可以做後臺的數據處理過程，這種小數據也是跨站的一種重要的組成部分，也有很廣闊的應用場景，我們日常接收到的一些快銷產品的短信，很多也是基於輕量級的 SCRM 場景去實現功能。

③ 電商場景

電商場景包括如下幾種：

• 短信推送營銷：比如在京東買過書、保健產品、在優衣庫買過衣服後，商家會做定期推送。通常隔兩三個月會收到推送短信，告知優惠信息，通知續買。還有像京東阿里平臺的商家也會自建或採購第三方輕量級 SCRM 產品，把自身在京東淘寶的商鋪數據接到第三方產品做定時的智能化營銷推送以及郵件推送。

• 郵件推送營銷：郵件推送現在用的比較少了，當然也是很重要的場景，比如買了阿里雲服務，經常收到阿里雲定時推送的營銷郵件。

• Push 消息：有幾個應用場景，一是促活，根據用戶瀏覽內容進行推薦，用戶感興趣點擊查看，可以促進用戶在站內的活躍；二是促進轉化，當用戶活躍度高之後，可能會多瀏覽廣告或者帶來下單轉化。通常基於自己產品做 Push 消息配置是免費的，而像郵件短信則是有渠道成本的。

④ 安防場景

安防場景能採集到的數據源非常多，包括物聯網和信息網的數據。主要用途是安防管控抓捕壞人，或者預防潛在的壞人做壞事。比如我們近期看到的抓捕犯罪分子新聞，基本是基於人臉識別來識別，然後再和後臺預警管控的名單做實時數據比對校驗，當比對相似度大於某個閾值時會觸發預警，後續視情況進行人爲干預。

這種安防場景在我們生活中有很多，比如識別不當言論去管控潛在的風險犯罪分子，以及去識別犯罪分子駕駛的車輛。人臉的面部識別、基於車牌號的識別其實都類似，都可以基於潛在風險的身份信息去做預警管控。

2. 關於畫像場景的一些思考

① 畫像場景總結起來，包括：

• 營銷賣貨：短信 / 郵件 / 電話 / 微信等各種渠道的營銷來賣貨。

• 營銷促活：同樣是各種渠道的營銷來把用戶拉 / 引到平臺上，有人活躍的地方就有流量就有生意。

• 個性化服務：這裏不僅指個性化推薦（比如淘寶上推薦商品，基於用戶瀏覽或購買過興趣類似或同類的商品，比如抖音快手上基於看過的視頻內容推薦相似內容），也包括個性化的人工客服、個性化的接口服務。

• 用戶分析：基於用戶在平臺上的行爲特徵來分析產品的優缺點、做產品迭代。

• 預警管控：基於不同行業不同應用場景來設計預警管控的模型，實現對潛在風險的預警與預防。比如識別潛在的風險賬號，把賬號直接拉黑名單；比如直接識別出風險用戶，直接做人工的干預管控，這也是預警管控，基本是基於實時數據對前方風險去做預防。

② 一直在 toC 類型的互聯網公司從事大數據類的工作，接觸到的用戶量或行爲日誌數據都是大幾千萬、幾億、幾十億、百億規模的數據處理，用到的技術棧也是 hive、spark、hbase、es、clickhouse 這些梳理大量數據的開源工具。但不是隻有大數據才能做畫像。

③ 最近在研究基於微信生態的 SCRM 類產品時發現，這類產品處理的數據量很小，不需要很重的大數據生態組件，但同樣可以實現基於特定場景 / 生態下的客戶營銷管理，同樣有廣闊的應用市場。對接淘寶、京東等商家後臺數據提供 CRM 功能的廠商也是，在畫像這塊處理的數據量有的用不上大數據組件。

02

畫像產品功能

畫像產品功能主要包括標籤的元數據管理、單用戶畫像、人羣篩選、人羣分析等。

1. 標籤的元數據管理

元數據管理來說，產品設計形態上可能會有各有不同，基於用戶屬性、用戶行爲，來做 123 級目錄分類的標籤元數據管理。

在元數據詳情頁可以查看標籤的源數據信息、標籤每天的產出量、標籤在所屬大類下的覆蓋率等。

在元數據編輯頁面可以對目前平臺上的標籤信息進行增刪等編輯。

2. 單用戶畫像

單用戶畫像，我們給每個人打上標籤後，在運營時或通過接口形式輸入用戶 ID，可查詢到這個人的全量標籤。

應用場景大致兩種：一種是分析場景，即分析師 / 業務人員基於一個或某幾個用戶 ID 做具體的查詢分析，這種通常是公司內部業務後臺作爲分析自用；另一種是客戶端接口調用，即通過線上服務接口請求方式傳入用戶 ID 查詢標籤，這涉及到高併發。這兩種應用場景，對數據服務能力要去是不一樣的，前者不涉及併發，後者涉及高併發，需要單獨部署兩套。

3. 人羣圈選

基於標籤組合及標籤的規則定義進行人羣圈選，即基於維護的標籤元數據信息、組合標籤及條件篩選、即席查詢符合特徵覆蓋到的人羣數量、保存查詢條件下用於下階段的運營推送。

4. 人羣分析

人羣分析：可以從多個維度透視分析人羣特徵。分析維度可以通過預製設定來自動生成分析報表，也可以自主篩選。選擇分析人羣、選擇分析的維度、分析的結果，可以進一步查看對應的用戶列表和標籤詳情。

5. 行爲分析

行爲分析模型是基於分析場景對數據的抽象。例如常見的留存分析、事件分析、分佈分析、漏斗分析等等，本質上是基於用戶行爲日誌 + 用戶屬性數據，來對用戶從多個分析維度進行分析。直白說就是將分析師常寫的分析 SQL 固化成產品和數據模型來實現，省去人工介入的時間。

現階段還沒有做行爲日誌的採集，一方面需要把日誌這塊缺漏補起來，另一方面 TOB 的行爲分析模型和互聯網 TOC 的這些分析模型也不盡相同，對於 TOB 經常需要做哪些分析還需要分析師整理提煉出來，再把常用到的分析固化成產品。

6. 基於標籤的 SOP

基於標籤的 SOP 是標準化運營流程，例如 SOP 在 SCRM 產品的場景中，基於企業微信給微信用戶打的標籤，通過設置給這些標籤用戶制定的運營策略來實現自動推送消息。

03

技術實現方案

1. 畫像系統整體數據流程

畫像系統中最重要的環節除了理清應用場景外，就是要理清整個系統的數據流向。

從項目全貌來說，我們首先是收集日誌和屬性數據，從線上業務庫抽取業務數據、或從日誌服務器抽取日誌數據，把抽取的數據放到數據倉庫裏。然後基於收倉的數據打標籤、建模和行爲主題的寬表建立。數據倉庫層面一般分多層，比如 ods 做基礎標籤，dws 層做直接推送到服務層的數據。

業務數據庫接入的數據、爬蟲外部抓取的數據都放在數倉的 ods 層。基於 ods 層數據圍繞應用場景進行數據建模後，把數據模型結果寫入到 dws 層，然後推送到各服務層需要調用的數據庫，以備線上 OLAP 分析、接口服務的調用。

2. 畫像系統的藍圖

畫像系統的技術藍圖包括標籤規劃、數據開發、應用場景等。畫像系統最終上線後，是一套完整的數據模型和應用流程。後續新增加的標籤或應用場景可以在現有的框架內增加流轉起來。

• 標籤規劃：由產品經理或業務人員基於公司的業務場景把整個標籤體系梳理出來。

• 數據開發：由數據開發人員或數倉人員基於梳理好的標籤體系開發對應的標籤，跑離線標籤以及跑實時任務。就數據開發來說，實時數據和離線的大部分標籤都是 T+1 的離線標籤。離線標籤又分爲基於統計類型的標籤和基於算法性標籤，大部分或者 90% 的標籤都是統計類型標籤，像機器學習的算法標籤很少，一方面是開發週期很長，另一方面效果也有限。但是基於某些場景，還是得需要使用機器學習，只是機器學習標籤的比重會很小。有時我們做實時數據支持，會通過實時數據流給用戶做刻畫或者做特徵標記，可做線上服務接口調用查詢。用戶維表是一張大寬表，大寬表基於篩選用戶的屬性或分析師分析用戶的時候用。除了標籤跑批、用戶維表，還有人羣計算、行爲數據等的數據開發。

• 應用場景：開發完數據後，再推送到應用場景，包括人員 360 視圖、人羣圈選、人羣分析、SOP 運營、內容推薦等場景。我們基於應用場景做迭代效果反饋之後，再反饋給標籤規劃以及數據開發，再優化數據標籤以及數據開發的流程，這是整個應用的藍圖。

3. ETL 調度模型示例

ETL 調度模型包括標籤的加工計算、數據標籤的校驗、人羣計算、跑一些分析寬表。跑完數據模型後，推薦到線上服務層，比如 Redise、Clickhouse、ES ，分到服務層做服務的調用，包括站內的服務調用以及 TOC 的客戶端服務調用。

站內的服務調用即公司內部的運營或產品人員用於分析、用於營銷；TOC 的客戶端服務調用則是瀏覽頁面點擊時產生請求，客戶端調用涉及到高併發的場景，需要單獨處理接口服務。

4. 技術棧劃分

畫像系統技術主要包括大數據 + 應用服務。大數據從存儲類型、開發語言、開發內容來了解；應用服務從技術選型與框架、開發內容來了解。

5. 技術棧難點

技術棧難點分兩塊來說明：

• 第一塊是大數據，從查詢速度來講，畫像相關的查詢有很多場景，比如單用戶畫像查詢、基於行爲事件的分析、組合標籤查詢、實時查詢等。不同的場景需要考慮到用不同的工具去存儲，比如 es 適合關鍵詞檢索、redis/hbase 適合單用戶查詢、clickhouse 適合多維度 OLAP 分析等；從調度時間來考慮，用戶基數規模較大的公司一般每天日誌量很大，跑標籤計算、跑數據服務的時間也會相對的較多。需要做一些優化來減少數據調度時間。

• 第二塊是應用服務，從後臺應用來說，後臺應用就指單用戶畫像、行爲時間分析、標籤管理等方面的產品端，這塊一般沒有什麼難點，就是後臺應用的增刪改查，面向的使用者也是企業內部人員；從數據服務角度，指標籤畫像數據的接口調用，比如線上服務請求某用戶的標籤數據。如果是熱門應用的話，每天畫像標籤的接口請求就是一個高併發的問題，需要考慮用 redis、hbase 等工具去解決。

04

精彩問答

Q：諮詢用戶畫像跟個人信息保護、數據安全方面的問題，在做技術底層架構的時候，數據安全有些什麼措施？

A：就數據安全來說，在採集數據上，不是特別涉密、涉及敏感信息的數據會進行採集。但在標籤應用查看權限上，技術上通過接口實現不同權限來控制。比如不同用戶分組對應不同的權限，可以查看分組下對應的標籤，通過這種方式控制內部的數據安全。

Q：公司已有推薦系統且有標籤，公司還想建設標籤畫像中臺。想諮詢中臺標籤畫像和標籤系統的標籤之間的關係應該是什麼樣的？

A：這個問題可能是侷限於公司內部的問題，不是通用性的問題。可能是有的公司比較大，不同的部門牽頭做一套自己東西，做的東西有衝突了。

Q：從最初的建立標籤體系，比如第二級標籤分組，除了梳理行業的競品、客戶的實際業務情況，還有沒有其他維度或常見的體系方法論？

A：一般是基於自己公司的業務場景去梳理指標體系。梳理標籤體系，一般由各個業務部門人員提需求，以及產品經理出需求。在開發過程中，根據使用情況不斷地做迭代。現在市面上也有專門講標籤類目體系的書，專門講如何面向業務去梳理標籤體系。

Q：對於離線跟實時的標籤，應該如何合理的處理？實時標籤應該怎麼做？

A：大部分場景基本 90% 多都是基於離線標籤去做。實時標籤是給用戶推送一些實時的東西，但可能不一定基於標籤的方式去做。就離線標籤來說，我們給用戶打上標籤，然後再去做一些篩選及推送；實時場景則可能直接通過任務計算好了，並把計算出來的這批用戶推送到對應的地方供調用。

今天的分享就到這裏，謝謝大家。

分享嘉賓：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/SMK5PWJ3PQ10YkkaxidERA