用戶畫像是建立在數據基礎之上的用戶模型，是產品改進、精準營銷等業務場景中不可或缺的重要基礎。而構建用戶畫像的過程就是要給用戶打上各種維度的標籤，並基於標籤進行定性或定量分析。這其中，建設靈活、全面、高效的標籤體系是工作的重中之重。本文就從標籤體系建設的需求出發，闡述神策數據在設計標籤生產引擎過程中所做的思考和實踐。主要內容包括：
用戶標籤及其應用場景標籤生產平臺的需求批流一體的標籤生產架構用戶標籤及其應用場景
1. 什麼是用戶標籤
簡單說，就是對用戶的某個維度特徵的描述。對一群用戶而言，我們為了能讓業務做的更好，就想知道他們的很多特徵。比如說，我現在有個 10 萬塊錢的活動預算，那這個錢應該集中花在哪裡呢？針對這個問題，我們希望對給定的用戶群體，能知道他們的商業價值，對他們的商業價值有一個很好的描述。知道裡面哪些人才是我們重點要服務的對象。
2. 用戶標籤的應用價值
用戶標籤的應用主要是四種場景：
用戶特徵洞察：
輔助用戶分析和用戶洞察，用戶標籤可以幫助業務人員快速的對用戶有一個認知，然後發現裡面顯著的特徵，獲得一些商業靈感。
增強數據分析：
標籤還可以豐富數據的維度。對我們的業務數據，有更深層次的對比分析，而分析洞察得到的靈感以後，可以輔助業務落地。
精細化運營：
一方面，可以將用戶群體，切割成更細粒度的群組，使得運營從粗放化到精細化，用多種不同的手段，不同的渠道去觸達，比如說簡訊、推送、郵件等等，對於用戶進行驅動或召回，從而達到事半功倍的效果。
數據產品應用：
另一方面，除了驅動人工的業務以外，用戶標籤還可以成為其他數據產品的基礎，比如個性化推薦系統，廣告系統，CRM 等這些系統。自動化的業務系統能更有效的利用這些用戶標籤，從而發揮更巨大的威力。
3. 為什麼常見的標籤體系用不起來？
用戶標籤其實已經不是新概念，十幾年前，就已經有各種各樣的標籤系統，但是在我們這幾年的實踐過程中，其實發現，很多的標籤系統在實際落地的過程中，都會多多少少的遇到一些問題。這裡面主要是兩大類問題。
難全面覆蓋：
在創建標籤的過程中，數據的提供方希望儘可能滿足各種各樣業務的需求，就會有一些發散性的構思，但是實際上在操作中很難覆蓋特別的全面，業務是一直變化的，不能預知一年以後這個業務發展成什麼樣子，所以很難覆蓋全。
難落地應用：
另外一大類問題，業務方在使用的時候，面對的是成百上千的甚至上萬的標籤，他們也比較懵，不知道怎麼使用，也不知道標籤的統計口徑是什麼，用戶分層的切割規則等等這些，從而導致了不會用或者不好用，用不起來。
標籤生產平臺的需求
1. 應用驅動的標籤構建
我們的解決方案其實是基於標籤的應用流程，去反向去反推這個標籤體系的構思和建設。
這個反推，其實是一個比較需要業務經驗的事情，根據我們的經驗，大部分情況下，產品部門和運營部門，都會有一些不同的標籤使用方式。比如運營部門，一般是用於做活動，他們關心的問題是，怎麼樣做一個活動才能夠提高客戶的轉化。而產品則是負責對某一個問題提供解決方案，他們需要觀察的是客戶的特徵，去決定如何設計才能解決大多數的問題。
2. 根據標籤的使用目的，體系化梳理標籤
總體來說，無論是產品還是運營，我們都把它叫做業務部門，他們應用標籤的流程實際上一般來講就分三步。
目標人群是誰？
其實是一個戰略性的問題，定位的目標人群，這裡其實往往應該先看，比如說商業價值類的標籤，然後去幫助我們的業務人員發現商業價值最大的那個人群。
他們喜歡什麼？
如果目標人群是有比較明確的行為數據的，比如說他們是活躍用戶，這時候應該去看他的用戶偏好類型的這個標籤，比如他喜歡做什麼，然後他的興趣愛好是什麼等等這些。
如果目標人群行為數據比較少，比如說他是新用戶，或者是一些靜默用戶，那這個時候就應該從他們所屬的生命周期標籤出發，去計劃構建促進轉化或者是召回的策略。
如何執行策略？
就是我們應該做什麼，做一個什麼樣的策略，這個策略怎麼落地？然後當策略方向有了以後，還需要一些具體的參考信息，比如推送什麼時間發這種問題，需要有一些具體的營銷時機類的標籤，比如說用戶一般的活躍時間段，然後來幫助整個計劃的這個落地。
3. 標籤類型
回到整個我們的標籤平臺本身，我們認為首先作為一個標籤平臺，它需要具有非常靈活的標籤創建的能力，從而才能適應不斷變化的業務需求。
具體來說，我們是把需要創建的這個標籤分成了三個大類。
數值聚合型標籤：
這類的標籤就是主要是在用戶維度的數值計算，主要是彌補在數據採集當中未能及時補全的一些信息。如：每個戶最近半年消費次數、最後次消費時間、近周消費的商品類別
還有一種數值聚合是實時標籤，類似這種標籤一般都是用於運營活動的受眾的篩選。如：某活動開始時間到當前時間，戶的下單額
分群標籤：
顧名思義就是給一群人，給他們打上一個標籤。
如：將累計充值額超過 10000 元的戶標記為 「價值戶」如：X運營活動開始後，通過運營註冊下單的戶，則標記為 「X活動轉化戶」狀態轉化標籤：
這個是我們在我們定義裡面是邏輯相對來說比較複雜的一類標籤，這類標籤通常來說都是實時標籤，對於實時性的要求都會比較高，要求是秒級分鐘級的。如：通過為來標記新戶是否為黨。
另外一類呢就是還有一些比較複雜的運營活動，或者是從控制成本的角度來做一些運營活動。如：在規定時間內，完成運營活動中的少 3 項任務，並完成領券下單轉化的，則標記為「價格敏感型戶」。
4. 標籤平臺的技術需求
靈活可拓展的標籤創建規則：我們需要有非常靈活可擴展的標籤的規則的定義。
在有限的資源條件下支持億級用戶基數的標籤生產：在相對比較有限的條件下，能夠支持相對比較大的用戶基數的標籤生產，需要對計算或者存儲方面有比較高的優化，對於系統架構來說，平臺的伸縮性和這種適應性都會要求相對高一些。
離線標籤按天更新，實時標籤秒級延遲：對於業務，我們一般的標籤可能是按天更新的，例行標籤。另外有一種就是實時活動，計算的響應要求比較高，實時標籤的計算要在秒級之內完成，可能秒級之內還要後面做推送，然後觸達到用戶。
批流一體的標籤生產架構
1. 基礎數據流
下面主要講講技術問題，首先，在我們的理解當中，標籤平臺是一個中間層的服務，為前臺服務提供一個數據支持，然後另外一方面，標籤平臺它所用到的數據其實是依賴於底層的基礎數據平臺的原始數據。
這張圖就展現了神策基礎數據流平臺的架構。數據流是從左到右的，最左邊是所有的採集的方式，各種 SDK 採集了數據之後，經過數據接收系統、導入系統和存儲系統，然後查詢系統，最後展現。
2. 簡化的數據模型
在這個流裡，數據模型其實是非常簡單的，基本會分成兩大類：用戶行為數據、用戶屬性數據。
用戶行為表：
其實是個寬表，它裡面是幾個常用的維度，主要描述了什麼人在什麼時間，做了一件什麼事。所以主要欄位就是：時間、用戶 ID、事件、渠道、搜索關鍵詞、商品價格等。
用戶屬性表：
用戶屬性表，主要描述用戶的屬性情況，相對變化不大。主要欄位有：用戶 ID、性別、註冊渠道、會員等級等。
3. 基於有限流的標籤計算
所以在我們的系統裡面，首先會做一套批量離線的標籤處理引擎，依賴的是我們底層比較穩定的數據結構。這個標籤引擎一邊讀事件數據，一邊讀用戶的屬性數據，再配合上特定的標籤規則，做一個批量計算，最後生成用戶標籤。
有限流：
Event-User 數據可以理解為永不停的數據流。只要業務在用，就有不斷的數據進來批量離線計算開始時，參與計算的數據已完全庫。不會有還沒有入庫的數據在有限流的情況下，數據是穩定的，計算具有冪等性，不會頻繁變化。與之相對的就是基於無限流的實時計算標籤，在計算啟動的時刻，數據還在源源不斷的進來，計算不具有冪等性。所以批量標籤引擎實際上跟一些離線數據倉庫和離線引擎一樣，最核心的兩部分，一個是調度器，一個是計算引擎。
實現式：
使 Impala + HDFS(parquet) 為底層計算引擎標籤規則引擎負責將標籤定義翻譯為效 SQL使 impala 分析函數實現特定的規則通調度器負責例任務的調度4. 非實時標籤數據存儲格式
數據存儲方面，我們採取的方式是每個標籤都存一張物理的表，以時間作為分區，因為離線計算一般都是按天調度的，所以就按天存儲，每日的結果存為一個 partition，然後這個 partition 下面存的都是 parquet 類型的文件，並且用 gzip 來壓縮。我們這個單表裡面每一行是一個用戶的 ID，然後後面有一列跟的是它的這個標籤的值，在這種結構下用 gzip 一壓，其實壓縮比還是比較高的，比較可觀。
5. 標籤寬表加速查詢
每個標籤存一張物理表，其實也是有比較大的問題。這個表雖然在數據更新的時候很好處理，能夠保持更新時的數據的一致性，但是對於查詢端其實並不是很友好，尤其是在做多條件過濾的時候，需要將底層的多張表進行 join 操作，計算代價很大。為了提高性能，我們在後臺會有一個例行任務，定時將這些已經固化下來的標籤編號，把它合併成一張寬表，主要依據標籤的離線計算，基本上每天都更新一次，更新完了以後這個數據基本上就固定保持穩定了。
標籤單表：
數據更新代價低，可保證數據致性問題：查詢需要多張表 join，性能堪憂 標籤寬表的實現式：
標籤寬表是個所有單表 join 的 view每當單表數據更新時，更新該 view定時將 view 固化為物理表遺留問題：parquet 在列數過多的情況下，性能會有所下降6. 用 bitmap 優化人群篩選
另外就是使用 bitmap 來做人群篩選優化，部分標籤值所對應的群使頻次更，如「價值戶」、「活躍戶」等。使標籤篩選戶，可以理解成針對群包的集合操作。
bitmap 過濾的實現式：
將標籤值對應的群包構建 RoaringBitmap群篩選時，先通過 bitmap 的交並差運算得到過濾的 bitmapimpala 使 bitmap 做最終的過濾器，得到群包（包含太多元素的 bitmap 體積太，反影響效率）7. 基於無限流的標籤計算
大部分業務場景實際上是離線的部分就能滿足了，實時的部分主要是要滿足一些運營活動的一些需求。我們這個實時標籤引擎其實也並不複雜，輸入的數據就是我們實時流的事件數據，根據標籤規則，還有用戶屬性，用戶標籤對他做在線的一個計算，從而輸出的是一個標籤狀態的變更，最後得到這個標籤結果。
8. 實時標籤引擎
實現式：
實時標籤計算使 FlinkFlink job 監聽 Kafka 的 event topic，計算由事件觸發計算過程就是實現個狀態機計算的中間狀態存儲在 Flink State 和 KV 存儲中實時計算能使的離線標籤，需要先訂閱到 KV 存儲中標籤結果輸出到 Kafka 的 tag topic9. 批流一體的架構
整體的架構就像這張圖一樣，在我們的標籤管理控制臺這一層，其實是對標籤規則做了一個劃分，在這裡會識別當前要算的這個標籤，到底是一個離線標籤還是一個實時標籤比較好？如果它是實時標籤，它要對哪些離線標籤進行訂閱，也是在這裡處理的。離線標籤就做離線的計算，然後在最下面有一個數據同步服務，會把離線標籤計算的結果同步到kv裡面，這裡面其實也不會依賴特別多，我們不會給他做一些特別複雜的計算，然後依賴特別多的數據，因為 kv 裡面也會有性能問題。然後 Flink State 實際上是 kv 存儲的半個緩存，實際上計算由 Flink Job 來進行。
最後總結一下，我們所理解的標籤平臺，實際上是以應用為目標來構建的標準體系。我們認為在這個平臺裡面標籤規則一定是要靈活的，要讓真正做業務的技術小白，也能夠靈活的自主配置，然後能夠自己搭建這個標準體系，能夠自己改規則。在技術層面，標籤平臺它是依賴於底層特別穩定的數據模型和數據流的，然後標籤平臺本身它的技術架構實際上是批流一體，因為批量相對來說計算性能更高，代價更小，然後流式是實時性更高，兩邊一起組合而成的標籤生產體系。
作者：王琛 神策數據