網站數據中的點擊流數據是怎麼去除冗餘信息，怎麼定義關鍵路徑的呢？

12-08

有個初級的問題想請教一下大家，網站的路徑分析是以點擊流為基礎的，但是點擊流數據的冗餘信息很多，而且也很稀疏，我們是怎麼去除冗餘的呢，是不是a-&>b-&>c&>a-&>d這類的就只是記錄了a-&>d這樣，把中間的重複步驟都去掉了呢？還是有別的方法呢

點擊流分析本身就是從訪客角度分析網站數據的一種手段，感覺對很多網站已經不適用了。應該多嘗試從業務組成的關鍵步驟去分析，最典型的就是電商，僅僅從訪客瀏覽角度去分析，會發現要分析和建好多指標啊。但如果圍繞商品和類目或者購物效率去嘗試建立模型或者指標分析的話，可能會更有效。
另外，我們過多的關注了用戶如何如何行為，而忽略了我們自己「是怎麼樣」，比如商品，它的性價比本身如何，競爭力怎麼樣？在這個城市是否流行？他面對的用戶群體是怎樣的？不管是分析點擊流還是其他指標，首先都要知己知彼，然後再面對點擊流或者瀏覽行為的時候才不會有那麼多迷惑。簡而言之，80%的時間進行自我分析和用戶的線下數據分析，對整盤有清楚的認知，20%的時間去分析具體的數據。
這是我自己的經驗，歡迎討論。

這裡要搞清楚兩個概念：
1.點擊流數據的冗餘數據是什麼？然後才能討論如何規避和去除。

不符合日誌格式的數據。這個需要在數據上報階段進行處理，如果是特定需求下上報了額外的數據欄位，就需要在日誌解析後的表中預留擴展欄位，可以是map型的鍵值對，以增強點擊流數據的可擴展性；同時，編碼的數據，在解析時進行解碼操作。
臟數據，偶然情況下產生的完全不符合規則的數據，且沒有具體的業務含義，佔比不大的無意義數據可以在解析時進行過濾；不明確的可以在模型欄位設計時歸結為其他。
允許必要的冗餘，寬表模型的設計要保證底層明細數據的完備，盡量保證數據的完整性，以便進行後續的匯總和特定應用場景的分析工作，這也是數據倉庫分層設計的原因之一。
題主提到的路徑濃縮問題，不屬於冗餘的範疇，而是訪客真實的訪問路徑，對於這種數據，需要如實統計，匯總的時候，可以做單線程和多線程等不同的匯總處理，以便統計會話時長和頁面訪問深度等指標。

2.網站分析方法：漏斗分析，路徑分析和來源去向分析。

漏斗的設計是按照預定的關鍵路徑來分析各個環節的轉化和流失，以便進行針對性的頁面優化或路徑調整
路徑分析是按照訪客真實的瀏覽行為進行的歸納，是訪客訪問路徑的實際寫照，可以提煉主流的訪問路徑，或對比不同用戶群體的路徑訪問特點以進行針對性的體驗優化等。
來源去向分析是針對單個頁面的上下游進行分析，是簡化的路徑分析。

分析任務不同，便需要採取不同的分析模型。題主關注的是如何提煉關鍵路徑，這裡有兩個角度：
一是從業務或者產品的角度，指定某個關鍵事項的關鍵路徑，比如電商網站的下單流程，之後結合漏斗分析來對各個環節做流失和轉化分析，優化關鍵路徑的用戶體驗。
二是從分析師的角度出發，通過路徑分析，提煉某種主流的關鍵路徑，比如對比付費用戶和非付費用戶的訪問路徑特點，來找出一條更有價值的路徑，進行優化設計。或者發現不同頁面之間的流轉關聯，比如到達A頁面的訪問中，30%通過B頁面到達了C頁面，那麼可以考慮在A頁面添加一個C頁面的入口或者引導性動作，以進一步提高轉化。
網站分析一定要有明確的分析任務，流量一般而言數據量是很龐大的，枝葉又比較繁雜，必須理清頭緒，才能順藤摸瓜，一個訪客的路徑很可能有幾十個節點，這就需要對某一類頁面或者某個群體有準確的劃分，分析才容易見效。
以上。

關鍵路徑分析無非是要回答幾個問題：用戶從哪來的，用戶到哪去，用戶是否按照預期的產品設計完成了操作：比如流程留存情況、產品設計是否出現未知的分支等。關鍵路徑的設計需要與你的分析目的有關，比如產品上線首次分析那需要全盤摸清用戶軌跡，當然有你提到的冗餘信息，去發現冗餘數據的原因和規律，可能的未知分支就是產品問題。如果是流程留存分析，一般是已清楚用戶行為路徑，可以去除冗餘，比如從a到d,非按照設計路徑從源到終的數據就是冗餘。
若初次分析數據量大，並且對用戶行為不清晰時，建議採用一些辦法讓數據更直觀，比如把用戶行為路徑可視化，可以全局發現更多問題。

這該屬於ETL的範疇？其實數據一層一層的處理，每個業務層抽取自己需要數據。
我也不懂，明天再了解下。