轉轉用戶畫像平臺實踐

作者：薛星海 2022-12-15 08:35:01

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

1. 背景

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

2. 什么是用戶畫像

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

3. 標簽畫像的應用場景

用戶特征洞察：

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

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

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

精細化運營：

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

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

4.1 系統(tǒng)結構圖

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

4.2 標簽畫像的構建原則

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

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

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

4.3 標簽類型和規(guī)則

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

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

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

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

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

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

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

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

興趣類標簽的計算過程:

預測類標簽的一般流程：

4.4 標簽的生產加工

標簽生產原則

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

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

標簽數(shù)據(jù)來源

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

標簽的模板的開發(fā)

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

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

用戶屬性集合運算

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

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

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

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

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

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

標簽的創(chuàng)建方式

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

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

4.5 標簽的存儲設計

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

數(shù)據(jù)模型表

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

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

4.6 用戶洞察

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

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

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

4.7 用戶分群計算

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

    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是整數(shù)，比如用戶設備id為abc, 生成一個123的mappingId。
將用戶id->mappingId映射寫入Hbase KV 存儲。
生成一張包含mappingId,標簽名稱，標簽值的Hive表。
使用Spark將mappingId標簽表同步到Clickhouse的bitmap表。
通過Clickhouse bitMap函數(shù)來計算人群。

簡化后的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要快很多。但由于我們的標簽數(shù)據(jù)量很大，目前已達到百億級別，當分群規(guī)則配置的特別復雜時，bitMap也會耗時較長，再加上業(yè)務需要下載人去明細數(shù)據(jù)，按照我們的方案，通過Clickhouse計算后還需要查詢Hbase把mappingId關聯(lián)的token查詢出來，當數(shù)據(jù)量很大的時候會有一些性能或穩(wěn)定性問題，所以目前針對于Clickhouse的分群計算還在探索中。

4.8 ID-MAPPING

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

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