基于Spark的用戶行為路徑分析的產(chǎn)品化實(shí)踐
路徑分析有助于產(chǎn)品的優(yōu)化與改進(jìn),可以用于分析各個(gè)模塊的流轉(zhuǎn)規(guī)律與特點(diǎn),挖掘用行為,進(jìn)而不斷實(shí)現(xiàn)產(chǎn)品優(yōu)化與改進(jìn)。
1. ?什么是用戶行為路徑
用戶行為路徑分析是互聯(lián)網(wǎng)行業(yè)特有的一類數(shù)據(jù)分析方法,它主要根據(jù)每位用戶在App或網(wǎng)站中的點(diǎn)擊行為日志,分析用戶在App或網(wǎng)站中各個(gè)模塊的流轉(zhuǎn)規(guī)律與特點(diǎn),挖掘用戶的訪問或點(diǎn)擊模式,進(jìn)而實(shí)現(xiàn)一些特定的業(yè)務(wù)用途,如App核心模塊的到達(dá)率提升、特定用戶群體的主流路徑提取與瀏覽特征刻畫,App產(chǎn)品設(shè)計(jì)的優(yōu)化與改版等。
2.?路徑分析業(yè)務(wù)場(chǎng)景
用戶行為路徑分析的一個(gè)重要終極目的便是優(yōu)化與提升關(guān)鍵模塊的轉(zhuǎn)化率,使得用戶可以便捷地依照產(chǎn)品設(shè)計(jì)期望的主流路徑直達(dá)核心模塊。具體在分析過程中還存在著以下的應(yīng)用場(chǎng)景:
i.用戶典型路徑識(shí)別與用戶特征分析
用戶特征分析中常常使用的都是一些如性別、地域等人口統(tǒng)計(jì)數(shù)據(jù)或訂單價(jià)、訂單數(shù)等運(yùn)營(yíng)數(shù)據(jù),用戶訪問路徑數(shù)據(jù)為我們了解用戶特征打開了另一扇大門。例如對(duì)于一款圖片制作上傳分享的應(yīng)用,我們可以通過用戶的App使用操作數(shù)據(jù),來劃分出樂于制作上傳的創(chuàng)作型用戶,樂于點(diǎn)贊評(píng)論的互動(dòng)型用戶,默默瀏覽看圖的潛水型用戶,以及從不上傳只會(huì)下載圖片的消費(fèi)型用戶。
ii.產(chǎn)品設(shè)計(jì)的優(yōu)化與改進(jìn)
路徑分析對(duì)產(chǎn)品設(shè)計(jì)的優(yōu)化與改進(jìn)有著很大的幫助,可以用于監(jiān)測(cè)與優(yōu)化期望用戶路徑中各模塊的轉(zhuǎn)化率,也可以發(fā)現(xiàn)某些冷僻的功能點(diǎn)。
一款視頻創(chuàng)作分享型App應(yīng)用中,從開始拍攝制作視頻到視頻的最終發(fā)布過程中,用戶往往會(huì)進(jìn)行一系列的剪輯操作;通過路徑分析,我們可以清晰的看到哪些是用戶熟知并喜愛的編輯工具,哪些操作過于冗長(zhǎng)繁瑣,這樣可以幫助我們針對(duì)性地改進(jìn)剪輯操作模塊,優(yōu)化用戶體驗(yàn)。
如果在路徑分析過程中用戶的創(chuàng)作數(shù)量與用戶被點(diǎn)贊、評(píng)論以及分享的行為密切相關(guān),就可以考慮增強(qiáng)這款A(yù)pp的社交性,增強(qiáng)用戶黏性與創(chuàng)作欲望。
iii.產(chǎn)品運(yùn)營(yíng)過程的監(jiān)控
產(chǎn)品關(guān)鍵模塊的轉(zhuǎn)化率本身即是一項(xiàng)很重要的產(chǎn)品運(yùn)營(yíng)指標(biāo),通過路徑分析來監(jiān)測(cè)與驗(yàn)證相應(yīng)的運(yùn)營(yíng)活動(dòng)結(jié)果,可以方便相關(guān)人員認(rèn)識(shí)了解運(yùn)營(yíng)活動(dòng)效果。
說到這里不得不提及一下漏斗模型與路徑分析的關(guān)系
以上提到的路徑分析與我們較為熟知的漏斗模型有相似之處,廣義上說,漏斗模型可以看作是路徑分析中的一種特殊情況,是針對(duì)少數(shù)人為特定模塊與事件節(jié)點(diǎn)的路徑分析。換句話說是一種高度的抽象邏輯。
漏斗模型通常是對(duì)用戶在網(wǎng)站或App中一系列關(guān)鍵節(jié)點(diǎn)的轉(zhuǎn)化率的描述,這些關(guān)鍵節(jié)點(diǎn)往往是我們?nèi)藶橹付ǖ?。例如我們可以看到某?gòu)物App應(yīng)用的購(gòu)買行為的漏斗轉(zhuǎn)化情況。
這款購(gòu)物App平臺(tái)上,買家從瀏覽到支付成功經(jīng)歷了4個(gè)關(guān)鍵節(jié)點(diǎn),商品瀏覽、加入購(gòu)物車、結(jié)算、付款成功,從步驟1到步驟4,經(jīng)歷了其關(guān)鍵節(jié)點(diǎn)的人群越來越少,節(jié)點(diǎn)的轉(zhuǎn)化率呈現(xiàn)出一個(gè)漏斗狀的情形,我們可以針對(duì)各個(gè)環(huán)節(jié)的轉(zhuǎn)化效率、運(yùn)營(yíng)效果及過程進(jìn)行監(jiān)控和管理,對(duì)于轉(zhuǎn)化率較低的環(huán)節(jié)進(jìn)行針對(duì)性的深入分析與改進(jìn)。
路徑分析與漏斗模型存在不同之處,它通常是對(duì)每一個(gè)用戶的每一個(gè)行為路徑進(jìn)行跟蹤與記錄,在此基礎(chǔ)上分析挖掘用戶路徑行為特點(diǎn),涉及到每一步的來源與去向、每一步的轉(zhuǎn)化率。
可以說,漏斗模型是事先的、人為的、主動(dòng)的設(shè)定了若干個(gè)關(guān)鍵事件節(jié)點(diǎn)路徑,而路徑分析是探索性的去挖掘整體的行為路徑,找出用戶的主流路徑,甚至可能發(fā)現(xiàn)某些事先不為人知的有趣的模式路徑。從技術(shù)手段上來看,漏斗模型簡(jiǎn)單直觀計(jì)算并展示出相關(guān)的轉(zhuǎn)化率,路徑分析會(huì)涉及到一些更為廣泛的層面。
這塊有一個(gè)對(duì)大部分產(chǎn)品問題初步判定實(shí)踐,首先我們會(huì)通過用戶行為路徑大概的了解一下用戶是否依照產(chǎn)品設(shè)計(jì)期望的主流路徑直達(dá)核心模塊。 然后結(jié)合具體的業(yè)務(wù)場(chǎng)景建立漏斗細(xì)看轉(zhuǎn)化。最后通過用戶細(xì)查詳細(xì)的查看具體用戶的行為。實(shí)際在具體實(shí)踐中反復(fù)結(jié)合這三步,我們可以得到許多有價(jià)值的信息。
3.?用戶行為自動(dòng)化報(bào)告實(shí)踐
Sunburst Partition可視化分析探索
通過解析布點(diǎn)獲得的用戶行為路徑數(shù)據(jù),我們可以用最簡(jiǎn)單與直接的方式將每個(gè)用戶的事件路徑點(diǎn)擊流數(shù)據(jù)進(jìn)行統(tǒng)計(jì),并用數(shù)據(jù)可視化方法將其直觀地呈現(xiàn)出來。
D3.js是當(dāng)前最流行的數(shù)據(jù)可視化庫之一,我們可以利用其中的Sunburst Partition來刻畫用戶群體的事件路徑點(diǎn)擊狀況。從該圖的圓心出發(fā),層層向外推進(jìn),代表了用戶從開始使用產(chǎn)品到離開的整個(gè)行為統(tǒng)計(jì);Sunburst事件路徑圖可以快速定位用戶的主流使用路徑。通過提取特定人群或特定模塊之間的路徑數(shù)據(jù),并使用Sunburst事件路徑圖進(jìn)行分析,可以定位到更深層次的問題。
4. 用戶行為路徑算法
較常用的用戶行為路徑算法有基于關(guān)聯(lián)分析的序列路徑挖掘方法和社會(huì)網(wǎng)絡(luò)分析
i.基于關(guān)聯(lián)分析的序列路徑挖掘方法
提到關(guān)聯(lián)規(guī)則分析,必然免不了數(shù)據(jù)挖掘中的經(jīng)典案例“啤酒與尿布”。暫且不論“啤酒與尿布”是不是Teradata的一位經(jīng)理胡編亂造吹噓出來的“神話故事”,這個(gè)案例在一定程度上讓人們理解與懂得了購(gòu)物籃分析(關(guān)聯(lián)分析)的流程以及背后所帶來的業(yè)務(wù)價(jià)值。
將超市的每個(gè)客戶一次購(gòu)買的所有商品看成一個(gè)購(gòu)物籃,運(yùn)用關(guān)聯(lián)規(guī)則算法分析這些存儲(chǔ)在數(shù)據(jù)庫中的購(gòu)買行為數(shù)據(jù),即購(gòu)物籃分析,發(fā)現(xiàn)10%的顧客同事購(gòu)買了尿布與啤酒,且在所有購(gòu)買了尿布的顧客中,70%的人同時(shí)購(gòu)買了啤酒。于是超市決定將啤酒與尿布擺放在一起,結(jié)果明顯提升了銷售額。
我們?cè)诖瞬环翆⒚總€(gè)用戶每次使用App時(shí)操作所有事件點(diǎn)看成“購(gòu)物籃”中的“一系列商品”,與上面提到的購(gòu)物籃不同的是,這里的所有事件點(diǎn)擊行為都是存在嚴(yán)格的前后事件順序的。
我們可以通過改進(jìn)關(guān)聯(lián)規(guī)則中的Apriori或FP-Growth算法,使其可以挖掘存在嚴(yán)格先后順序的頻繁用戶行為路徑,不失為一種重要的用戶路徑分析思路。我們可以仔細(xì)考量發(fā)掘出來的規(guī)則序列路徑所體現(xiàn)的產(chǎn)品業(yè)務(wù)邏輯,也可以比較分析不同用戶群體之間的規(guī)則序列路徑。
ii.社會(huì)網(wǎng)絡(luò)分析(或鏈接分析)
早期的搜索引擎主要基于檢索網(wǎng)頁內(nèi)容與用戶查詢的相似性或者通過查找搜索引擎中被索引過的頁面為用戶查找相關(guān)的網(wǎng)頁,隨著90年代中后期互聯(lián)網(wǎng)網(wǎng)頁數(shù)量 的爆炸式增長(zhǎng),早期的策略不再有效,無法對(duì)大量的相似網(wǎng)頁給出合理的排序搜索結(jié)果。
現(xiàn)今的搜索引擎巨頭如Google、百度都采用了基于鏈接分析的搜索引擎算法來作為這個(gè)問題的解決方法之一。網(wǎng)頁與網(wǎng)頁之間通過超鏈接結(jié)合在一起,如同微博上的社交網(wǎng)絡(luò)通過關(guān)注行為連接起來,社交網(wǎng)絡(luò)中有影響力很大的知名權(quán)威大V們,互聯(lián)網(wǎng)上也存在著重要性或權(quán)威性很高的網(wǎng)頁。將權(quán)威性較高的網(wǎng)頁提供到搜索引擎結(jié)果的前面,使得搜索的效果更佳。
我們將社交網(wǎng)絡(luò)中的人看作一個(gè)個(gè)節(jié)點(diǎn),將互聯(lián)網(wǎng)中的網(wǎng)頁看作一個(gè)個(gè)節(jié)點(diǎn),甚至可以將我們的App產(chǎn)品中的每一個(gè)模塊事件看作一個(gè)個(gè)節(jié)點(diǎn),節(jié)點(diǎn)與節(jié)點(diǎn)之間通過各自的方式連接組成了一個(gè)特定的網(wǎng)絡(luò)圖,以下將基于這些網(wǎng)絡(luò)結(jié)構(gòu)的分析方法統(tǒng)稱為社會(huì)網(wǎng)絡(luò)分析。
社會(huì)網(wǎng)絡(luò)分析中存在一些較為常見的分析方法可以運(yùn)用到我們的路徑分析中來,如節(jié)點(diǎn)的中心性分析,節(jié)點(diǎn)的影響力建模,社區(qū)發(fā)現(xiàn)等。通過中心性分析,我們可以去探索哪些模塊事件處于中心地位,或者作為樞紐連接了兩大類模塊事件,或者成為大多數(shù)模塊事件的最終到達(dá)目的地。通過社區(qū)發(fā)現(xiàn),我們可以去探索這個(gè)社會(huì)網(wǎng)絡(luò)中是否存在一些“小圈子”,即用戶總是喜歡去操作的一小部分行為路徑,而該部分路徑又與其他大部分模塊相對(duì)獨(dú)立。
5. 用戶行為路徑產(chǎn)品化實(shí)踐
下面是一個(gè)大致的用戶行為路徑產(chǎn)品需求導(dǎo)圖
我們大體目標(biāo)要完成基于人數(shù)和次數(shù)的用戶行為路徑,可以支持從任意事件起下查后續(xù)行為或者上查來源行為,并且要支持任意30天時(shí)間行為路徑的查看。最重要的一點(diǎn)是強(qiáng)調(diào)用戶體驗(yàn)需要較實(shí)時(shí)處理獲得結(jié)果。根據(jù)上述這些需求,我們給出基于Spark的用戶行為路徑實(shí)踐。
6. 基于Spark的用戶行為路徑
Spark是一個(gè)基于內(nèi)存計(jì)算的開源集群計(jì)算系統(tǒng),目的是更快速的進(jìn)行數(shù)據(jù)分析
下面是一個(gè)Spark的套件圖
伯克利將Spark的整個(gè)生態(tài)系統(tǒng)稱為伯克利數(shù)據(jù)分析棧(BDAS)。其核心框架是Spark,同時(shí)BDAS涵蓋支持結(jié)構(gòu)化數(shù)據(jù)SQL查詢與分析的查詢引擎Spark SQL,提供機(jī)器學(xué)習(xí)功能的系統(tǒng)MLbase及底層的分布式機(jī)器學(xué)習(xí)庫MLlib、并行圖計(jì)算框架GraphX,流計(jì)算框架Spark Streaming。這些子項(xiàng)目在Spark上層提供了更高層、更豐富的計(jì)算范式。
下面簡(jiǎn)單介紹一下Spark的 Yarn-Cluster任務(wù)提交流程:
- Spark Yarn Client向YARN中提交應(yīng)用程序,包括ApplicationMaster程序、啟動(dòng)ApplicationMaster的命令、需要在Executor中運(yùn)行的程序等;
- ResourceManager收到請(qǐng)求后,在集群中選擇一個(gè)NodeManager,為該應(yīng)用程序分配第一個(gè)Container,要求它在這個(gè)Container中啟動(dòng)應(yīng)用程序的ApplicationMaster,其中ApplicationMaster進(jìn)行SparkContext等的初始化;
- ApplicationMaster向ResourceManager注冊(cè),這樣用戶可以直接通過ResourceManage查看應(yīng)用程序的運(yùn)行狀態(tài),然后它將采用輪詢的方式通過RPC協(xié)議為各個(gè)任務(wù)申請(qǐng)資源,并監(jiān)控它們的運(yùn)行狀態(tài)直到運(yùn)行結(jié)束;
- 一旦ApplicationMaster申請(qǐng)到資源(也就是Container)后,便與對(duì)應(yīng)的NodeManager,要求它在獲得的Container中啟動(dòng)啟動(dòng)CoarseGrainedExecutorBackend,CoarseGrainedExecutorBackend啟動(dòng)后會(huì)向ApplicationMaster中的SparkContext注冊(cè)并申請(qǐng)Task。這一點(diǎn)和Standalone模式一樣,只不過SparkContext在Spark Application中初始化時(shí),使用CoarseGrainedSchedulerBackend配合YarnClusterScheduler進(jìn)行任務(wù)的調(diào)度,其中YarnClusterScheduler只是對(duì)TaskSchedulerImpl的一個(gè)簡(jiǎn)單包裝,增加了對(duì)Executor的等待邏輯等;
- ApplicationMaster中的SparkContext分配Task給CoarseGrainedExecutorBackend執(zhí)行,CoarseGrainedExecutorBackend運(yùn)行Task并向ApplicationMaster匯報(bào)運(yùn)行的狀態(tài)和進(jìn)度,以讓ApplicationMaster隨時(shí)掌握各個(gè)任務(wù)的運(yùn)行狀態(tài),從而可以在任務(wù)失敗時(shí)重新啟動(dòng)任務(wù);
- 應(yīng)用程序運(yùn)行完成后,ApplicationMaster向ResourceManager申請(qǐng)注銷并關(guān)閉自己。
下面給出我們整體行為路徑的數(shù)據(jù)流向以及請(qǐng)求過程
數(shù)據(jù)收集:
互聯(lián)網(wǎng)行業(yè)對(duì)數(shù)據(jù)的獲取有著得天獨(dú)厚的優(yōu)勢(shì),路徑分析所依賴的數(shù)據(jù)主要就是服務(wù)器中的日志數(shù)據(jù)。用戶在使用App過程中的每一步都可以被記錄下來,這時(shí)候需要關(guān)注的便是優(yōu)秀的布點(diǎn)策略,它應(yīng)當(dāng)與我們所關(guān)心的業(yè)務(wù)息息相關(guān)。事實(shí)上,在每個(gè)App里,不是所有事件都有著同樣的價(jià)值,基于對(duì)核心事件的深度分析需求,推薦大家使用層級(jí)化的自定義事件布點(diǎn)方式,每一個(gè)事件由三個(gè)層次組成的:事件(Event)、屬性(Key)和屬性值(Value)。
數(shù)據(jù)清洗:
在ETL階段我們會(huì)把收集到的Android/IOS/JS SDK數(shù)據(jù)進(jìn)行統(tǒng)一的處理,從上述的JSON格式里面取出預(yù)定義好的字段(我們需要的一些信息)寫入本地文件中。
數(shù)據(jù)獲?。?/strong>
將寫好的本地文件通過定時(shí)加載程序加載到Inforbright里面,得到一系列的基礎(chǔ)表。然后從這些基礎(chǔ)表里通過跑批程序跑出方便查詢和使用的一些匯總表。
為了減少Spark實(shí)時(shí)內(nèi)存計(jì)算壓力我們將用戶行為路徑核心算法過程分為離線部分和線上請(qǐng)求部分。如下:
中間結(jié)果計(jì)算:
回溯之前第五節(jié)說到產(chǎn)品需求,要完成這些需要(人數(shù),次數(shù),后續(xù)行為,來源行為,30天時(shí)間內(nèi)任意查詢),我們需要從數(shù)據(jù)庫里獲取事件ID,會(huì)話ID,事件觸發(fā)時(shí)間,設(shè)備ID,用戶ID這些信息。如圖所示:
下面重點(diǎn)來了,首先我們會(huì)將上述信息做一些處理。
原則就是將一個(gè)會(huì)話ID下面的同一個(gè)用戶ID的所有事件按照事件發(fā)生的順序進(jìn)行排序。這塊為了進(jìn)一步減少之后Spark內(nèi)存使用我們會(huì)將所有超長(zhǎng)ID進(jìn)行一次map。 例如下圖中最后一列的1表示的就是map過后的會(huì)話ID。第三列表示的是用戶ID第五列和第六列表示的是這個(gè)會(huì)話ID內(nèi)事件對(duì)發(fā)生的順序。第一列和第二列表示的是具體的事件對(duì)。
具體解讀一下圖中的信息:
用戶ID為16351的用戶在其map過后ID為1的會(huì)話中的事件
正序順序 8532810 -> 7232351 -> 7232351 -> 8532810 -> 8532810 -> 7232351 -> 8532810 -> 8532810 -> 565 -> 8532810 -> 6907797 -> 565
逆序順序 565 -> 6907797 -> 8532810 -> 565 -> 8532810 -> 8532810 -> 7232351 -> 8532810 -> 8532810 -> 7232351 -> 7232351 -> 8532810
你會(huì)發(fā)現(xiàn)按照上述的過程,我們將獲取到的原始數(shù)據(jù)進(jìn)行離線轉(zhuǎn)化后,新的數(shù)據(jù)就會(huì)天然的支持我們的產(chǎn)品需求:人數(shù),次數(shù),后續(xù)行為,來源行為。對(duì)于30天內(nèi)任意時(shí)間查詢,我們也做了特殊的處理。我們會(huì)將每天的數(shù)據(jù)存放在一個(gè)文件里面,這樣就會(huì)有30個(gè)用天數(shù)命名的文件,這樣每天的離線計(jì)算只需要進(jìn)行增量的部分。這種做法會(huì)大大節(jié)省我們離線部分計(jì)算的開銷。
數(shù)據(jù)計(jì)算:
由于在離線部分準(zhǔn)備的充分,故在Spark實(shí)時(shí)計(jì)算階段我們只需要將數(shù)據(jù)Load到內(nèi)存后通過一系列的Spark RDD算子查出我們需要的結(jié)果即可。當(dāng)然按照離線計(jì)算后數(shù)據(jù)格式的特點(diǎn)結(jié)合我們的具體產(chǎn)品需求,在Spark處理過程中也是有不少小技巧可循,例如查詢某個(gè)條件的用戶行為路徑可以只使用filter算子就可以得到結(jié)果,今天就不多贅述了。
數(shù)據(jù)請(qǐng)求:
前端的請(qǐng)求會(huì)通過Redis的訂閱和發(fā)布機(jī)制告訴Spark提交相應(yīng)的任務(wù)到集群。
作者:李亮,諸葛io創(chuàng)新產(chǎn)品部 架構(gòu)師。前Intel 移動(dòng)事業(yè)部算法成員,在Intel期間,獲得4項(xiàng)專利授權(quán)。5年機(jī)器學(xué)習(xí)和數(shù)據(jù)挖掘經(jīng)驗(yàn)。現(xiàn)關(guān)注點(diǎn)為大規(guī)模機(jī)器學(xué)習(xí)算法,流式機(jī)器學(xué)習(xí)算法,場(chǎng)景化數(shù)據(jù)分(含作者介紹)
來源:http://www.36dsj.com/archives/70253
本文來源于人人都是產(chǎn)品經(jīng)理合作媒體@36大數(shù)據(jù),作者@李亮
- 目前還沒評(píng)論,等你發(fā)揮!