8000字，詳解用戶畫像，助力企業(yè)精細化運營
導讀：在互聯(lián)網(wǎng)步入大數(shù)據(jù)時代后，用戶行為給企業(yè)的產(chǎn)品和服務帶來了一系列的改變和重塑，其中最大的變化在于，用戶的一切行為在企業(yè)面前是可“追溯”“分析”的。企業(yè)內(nèi)保存了大量的原始數(shù)據(jù)和各種業(yè)務數(shù)據(jù)，這是企業(yè)經(jīng)營活動的真實記錄，如何更加有效地利用這些數(shù)據(jù)進行分析和評估，成為企業(yè)基于更大數(shù)據(jù)量背景的問題所在。
隨著大數(shù)據(jù)技術(shù)的深入研究與應用，企業(yè)的關(guān)注點日益聚焦在如何利用大數(shù)據(jù)來為精細化運營和精準營銷服務，而要做精細化運營，首先要建立本企業(yè)的用戶畫像。
用戶畫像，即用戶信息標簽化，通過收集用戶的社會屬性、消費習慣、偏好特征等各個維度的數(shù)據(jù)，進而對用戶或者產(chǎn)品特征屬性進行刻畫，并對這些特征進行分析、統(tǒng)計，挖掘潛在價值信息，從而抽象出用戶的信息全貌，如圖1-1所示。用戶畫像可看作企業(yè)應用大數(shù)據(jù)的根基，是定向廣告投放與個性化推薦的前置條件，為數(shù)據(jù)驅(qū)動運營奠定了基礎。由此看來，如何從海量數(shù)據(jù)中挖掘出有價值的信息越發(fā)重要。
大數(shù)據(jù)已經(jīng)興起多年，其對于互聯(lián)網(wǎng)公司的應用來說已經(jīng)如水、電、空氣對于人們的生活一樣，成為不可或缺的重要組成部分。從基礎設施建設到應用層面，主要有數(shù)據(jù)平臺搭建及運維管理、數(shù)據(jù)倉庫開發(fā)、上層應用的統(tǒng)計分析、報表生成及可視化、用戶畫像建模、個性化推薦與精準營銷等應用方向。
很多公司在大數(shù)據(jù)基礎建設上投入很多，也做了不少報表，但業(yè)務部門覺得大數(shù)據(jù)和傳統(tǒng)報表沒什么區(qū)別，也沒能體會大數(shù)據(jù)對業(yè)務有什么幫助和價值，究其原因，其實是“數(shù)據(jù)靜止在數(shù)據(jù)倉庫，是死的”。
而用戶畫像可以幫助大數(shù)據(jù)“走出”數(shù)據(jù)倉庫，針對用戶進行個性化推薦、精準營銷、個性化服務等多樣化服務，是大數(shù)據(jù)落地應用的一個重要方向。數(shù)據(jù)應用體系的層級劃分如圖1-2所示。
圖1-2 數(shù)據(jù)應用體系的層級劃分
標簽類型：
用戶畫像建模其實就是對用戶“打標簽”，從對用戶打標簽的方式來看，一般分為3種類型（如圖1-3所示）：①統(tǒng)計類標簽；②規(guī)則類標簽；③機器學習挖掘類標簽。
圖1-3 標簽類型
下面我們介紹這3種類型的標簽的區(qū)別：
① 統(tǒng)計類標簽
這類標簽是最為基礎也最為常見的標簽類型，例如，對于某個用戶來說，其性別、年齡、城市、星座、近7日活躍時長、近7日活躍天數(shù)、近7日活躍次數(shù)等字段可以從用戶注冊數(shù)據(jù)、用戶訪問、消費數(shù)據(jù)中統(tǒng)計得出。該類標簽構(gòu)成了用戶畫像的基礎。
② 規(guī)則類標簽
該類標簽基于用戶行為及確定的規(guī)則產(chǎn)生。例如，對平臺上“消費活躍”用戶這一口徑的定義為“近30天交易次數(shù)≥2”。在實際開發(fā)畫像的過程中，由于運營人員對業(yè)務更為熟悉，而數(shù)據(jù)人員對數(shù)據(jù)的結(jié)構(gòu)、分布、特征更為熟悉，因此規(guī)則類標簽的規(guī)則由運營人員和數(shù)據(jù)人員共同協(xié)商確定；
③ 機器學習挖掘類標簽
該類標簽通過機器學習挖掘產(chǎn)生，用于對用戶的某些屬性或某些行為進行預測判斷。例如，根據(jù)一個用戶的行為習慣判斷該用戶是男性還是女性、根據(jù)一個用戶的消費習慣判斷其對某商品的偏好程度。該類標簽需要通過算法挖掘產(chǎn)生。
在項目工程實踐中，一般統(tǒng)計類和規(guī)則類的標簽即可以滿足應用需求，在開發(fā)中占有較大比例。機器學習挖掘類標簽多用于預測場景，如判斷用戶性別、用戶購買商品偏好、用戶流失意向等。一般地，機器學習標簽開發(fā)周期較長，開發(fā)成本較高，因此其開發(fā)所占比例較小。
在整個工程化方案中，系統(tǒng)依賴的基礎設施包括Spark、Hive、HBase、Airflow、MySQL、Redis、Elasticsearch。除去基礎設施外，系統(tǒng)主體還包括Spark Streaming、ETL、產(chǎn)品端3個重要組成部分。圖1-4所示是用戶畫像數(shù)倉架構(gòu)圖，下面對其進行詳細介紹。
圖1-4 用戶畫像數(shù)倉架構(gòu)
圖1-4下方虛線框中為常見的數(shù)據(jù)倉庫ETL加工流程，也就是將每日的業(yè)務數(shù)據(jù)、日志數(shù)據(jù)、埋點數(shù)據(jù)等經(jīng)過ETL過程，加工到數(shù)據(jù)倉庫對應的ODS層、DW層、DM層中。
中間的虛線框即為用戶畫像建模的主要環(huán)節(jié)，用戶畫像不是產(chǎn)生數(shù)據(jù)的源頭，而是對基于數(shù)據(jù)倉庫ODS層、DW層、DM層中與用戶相關(guān)數(shù)據(jù)的二次建模加工。在ETL過程中將用戶標簽計算結(jié)果寫入Hive，由于不同數(shù)據(jù)庫有不同的應用場景，后續(xù)需要進一步將數(shù)據(jù)同步到MySQL、HBase、Elasticsearch等數(shù)據(jù)庫中。
Hive：存儲用戶標簽計算結(jié)果、用戶人群計算結(jié)果、用戶特征庫計算結(jié)果。
MySQL：存儲標簽元數(shù)據(jù)，監(jiān)控相關(guān)數(shù)據(jù)，導出到業(yè)務系統(tǒng)的數(shù)據(jù)。
HBase：存儲線上接口實時調(diào)用類數(shù)據(jù)。
Elasticsearch：支持海量數(shù)據(jù)的實時查詢分析，用于存儲用戶人群計算、用戶群透視分析所需的用戶標簽數(shù)據(jù)（由于用戶人群計算、用戶群透視分析的條件轉(zhuǎn)化成的SQL語句多條件嵌套較為復雜，使用Impala執(zhí)行也需花費大量時間）。
用戶標簽數(shù)據(jù)在Hive中加工完成后，部分標簽通過Sqoop同步到MySQL數(shù)據(jù)庫，提供用于BI報表展示的數(shù)據(jù)、多維透視分析數(shù)據(jù)、圈人服務數(shù)據(jù)；另一部分標簽同步到HBase數(shù)據(jù)庫用于產(chǎn)品的線上個性化推薦。
搭建一套用戶畫像方案整體來說需要考慮8個模塊的建設，如圖1-5所示。
用戶畫像基礎：需要了解、明確用戶畫像是什么，包含哪些模塊，數(shù)據(jù)倉庫架構(gòu)是什么樣子，開發(fā)流程，表結(jié)構(gòu)設計，ETL設計等。這些都是框架，大方向的規(guī)劃，只有明確了方向后續(xù)才能做好項目的排期和人員投入預算。這對于評估每個開發(fā)階段重要指標和關(guān)鍵產(chǎn)出非常重要，重點可看1.4節(jié)。
數(shù)據(jù)指標體系：根據(jù)業(yè)務線梳理，包括用戶屬性、用戶行為、用戶消費、風險控制等維度的指標體系。
標簽數(shù)據(jù)存儲：標簽相關(guān)數(shù)據(jù)可存儲在Hive、MySQL、HBase、Elasticsearch等數(shù)據(jù)庫中，不同存儲方式適用于不同的應用場景。
標簽數(shù)據(jù)開發(fā)：用戶畫像工程化的重點模塊，包含統(tǒng)計類、規(guī)則類、挖掘類、流式計算類標簽的開發(fā)，以及人群計算功能的開發(fā)，打通畫像數(shù)據(jù)和各業(yè)務系統(tǒng)之間的通路，提供接口服務等開發(fā)內(nèi)容。
圖1-5 用戶畫像主要覆蓋模塊
開發(fā)性能調(diào)優(yōu)：標簽加工、人群計算等腳本上線調(diào)度后，為了縮短調(diào)度時間、保障數(shù)據(jù)的穩(wěn)定性等，需要對開發(fā)的腳本進行迭代重構(gòu)、調(diào)優(yōu)。
作業(yè)流程調(diào)度：標簽加工、人群計算、同步數(shù)據(jù)到業(yè)務系統(tǒng)、數(shù)據(jù)監(jiān)控預警等腳本開發(fā)完成后，需要調(diào)度工具把整套流程調(diào)度起來。本書講解了Airflow這款開源ETL工具在調(diào)度畫像相關(guān)任務腳本上的應用。
用戶畫像產(chǎn)品化：為了能讓用戶數(shù)據(jù)更好地服務于業(yè)務方，需要以產(chǎn)品化的形態(tài)應用在業(yè)務上。產(chǎn)品化的模塊主要包括標簽視圖、用戶標簽查詢、用戶分群、透視分析等。
用戶畫像應用：畫像的應用場景包括用戶特征分析、短信、郵件、站內(nèi)信、Push消息的精準推送、客服針對用戶的不同話術(shù)、針對高價值用戶的極速退貨退款等VIP服務應用。
本節(jié)主要介紹畫像系統(tǒng)開發(fā)上線的流程以及各階段的關(guān)鍵產(chǎn)出。
1. 開發(fā)上線流程
用戶畫像建設項目流程，如圖1-6所示。
第一階段：目標解讀
在建立用戶畫像前，首先需要明確用戶畫像服務于企業(yè)的對象，再根據(jù)業(yè)務方需求，明確未來產(chǎn)品建設目標和用戶畫像分析之后的預期效果。
一般而言，用戶畫像的服務對象包括運營人員和數(shù)據(jù)分析人員。不同業(yè)務方對用戶畫像的需求有不同的側(cè)重點，就運營人員來說，他們需要分析用戶的特征、定位用戶行為偏好，做商品或內(nèi)容的個性化推送以提高點擊轉(zhuǎn)化率，所以畫像的側(cè)重點就落在了用戶個人行為偏好上；就數(shù)據(jù)分析人員來說，他們需要分析用戶行為特征，做好用戶的流失預警工作，還可根據(jù)用戶的消費偏好做更有針對性的精準營銷。
第二階段：任務分解與需求調(diào)研
經(jīng)過第一階段的需求調(diào)研和目標解讀，我們已經(jīng)明確了用戶畫像的服務對象與應用場景，接下來需要針對服務對象的需求側(cè)重點，結(jié)合產(chǎn)品現(xiàn)有業(yè)務體系和“數(shù)據(jù)字典”規(guī)約實體和標簽之間的關(guān)聯(lián)關(guān)系，明確分析維度。就后文將要介紹的案例而言，需要從用戶屬性畫像、用戶行為畫像、用戶偏好畫像、用戶群體偏好畫像等角度去進行業(yè)務建模。
第三階段：需求場景討論與明確
在本階段，數(shù)據(jù)運營人員需要根據(jù)與需求方的溝通結(jié)果，輸出產(chǎn)品用戶畫像需求文檔，在該文檔中明確畫像應用場景、最終開發(fā)出的標簽內(nèi)容與應用方式，并就該文檔與需求方反復溝通并確認無誤。
第四階段：應用場景與數(shù)據(jù)口徑確認
經(jīng)過第三個階段明確了需求場景與最終實現(xiàn)的標簽維度、標簽類型后，數(shù)據(jù)運營人員需要結(jié)合業(yè)務與數(shù)據(jù)倉庫中已有的相關(guān)表，明確與各業(yè)務場景相關(guān)的數(shù)據(jù)口徑。在該階段中，數(shù)據(jù)運營方需要輸出產(chǎn)品用戶畫像開發(fā)文檔，該文檔需要明確應用場景、標簽開發(fā)的模型、涉及的數(shù)據(jù)庫與表以及應用實施流程。該文檔不需要再與運營方討論，只需面向數(shù)據(jù)運營團隊內(nèi)部就開發(fā)實施流程達成一致意見即可。
第五階段：特征選取與模型數(shù)據(jù)落表
本階段中數(shù)據(jù)分析挖掘人員需要根據(jù)前面明確的需求場景進行業(yè)務建模，寫好HQL邏輯，將相應的模型邏輯寫入臨時表中，并抽取數(shù)據(jù)校驗是否符合業(yè)務場景需求。
第六階段：線下模型數(shù)據(jù)驗收與測試
數(shù)據(jù)倉庫團隊的人員將相關(guān)數(shù)據(jù)落表后，設置定時調(diào)度任務，定期增量更新數(shù)據(jù)。數(shù)據(jù)運營人員需要驗收數(shù)倉加工的HQL邏輯是否符合需求，根據(jù)業(yè)務需求抽取表中數(shù)據(jù)查看其是否在合理范圍內(nèi)，如果發(fā)現(xiàn)問題要及時反饋給數(shù)據(jù)倉庫人員調(diào)整代碼邏輯和行為權(quán)重的數(shù)值。
第七階段：線上模型發(fā)布與效果追蹤
經(jīng)過第六階段，數(shù)據(jù)通過驗收之后，會通過Git進行版本管理，部署上線。使用Git進行版本管理，上線后通過持續(xù)追蹤標簽應用效果及業(yè)務方反饋，調(diào)整優(yōu)化模型及相關(guān)權(quán)重配置。
2. 各階段關(guān)鍵產(chǎn)出
為保證程序上線的準時性和穩(wěn)定性，需要規(guī)劃好各階段的任務排期和關(guān)鍵產(chǎn)出。畫像體系的開發(fā)分為幾個主要階段，包括前期指標體系梳理、用戶標簽開發(fā)、ETL調(diào)度開發(fā)、打通數(shù)據(jù)服務層、畫像產(chǎn)品端開發(fā)、面向業(yè)務方推廣應用、為業(yè)務方提供營銷策略的解決方案等，如表1-1所示。
表1-1 用戶畫像項目各階段關(guān)鍵產(chǎn)出
標簽開發(fā)：根據(jù)業(yè)務需求和應用場景梳理標簽指標體系，調(diào)研業(yè)務上定義的數(shù)據(jù)口徑，確認數(shù)據(jù)來源，開發(fā)相應的標簽。標簽開發(fā)在整個畫像項目周期中占有較大比重。
ETL調(diào)度開發(fā)：梳理需要調(diào)度的各任務之間的依賴關(guān)系，開發(fā)調(diào)度腳本及調(diào)度監(jiān)控告警腳本，上線調(diào)度系統(tǒng)。
打通服務層接口：為了讓畫像數(shù)據(jù)走出數(shù)據(jù)倉庫，應用到用戶身上，需要打通數(shù)據(jù)倉庫和各業(yè)務系統(tǒng)的接口。
畫像產(chǎn)品化：需要產(chǎn)品經(jīng)理與業(yè)務人員、技術(shù)開發(fā)人員一起對接業(yè)務需求點和產(chǎn)品功能實現(xiàn)形式，畫產(chǎn)品原型，確定工作排期。Java Web端開發(fā)完成后，需要數(shù)據(jù)開發(fā)人員向?qū)膸毂碇泄嗳霐?shù)據(jù)。
開發(fā)調(diào)優(yōu)：在畫像的數(shù)據(jù)和產(chǎn)品端搭建好架構(gòu)、能提供穩(wěn)定服務的基礎上，為了讓調(diào)度任務執(zhí)行起來更加高效、提供服務更加穩(wěn)健，需要對標簽計算腳本、調(diào)度腳本、數(shù)據(jù)同步腳本等相關(guān)計算任務進行重構(gòu)優(yōu)化。
面向業(yè)務方推廣應用：用戶畫像最終的價值產(chǎn)出點是業(yè)務方應用畫像數(shù)據(jù)進行用戶分析，多渠道觸達運營用戶，分析ROI，提升用戶活躍度或營收。因此，面向業(yè)務人員推廣畫像系統(tǒng)的使用方式、提供針對具體業(yè)務場景的解決方案顯得尤為重要。在該階段，相關(guān)人員需要撰寫畫像的使用文檔，提供業(yè)務支持。
畫像應用的落地
用戶畫像最終的價值還是要落地運行，為業(yè)務帶來實際價值。這里需要開發(fā)標簽的數(shù)據(jù)工程師和需求方相互協(xié)作，將標簽應用到業(yè)務中。否則開發(fā)完標簽后，數(shù)據(jù)還是只停留在數(shù)據(jù)倉庫中，沒有為業(yè)務決策帶來積極作用。
畫像開發(fā)過程中，還需要開發(fā)人員組織數(shù)據(jù)分析、運營、客服等團隊的人員進行畫像應用上的推廣。對于數(shù)據(jù)分析人員來說，可能會關(guān)注用戶畫像開發(fā)了哪些表、哪些字段以及字段的口徑定義；對運營、客服等業(yè)務人員來說，可能更關(guān)注用戶標簽定義的口徑，如何在Web端使用畫像產(chǎn)品進行分析、圈定用戶進行定向營銷，以及應用在業(yè)務上數(shù)據(jù)的準確性和及時性。
只有業(yè)務人員在日常工作中真正應用畫像數(shù)據(jù)、畫像產(chǎn)品，才能更好地推動畫像標簽的迭代優(yōu)化，帶來流量提升和營收增長，產(chǎn)出業(yè)績價值。
這里通過一個實踐案例來將大家更好地帶入實際開發(fā)畫像、應用畫像標簽的場景中。本節(jié)主要介紹案例背景及相關(guān)的元數(shù)據(jù)，以及開發(fā)標簽中可以設計的表結(jié)構(gòu)樣式。
在本案例的開發(fā)工作中，基于Spark計算引擎，主要涉及的語言包括HiveQL、Python、Scala、Shell等。
1. 案例背景介紹
某圖書電商網(wǎng)站擁有超過千萬的網(wǎng)購用戶群體，所售各品類圖書100余萬種。用戶在平臺上可進行瀏覽、搜索、收藏、下單、購買等行為。商城的運營需要解決兩個問題：一方面在企業(yè)產(chǎn)品線逐漸擴張、信息資源過載的背景下，如何在兼顧自身商業(yè)目標的同時更好地滿足消費者的需求，為用戶帶來更個性化的購物體驗，通過內(nèi)容的精準推薦，更好地提高用戶的點擊轉(zhuǎn)化率；另一方面在用戶規(guī)模不斷增長的背景下，運營方考慮建立用戶流失預警機制，及時識別將要流失的用戶群體，采取運營措施挽回用戶。
商城自建立以來，數(shù)據(jù)倉庫中積累著大量的業(yè)務數(shù)據(jù)、日志數(shù)據(jù)及埋點數(shù)據(jù)。如何充分挖掘沉淀在數(shù)據(jù)倉庫中的數(shù)據(jù)的價值，有效支持用戶畫像的建設，成為當前的重要工作。
2. 相關(guān)元數(shù)據(jù)
在本案例中，可以獲取的數(shù)據(jù)按其類型分為：業(yè)務類數(shù)據(jù)和用戶行為數(shù)據(jù)。其中業(yè)務類數(shù)據(jù)是指用戶在平臺上下單、購買、收藏物品、貨物配送等與業(yè)務相關(guān)的數(shù)據(jù)；用戶行為數(shù)據(jù)是指用戶搜索某條信息、訪問某個頁面、點擊某個按鈕、提交某個表單等通過操作行為產(chǎn)生（在解析日志的埋點表中）的數(shù)據(jù)。
涉及數(shù)據(jù)倉庫中的表主要包括用戶信息表、商品訂單表、圖書信息表、圖書類目表、App端日志表、Web端日志表、商品評論表等。下面就用戶畫像建模過程中會用到的一些數(shù)據(jù)表做詳細介紹。
① 用戶信息表
用戶信息表（見表1-2）存放有關(guān)用戶的各種信息，如用戶姓名、年齡、性別、電話號碼、歸屬地等信息。
表1-2 用戶信息表（dim.user_basic_info）
② 商品訂單表
商品訂單表（見表1-3）存放商品訂單的各類信息，包括訂單編號、用戶id、用戶姓名、訂單生成時間、訂單狀態(tài)等信息。
表1-3 商品訂單表（dw.order_info_fact）
③ 埋點日志表
埋點日志表（見表1-4）存放用戶訪問App時點擊相關(guān)控件的打點記錄。通過在客戶端做埋點，從日志數(shù)據(jù)中解析出來。
表1-4 埋點日志表（ods.page_event_log）
④ 訪問日志表
訪問日志表（見表1-5）存放用戶訪問App的相關(guān)信息及用戶的LBS相關(guān)信息，通過在客戶端埋點，從日志數(shù)據(jù)中解析出來。
表1-5 訪問日志表（ods.page_view_log）
⑤ 商品評論表
商品評論表（見表1-6）存放用戶對商品的評論信息。
表1-6 商品評論表（dw.book_comment）
⑥ 搜索日志表
搜索日志表（見表1-7）存放用戶在App端搜索相關(guān)的日志數(shù)據(jù)。
表1-7 搜索日志表（dw.app_search_log）
⑦ 用戶收藏表
用戶收藏表（見表1-8）記錄用戶收藏圖書的數(shù)據(jù)。
表1-8 用戶收藏表（dw.book_collection_df）
⑧ 購物車信息表
購物車信息表（見表1-9）記錄用戶將圖書加入購物車的數(shù)據(jù)。
表1-9 購物車信息表（dw.shopping_cart_df）
3. 畫像表結(jié)構(gòu)設計
表結(jié)構(gòu)設計也是畫像開發(fā)過程中需要解決的一個重要問題。
表結(jié)構(gòu)設計的重點是要考慮存儲哪些信息、如何存儲（數(shù)據(jù)分區(qū)）、如何應用（如何抽取標簽）這3個方面的問題。
不同業(yè)務背景有不同的設計方式，這里提供兩種設計思路：一是每日全量數(shù)據(jù)的表結(jié)構(gòu)；二是每日增量數(shù)據(jù)的表結(jié)構(gòu)。
Hive需要對輸入進行全盤掃描來滿足查詢條件，通過使用分區(qū)可以優(yōu)化查詢。對于用戶標簽這種日加工數(shù)據(jù)，隨著時間的推移，分區(qū)數(shù)量的變動也是均勻的。
每日全量數(shù)據(jù)，即該表的日期分區(qū)中記錄著截止到當天的全量用戶數(shù)據(jù)。例如，“select ?count(*) ?from userprofile ?where data='20180701'”這條語句查詢的是userprofile表截止到2018年7月1日的全量用戶數(shù)據(jù)。日全量數(shù)據(jù)的優(yōu)勢是方便查詢，缺點是不便于探查更細粒度的用戶行為。
每日增量數(shù)據(jù)，即該表的日期分區(qū)中記錄著當日的用戶行為數(shù)據(jù)。例如，同樣是“select count(*) from userprofile where data='20180701'”，這條語句查詢的是userprofile表在2018年7月1日記錄的當日用戶行為數(shù)據(jù)。日增量數(shù)據(jù)可視為ODS層的用戶行為畫像，在應用時還需要基于該增量數(shù)據(jù)做進一步的建模加工。
下面詳細介紹這兩種表結(jié)構(gòu)的設計方法。
① 日全量數(shù)據(jù)
日全量數(shù)據(jù)表中，在每天對應的日期分區(qū)中插入截止到當天為止的全量數(shù)據(jù)，用戶進行查詢時，只需查詢最近一天的數(shù)據(jù)即可獲得最新全量數(shù)據(jù)。下面以一個具體的日全量表結(jié)構(gòu)的例子來進行說明。
這里userid表示用戶id，labelweight表示標簽權(quán)重，theme表示標簽歸屬的二級主題，labelid表示一個標簽id。通過“日期 +標簽歸屬的二級主題+標簽id”的方式進行分區(qū)，設置三個分區(qū)字段更便于開發(fā)和查詢數(shù)據(jù)。該表結(jié)構(gòu)下的標簽權(quán)重僅考慮統(tǒng)計類型標簽的權(quán)重，如：歷史購買金額標簽對應的權(quán)重為金額數(shù)量，用戶近30日訪問天數(shù)為對應的天數(shù)，該權(quán)重值的計算未考慮較為復雜的用戶行為次數(shù)、行為類型、行為距今時間等復雜情況。
通過表名末尾追加“_all”的規(guī)范化命名形式，可直觀看出這是一張日全量表。
例如，對于主題類型為“會員”的標簽，插入“20190101”日的全量數(shù)據(jù)，可通過語句：
insert overwrite table dw. userprofile_userlabel_all partition(data_date= '20190101', theme= 'member', labelid='ATTRITUBE_U_05_001')來實現(xiàn)。
查詢截止到“20190101”日的被打上會員標簽的用戶量，可通過語句：
select count(distinct userid) from dw.userprofile_userlabel_all where data_date='20190101'來實現(xiàn)。
② 日增量數(shù)據(jù)
日增量數(shù)據(jù)表，即在每天的日期分區(qū)中插入當天業(yè)務運行產(chǎn)生的數(shù)據(jù)，用戶進行查詢時通過限制查詢的日期范圍，就可以找出在特定時間范圍內(nèi)被打上特定標簽的用戶。下面以一個具體的日增量表結(jié)構(gòu)的例子來說明。
這里，labelid表示標簽名稱；cookieid表示用戶id；act_cnt表示用戶當日行為次數(shù)，如用戶當日瀏覽某三級品類商品3次，則打上次數(shù)為3；tag_type_id為標簽類型,如母嬰、3C、數(shù)碼等不同類型；act_type_id表示行為類型，如瀏覽、搜索、收藏、下單等行為。分區(qū)方式為按日期分區(qū)，插入當日數(shù)據(jù)。
通過表名末尾追加“_append”的規(guī)范化命名形式，可直觀看出這是一張日增量表。
例如，某用戶在“20180701”日瀏覽某3C電子商品4次（act_cnt），即給該用戶（userid）打上商品對應的三級品類標簽（tagid），標簽類型（tag_type_id）為3C電子商品，行為類型（act_type_id）為瀏覽。這里可以通過對標簽類型和行為類型兩個字段配置維度表的方式，對數(shù)據(jù)進行管理。例如對于行為類型（act_type_id）字段，可以設定1為購買行為、2為瀏覽行為、3為收藏行為等，在行為標簽表中以數(shù)值定義用戶行為類型，在維度表中維護每個數(shù)值對應的具體含義。
該日增量數(shù)據(jù)表可視為ODS層用戶行為標簽明細。在查詢過程中，例如對于某用戶id為001的用戶，查詢其在“20180701”日到“20180707”日被打上的標簽，可通過命令：
select * from dw.userprofile_act_feature_append where userid = '001' and data_date>='20180701' and data_date<= '20180707'查詢。
該日增量的表結(jié)構(gòu)記錄了用戶每天的行為帶來的標簽，但未計算打在用戶身上標簽的權(quán)重，計算權(quán)重時還需做進一步建模加工。標簽權(quán)重算法詳見4.6節(jié)的內(nèi)容。
③ 關(guān)于寬表設計
用戶畫像表結(jié)構(gòu)如何設計，沒有一定要遵循的固定的格式，符合業(yè)務需要、能滿足應用即可。下面通過兩個寬表設計的案例，提供另一種解決方案的思路。
用戶屬性寬表設計（見表1-10），主要記錄用戶基本屬性信息。
表1-10 用戶屬性寬表設計
用戶日活躍寬表設計（見表1-11），主要記錄用戶每天訪問的信息。
本書重點講解如何運用大數(shù)據(jù)定量刻畫用戶畫像，然而對于用戶的刻畫除了定量維度外，定性刻畫也是常見手段。定性類畫像多見于用戶研究等運營類崗位，通過電話調(diào)研、網(wǎng)絡調(diào)研問卷、當面深入訪談、網(wǎng)上第三方權(quán)威數(shù)據(jù)等方式收集用戶信息，幫助其理解用戶。這種定性類調(diào)研相比大數(shù)據(jù)定量刻畫用戶來說，可以更精確地了解用戶需求和行為特征，但這個樣本量是有限的，得出的結(jié)論也不一定能代表大部分用戶的觀點。
通過制定調(diào)研問卷表，我們可以收集用戶基本信息以及設置一個或多個場景，專訪用戶或網(wǎng)絡回收調(diào)研問卷，在分析問卷數(shù)據(jù)后獲取用戶的畫像特征。目前市場上“問卷星”等第三方問卷調(diào)查平臺可提供用戶問卷設計、鏈接發(fā)放、采集數(shù)據(jù)和信息、調(diào)研結(jié)果分析等一系列功能，如圖1-7所示。
圖1-7 某調(diào)研問卷示例（截圖自“問卷星”）
根據(jù)回收的調(diào)研問卷，可結(jié)合統(tǒng)計數(shù)據(jù)進一步分析用戶畫像特征（如圖1-8所示）。
圖1-8 回收的調(diào)研問卷（截圖自“問卷星”）