1. 背景

轉轉作為二手電商交易領域的領軍者，隨著這幾年的高速發展，用戶數和業務量都急劇增長，為了更好的服務用戶，并持續增長，產品運營的戰略戰術也會隨之發生變化。在創業早期產品一般以粗放式運營為主，力求快速獲取用戶、推廣產品，領跑賽道。業界也曾流傳著這樣的段子，產品有三寶：彈窗、浮層、加引導；運營有三寶：短信、push、加紅包。然而到了中后期公司都會面臨的三大問題是降本提效、持續增長、用戶體驗，所以基于數據的精細化運營成了大家的必然選擇，而用戶畫像平臺是幫助業務進行精細化運營的輔助工具，這其中，建設靈活、全面、高效的標簽體系是工作的重中之重。本文就從標簽畫像體系建設的需求出發，闡述轉轉在建設用戶畫像平臺過程中的思考和實踐。

2. 什么是用戶畫像

用戶畫像是指根據用戶的屬性、用戶偏好、生活習慣、用戶行為等信息而抽象出來的標簽化用戶模型。通俗說就是給用戶打標簽，而標簽是通過對用戶信息分析而來的高度精煉的特征標識。通過打標簽可以利用一些高度概括、容易理解的特征來描述用戶，可以讓人更容易理解用戶，并且可以方便計算處理。簡單說，就是對用戶的某個維度特征的描述。對一群用戶而言，我們為了能讓業務做的更好，就想知道他們的很多特征。比如說，我現在有個10萬塊錢的活動預算，那這個錢應該集中花在哪里呢？針對這個問題，我們希望對給定的用戶群體，能知道他們的商業價值，對他們的商業價值有一個很好的描述。知道里面哪些人才是我們重點要服務的對象, 如下圖是對一個用戶的洞察，我們通過標簽的加工可以觀察到一個用戶的一些特征屬性。

3. 標簽畫像的應用場景

用戶特征洞察：

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

增強數據分析：

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

精細化運營：

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

4. 轉轉用戶畫像平臺的實踐

4.1 系統結構圖

上圖介紹了用戶畫像平臺的系統結構圖，按大的模塊總共有6大模塊，標簽模塊，人群計算模塊，用戶群畫像分析模塊，用戶運營模塊，用戶洞察模塊，以及權限管理模塊。下面介紹一下標簽畫像的構建過程。

4.2 標簽畫像的構建原則

我們建設用戶畫像平臺的目的有2個：

必須從業務場景出發，解決實際的業務問題，之所以進行用戶畫像要么是獲取新用戶，或者是提升用戶體驗，或者是挽回流失用戶等有明確的業務目標。

根據用戶畫像的信息做產品設計，必須要清楚知道用戶長什么樣子，有什么行為特征和屬性，這樣才能為用戶設計產品或開展營銷活動。一般常見的錯誤想法是畫像維度的數據越多越好，畫像數據越豐富越好，費了很大的力氣進行畫像后，卻發現只剩下了用戶畫像，和業務相差甚遠，沒有辦法直接支持業務運營，投入精力巨大但是回報微小，可以說得不償失。鑒于此，我們的畫像的維度和設計原則都是緊緊跟著業務需求去推動。

4.3 標簽類型和規則

我們認為首先作為一個標簽平臺，它需要具有非常靈活的標簽創建的能力，從而才能適應不斷變化的業務需求。具體來說，我們根據標簽的場景和特征把標簽分成了兩個大類。

• 通用標簽     通用標簽是一些用戶的基本屬性。比如年齡，性別，城市，出生年代等。
• 業務標簽     而業務標簽是主要是按照轉轉幾大業務線來分類，包含了與業務行為有關的標簽，比如累計下單訂單數，歷史下單一級品類，B2C用戶業務環節等。

為了更好的描述和定義標簽， 我們將標簽分為四個層級，從上到下粒度逐漸變小，而標簽的定義和命名也是按照四個層級來進行，規則為一級標簽名稱_二級標簽名稱_三級標簽名稱_標簽值(四級標簽)。

比如近30天活躍時間段這個標簽，最終的定義形式是 業務標簽_B2C_近30天活躍時間段_12點-20點， 其中12點-20點為我們標簽的一個值,也是四級標簽。

按照標簽的計算方式我們把標簽分為事實標簽、統計標簽和預測標簽。

事實標簽：是通過對于原始業務數據、埋點數據進行統計分析而來的，比如用戶累計下單數，是基于用戶一段時間內累計下單的數據量做的統計。

模型標簽：模型標簽是以事實標簽為基礎，通過構建事實標簽與業務問題之間的模型，進行模型分析得到。比如興趣類標簽，最感興趣的品類。

預測標簽：通過算法建模預測該用戶的一些特征，比如年齡、性別、學歷、婚姻等。

興趣類標簽的計算過程:

預測類標簽的一般流程：

4.4 標簽的生產加工

標簽生產原則

標簽的生產和加工要滿足一下幾個原則:

• 可擴展的標簽創建規則  我們需要有非常靈活可擴展的標簽的規則的定義，以滿足用戶業務場景變化導致的標簽規則變化。所以我們開發了一套標簽模板，每個標簽的規則可以通過配置模板來實現，模板支持可視化配置相關的參數，支持隨時變更模板規則，如果需要更改標簽計算規則和參數 ，只需要更改模板SQL即可。并且一個模板既可以被用來一個標簽上，也可以復用到多個標簽了 ，大大降低了用戶創建標簽的門檻，同時有利于我們管理標簽規則。
• 支持億級用戶的標簽生產 在相對比較有限資源條件下，能夠支持相對比較大的用戶基數的標簽生產，需要對計算或者存儲方面有比較高的優化，對于系統架構來說，平臺的伸縮性和這種適應性都會要求相對高一些。
• 標簽數據按天更新 對于業務，我們一般的標簽是按天更新的，每天凌晨會通過調度平臺進行標簽的計算，由于標簽所依賴的上游表的產出的時間不定，標簽計算會根據上游業務表的產出情況來計算，標簽計算模塊會檢測相關依賴的表。如果監控到依賴表已經計算完成， 則開始計算這個標簽。最后更新計算結果。

標簽數據來源

轉轉標簽計算所使用的數據主要分為2部分，一部分是業務數據，比如訂單；一部分是用戶行為數據，商品曝光事件。標簽在創建前需要提前把相關業務數據或者埋點數據清洗好。

標簽的模板的開發

我們設計了一套標簽計算SQL模板，并支持可視化創建配置模板。創建好模板后用戶不用關心標簽的底層計算規則，只需要通過頁面將相關的業務屬性條件配置好就可以了。

模板類型有屬性篩選模板和上傳文件模板。屬性篩選模板用于篩選特定屬性的用戶集，比如篩選男性，瀏覽商品次數為5次的用戶。上傳文件是直接將特性屬性的用戶集上傳，用戶集上傳之后會放到某個hive表的一個分區下，我們計算時用SQL取出這些用戶即可。

用戶屬性集合運算

標簽計算時會涉及到多種屬性計算， 比如要計算瀏覽商品10次且下單未支付的用戶。那就需要集合運算瀏覽商品10次的用戶集和下單未支付的用戶集。每個屬性模板代表的都是一個用戶集，這些用戶集之間的運算就是集合運算。我們這里支持完整的集合運算：交、并、非，同時支持多級嵌套。為此，我們設計了一個簡單的邏輯表達式，用來表示用戶設置的邏輯。比如，我們想要的用戶集（下圖藍色部分）是買過手機或看過手機的男性，并排除掉賣家。

那這個的邏輯表達式就是：

實際使用的時候表達式中不會有中文，會用集合ID來代替（就是前面說的tag字段）。為了方便解析，每個集合都用括號包裹了起來，邏輯表達式中每個節點只能有兩個子節點，或者沒有子節點。

我們需要收集到每個用戶的所有tag，這里我們把這個標簽用到的所有模板union all 到一起，然后group by xxid，收集到每個用戶的所有tag。

我們用UDF實現了這個邏輯表達式的執行引擎。將用戶的tag列表和邏輯表達式傳入UDF，就可以判斷用戶是不是我們想要的用戶了。執行引擎會先將邏輯表達式解析為一棵樹（會緩存，避免重復解析），類似于抽象語法樹，然后遍歷這顆樹，做解釋執行。邏輯運算中有個優化就是短路運算，即做一部分運算之后就可以得到整個表達式的值，剩下部分不需要再計算。比如，“與運算”中有一個false，結果就是false，“或運算”中有一個true，結果就是true。解析得到的樹如下：

通過自定義UDF函數，我們解決了多種用戶集和運算的問題，滿足了用戶不同業務場景不同用戶屬性的標簽計算。

標簽的創建方式

我們使用標簽SQL模板作為標簽計算的基石，在創建標簽時支持4中標簽類型，其中枚舉標簽和分組標簽都使用SQL模板來實現，用戶不需要了解SQL。

上傳標簽是可以直接上傳用戶的ID數據。自定義SQL滿足在一些情況下用戶自己寫SQL來定義標簽。

4.5 標簽的存儲設計

由于我們的標簽是基于離線數據計算的，所有標簽數據集都存放在Hive中，因為離線計算一般是按天調度，所以底層表按照天作為分區來存儲，每日的標簽存一個分區。然后這個partition下面的數據文件為ORC文件，采用ORC文件是為了利用ORC的列式存儲,節省存儲空間。如下圖所示：

數據模型表

標簽模型表將所有的用戶token/uid和用戶的標簽名和值關聯起來，形成明細數據集，并增加平臺和用戶ID字段，用來區分轉轉和找靚機平臺側的用戶。

用戶ID類型用來標識用戶身份標識是注冊后生成的uid還是設置token。同時為了快速檢索單個標簽的數據，我們將標簽id作為分區，提高查詢單個標簽數據的效率。目前每日標簽全量數據達300億左右，為了減少存儲以及避免特殊字符，應對標簽名稱變更問題，對標簽數據存儲表做了規范約束，標簽名稱存儲為英文名稱，多級名稱之間由下劃線連接，同時開發了標簽中文名的維表，當用戶需要查詢中文名稱時，關聯維表進行查詢。

4.6 用戶洞察

為了支持對單個用戶的洞察分析，開發了查詢單用戶的標簽畫像和用戶行為路徑。單用戶標簽畫像的思路將所有的標簽明細數據根據用戶ID聚合,聚合后的數據寫入Hbase KV存儲， 設計Rowkey時，對用戶uid做字符串反轉+hash(uid)運算后取6位，來解決Hbase Rowkey查詢熱點的問題，使用Hbase我們可以提供秒級的用戶標簽查詢能力。

同時將用戶事件行為數據從Hive同步到Clickhouse,  通過Clickhouse實現對用戶行為路徑的查詢分析。只所以選擇Clickhouse作為事件行為分析的組件，是考慮到Clickhouse的是一個比較強大的OLAP引擎，在海量數據的場景下依然可以做到秒級響應的即席查詢。

下面展示的一個用戶單日按時間序列的行為路徑，業務通過對路徑的分析可以幫助更好的理解用戶，更好的優化運營計劃。

4.7 用戶分群計算

用戶分群是將不同類型規則的標簽進行運算， 圈出符合某些特征屬性的用戶，可以針對這部分用戶來做運營計劃。我們支持多種類型圈群，可以基于標簽圈人，比如年齡為20-40歲的男性用戶且累計B2C支付訂單為1單的用戶。也可以根據用戶行為事件屬性來圈人，比如對進行商品比價行為事件且事件屬性為品牌的用戶進行分群計算。標簽數據和行為數據都是Hive寬表， 結合開發的UDF函數，支持且、或、非三種運算和多層規則嵌套計算場景。下面是簡單的示例代碼：

    select
    xid
from
    (
        SELECT
            xid,
            '1670502093000' as tag_ex
        from
            table
        where
            label_name = xxx
            and label_value = xxx
        union
        all
        select
            xid,
            '1670502131570' as tag_ex,
        from
            table
        where
            label_name = xxx
            and label_value = xxx
    )
group by
    xid
having
    group_c (
        collect_set(tag_ex),
        '((1664348724964)&(1664348724974))'
    )

基于Clickhouse的人群計算嘗試

從上面用Hive計算的思路來看，我們是先篩選出來不同標簽的用戶集合， 再進行多個集合的用戶id的運算。那這種運算剛好可以使用bitmap來運算。于是我們借助于Clickhouse的BitMap特性來計算，計算效率要比HiveSQL快很多。使用Clickhouse計算人群分幾個步驟：

• 將用戶標簽hive表中的用戶id都生成一個全局唯一的mappingId,這個mappingId是整數，比如用戶設備id為abc, 生成一個123的mappingId。
• 將用戶id->mappingId映射寫入Hbase KV 存儲。
• 生成一張包含mappingId,標簽名稱，標簽值的Hive表。
• 使用Spark將mappingId標簽表同步到Clickhouse的bitmap表。
• 通過Clickhouse bitMap函數來計算人群。

簡化后的Clickhouse表:

CREATE TABLE user_labels
(
    label_name String,
    label_value String 
    userIds AggregateFunction(groupBitmap, UInt64)
)
ENGINE = MergeTree
PARTITION by label_name,label_value
ORDER BY label_name,label_value

Clickhouse計算人群示例SQL:

bitmapAnd (
    (
        select
            groupBitmapMergeState(mapping_id)
        from
            table
        where
            dt = '2022-12-01'
            and label_name = 'XXX'
            and label_value = 'XXX'
        group by
            label_name,
            label_value
    ),
    (
        select
            groupBitmapState(abs(mapping_id))
        from
           table
        where
            dt = '2022-12-01'
            and label_name = 'XXX'
            and label_value = 'XXX'
    )
)

使用Clickhouse計算分群的時間可以達到秒級，比HiveSQL要快很多。但由于我們的標簽數據量很大，目前已達到百億級別，當分群規則配置的特別復雜時，bitMap也會耗時較長，再加上業務需要下載人去明細數據，按照我們的方案，通過Clickhouse計算后還需要查詢Hbase把mappingId關聯的token查詢出來，當數據量很大的時候會有一些性能或穩定性問題，所以目前針對于Clickhouse的分群計算還在探索中。

4.8 ID-MAPPING

當前轉轉APP、找靚機APP和小程序登錄狀態的uid和未登錄狀態的token是散亂的，無法識別同一個用戶或設備，各端用戶標識并沒有打通。在收集和積累用戶信息與行為信息之后，為了建立更完善的標簽體系、更完整的用戶畫像、支持更多的數據應用場景，要將各端的ID 關聯起來，盡可能地將用戶的數據打通，從而提供更加全面準確的分析。通過ID-MAPPING我們建立全域下的統一的、標準的、高準確率、高時效性的OneID數據模型。

各端標識信息,在授權的情況下允許獲取到的設備標識信息。

OneID用戶識別規則-場景抽象

識別規則

OneID模型設計

表結構示例  作用域：集團全域

5 未來規劃

對標簽畫像未來的規劃：

支持實時標簽。隨著業務運營對標簽的產出失效有更高的要求，未來我們會以業務場景出發，對部分標簽進行實時打標，系統架構會同時支持離線和實時標簽的計算，這對我們目前的純離線標簽架構有更大的挑戰。

和智能運營計劃平臺無縫打通。目前標簽畫像和運營計劃平臺是相對割裂的，在產品形態上并沒有完全的融合，用戶使用起來也不是很順暢， 未來會更加緊密的跟運營計劃平臺打通，更好的助力業務。

6 總結

以上主要是針對轉轉用戶標簽畫像的建設實踐，主要從標簽的構建，標簽的生產加工，存儲設計， 用戶洞察，用戶分群以及ID-MAPPING等幾個方面闡述了一些經驗和思考。在實踐的過程中也會遇到一些問題，未來會持續優化標簽畫像產品和架構，為業務更好的助力。