1. 背景

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

2. 什么是用戶畫像

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

3. 標(biāo)簽畫像的應(yīng)用場景

用戶特征洞察：

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

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

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

精細(xì)化運營：

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

4. 轉(zhuǎn)轉(zhuǎn)用戶畫像平臺的實踐

4.1 系統(tǒng)結(jié)構(gòu)圖

上圖介紹了用戶畫像平臺的系統(tǒng)結(jié)構(gòu)圖，按大的模塊總共有6大模塊，標(biāo)簽?zāi)K，人群計算模塊，用戶群畫像分析模塊，用戶運營模塊，用戶洞察模塊，以及權(quán)限管理模塊。下面介紹一下標(biāo)簽畫像的構(gòu)建過程。

4.2 標(biāo)簽畫像的構(gòu)建原則

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

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

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

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

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

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

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

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

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

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

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

預(yù)測標(biāo)簽：通過算法建模預(yù)測該用戶的一些特征，比如年齡、性別、學(xué)歷、婚姻等。

興趣類標(biāo)簽的計算過程:

預(yù)測類標(biāo)簽的一般流程：

4.4 標(biāo)簽的生產(chǎn)加工

標(biāo)簽生產(chǎn)原則

標(biāo)簽的生產(chǎn)和加工要滿足一下幾個原則:

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

標(biāo)簽數(shù)據(jù)來源

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

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

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

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

用戶屬性集合運算

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

那這個的邏輯表達(dá)式就是：

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

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

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

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

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

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

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

4.5 標(biāo)簽的存儲設(shè)計

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

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

標(biāo)簽?zāi)Ｐ捅韺⑺械挠脩魌oken/uid和用戶的標(biāo)簽名和值關(guān)聯(lián)起來，形成明細(xì)數(shù)據(jù)集，并增加平臺和用戶ID字段，用來區(qū)分轉(zhuǎn)轉(zhuǎn)和找靚機平臺側(cè)的用戶。

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

4.6 用戶洞察

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

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

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

4.7 用戶分群計算

用戶分群是將不同類型規(guī)則的標(biāo)簽進行運算， 圈出符合某些特征屬性的用戶，可以針對這部分用戶來做運營計劃。我們支持多種類型圈群，可以基于標(biāo)簽圈人，比如年齡為20-40歲的男性用戶且累計B2C支付訂單為1單的用戶。也可以根據(jù)用戶行為事件屬性來圈人，比如對進行商品比價行為事件且事件屬性為品牌的用戶進行分群計算。標(biāo)簽數(shù)據(jù)和行為數(shù)據(jù)都是Hive寬表， 結(jié)合開發(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計算的思路來看，我們是先篩選出來不同標(biāo)簽的用戶集合， 再進行多個集合的用戶id的運算。那這種運算剛好可以使用bitmap來運算。于是我們借助于Clickhouse的BitMap特性來計算，計算效率要比HiveSQL快很多。使用Clickhouse計算人群分幾個步驟：

• 將用戶標(biāo)簽hive表中的用戶id都生成一個全局唯一的mappingId,這個mappingId是整數(shù)，比如用戶設(shè)備id為abc, 生成一個123的mappingId。
• 將用戶id->mappingId映射寫入Hbase KV 存儲。
• 生成一張包含mappingId,標(biāo)簽名稱，標(biāo)簽值的Hive表。
• 使用Spark將mappingId標(biāo)簽表同步到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計算分群的時間可以達(dá)到秒級，比HiveSQL要快很多。但由于我們的標(biāo)簽數(shù)據(jù)量很大，目前已達(dá)到百億級別，當(dāng)分群規(guī)則配置的特別復(fù)雜時，bitMap也會耗時較長，再加上業(yè)務(wù)需要下載人去明細(xì)數(shù)據(jù)，按照我們的方案，通過Clickhouse計算后還需要查詢Hbase把mappingId關(guān)聯(lián)的token查詢出來，當(dāng)數(shù)據(jù)量很大的時候會有一些性能或穩(wěn)定性問題，所以目前針對于Clickhouse的分群計算還在探索中。

4.8 ID-MAPPING

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

各端標(biāo)識信息,在授權(quán)的情況下允許獲取到的設(shè)備標(biāo)識信息。

OneID用戶識別規(guī)則-場景抽象

識別規(guī)則

OneID模型設(shè)計

表結(jié)構(gòu)示例  作用域：集團全域

5 未來規(guī)劃

對標(biāo)簽畫像未來的規(guī)劃：

支持實時標(biāo)簽。隨著業(yè)務(wù)運營對標(biāo)簽的產(chǎn)出失效有更高的要求，未來我們會以業(yè)務(wù)場景出發(fā)，對部分標(biāo)簽進行實時打標(biāo)，系統(tǒng)架構(gòu)會同時支持離線和實時標(biāo)簽的計算，這對我們目前的純離線標(biāo)簽架構(gòu)有更大的挑戰(zhàn)。

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

6 總結(jié)

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