用戶路徑分析及桑基圖作法前端
用戶路徑分析執行過程有很是多的「坑」，本文講解細節處理，沉澱記錄了2018年筆者執行用戶路徑分析的過程。python
用戶路徑是什麼？web
用戶路徑是互聯網行業表達用戶使用產品完成轉化/知足需求/達到目的所通過的流程。映射到現實即要去某個目的地，有多條路線可選，不一樣的人選擇了不一樣的路，雖然都到達了目的地，但有的人高興，有的人鬱悶，有的路擁堵，有的路風景好，體驗不一樣，對決策是否還會再來該目的地，已是否還會再走這條路都會有顯著影響。再折回看互聯網，本質是「生意」，是爲了賺錢，須促成轉化。互聯網APP賺錢的方式大體兩大類：後端
用戶支付微信
對於金融類APP、電商類APP、O2O類APP、社交網絡會員卡、遊戲類APP購買道具等以完成轉化爲目的，轉化就是支付完成，這類APP會有多個入口方便用戶轉化成成交用戶，這些入口即是在用戶經常使用路徑上設定的。這類產品會高頻研究用戶行爲路徑，找到高頻路徑，爲用戶轉化添加入口，並不斷優化每一個入口的支付流程體驗。網絡
廣告費工具
資訊類、社交網絡、應用商店等APP是經過不斷提高用戶量和用戶的複用率，以CPM、CPC和CPD的形式來獲取收入，那麼資訊與社交網絡類的產品會找到用戶使用的高頻路徑節點，增長推薦，以促進用戶的使用時長與訪問PV，來增長收入。優化
用戶路徑在原PC時代是相對容易刻畫的，由於每一步訪問在頁面上都有來源標識，而APP時代加大了難度，一方面用戶的行爲在埋點中表現爲一個個獨立的點擊，除非每一個點擊特地埋上來源，不然很難串起來，但埋點工做量是龐大的，有時候一個版本的發佈都要增長100多個埋點，較難實行；另外一方面客戶端埋點較PC端要複雜，分前端和後端埋點，用戶場景不一樣，研發手段不一樣，埋點方式不一樣，每每耦合性比較差。spa
用戶路徑分析與漏斗分析的聯繫與區別.net
漏斗是用戶路徑的子集，是其中的一種路徑。
漏斗是產品預設的路徑，但願用戶按照產品設計的路徑來知足需求。然而有時候用戶會玩出新的路徑，經過用戶路徑分析能夠發現這樣的路徑，這有時候會是衍生新產品的機會。好比：產品想讓用戶經過首頁-列表頁-詳情頁來完成內容閱讀，但發現用戶習慣是首頁-搜索-搜索結果頁-詳情頁來完成閱讀，這背後反映了什麼問題，產品應該如何改造，便有了契機和方向。
漏斗是一種衡量產品路徑的方式，用戶路徑分析是發現用戶使用規律的分析模型。漏斗的統計常見的有兩種，一種是抓產品流程關鍵節點，統計這若干節點的總使用量，監控出是哪一個關鍵節點轉化率不足；另外一種是抓產品流程關鍵節點，統計上一步來的用戶，這一步也來的有多少，來監控哪一個關鍵節點轉化率不足；後者比前者的統計更嚴謹一些，反映的問題更貼近真實狀況些，但按預設的關鍵節點統計的方式，會有盲區，可能存在你不知道的用戶行爲路徑。用戶路徑分析是統計出用戶的每一條路徑，來分析用戶使用產品的行爲習慣。
用戶路徑分析步驟（以APP爲例，一樣適用於移動web版和PC端）
第一步，清洗數據，梳理出用戶路徑統計所需的這些埋點。
每一個公司的埋點都是雜亂的，都是須要清洗的，我歷來不懷疑這一點。如何從雜亂無章的埋點中清洗出有效的路徑信息？
第一步羅列出最關鍵的頁面，判斷關鍵頁面最好的方式是統計出全部埋點（含前端點擊日誌和後端server日報）的訪問量，降序排列，能覆蓋90%以上pv的這些埋點，就是關鍵頁面。
第二步清洗這些埋點。排名top的點中，有些非用戶主動觸發，而是系統隨着用戶的行爲而觸發，須要清洗掉。
第三步根據埋點字典表，匹配出這些埋點的描述，再次排查異常狀況，最終獲得用以統計用戶路徑的這些點。
第二步，每一個用戶的行爲進行排序
對每一個用戶觸發的埋點（即用戶的行爲）進行排序，使用row_number() over(partition by 用戶id order by 行爲（埋點）的時間戳)，獲得用戶-行爲-順序
第三步，排除重複頁面的干擾
形成重複的緣由：1.用戶使用過程當中從新刷新/點擊頁面；2.用戶使用過程當中翻頁或瀑布流閱讀模式下的加載都會從新產生一個埋點。這些本質是在同一個頁面上，沒有到下一步，這樣的重複對用戶路徑分析意義不大。排重，即順序序號差異爲1且重複的多個埋點code，只剩1個。我使用的排重方法：自join（a表 join b表，a和b爲同一表)，取row_number（b-a）的差值爲1且a.埋點code!=b.埋點code。排重後，再次對剩餘的行爲code排序，使用第二步的方法，獲得排重後的用戶-行爲-順序，生成數據倉庫表，便於後續計算。
第四步，路徑彙總
路徑彙總即將每一個用戶的行爲路徑從route1/route2/route3/……每行的格式，轉換成route1-route2-route3-……這樣的路徑格式。路徑有長有端，但從可描述、可視化、易理解以及產品設計（不會有人去設計一個須要不少步才能夠知足用戶需求的產品）出發，看的行爲數是有限制的，我每每看十步，這個因產品而異。
個人SQL實現方式：選出全部用戶的第1步，left outer join第2步，以此類推，作10個這樣的join，即可以獲得10步中有多少個路徑，每一個路徑有多少用戶。
這個是SQL的笨方法，R和python大拿會有更牛的方法。
第五步，可視化-桑基圖
將第四步獲得的結果與第一步的字典表匹配，獲得頁面的漢字描述，是可視化易讀的前提。在展現上是有一些技巧的：若是想要突出核心路徑，能夠把小的路徑剔除，只留用戶量多的路徑作可視化。
關於可視化的工具，我用到的是海智bdp平臺我的版。
建立儀表盤，自命名。
根據產品設計的路徑，一步步導入數據後，點擊右上角新建圖表
進入編輯圖表頁面，將字段拖拽至「維度」處，將計算字段拖拽至「數值」處，選擇右部圖表類型，便可繪製好桑基圖。支持存儲。
路徑分析除了上述優化路徑、找到運營着力點外，還可結合其餘用戶特徵綜合分析，如：結合生命週期觀察成長期用戶的路徑特徵，找到刺激用戶轉化爲成長期用戶的頁面；觀察新增用戶進入後的路徑特徵，能夠找到刺激新增留存的關鍵功能或頁面；甚至能夠直接使用路徑對用戶進行歸類等等。
原文：
[用戶路徑分析及桑基圖作法](http://www.itongji.cn/detail?type=99991436 )
本文分享自微信公衆號 - SQL數據分析（dianwu_dw）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。