一、什麼是會話
會話分析分析，字面理解的意思就是以
一次會話作為主體進行分析。會話（譯自 session），起源自 web 服務中的 session 機制。在、數據分析的語境中，我們可以解釋為：一次有始有終，目的明確的一連串動作。
- 有始：我們需要知道用戶從哪裡、什麼時間開始；
- 有終：我們需要知道用戶從哪裡、什麼時間結束；
- 目的明確：我們需要知道用戶做了什麼、目的是什麼、結果又如何……
二、為什麼要做會話分析
做數據分析絕對不是單純的分析數據做數據的可視化展示。我們搭建各種分析模型，採用不同的分析策略，最根本的目的就是——發現並解決我們遇到的問題。
首先，在數據分析行業剛興起的時候，人們分析數據的視角站在事件發生的本身，比如：關注支付訂單的金額，訂單的數量。在我們進行分析時，也很自然地將事件和人關聯到一起，然後得到「人 → 事件」的關係。
後來，我們發現每個人在用我們的產品的時候，使用的路徑、時間長短、瀏覽的深度甚至啟動 App 的方式，都會對用戶最後的轉化帶來影響。所以，只有真正地還原事件發生的場景，才可以更好進行數據的分析。
由於我們的產品形態大部分都是流程化的引導，即逐步引導客戶（搜索）、逐步拆解客戶需求（列表），然後給出解決方案（商品購買）。那麼，用戶的一次完整的體驗，就是「用戶產生需求 → 使用產品 → 解決需求」這樣一個流程。
於是，我們就依照上述的思想，設計了「會話分析」的數據模型。
三、會話分析的推演
我們的目標，是把用戶「有始有終」的行為序列還原出來，作為一個整體參與分析。
思路
當我們發現我們需要分析的數據，不是一個點，而是一條線的時候，最簡單粗暴的方式，就是把這些數據連在一起，變成一條線來記錄就好了。
於是我們可以在 App 啟動的時候，記錄一些啟動來源（session id），然後後續的所有事件都使用該來源作為屬性一直攜帶。這樣，我們在分析每個事件發生的時候，就知道了這個事件是在哪個場景（啟動來源）下發生的了。
實現
記錄啟動的來源和參數，可能需要服務端輔助記錄一些信息，並同步給我們的 App 或直接在數據層進行加工，最後我們需要實現：啟動的方式（桌面、push、其他應用喚起..）和啟動的來源（廣告渠道、活動id、用戶主動...）的信息記錄。
應用
接下來，我們把有相同啟動來源的事件按照時間排序，放在一起，這一步實際上我們就還原了用戶的一次會話。我們有了用戶一次訪問的開始和結束，我們就可以做以下分析：
沉浸式體驗的相關分析：
會話時長：一個會話的持續時間
會話深度：會話的層級數
使用：有了用戶的使用時長和深度，我們就可以分析出用戶對我們的產品投入程度。結合每個會話中的事件順序，我們可以得到一個局部的最優價：用戶按照哪個路徑走，使用效果最好。當然了，這個肯定要結合自己的分析和業務，如果客戶每次都是直接進入，然後立刻購買後就離開，我覺得不做沉浸式的體驗似乎也沒什麼問題。
跳出率：用戶做了某個事件後退出的佔比
使用：我們把跳出率高的事件找出來，並且排除我們的目標事件，做個排序，就不難發現，用戶的退出大都發生在哪些步驟，如何改進這些非正常的跳出，就是我們需要解決的事情。
事件時長：用戶在某個頁面或某個事件花費的事件。
使用：通過事件時長，我們可以分析出用戶對哪個頁面感興趣，在哪個頁面耗時比較久，從而發現問題。
同時在線人數的相關分析：
同時在線人數：同一時間有效的會話數量。
使用：由於我們將數據由點變成了線，那麼理論上我們就可以統計某個時間點存在的會話數量，即業內常用的同時在線人數。與傳統方式相比，使用會話計算的好處是：他的計算是靈活的，而且對數據的採集要求不高；但是缺點也很明顯，會損失部分精度。
改進
建模後，在我們的會話分析過程中，逐漸暴露了幾個問題，如下所示：
1. 如何更靈活地定義一個會話？
我們使用的是實體參數記錄的方法，這種方式會引入切割不靈活的問題。但是實際上，我們可以通過定義切割事件和切割時間，加上邏輯運算來實現這種會話的拼裝。
比如，我們定義「App 啟動」作為起始條件，「App 退出」和「超過 5 min 進行切割」兩個條件作為退出條件，我們便可以將排好序的用戶行為序列切割為一個又一個會話了；同時我們使用起始事件「App 啟動」的一些指定屬性，虛擬的為會話中事件進行賦值。
所以我們的要做的改進是：實體記錄 → 邏輯還原。
2. 如何評估會話質量？
我們採集了會話後，可以得到「時長」「深度」「包含事件」「跳出」等等一系列的會話級別的指標。
首先我們可以簡單將會話分為三類：「常規型會話」「無用型會話」和「貢獻型會話」
如果一個用戶僅進行了開始和結束，那麼就可以理解為本次會話是無用的（看起來有點殘酷）；做了很多事情但是卻沒有形成轉化，這種會話應該是最普遍並佔比很高，是我們分析的重心；產生會話並且發生了轉化，這種屬於標杆型的會話。
所以我們要做的改進是：做會話切割，並且進行類型的標記。
3. 如何解釋會話深度？
目前使用會話中的事件數量來表示會話的深度，可能很多人都會覺得這個不是深度的概念，而是會話的內容數量。因為瀏覽的頁面內容和會話的質量之間有很大的關係，針對這種通過時序還原的行為序列，解決深度層級的計算有兩個比較通用的方法：
- 記錄前序，然後靠計算來還原層級結構；
- 預定義，提前定義好每個頁面層級的深度。
所以我們要做的改進是：引入其他維度，來更準確的記錄或還原會話的深度，從而更好的評估會話的質量。
4. 如何防止因頁面久留而導致的誤切割問題
這是一個很經典的問題，純計算的方式，必然會引入這種誤切割的問題。那麼我們看看有什麼辦法可以解決掉。
第一種，上傳心跳，類似於視頻類的網站，可以包裝在視頻的分段下載中判斷用戶是否還在記錄觀看視頻；
第二種，自定義每個事件的切割時長。我們把每個單點事件都假象成是一條線段，這樣只要線段有重疊，我們就認為會話是連續的。當然，記得添加一個退出事件來進行切割，不然你會發現你每個視頻的觀看時長都很久。
所以我們要做的改進是：支持每個事件的預期時間（切割時間）都是可定義的，這樣來實現更貼合業務的會話構成。
四、總結
在數據分析的時候，我們是需要自上而下地進行指標和需求的梳理；再自下而上地進行數據的採集和建模。在不考慮計算性能的情況下，邏輯運算的靈活性要遠高於實體的數據採集，並且維護成本也要少很多。模型的搭建都是循序漸進的，找到適合自己業務的計算模型至關重要。
會話分析這個模型，更多的價值在於體現了「從一次會話的角度，來看用戶從進入到離開的這一小個生命後期的使用情況」，更多的是帶來用戶體驗相關的反饋結果。將很多有關聯的行為放在一起來進行分析，可以比較宏觀地進行問題的挖掘和排查。
閱讀更多 泊兮閱讀 的文章
