推薦 :一文從0到1掌握用戶畫像知識體系

00

引言

前段時間上了一個用戶畫像的課程,授課老師是《用戶畫像:方法論與工程化解決方案》的作者趙宏田老師;另外也研讀了一些講述用戶畫像的文章。

基於對上述學習內容的理解,同時結合工作實踐,通過本文和大家分享下有關用戶畫像的認知、建設方法、產品化和應用。

01

初識用戶畫像

1.1   用戶畫像

隨着用戶的一切行爲數據可以被企業追蹤到,企業的關注點日益聚焦在如何利用大數據爲經營分析和精準營銷服務,而要做精細化運營,首先要建立本企業的用戶畫像。

提到用戶畫像的概念,我們區分下用戶角色(Persona)和用戶畫像(Profile):

1.1.1  用戶角色(Persona)

用戶角色本質是一個用以溝通的工具,當我們討論產品、需求、場景、用戶體驗的時候,爲了避免在目標用戶理解上的分歧,用戶角色應運而生。用戶角色建立在對真實用戶深刻理解,及高精準相關數據的概括之上,虛構的包含典型用戶特徵的人物形象。如下是一個典型的用戶角色:

1.1.2  用戶畫像(Profile)

用戶畫像更多被運營和數據分析師使用,精準營銷、經營分析、個性化推薦都是基於用戶畫像的應用。用戶畫像是各類描述用戶數據的變量集合,能夠準確描述任何一個真實用戶。如下是一個簡化的用戶畫像:

{  "ID": 123456,   

"姓名": "張建國",   

"性別": "男",   

"出生年月": 631123200,   

"籍貫": "北京",   

"居住地": "北京",   

"教育背景":

{  "學校":"北京大學",       

"專業": "CS",       

"入學年月":1220198400   

}

}

1.2  用戶標籤和用戶畫像

1.2.1  用戶標籤

用戶標籤,即對用戶某個維度屬性的描述,具有相互獨立、可枚舉窮盡的特點。採集業務、日誌、埋點等數據後,經過不同統計方式計算出用戶屬性、用戶行爲、用戶消費、風險控制、社交等維度標籤。例如:性別、年齡、近30日訪問次數、購買水平、經常活躍時間段等。有關用戶標籤體系建設的詳細描述,見「2 建設標籤和標籤體系」章節。

1.2.2  用戶畫像

構建用戶畫像,就是給用戶打上各種維度的標籤。從業務價值來說,標籤和畫像是類似中間層的系統模塊,爲數據驅動運營奠定了基礎,可以幫助大數據“走出”數據倉庫,針對用戶進行個性化推薦、精準營銷等多樣化服務。有關用戶畫像系統、落地應用的詳細描述,見「3 用戶畫像產品化」「4 用戶畫像應用」「5 用戶畫像實踐案例」章節。

1.3  用戶羣組和用戶標籤

用戶標籤和用戶羣組是兩個容易混淆、具有迷惑的概念,下面嘗試區分:

1.3.1  用戶羣組

需要用戶屬性和行爲組合,才能圈選出全面的目標羣體。只有行爲數據,只能看到這個人做過什麼事,但這個人是男是女、年齡多大、註冊多久 、購買能力如何等信息都不知道,這樣圈選出的用戶羣是有缺陷的,一般不會直接應用於精準營銷場景。

1.3.2  用戶標籤

建立用戶標籤,不用非要組合用戶屬性和行爲事件,單用用戶屬性可以,單用行爲事件也可以。基於用戶屬性、行爲事件計算出的用戶標籤,本質也是用戶屬性,或者說用戶屬性本身就是標籤。

1.3.3  羣組是標籤的一種應用方式

標籤作爲一箇中間層系統模塊,在精準營銷場景,往往不會只使用一個標籤進行推送,更多情況下需要組合多個標籤來滿足業務上對人羣的定義,見下圖:

這裏通過一個場景來介紹基於用戶標籤圈選用戶羣組的應用。某女裝大促活動期間,渠道運營人員需要篩選出平臺上的優質用戶,並通過短信、郵件、Push等渠道進行營銷。

第1步:通過圈選“瀏覽”“收藏”“加購”“購買”“搜索”與該女裝相關品類的標籤來篩選出可能對該女裝感興趣的潛在用戶

第2步:組合其他標籤(如“性別”“消費金額”“活躍度”等)篩選出對應的高質量用戶羣,推送到對應渠道。

因此,將用戶屬性、行爲事件數據抽象成標籤後,可通過組合標籤方式找到目標潛在用戶人羣。從這個角度理解,用戶羣組是用戶標籤應用的一種方式。 

02

建設標籤和標籤體系

2.1  標籤的分類

標籤本身會有很多分類方式,但從標籤的實現規則來看,大致可以分爲以下3種類型:① 統計類標籤、② 規則類標籤、③ 機器學習挖掘類標籤。

2.1.1 統計類標籤

這類標籤是最爲基礎也最爲常見的標籤類型,例如,對於某個用戶來說,其性別、年齡、城市、星座、近7日活躍時長、近7日活躍天數、近7日活躍次數等字段可以從用戶註冊數據、用戶訪問、消費數據中統計得出。該類標籤構成了用戶畫像的基礎。 

2.1.2  規則類標籤

該類標籤基於用戶行爲、用戶屬性和確定的規則產生。例如,對平臺上“消費活躍”用戶這一口徑的定義爲“近30天交易次數≥2”。在實際開發畫像的過程中,由於運營人員對業務更爲熟悉,而數據人員對數據的結構、分佈、特徵更爲熟悉,因此規則類標籤的規則由運營人員和數據人員共同協商確定。

2.1.3  機器學習挖掘類標籤

該類標籤通過機器學習挖掘產生,用於對用戶的某些屬性或某些行爲進行預測判斷。例如,根據一個用戶的行爲習慣判斷該用戶是男性還是女性、根據一個用戶的消費習慣判斷其對某商品的偏好程度。該類標籤需要通過算法挖掘產生。

在項目工程實踐中,一般統計類和規則類的標籤即可以滿足應用需求,在開發中佔有較大比例。機器學習挖掘類標籤多用於預測場景,如判斷用戶性別、用戶購買商品偏好、用戶流失意向等。一般地,機器學習標籤開發週期較長,開發成本較高,因此其開發所佔比例較小。

事實上,最終標籤體系中是以用戶視角定義的,需要結合具體的業務。比如某電商業務標籤分類,用戶屬性維度標籤、用戶行爲維度標籤、用戶消費維度標籤、風險控制維度標籤、社交屬性維度標籤。

2.2  標籤建設流程

下圖是一個標籤建設流程,會側重產品經理視角,主要描述需求的分析過程和產出文檔,同時對標籤的開發原理進行簡單總結。

2.2.1  需求收集與分析

在需求收集與分析環節,可以按還原業務流程——明確商業目的——從策略推標籤——匯聚標籤的步驟開展。

某服裝零售商,通過佈局線上商城和線下實體店來擴大經營。線上的話,主要是通過微信公衆號引流到小程序,然後在小程序完成交易。下面通過該服裝零售案例,具體描述下,如何進行標籤需求的收集與分析:

1、識別分析業務流程和業務場景觸點

用戶畫像是基於業務的,因此,構建標籤的第一個步驟就是識別與分析用戶的決策流程和業務場景,以便快速熟悉業務。參考下方案例業務流程的還原:

首先是通過各種場景被吸引來的微信用戶關注公衆號成爲了粉絲,然後公衆號運營人員會給微信粉絲推送圖文消息進行粉絲運營,同時把粉絲引流到小程序商城,公衆號粉絲最終會在小程序商城成交轉化。在整個過程中,公衆號運營人員會持續進行微信粉絲的維護和流失粉絲的挽回等運營工作。

此處推薦:

  1. 《有效需求分析》中詳細需求篇業務功能支持主線需求分析方法

2、明確每個業務場景觸點的商業目的

這一步基於之前對業務流程的梳理,洞察業務問題,明確想要達到什麼商業目的,並對商業目的進行拆分。參考下方案例從明確整體商業目標,到商業目標拆解和量化的過程:

O:假設該服裝零售商線上的佈局已經比較完善,現階段的首要商業目的就是提升銷售金額,因此“提升銷售金額”就是該零售電商的北極星指標,那麼提升流量、提升轉化率、提升客單價、提升復購率就是拆解後的核心指標。

S:此處假設想要提升進入小程序商城的流量,可以採取的策略也很多。比如,通過掃碼關注後推送優惠券方式吸引更多的微信用戶關注成爲粉絲;再比如,產出更高質量微信圖文,更好的運營微信私域流量。

M:緊接上一步,針對推送優惠券吸引用戶關注公衆號這個策略,我們可以重點關注通過掃碼方式關注公衆號比率、取關的比率,新舊粉絲的比率。

此處推薦:

  1. OSM模型(Objective、Strategy、Measurement)

  2. 銷售公式=流量*轉化率*客單價*復購率

3、從商業目的導向運營策略設計及用戶標籤需求

針對不同商業目的,對標籤體系的建設也是不一樣的,因此要從運營策略推導出標籤。比如業務部門要做個性化推薦,做關於物或者人的興趣、偏好的標籤會比較有價值;但是如果要做精細化運營,關於用戶的留存、活躍標籤會更有價值。參考下方用戶標籤選用的案例:

把提升掃碼方式關注率作爲量化的目標,選用的運營策略是通過推送優惠券方式吸引微信用戶掃碼,新粉絲掃碼關注後推送100元優惠券,老粉絲掃碼後推送50元優惠券,那麼執行運營策略過程中需要用到“是否新粉絲”這個標籤。

在此階段,可以準備一個簡單的記錄溝通內容的Excel模板,列表頭包括標籤名、標籤規則、使用場景等,和業務方一起把溝通內容記錄下來。

4、組織標籤

關於組織標籤,需要基於對業務和策略的理解,以用戶視角進行分類管理。下面是一個參考框架:

(1)用戶屬性類標籤:性別、年齡、省份、城市、註冊日期、手機號碼等

(2)用戶行爲類標籤:近30日訪問次數、近30日客單價、近30日活躍天數、近30日訪問時長、平均訪問深度等

(3)用戶消費類標籤:收入狀況、購買力水平、已購商品、購買渠道偏好、最後購買時間、購買頻次等

(4)商品品類類標籤:高跟鞋、靴子、襯衫、法式連衣裙、牛仔褲等

(5)社交屬性類標籤:經常活躍的時間段、活躍地點、單身、評價次數、好評度等

2.2.2  產出標籤需求文檔

經過前面的需求收集與分析,已明確了業務方的標籤需求。爲了順利交付研發,接下來還需要:撰寫標籤體系文檔——根據標籤規則確定埋點——撰寫數據需求文檔。

1、撰寫標籤體系文檔

在此環節,數據產品經理需要根據前期和業務方的溝通內容,產出具體的標籤體系文檔:

(1)標籤ID:例如, ATTRITUBE_U_01_001, 其中“ATTRITUBE”爲人口屬性主題,“_”後面的”U”爲userid維度,“_”後面“01”爲一級歸類,最後面的“001”爲該一級標籤下的標籤明細

(2)標籤名稱:英文格式名稱,例如,famale

(3)標籤漢語:女

(4)標籤主題:描述標籤所屬的主題,例如,用戶屬性維度標籤、用戶行爲維度標籤、用戶消費維度標籤

(5)標籤層級ID:標籤所屬的層級,一般會分爲2級

(6)名稱:與ID對應的名稱

(7)標籤類型:統計類標籤、規則類標籤、機器學習算法類標籤

(8)更新頻率:實時更新、離線T+1更新、單次計算

(9)標籤算法規則:

  1. 需要描述選擇哪張數據表中的具體哪個字段,若需要多張表做關聯,還需要說明通過什麼字段進行join

  2. 具體的算法邏輯和統計週期,比如“近7天支付次數”,就是需要統計近7天支付的總次數。

(10)使用場景描述

(11)排期

(12)開發人

(13)需求方

(14)優先級

2、根據標籤規則確定埋點

前面已經明確了標籤的算法規則,接下來要進一步確定應該埋哪些點來採集所需的數據,下面是一個具體案例:

針對“購買商品品類偏好”這個標籤,會用到點擊下單按鈕事件數據,以及商品名稱、商品分類等事件屬性數據,那麼就需要對點擊下單按鈕事件進行埋點。

3、撰寫數據需求文檔

埋點取哪些數據已經確定了,就需要產出具體的數據需求文檔,交付負責埋點的開發同事進行埋點取數了。在數據需求文檔,應該明確以下內容:

(1)埋點名:click_order

(2)埋點顯示名:點擊下單按鈕

(3)上報時機:根據實際情況,選擇是何時進行上報。比如對於點擊下單事件,可以選擇點擊了下單按鈕時就進行上報

(4)埋點形式:根據實際情況,選擇是客戶端埋點,還是服務端埋點。比如“購買商品品類偏好”標籤的下單按鈕點擊事件,因爲只是想判斷用戶對購買商品的偏好,用戶點擊按鈕後已經能說明是否有偏好了,不需要等服務端返回是否成功的提醒,因此適合採用客戶端埋點形式

(5)屬性名:事件屬性的名稱,比如點擊下單按鈕事件的商品名稱屬性

(6)屬性值:比如襯衫

(7)備註

實際工作中,撰寫標籤體系文檔、根據標籤規則確定埋點、撰寫數據需求文檔,會是一個互相完善補充的過程。

2.2.3  標籤的開發

在整個工程化方案中,系統依賴的基礎設施包括Spark、Hive、HBase、Airflow、MySQL、Redis、Elasticsearch。除去基礎設施外,系統主體還包括ETL作業、用戶畫像主題建模、標籤結果數據在應用端的存儲3個重要組成部分。如圖所示是用戶畫像數倉架構圖,下面對其進行簡單介紹。

1、Hive數據倉庫ETL作業

下方虛線框中爲常見的數據倉庫ETL加工流程,也就是將每日的業務數據、日誌數據、埋點數據等經過ETL過程,加工到數據倉庫對應的ODS層、DW層、DM層中。

2、Hive數據倉庫用戶畫像主題建模

中間的虛線框即爲用戶畫像建模的主要環節,會對基於數據倉庫ODS層、DW層、DM層中與用戶相關數據進行二次建模加工。

3、標籤結果數據在應用端的存儲

在用戶畫像主題建模過程中,會將用戶標籤計算結果寫入Hive,由於不同數據庫有不同的應用場景,下面分別進行描述:

(1)MySQL

作爲關係型數據庫,在用戶畫像中可用於元數據管理、監控預警數據、結果集存儲等應用中。下面詳細介紹這3個應用場景:

  1. 元數據管理:

    MySQL具有更快的讀寫速度,平臺標籤視圖中(Web端產品)的標籤元數據可以維護在MySQL關係數據庫中,便於標籤的編輯、查詢和管理。

  2. 監控預警數據:

    在對畫像的數據監控中,調度流每跑完相應的模塊,就將該模塊的監控數據插入MySQL中,當校驗任務判斷達到觸發告警閾值時,就觸發告警。

  3. 結果集存儲:

    存儲多維透視分析用的標籤、圈人服務用的用戶標籤、當日記錄各標籤數量等。

(2)HBase

與Hive不同的是,HBase能夠在數據庫上實時運行,而不是跑MapReduce任務,適合進行大數據的實時查詢。下面通過一個案例來介紹HBase在畫像系統中的應用場景和工程化實現方式:

某渠道運營人員爲促進未註冊的新安裝用戶註冊、下單,計劃通過App首頁彈窗發放紅包或優惠券的方式進行引導。每天畫像系統的ETL調度完成後對應人羣數據就被推送到廣告系統(HBase數據庫進行存儲)。滿足條件的新用戶來訪App時,由在線接口讀取HBase數據庫,在查詢到該用戶時爲其推送該彈窗。

(3)Elasticsearch

是一個開源的分佈式全文檢索引擎,可以近乎實時地存儲、檢索數據。對於用戶標籤查詢、用戶人羣計算、用戶羣多維透視分析這類對響應時間要求較高的場景,也可以考慮選用Elasticsearch進行存儲。

2.2.4  標籤發佈與效果追蹤

通過開發測試,上線後需要持續追蹤標籤應用效果及業務方反饋,調整優化模型及相關權重配置。 

03

用戶畫像產品化

從業務價值來說,標籤和畫像類似一個爲前臺服務提供數據支持的中間層系統模塊。開發完畫像標籤數據,如果只是“躺在”數據倉庫中,並不能發揮更大的業務價值。只有將畫像數據產品化後才能以標準方式提升數據處理鏈路上各個環節的效率,同時也更便於業務方使用。下面分別從產品化後涵蓋的標籤生產架構和功能模塊兩個角度進行總結:

3.1  用戶畫像產品系統架構

下圖是一個用戶畫像產品系統的結構圖,數據是從左到右的,主要包括數據採集、數據接入、數據整合/標籤計算、標籤應用4個層級。下面嘗試對其進行簡單描述:

3.1.1  數據採集

在數據採集模塊,主要通過客戶端/服務端SDK、導入、對接第三方應用3種埋點方式進行日誌數據、業務數據、第三方數據的採集。

1、SDK

(1)客戶端SDK:通過客戶端SDK埋點,可以採集iOS、Android、小程序、網站等各種客戶端的用戶行爲數據和用戶屬性信息。

(2)服務端SDK:若數據已經存在數據庫、數據倉庫,比如訂單信息,可以使用對應開發語言的服務端SDK進行數據的採集。

2、Importer

可以根據運行環境、源數據格式、導入數據量的大小等影響因素,選擇不同大導入方式,把歷史文件數據導進用戶畫像產品系統。

3、Link

針對不同第三方產品OpenAPI的特點,採用接收事件消息推送、或主動輪詢方式採集用戶在不同第三方應用系統的個人屬性和行爲事件數據。

3.1.2  數據接入

埋點數據先大量進入Kafka,然後慢慢消費接入後續的數據整合存儲系統。

3.1.3  數據整合/標籤計算

在用戶畫像系統中,主要使用Hive作爲數據倉庫,進行ETL處理,開發相應的用戶屬性表和用戶行爲表,以及標籤的計算。

1、數據整合

各種渠道接進來的數據,存在孤立、空值、格式不對應、超過極限範圍等數據質量問題,因此需要進行髒數據清洗、格式轉換、用戶識別與合併等整合工作:

(1)Clean/Transform

  1. Clean:

    比如,某個用戶的出生年月時間是未來的某個日期時刻,因此就需要把這類髒數據給過濾掉

  2. Transform:

    比如,通過某個第三方應用API獲取到的所有用戶的地區信息是IPB標準編碼形式,爲了能和其他渠道的信息一起進行分析,就需要根據IPB標準編碼轉換成標準的省、市格式

(2)Id Mapping

  1. 各個渠道接進來的用戶屬性數據、行爲事件數據等都是孤立的,爲了能計算用戶的全方位的綜合標籤,就需要做用戶的識別合併,比如通過unionID,識別合併綁定在同一微信開放平臺的公衆號、小程序、網站的同一個用戶的信息。

經過數據整合處理,數據會進入下面的數據模型中:

2、標籤計算

在用戶畫像系統,會做一套批量離線的標籤處理引擎,依賴的是底層比較穩定的數據結構。這個標籤引擎一邊讀事件數據,一邊讀用戶的屬性數據,再配合上特定的標籤規則,做一個批量計算,最後生成用戶標籤。

3.1.4  標籤應用

標籤的應用主要分爲前端畫像展示、通過API接入其他系統兩大類應用方式,通過下面的「3.2 用戶畫像產品化功能模塊」章節具體描述。

3.2  用戶畫像產品功能模塊

3.2.1  系統看板

通常用戶畫像系統的數據看板,以可視化形式展示企業的核心用戶數據資產情況或者重點關注的人羣數據。旨在建立和統一使用者對企業數據資產或者核心人羣數據的基礎認知,主要分成以下幾類:

1、用戶量級及變化趨勢:不同設備類型ID量級、不同類型用戶量級(如註冊與非註冊用戶、付費與非付費用戶等);

2、標籤資產:按主要類目統計標籤個數等; 

3、核心用戶標籤:展示固有或自定義人羣的關鍵標籤畫像數據等;

3.2.2  標籤管理

供業務人員進行標籤的增、刪、改、查等操作,包含:標籤分類、新建標籤、標籤審覈、標籤上下架、標籤覆蓋人數監控等。

基於用戶行爲數據、用戶屬性數據,通過設置標籤規則創建標籤:

3.2.3  單用戶畫像

主要能力包含通過輸入用戶ID,來查看單用戶畫像的詳情數據,如用戶的屬性信息、用戶行爲等數據。

3.2.4  用戶分羣和用戶羣畫像

1、用戶分羣

用戶分羣功能主要是面向業務人員使用。產品經理、運營、客服等業務人員在應用標籤時,可能不僅僅只查看某一個標籤對應的人羣情況,更多地可能需要組合多個標籤來滿足其在業務上對人羣的定義。例如:組合“過去7天領取優惠券次數大於1次”、“活動活躍度等於高和極高”、“女性”用戶這3個標籤定義目標人羣,查看該類人羣覆蓋的用戶量。

2、用戶羣畫像

和用戶分羣功能相似,用戶羣畫像功能首先也需要組合標籤圈定用戶羣體,不同之處在於用戶羣畫像功能支持從多個維度去分析圈定用戶羣體的特徵,而用戶分羣功能側重的是將篩選出來的用戶羣推送到各業務系統中,提供服務支持。

3.2.5  BI分析

BI平臺和這些數據打通後,可以豐富數據的維度,支持通過多種分析模型進行更加豐富和深層的分析及對比。

3.2.6   OpenAPI

OpenAPI能夠保障畫像系統數據與各系統之間打通,如push推送系統、營銷系統、廣告系統、推薦系統、BI等平臺,並且保證各系統數據的實時更新,避免同源不同數的問題。

04

用戶畫像應用

前面提到過用戶畫像主要有:經營分析、精準營銷、個性化推薦與服務3個方面的應用。具體又可以分爲:

4.1  經營分析

用戶畫像系統的標籤數據通過API進入分析系統後,可以豐富分析數據的維度,支持進行多種業務對象的經營分析。下面總結的是一些市場、運營、產品人員分析時會關注的指標:

4.1.1  流量分析

1、流量來源

2、流量數量:UV、PV

3、流量質量:瀏覽深度(UV、PV)、停留時長、來源轉化、ROI(投資回報率,return on investment)

4.1.2  用戶分析

1、用戶數量:新用戶數、老用戶數、新/老用戶數量比

2、用戶質量:新增用戶數(App啓動)、活躍用戶數(App啓動)、用戶留存(App啓動-App啓動)、用戶參與度、沉睡、客單價

4.1.3  商品分析

1、商品動銷:GMV、客單價、下單人數、取消購買人數、退貨人數、各端復購率、購買頻次分佈、運營位購買轉化

2、商品品類:支付訂單情況(次數、人數、趨勢、復購)、訪購情況、申請退貨情況、取消訂單情況、關注情況

4.1.4  訂單分析

1、訂單指標:總訂單量、退款訂單量、訂單應付金額、訂單實付金額、下單人數

2、轉化率指標:新增訂單/訪問UV、有效訂單/訪問UV

4.1.5  渠道分析

1、用戶活躍

(1)活躍用戶:UV、PV

(2)新增用戶:註冊量、註冊同環比

2、用戶質量

(1)留存:次日/7日/30日留存率

3、渠道收入

(1)訂單:訂單量、日均訂單量、訂單同環比

(2)營收:付費金額、日均付費金額、金額同環比

(3)用戶:人均訂單量、人均訂單金額

4.1.6  產品分析

1、搜索功能:搜索人數/次數、搜索功能滲透率、搜索關鍵詞

2、關鍵路徑漏斗等產品功能設計分析

4.2  精準營銷

4.2.1  短信/郵件/push營銷

日常生活中我們經常會從許多渠道接收到營銷來的信息。一條關於紅包到賬的短信消息推送可能會促使用戶打開已經很久沒訪問的App,一條關於心願單裏面圖書降價的郵件消息推送可能會刺激用戶打開推送鏈接直接下單購買。具體有哪些類型的營銷方式呢?大致可以分爲以下4類:

1、基於行爲營銷:產品瀏覽、加入購物車、門店掃碼、訂單取消、訂單退貨等

2、基於位置營銷:周邊門店、周邊活動、常去區域等

3、基於節日營銷:生日、春節、雙十一、雙十二、聖誕等

4、基於會員營銷:歡迎入會、卡券提醒、積分變更、等級變化、會員禮遇等

4.2.2  客服話術

當我們在向某平臺的客服部門投訴、諮詢或反饋意見時,客服人員可以準確的說出我們在平臺的購買情況,上一次諮詢問題的處理結果等信息,針對性的提出解決方法,對於高價值用戶提供VIP客服通道等專項服務。

4.3  個性化推薦與服務

應用的運營者,可以通過個推用戶畫像中的性別、年齡段、興趣愛好、瀏覽購買行爲等標籤,給用戶推薦不同的內容。如今日頭條上的個性化文章內容推薦、抖音上基於用戶畫像做的個性化視頻內容推薦、淘寶上基於用戶瀏覽行爲等畫像數據做的個性化商品推薦等。

05

用戶畫像實踐案例

基於畫像系統去做多方面的數據分析、觸達用戶的運營方案,可以快速地將標籤數據應用到服務層(T+1、實時應用),通過效果分析得到用戶反饋後,幫助迭代營銷策略或產品設計。下面通過一些實踐案例來場景化復現用戶畫像的應用點和應用方式。

5.1  A/B人羣效果測試

5.1.1  案例背景

某零食類快消商品爲在大促活動期間獲得較好的銷量,計劃通過消息推送的方式種草新上市產品、產品的保健功能等系列文章,爲大促活動造勢,激發銷量轉化。爲了精準定位目標人羣流量,渠道運營人員現在計劃做兩個A/B人羣效果測試: 

1、不同內容標題對流量的影響; 

2、精準推送相比普通推送帶來的流量提升。

5.1.2  用戶畫像切入點

整個項目中需要梳理清楚如何切分AB組流量,如何設計好AB組人羣規則和效果監測。下面分步驟介紹畫像系統如何切入AB人羣測試中。 

1、對AB組用戶做切分 

爲了做A/B組測試,首先需要做好流量的切分,可以使用A/B分配隨機分流的形式,將用戶劃分爲A/B人羣。

2、測試文案標題對流量影響的方案 

某平臺渠道運營人員爲在大促活動期間召回更多用戶來訪App,計劃在活動預熱期選取少量用戶做一版文案標題的AB效果測試。 

在該測試方案中,控制組A選取了A路徑、近x天來訪過,且近x天內瀏覽/收藏/加購過該零食的用戶羣,給該批用戶推送零售文案A;對照組B選取了B路徑、近x天來訪過,且近x天內瀏覽/收藏/加購過該零食的用戶羣,給該批用戶推送零食文案B。控制組和對照組的用戶量相同,但文案不同,後續監控兩組人羣的點擊率大小,進而分析不同文案對用戶點擊的影響。 

例如,通過用戶羣組功能圈選出A組的用戶,見下圖:

3、精準推送相比普通推送帶來的流量提升的測試方案 

在使用畫像系統精細化推送人羣前,某平臺對用戶採用無差別推送消息的形式進行推送。爲了測試精細化運營人羣相比無差別運營帶來的流量提升,渠道運營人員決定在近期重點運營的零食營銷會場做一個AB效果測試。 

該測試方案中,控制組A選取了A路徑、近x天來訪過,近x天內瀏覽/收藏/加購過該零食的用戶羣;對照組B選取了B路徑、近x天來訪過,且沒有類目偏好的用戶羣。對AB組用戶羣都消息推送相同的文案,後續監控兩組人羣的點擊率大小,進而分析精準營銷推送帶來的增長點大小。

5.1.3  效果分析

在AB組人羣消息推送上線後,後續需要搭建監控報表來監測控制組和測試組的流量和轉化情況,主要關注下方列表中的指標:

例如,使用事件分析模型搭建的AB人羣的GMV對比報表,見下圖:

5.2  女神節定向營銷

5.2.1  案例背景

某主打女士商品的品牌商,計劃在女神節對不同品類偏好的女神進行定向營銷。營銷信息會分兩次推送,首次是在當天的10:00推送促銷信息,第二次是在當天晚上的10:00再統一來一波促銷提醒。最後通過追蹤目標受衆的當日支付訂單完成率來評估營銷效果。

5.2.2  實現邏輯

首先基於用戶性別標籤、年齡標籤圈選出18~40歲,女性的用戶。然後統一延時至2020-03-08 上午 10:00,根據用戶品類偏好標籤定向推送不同的營銷內容,比如給品類偏好=彩妝護膚的人羣推送春日美妝節類的營銷信息。第二波推送會延時至2020-03-08 下午 10:00 進行推送,推送信息爲統一的促銷提醒。

5.3  新安裝未註冊用戶實時營銷

5.3.1  案例背景

某零食商城App運營人員爲促進未註冊的新安裝用戶註冊、下單,制定了運營規則:新安裝未註冊用戶打開App時,通過App彈窗方式爲其推送優惠券進行營銷。比如,用戶安裝App後未進行註冊,用戶改天打開後立馬對其推送App彈窗優惠券,以更好地引導用戶完成註冊、下單。

5.3.2  用戶畫像切入點

渠道運營人員通過組合用戶標籤(如“未註冊用戶”和“安裝距今天數”小於××天)篩選出對應的用戶羣,然後選擇將對應人羣推送到“廣告系統”。這樣每天畫像系統的ETL調度完成後對應人羣數據就被推送到HBase數據庫進行存儲。滿足條件的新用戶來訪App時,由在線接口讀取HBase數據庫,在查詢到該用戶時爲其推送該彈窗。

5.4  某電商再營銷廣告

5.4.1  案例背景

某電商App的商品運營團隊欲提升電子產品的老客復購率、新客下單率,於是選擇了和頭條合作投放再營銷廣告。比如,某用戶在該電商App看了vivo手機,第二天刷今日頭條的時候,就看到了對應手機的廣告信息。

5.4.2  實現邏輯

首先需要保證該電商App和今日頭條的API已經打通,然後基於用戶在App內行爲(瀏覽、收藏、加購、搜索等)進行算法挖掘產生用戶商品偏好的標籤。當今日頭條捕獲用戶設備信息後,就會向該電商發送一個請求,詢問是否需要對這個用戶展示廣告。這個時候電商平臺會判斷該用戶是否是自己的用戶,如果是自己用戶,就會對今日頭條返回一個推薦結果,那麼用戶就會在今日頭條看到之前瀏覽過的商品信息了,點擊後就可以跳轉到電商App內的商品詳情頁了。

06

總結

1、首先,描述了有關用戶畫像、用戶標籤、用戶羣組的認知性概念;

2、然後,闡述了標籤體系的分類、標籤建設的流程和方法;

3、爲了說明如何讓“躺在”數據倉庫中的畫像標籤數據發揮更大的業務價值,接下來從系統架構、應用層功能兩個角度簡單總結了用戶畫像系統的建設;

4、最後,從經營分析、精準營銷、個性化推薦3個角度總結了用戶畫像的應用,並在實踐案例部分列舉幾個用戶畫像實際應用的案例。

參考資料:

[1]  趙宏田,《用戶畫像:方法論與工程化解決方案》

[2]  小風老師,21天埋點訓練營

[3]  草帽小子,如何從0-1構建用戶畫像體系

[4]  酒仙橋@道明學長,從0搭建用戶畫像系統系列文章

[5]  秦路,什麼是用戶畫像,一般用戶畫像的作用是什麼

[6]  蔡晴晴,如何創建一個有效的用戶畫像(Persona)

[7]  趙宏田,《數據化運營:系統方法與實踐案例》

[8]  劉振華,《電商數據分析與數據化運營》

作者:上海@王松  客戶數據平臺產品經理

轉自: 一個數據人的自留地  公衆號;

END


版權聲明:本號內容部分來自互聯網,轉載請註明原文鏈接和作者,如有侵權或出處有誤請和我們聯繫。


合作請加QQ:365242293  

數據分析(ID : ecshujufenxi )互聯網科技與數據圈自己的微信,也是WeMedia自媒體聯盟成員之一,WeMedia聯盟覆蓋5000萬人羣。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章