導讀：用戶畫像是建立在數(shù)據(jù)基礎之上的用戶模型，是產(chǎn)品改進、精準營銷等業(yè)務場景中不可或缺的重要基礎。而構建用戶畫像的過程就是要給用戶打上各種維度的標簽，并基于標簽進行定性或定量分析。這其中，建設靈活、全面、高效的標簽體系是工作的重中之重。本文就從標簽體系建設的需求出發(fā)，闡述神策數(shù)據(jù)在設計標簽生產(chǎn)引擎過程中所做的思考和實踐。主要內容包括：

• 用戶標簽及其應用場景

• 標簽生產(chǎn)平臺的需求

• 批流一體的標簽生產(chǎn)架構

用戶標簽及其應用場景

1.?什么是用戶標簽

簡單說，就是對用戶的某個維度特征的描述。對一群用戶而言，我們?yōu)榱四茏寴I(yè)務做的更好，就想知道他們的很多特征。比如說，我現(xiàn)在有個 10 萬塊錢的活動預算，那這個錢應該集中花在哪里呢？針對這個問題，我們希望對給定的用戶群體，能知道他們的商業(yè)價值，對他們的商業(yè)價值有一個很好的描述。知道里面哪些人才是我們重點要服務的對象。

2.?用戶標簽的應用價值

用戶標簽的應用主要是四種場景：

用戶特征洞察：

輔助用戶分析和用戶洞察，用戶標簽可以幫助業(yè)務人員快速的對用戶有一個認知，然后發(fā)現(xiàn)里面顯著的特征，獲得一些商業(yè)靈感。

增強數(shù)據(jù)分析：

標簽還可以豐富數(shù)據(jù)的維度。對我們的業(yè)務數(shù)據(jù)，有更深層次的對比分析，而分析洞察得到的靈感以后，可以輔助業(yè)務落地。

精細化運營：

一方面，可以將用戶群體，切割成更細粒度的群組，使得運營從粗放化到精細化，用多種不同的手段，不同的渠道去觸達，比如說短信、推送、郵件等等，對于用戶進行驅動或召回，從而達到事半功倍的效果。

數(shù)據(jù)產(chǎn)品應用：

另一方面，除了驅動人工的業(yè)務以外，用戶標簽還可以成為其他數(shù)據(jù)產(chǎn)品的基礎，比如個性化推薦系統(tǒng)，廣告系統(tǒng)，CRM 等這些系統(tǒng)。自動化的業(yè)務系統(tǒng)能更有效的利用這些用戶標簽，從而發(fā)揮更巨大的威力。

3. 為什么常見的標簽體系用不起來？

用戶標簽其實已經(jīng)不是新概念，十幾年前，就已經(jīng)有各種各樣的標簽系統(tǒng)，但是在我們這幾年的實踐過程中，其實發(fā)現(xiàn)，很多的標簽系統(tǒng)在實際落地的過程中，都會多多少少的遇到一些問題。這里面主要是兩大類問題。

難全面覆蓋：

在創(chuàng)建標簽的過程中，數(shù)據(jù)的提供方希望盡可能滿足各種各樣業(yè)務的需求，就會有一些發(fā)散性的構思，但是實際上在操作中很難覆蓋特別的全面，業(yè)務是一直變化的，不能預知一年以后這個業(yè)務發(fā)展成什么樣子，所以很難覆蓋全。

難落地應用：

另外一大類問題，業(yè)務方在使用的時候，面對的是成百上千的甚至上萬的標簽，他們也比較懵，不知道怎么使用，也不知道標簽的統(tǒng)計口徑是什么，用戶分層的切割規(guī)則等等這些，從而導致了不會用或者不好用，用不起來。

標簽生產(chǎn)平臺的需求

1.?應用驅動的標簽構建

我們的解決方案其實是基于標簽的應用流程，去反向去反推這個標簽體系的構思和建設。

這個反推，其實是一個比較需要業(yè)務經(jīng)驗的事情，根據(jù)我們的經(jīng)驗，大部分情況下，產(chǎn)品部門和運營部門，都會有一些不同的標簽使用方式。比如運營部門，一般是用于做活動，他們關心的問題是，怎么樣做一個活動才能夠提高客戶的轉化。而產(chǎn)品則是負責對某一個問題提供解決方案，他們需要觀察的是客戶的特征，去決定如何設計才能解決大多數(shù)的問題。

2.?根據(jù)標簽的使用目的，體系化梳理標簽

總體來說，無論是產(chǎn)品還是運營，我們都把它叫做業(yè)務部門，他們應用標簽的流程實際上一般來講就分三步。

目標人群是誰？

其實是一個戰(zhàn)略性的問題，定位的目標人群，這里其實往往應該先看，比如說商業(yè)價值類的標簽，然后去幫助我們的業(yè)務人員發(fā)現(xiàn)商業(yè)價值最大的那個人群。

他們喜歡什么？

如果目標人群是有比較明確的行為數(shù)據(jù)的，比如說他們是活躍用戶，這時候應該去看他的用戶偏好類型的這個標簽，比如他喜歡做什么，然后他的興趣愛好是什么等等這些。

如果目標人群行為數(shù)據(jù)比較少，比如說他是新用戶，或者是一些靜默用戶，那這個時候就應該從他們所屬的生命周期標簽出發(fā)，去計劃構建促進轉化或者是召回的策略。

如何執(zhí)行策略？

就是我們應該做什么，做一個什么樣的策略，這個策略怎么落地？然后當策略方向有了以后，還需要一些具體的參考信息，比如推送什么時間發(fā)這種問題，需要有一些具體的營銷時機類的標簽，比如說用戶一般的活躍時間段，然后來幫助整個計劃的這個落地。

3.?標簽類型

回到整個我們的標簽平臺本身，我們認為首先作為一個標簽平臺，它需要具有非常靈活的標簽創(chuàng)建的能力，從而才能適應不斷變化的業(yè)務需求。

具體來說，我們是把需要創(chuàng)建的這個標簽分成了三個大類。

數(shù)值聚合型標簽：

這類的標簽就是主要是在用戶維度的數(shù)值計算，主要是彌補在數(shù)據(jù)采集當中未能及時補全的一些信息。如：每個?戶最近半年消費次數(shù)、最后?次消費時間、近?周消費的商品類別

還有一種數(shù)值聚合是實時標簽，類似這種標簽一般都是用于運營活動的受眾的篩選。如：某活動開始時間到當前時間，?戶的下單?額

分群標簽：

顧名思義就是給一群人，給他們打上一個標簽。

• 如：將累計充值?額超過 10000 元的?戶標記為 「?價值?戶」

• 如：X運營活動開始后，通過運營?注冊下單的?戶，則標記為 「X活動轉化?戶」

狀態(tài)轉化標簽：

這個是我們在我們定義里面是邏輯相對來說比較復雜的一類標簽，這類標簽通常來說都是實時標簽，對于實時性的要求都會比較高，要求是秒級分鐘級的。如：通過?為來標記新?戶是否為??黨。

另外一類呢就是還有一些比較復雜的運營活動，或者是從控制成本的角度來做一些運營活動。如：在規(guī)定時間內，完成運營活動中的?少 3 項任務，并完成領券下單轉化的，則標記為「價格敏感型?戶」。

4.?標簽平臺的技術需求

靈活可拓展的標簽創(chuàng)建規(guī)則：我們需要有非常靈活可擴展的標簽的規(guī)則的定義。

在有限的資源條件下支持億級用戶基數(shù)的標簽生產(chǎn)：在相對比較有限的條件下，能夠支持相對比較大的用戶基數(shù)的標簽生產(chǎn)，需要對計算或者存儲方面有比較高的優(yōu)化，對于系統(tǒng)架構來說，平臺的伸縮性和這種適應性都會要求相對高一些。

離線標簽按天更新，實時標簽秒級延遲：對于業(yè)務，我們一般的標簽可能是按天更新的，例行標簽。另外有一種就是實時活動，計算的響應要求比較高，實時標簽的計算要在秒級之內完成，可能秒級之內還要后面做推送，然后觸達到用戶。?

批流一體的標簽生產(chǎn)架構

1.?基礎數(shù)據(jù)流

下面主要講講技術問題，首先，在我們的理解當中，標簽平臺是一個中間層的服務，為前臺服務提供一個數(shù)據(jù)支持，然后另外一方面，標簽平臺它所用到的數(shù)據(jù)其實是依賴于底層的基礎數(shù)據(jù)平臺的原始數(shù)據(jù)。

這張圖就展現(xiàn)了神策基礎數(shù)據(jù)流平臺的架構。數(shù)據(jù)流是從左到右的，最左邊是所有的采集的方式，各種 SDK 采集了數(shù)據(jù)之后，經(jīng)過數(shù)據(jù)接收系統(tǒng)、導入系統(tǒng)和存儲系統(tǒng)，然后查詢系統(tǒng)，最后展現(xiàn)。?

2.?簡化的數(shù)據(jù)模型

在這個流里，數(shù)據(jù)模型其實是非常簡單的，基本會分成兩大類：用戶行為數(shù)據(jù)、用戶屬性數(shù)據(jù)。

用戶行為表：

其實是個寬表，它里面是幾個常用的維度，主要描述了什么人在什么時間，做了一件什么事。所以主要字段就是：時間、用戶 ID、事件、渠道、搜索關鍵詞、商品價格等。

用戶屬性表：

用戶屬性表，主要描述用戶的屬性情況，相對變化不大。主要字段有：用戶 ID、性別、注冊渠道、會員等級等。

3.?基于有限流的標簽計算

所以在我們的系統(tǒng)里面，首先會做一套批量離線的標簽處理引擎，依賴的是我們底層比較穩(wěn)定的數(shù)據(jù)結構。這個標簽引擎一邊讀事件數(shù)據(jù)，一邊讀用戶的屬性數(shù)據(jù)，再配合上特定的標簽規(guī)則，做一個批量計算，最后生成用戶標簽。

有限流：

• Event-User 數(shù)據(jù)可以理解為永不停?的數(shù)據(jù)流。只要業(yè)務在用，就有不斷的數(shù)據(jù)進來

• 批量離線計算開始時，參與計算的數(shù)據(jù)已完全?庫。不會有還沒有入庫的數(shù)據(jù)

在有限流的情況下，數(shù)據(jù)是穩(wěn)定的，計算具有冪等性，不會頻繁變化。與之相對的就是基于無限流的實時計算標簽，在計算啟動的時刻，數(shù)據(jù)還在源源不斷的進來，計算不具有冪等性。所以批量標簽引擎實際上跟一些離線數(shù)據(jù)倉庫和離線引擎一樣，最核心的兩部分，一個是調度器，一個是計算引擎。

實現(xiàn)?式：

• 使? Impala + HDFS(parquet) 為底層計算引擎

• 標簽規(guī)則引擎負責將標簽定義翻譯為?效 SQL

• 使? impala 分析函數(shù)實現(xiàn)特定的規(guī)則

• 通?調度器負責例?任務的調度

4.?非實時標簽數(shù)據(jù)存儲格式

數(shù)據(jù)存儲方面，我們采取的方式是每個標簽都存一張物理的表，以時間作為分區(qū)，因為離線計算一般都是按天調度的，所以就按天存儲，每日的結果存為一個 partition，然后這個 partition 下面存的都是 parquet 類型的文件，并且用 gzip 來壓縮。我們這個單表里面每一行是一個用戶的 ID，然后后面有一列跟的是它的這個標簽的值，在這種結構下用 gzip 一壓，其實壓縮比還是比較高的，比較可觀。

5.?標簽寬表加速查詢

每個標簽存一張物理表，其實也是有比較大的問題。這個表雖然在數(shù)據(jù)更新的時候很好處理，能夠保持更新時的數(shù)據(jù)的一致性，但是對于查詢端其實并不是很友好，尤其是在做多條件過濾的時候，需要將底層的多張表進行 join 操作，計算代價很大。為了提高性能，我們在后臺會有一個例行任務，定時將這些已經(jīng)固化下來的標簽編號，把它合并成一張寬表，主要依據(jù)標簽的離線計算，基本上每天都更新一次，更新完了以后這個數(shù)據(jù)基本上就固定保持穩(wěn)定了。

標簽單表：

• 數(shù)據(jù)更新代價低，可保證數(shù)據(jù)?致性

• 問題：查詢需要多張表 join，性能堪憂?

標簽寬表的實現(xiàn)?式：

• 標簽寬表是?個所有單表 join 的 view

• 每當單表數(shù)據(jù)更新時，更新該 view

• 定時將 view 固化為物理表

• 遺留問題：parquet 在列數(shù)過多的情況下，性能會有所下降

6.?用 bitmap 優(yōu)化人群篩選

另外就是使用 bitmap 來做人群篩選優(yōu)化，部分標簽值所對應的?群使?頻次更?，如「?價值?戶」、「活躍?戶」等。使?標簽篩選?戶，可以理解成針對?群包的集合操作。

bitmap 過濾的實現(xiàn)?式：

• 將標簽值對應的?群包構建 RoaringBitmap

• ?群篩選時，先通過 bitmap 的交并差運算得到過濾?的 bitmap

• impala 使? bitmap 做最終的過濾器，得到?群包（包含太多元素的 bitmap 體積太?，反?影響效率）

7.?基于無限流的標簽計算

大部分業(yè)務場景實際上是離線的部分就能滿足了，實時的部分主要是要滿足一些運營活動的一些需求。我們這個實時標簽引擎其實也并不復雜，輸入的數(shù)據(jù)就是我們實時流的事件數(shù)據(jù)，根據(jù)標簽規(guī)則，還有用戶屬性，用戶標簽對他做在線的一個計算，從而輸出的是一個標簽狀態(tài)的變更，最后得到這個標簽結果。

8.?實時標簽引擎

實現(xiàn)?式：

• 實時標簽計算使? Flink

• Flink job 監(jiān)聽 Kafka 的 event topic，計算由事件觸發(fā)

• 計算過程就是實現(xiàn)?個狀態(tài)機

• 計算的中間狀態(tài)存儲在 Flink State 和 KV 存儲中

• 實時計算能使?的離線標簽，需要先訂閱到 KV 存儲中

• 標簽結果輸出到 Kafka 的 tag topic

9.?批流一體的架構

整體的架構就像這張圖一樣，在我們的標簽管理控制臺這一層，其實是對標簽規(guī)則做了一個劃分，在這里會識別當前要算的這個標簽，到底是一個離線標簽還是一個實時標簽比較好？如果它是實時標簽，它要對哪些離線標簽進行訂閱，也是在這里處理的。離線標簽就做離線的計算，然后在最下面有一個數(shù)據(jù)同步服務，會把離線標簽計算的結果同步到kv里面，這里面其實也不會依賴特別多，我們不會給他做一些特別復雜的計算，然后依賴特別多的數(shù)據(jù)，因為 kv 里面也會有性能問題。然后 Flink State 實際上是 kv 存儲的半個緩存，實際上計算由 Flink Job 來進行。

最后總結一下，我們所理解的標簽平臺，實際上是以應用為目標來構建的標準體系。我們認為在這個平臺里面標簽規(guī)則一定是要靈活的，要讓真正做業(yè)務的技術小白，也能夠靈活的自主配置，然后能夠自己搭建這個標準體系，能夠自己改規(guī)則。在技術層面，標簽平臺它是依賴于底層特別穩(wěn)定的數(shù)據(jù)模型和數(shù)據(jù)流的，然后標簽平臺本身它的技術架構實際上是批流一體，因為批量相對來說計算性能更高，代價更小，然后流式是實時性更高，兩邊一起組合而成的標簽生產(chǎn)體系。

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

???

【更多內容】

• 中原銀行張本晨：中原銀行數(shù)字化營銷體系建設實踐
  

• 神策數(shù)據(jù)：驢媽媽的用戶增長案例分析

• 神策營銷云：微信生態(tài)中，「電商」如何借“運營工具”，搶占 4.5 億流量紅利？
  

▼?點擊“閱讀原文”，下載演講?PPT

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的神策数据王琛：用户画像实践之神策标签生产引擎架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。