大數據技術中，關於用戶行為分析方面的有哪些技術？

01-12

謝邀，我不是做演算法方向的，所以無法給你這個方向相關的建議和答案，留給大神們補充，我回答一下做用戶行為分析前所必須要用到的一些技術。

做用戶行為分析的基礎是獲得用戶行為數據，例如用戶頁面停留時間、跳轉來源等等。這些信息有些能直接拿到，有些是需要做一些計算才能拿到的。一般來說用戶訪問時的一些信息都是以日誌的形式打到web容器的日誌空間中去，這其中包含了最通用的一些訪問信息以及一些自定義的日誌打點。

題主提到了大數據技術中對用戶行為進行分析，那麼可以假定網站或者App的訪問量是比較傲多的。由於系統流量比較大，計算維度又比較多，後續數據消費者的需求增長比較快，所以對計算分析平台有了一定的要求。具體表現為：

1.負載能力。流量增大以後帶來的壓力是多方面的，比如網路帶寬的壓力、計算複雜度帶來的壓力、存儲上的壓力等等。一般來說這些都是比較顯而易見的，會對產生比較直接的影響，比如計算實時性下降、消息出現了堆積、OOM等等。為了解決這一現象，一般來說會選擇一些分散式的框架來解決這個問題，比如引入分散式計算框架storm、spark，分散式文件系統hdfs等。

2.實時性。在系統資源捉襟見肘時消息的實時性會立即受到嚴重影響，這使得部分演算法失效（例如對計算和收集上來的數據進行行為分析後，反饋到推薦系統上，當整體響應時間過場時會嚴重影響推薦效果和準確度）。對於這個情況來說可能會選擇storm這種具有高實時性的分散式流式計算框架來完成任務。

3.系統管理和平台化相關技術手段。在大數據情景下，企業內數據環境和應用環境都是比較複雜的，用戶行為分析應用不是一成不變的，那麼就要求用戶行為分析這種多變的應用在複雜環境中能有效生存，這包括演算法數據材料的獲得、系統運維、系統任務調度、系統資源調度等等，相關的技術很多時候要求團隊自研，但也有ganglia、yarn、mesos這類開源系統可以參考或者直接使用。

4.數據鏈路。企業技術環境一般來說是非常複雜的，一層一層交錯在一起，遠不是一句MVC三層架構能夠概括得了的，為了避免消息流通呈複雜的網狀結構，一般會考慮應用服務化、企業服務匯流排（ESB）及消息匯流排來做傳輸，有興趣的話題主可以百度一下這幾個方向的技術和開源工具。

5.應用快速生成工具。我個人認為在大數據環境下應用都擺脫不了一個快速開發的要求，用戶行為分析也是如此，這時候要考慮對接一些開源的分散式數據分析演算法庫而不是通過自己去實現，比如像spark ml，mahout這類的庫用得好能減少很多工作量。

以上是偏向基礎架構方面的，演算法方面可以翻閱相關的論文和文獻，善用谷歌學術會幫你很多。

用戶行為數據採集與分析實踐方法論

作者：葉玎玎

我們使用過不少分析工具：GA、Mixpanel、Heap 等，功能很強大，但總感覺少點什麼........

我們看到PV/UV這樣概覽性指標，但它們沒法指導我們做得更好。在通過這些粗糙的數據得到用戶做了什麼後，還要看到他們是怎麼做的，明白他們為什麼做。我們需要實時、全量的用戶行為數據，通過對用戶行為整體流程的分析，找到轉化的關鍵節點以及用戶流失的核心原因，以此幫助我們對症下藥，找到可執行的指標，落實為優化行動。

今天，我想分享的就是我們在這方面的一些探索與解決方案。

一、用戶行為分析的巨大需求

單從數據組成的角度來說，一個完善的閉環數據源主要是分成三大塊：第一塊是用戶行為數據，第二塊是服務端日誌數據，第三塊是交易 Transaction 數據。其中，除了交易數據會經常被存儲在離線資料庫中，通過 ETL 來獲取分析以外，行為數據和日誌數據很多時候都是近似的，完備的用戶行為數據基本能覆蓋絕大多數的服務端日誌數據，同時裡面包含著很多日誌數據裡面所缺乏的信息。

從技術發展角度來說，最近幾年發展最快的可以說是前端，每個月都會有很多新的東西出現，整體趨勢是往單頁應用發展，追求用戶體驗。同時，還有移動端應用，也產生著大量的行為數據，這些都不會跟服務端有過多交互。

所以，從應用提供商來說，我們需要知道屏幕前的人是怎麼使用我們的產品的，洞悉用戶行為背後的價值。

從去年 12 月 8 號內測及發布到現在已經過去半年時間了，目前有幾百家客戶在使用。我總結了一下客戶經常問的分析需求，大致可以分成三個場景：

Δ第一個場景： 我做了一次活動，我寫了一篇文章，我想知道到底效果如何，有沒有給我帶來足夠的流量，也就是市場營銷效果衡量。我們有些客戶，每年有上百萬的市場預算在 SEM 上，但是卻完全不知道這些錢花出去到底帶來了多少回報。

Δ第二個場景： 用戶激活流程是否合理，辛辛苦苦導入了流量，這些流量有沒有轉化為用戶，註冊流裡面每一步轉化了多少，流失了多少，沒有轉化的去了哪裡。在這個基礎上，我們應該怎麼優化，優化後的效果是怎樣的，這周的轉化率比上周是否有進步，差別是怎麼引起的等等。

Δ第三個場景： 這些註冊用戶，有沒有留下來成為一個忠誠用戶甚至付費用戶。留下來的用戶，是因為什麼留下來的。是否存在一個魔法數字，可以去極大的提高用戶留存，比如： LinkedIn 發現在第一周增加 5 個社交關係的用戶留存度很高； Facebook 發現在第一周增加 10 個好友的用戶留存度很高； Twitter 發現在第一周有 30 個 followers 的用戶留存度很高； Dropbox 發現在第一周安裝兩個以上操作系統的用戶留存度很高。這些都是在留存分析中發現的魔法數字。

二、複雜而易錯的傳統分析方法

歸根結底，所有的分析最終都是為了商業服務，而商業是為人服務的。所以，用戶行為分析就是我們需要建立一套基於用戶行為的分析體系，在了解用戶「誰」做了「什麼」，「怎麼」做的之外，進而明白是「為什麼」做，對症下藥，轉化成為優化行動。

分析是一個長時間優化的過程，需要我們持續監控數據的變化。而數據指標除了行為數據指標外還有一類，我們稱之為虛榮指標，比如 PV、UV 之類流量概覽性數據，這些指標看到了也就看到了，沒法指導我們做的更好。用戶行為數據指標則是另外一類，比如我們上面介紹的用戶獲取、用戶激活、用戶留存之類，了解這些行為後面都會對應到一個優化流程，所以也叫做 Actionable Metric，可執行指標，這也是用戶行為數據的魅力。

● 那麼接下來，我們要開始跟蹤用戶行為了。

一般可以分為以下七步：

1.確定分析場景或目標。

確定一個場景或一個目標。比如，我們發現很多用戶訪問了註冊頁面，但是最終完成註冊的很少，那麼我們的目標就是提高註冊轉化率，了解為什麼用戶沒有完成註冊，是哪一個步驟擋住用戶了。

2.思考需要了解哪些數據。

思考哪些數據我們需要了解，幫助我們實現這個目標。比如對於之前的目標，我們需要拆解從進入註冊頁面到完成註冊的每一個步驟的數據，每一次輸入的數據，同時，完成或未完成這些步驟的人的特徵數據。

3.確定誰來負責收集數據？

誰負責收集這些數據，一般是我們工程師。

4.什麼時候評估和分析？

收集上來的數據如何分析，什麼時候來評估採集到的數據。

5.如何給出優化解決方案？

發現問題後，怎麼來出解決方案。比如，是否在設計上改進，或者是否是工程上的 bug。

6.誰負責實現解決方案。確定方案的實施責任人。

7.如何評估解決方案的效果？

下一輪數據採集和分析，回到第一步繼續迭代。

知易行難。這整個流程里，第 2 步到第 4 步是關鍵。目前傳統的服務商比如 GA、Mixpanel、友盟所採用的方式我稱之為 Capture 模式。通過在客戶端埋下確定的點，採集相關數據到雲端，最終在雲端做呈現。比如圖中這個示例，相信在座的各位應該都有寫過類似的代碼。

Capture 模式對於非探索式分析來說，是一個非常行之有效的方法。然而，同時對參與整個流程的人也提出了非常高的要求：

Δ缺點1：依賴經驗導向

Capture 模式非常依賴人的經驗和直覺，不是說經驗和直覺不好，而是有時我們自己也不知道到底什麼是好的，經驗反而會成為一個先入為主的負擔，我們需要用數據來測試來證明。

Δ缺點2：溝通成本高

另外，一個有效的分析結果，依賴於數據的完整性和完備性。跟不少企業溝通後，不少的吐槽都是「連日誌格式都統一不了」，更別提後續分析了。這不是具體人的問題，更多是協作溝通的問題。參與人越多，產品經理、分析師、工程師、運營等等，每個人的專業領域又各不相同，出現誤解太正常了。曾經跟我們的 CEO Simon 交流過，他在 LinkedIn 帶領數據分析部門的時候，LinkedIn 專門組建了一個多達 27 人的埋點團隊，每天開會，就是為了統一埋點的格式和位置，經常一開就是幾個星期。

Δ缺點3：大量時間數據清洗和數據分析代碼侵入

另外，由於需求的多變性，埋點分成多次加入，缺乏統籌設計和統一管理，結果自然是無比骯髒。所以我們數據工程師還有個很大的工作是數據清洗，手動跑 ETL 出報表。根據統計，絕大多數分析工作，百分之七十到八十的時間是在做數據清洗和手動 ETL，只有百分之二十左右在做真正有業務價值的事情。另外一方面，作為一個有潔癖的工程師，最恨的就是大量的分析代碼侵入了我的業務代碼，刪不敢刪，改不敢改，日積月累，最終代碼庫整個就混亂了。

Δ缺點4：數據漏采錯踩

以上都還是好的，最讓人抓狂的是，上線了，發現數據採集錯了或者漏了，修正後，又得重新跑一遍流程，一個星期兩個星期又過去了。這也是為啥，數據分析工作是如此耗時一般以月計的原因，非常低效。

三、無需埋點的數據分析原理

在經歷了無數個痛苦的夜晚以後，我們決定要換個思路思考，希望能最大限度的降低人為錯誤，我們稱之為 Record 模式。區別於 Capture 模式，Record 模式是用機器來替代人的經驗，自動採集用戶在網站或者應用里的全量行為數據。因為自動化，我們從分析流程的源頭開始就控制了數據的格式。

所有數據，從業務角度出發，劃分為 5 種維度： Who，行為背後的人，具有哪些屬性；When，什麼時候觸發的這個行為；Where，城市地區瀏覽器甚至 GPS 等；What，也就是內容；How，是怎樣完成的。基於對信息的解構，保證了數據從源頭就是乾淨的，在此基礎之上，我們完全可以把 ETL 自動化，需要什麼數據可以隨時回溯。

回到之前流程的第二步到第四步，我們已經把參與人從多方減少到基本就一方，無論是產品經理、分析師還是運營人員，都可以使用可視化工具來查詢和分析數據，真正做到所見即所得。不僅是 PC，還支持 iOS、Android 和 Hybrid，可以進行跨屏的用戶分析。

作為一家用戶行為分析工具提供商，要做的並不只是用於內部，還需要適應外部成千上萬的網站和應用，所以在實現過程中我們做了很多探索：

● 自動用戶行為採集

目前我們所接觸的 GUI 程序，無論是 Web App、iOS App 還是 Android App，都是基於兩個原則，樹形結構和事件驅動模型。無論是 Web 上的 DOM 結點結構，還是 App 上的 UI 控制項結構，都是構建好的一顆完整的樹形結構渲染在頁面或者屏幕上。所以通過對樹結構的監控和檢測，我們就可以非常方便地知道哪些結點發生了變化，何時發生了變化，發生了什麼變化。同時，當用戶做了某個操作，比如滑鼠點擊、屏幕觸控，都會觸發一個事件，綁定了該事件的回調函數就會被觸發開始執行。基於此兩點認識，在 SDK 裡面如何實現無埋點就比較清楚了。只要能在結點變化或者事件發生的時候觸發我們定義的函數，那麼我就知道事件發生的多重信息。

● 數據可視化

如何把採集到的數據和業務目標匹配在一起。我們的解決方案是我們的可視化工具。剛才已經提到任何一個原子數據，都被拆解成 5 種不同分類的維度。所以，當我們在可視化工具裡面做匹配時，也就是對於不同維度信息的匹配。比如一個鏈接的點擊，會匹配到內容或者跳轉地址也就是 What，點擊行為也就是 How。還有其在頁面的定位信息，比如在樹形結構中的層次位置，是否帶一些 id、class 或者 tag，都是用來做數據匹配的信息。我們開發了一套智能匹配系統，通過對用戶真實行為的學習，建立了一套規則引擎，用於元素匹配。也正因為採集到的是全量數據，整個匹配系統有如基因進化一般，既有對過去歷史的記憶，也有順應新結構的演進變化。

● BI

商業分析我們在系統設計過程中，整個 Data Pipeline 過程中，數據經過處理後，會根據優先順序不同，首先通過 Spark Streaming 實時的處理已定義數據，然後每過一段時間對匹配到的數據做離線預聚合，多維分析非常靈活。

用戶行為數據採集的目的是通過了解用戶過去做的行為，用來預測未來發生的事情，無需埋點，隨時回溯數據，讓產品經理一個人就可以搞定用戶行為分析的全部流程。我們希望能提供一個簡單、迅速和規模化的數據分析產品，能極大地簡化分析流程，提交效率，直達業務。而這一切的基礎，就是我們從第一天開始就一直在研發的無埋點智能全量數據採集，基於此優化產品體驗，實現精細化運營，用數據驅動用戶和營收增長。

微信訂閱號：[不設計]

山川分享：場景運營、用戶體驗、商業定位等領域的行業信息，觀點犀利刻薄，有潔癖者請勿關注，如有冒犯，純屬必然，堅決不改。

Δ山川：產品、運營老兵一枚

Δ歡迎添加個人微信號（掃描下方二維碼添加更方便），期待多多交流學習哦......

用戶的行為數據通常是時序數據。

所以需要將其通過各種轉換，疊加，變成有意義的變數。

再結合目標變數用預測演算法建模。

典型的應用：

1、用戶瀏覽了X，又做了Y，那他會否對新產品感興趣？

2、用戶一年前加入，兩個月前升級成vip，一個月前購買了N個產品，那他接下來會做什麼？怎樣才能提高其客戶體驗？

剛找到實習，就是做這個的，待以後了解了補充！