隨著移動互聯(lián)網(wǎng)應(yīng)用的飛速發(fā)展，企業(yè)越發(fā)開始重視起用戶使用其應(yīng)用服務(wù)時的體驗。在實際的工作中，也有越來越多的企業(yè)也開始使用移動應(yīng)用體驗數(shù)據(jù)監(jiān)控工具，來幫助企業(yè)相關(guān)人員實時掌握其應(yīng)用服務(wù)的質(zhì)量。這些監(jiān)控工具，通常會監(jiān)控應(yīng)用的各項技術(shù)指標(biāo)是否超過企業(yè)制訂的健康度閾值，以此來評估應(yīng)用服務(wù)水平，并發(fā)現(xiàn)體驗受損問題。

然而，這些技術(shù)數(shù)據(jù)和指標(biāo)往往是彼此獨(dú)立的，例如用于評估網(wǎng)絡(luò)質(zhì)量的網(wǎng)絡(luò)請求性能類指標(biāo)，用于評估應(yīng)用代碼運(yùn)行穩(wěn)定性的崩潰率指標(biāo)、崩潰堆棧數(shù)據(jù)，用于評估用戶交互體驗的點(diǎn)擊事件性能、視圖訪問等。當(dāng)一方面出現(xiàn)問題時，管理員只能看到問題相關(guān)的數(shù)據(jù)，而無法了解用戶在出現(xiàn)該問題前，都做了哪些事情，在這之后又出現(xiàn)過哪些問題。這種方式，實際上對于解決問題，并沒有太大幫助。

博睿數(shù)據(jù)（股票代碼688229）依托多年應(yīng)用性能管理和數(shù)據(jù)管理經(jīng)驗，創(chuàng)造性地提出了基于用戶會話的監(jiān)控視角和分析模型。這一模型，可以按照會話ID和事件發(fā)生的時間順序進(jìn)行聚合，形成用戶一次使用應(yīng)用的全過程，在國內(nèi)DEM領(lǐng)域監(jiān)控工具中獨(dú)家具備了用戶會話及全量訪問事件的監(jiān)控和分析能力。

用戶會話是一個全新的數(shù)據(jù)分析模型和視角，它打破了過去“做用戶體驗分析產(chǎn)品，但卻不是以用戶為主視角”的傳統(tǒng)，創(chuàng)造性地以每個用戶每次使用App的過程為一個數(shù)據(jù)集合，還原用戶使用App的完整過程，可做到精準(zhǔn)檢索用戶/用戶群，快速識別異常會話，全量查看訪問全過程，詳細(xì)定位問題，持續(xù)跟蹤改進(jìn)效果。

什么是用戶會話？
用戶會話定義：一次用戶會話，就是用戶使用App的一次體驗全過程。我們將用戶每一次打開App，作為一次用戶會話的起點(diǎn)，自動記錄用戶在本次使用過程中的各類數(shù)據(jù)，直到用戶結(jié)束本次使用（退出或不再產(chǎn)生新數(shù)據(jù)超過30秒），記為一次完整的會話數(shù)據(jù)。

移動應(yīng)用體驗監(jiān)控系統(tǒng)分為兩種類型的數(shù)據(jù)：

統(tǒng)計型數(shù)據(jù)，又稱為聚合數(shù)據(jù)，是系統(tǒng)依據(jù)業(yè)務(wù)特點(diǎn)，按照特定的規(guī)則對數(shù)據(jù)進(jìn)行匯總聚合計算后的結(jié)果，用來分析變化趨勢、分布占比等規(guī)律問題十分有效，但在定位特定用戶，還原問題現(xiàn)場過程的場景上顯得力不從心。

離散型數(shù)據(jù)，又稱為日志型數(shù)據(jù)，是用戶使用App過程中的各類原始數(shù)據(jù)，他們以一種離散的形式上報至服務(wù)器，雖然能夠代表每個獨(dú)立的個體事件，但不便于統(tǒng)計和分析。之前的各類移動應(yīng)用體驗監(jiān)控系統(tǒng)通常只是用這部分?jǐn)?shù)據(jù)來計算生成統(tǒng)計性數(shù)據(jù)。

用戶會話能夠以“用戶和用戶使用App的完整過程”這種全新的視角，來組織、展示、檢索離散型數(shù)據(jù)，使得客戶可以快速定位特定的用戶或用戶群體，對特定用戶或特定交互特征的用戶進(jìn)行分析，輕松還原用戶每一次使用的全過程、全數(shù)據(jù)。

適用場景

場景1：發(fā)現(xiàn)某個體驗受損問題，希望了解到用戶前后的使用情況

例如發(fā)現(xiàn)了某個核心業(yè)務(wù)接口出現(xiàn)了訪問緩慢，用戶沒有耐心繼續(xù)等待，或發(fā)生了嚴(yán)重的應(yīng)用崩潰導(dǎo)致服務(wù)中斷等問題，在過去的分析平臺中，只能針對該次問題查看對應(yīng)的詳情數(shù)據(jù)，但無法知道用戶在出現(xiàn)問題之前都做了哪些操作，可能會導(dǎo)致問題的發(fā)生，或者問題發(fā)生后用戶去了哪里，又發(fā)生了哪些問題，是否對業(yè)務(wù)造成了影響等。

而通過用戶會話視角，可以點(diǎn)擊頁面中的“跳轉(zhuǎn)至所屬會話詳情”按鈕，可以查找到包含了本次問題事件的會話，并展示從會話開始到結(jié)束的完整過程數(shù)據(jù)。

通過會話詳情，可以按照事件的先后順序，詳細(xì)查看本次問題出現(xiàn)前的用戶訪問軌跡，交互操作，以及是否出現(xiàn)過App前后臺切換，網(wǎng)絡(luò)連接狀態(tài)切換（如WiFi切換4G，4G切換3G等）。

同時，也能由點(diǎn)即線，從一次問題出發(fā)，關(guān)聯(lián)到用戶這一次完整的使用全過程是否健康，是否出現(xiàn)過其他嚴(yán)重問題等等，使得評估用戶體驗從整體出發(fā)，而非僅僅從某一次問題快照管中窺豹。

場景2：掌握VIP用戶會話健康情況

可在用戶會話的高級搜索框中，輸入VIP用戶的用戶標(biāo)識（可以是設(shè)備ID，可以是上傳的用戶ID，也可以是上報的任意用戶信息），可檢索出指定的用戶。

之后可以針對檢索到的VIP用戶進(jìn)行針對性的分析，展示當(dāng)前用戶的用戶畫像信息，會話健康評估，以及每一次會話的列表。

每一次會話都會評估健康情況，可以選擇健康度不佳的會話，進(jìn)入到會話詳情，查看完整會話過程。

場景3：希望了解具有某些操作特征的用戶，是如何使用應(yīng)用，在使用過程中是否遇到了體驗相關(guān)的問題

例如，企業(yè)人員想要了解通過官站注冊的（假設(shè)官站注冊的帶有BR開頭），訪問過SDK產(chǎn)品的相關(guān)頁面（對SDK產(chǎn)品感興趣），點(diǎn)擊過報價按鈕（了解了產(chǎn)品的報價信息），在線提交生成了訂單（最終通過了解后成功下單，完成了一次轉(zhuǎn)化），具有以上特征的用戶。

通過分析以上場景需求，可以使用用戶會話中的高級檢索功能，將具有此類特征的用戶檢索出來。

我們通過使用“用戶ID包含BR”，頁面地址包含“sdk”，點(diǎn)擊的控件名包含“price”（報價按鈕的id包含price關(guān)鍵字），自定義事件包含“pay”（埋點(diǎn)的生成訂單自定義事件id包含pay關(guān)鍵字）的組合條件，檢索出此類用戶。

由于用戶會話數(shù)據(jù)是記錄的全部用戶訪問App的全量過程數(shù)據(jù)，因此檢索的條件也是基于用戶與App交互的全部事件，只要用戶做出過某些我們期望的訪問動作，就能夠精準(zhǔn)鎖定他。

監(jiān)控事件內(nèi)容

用戶會話模塊會記錄用戶每一次使用App全過程中的上述事件數(shù)據(jù)，以及對應(yīng)事件的詳情信息。

數(shù)據(jù)關(guān)聯(lián)及意義

用戶會話的加入，開拓了數(shù)字體驗監(jiān)控的視角，使得我們有能力對于離散型的事件數(shù)據(jù)進(jìn)行有序的分析，能夠真正的以用戶使用App的全過程為視角對用戶體驗進(jìn)行評估和追蹤。

當(dāng)然，用戶會話模塊并非要完全替代之前的分析模塊，作為一種全新的分析思路出現(xiàn)的，和平臺現(xiàn)有的分析模型是一種互補(bǔ)的關(guān)系，他們之間有著緊密的關(guān)聯(lián)，這種數(shù)據(jù)關(guān)聯(lián)的加強(qiáng)主要體現(xiàn)在下面四個部分。

1、會話中查看快照數(shù)據(jù)
會話詳情中，如果檢測到有對應(yīng)的數(shù)據(jù)快照，則可以直接在會話詳情中拉取快照數(shù)據(jù)進(jìn)行分析，必要時也可以跳轉(zhuǎn)到對應(yīng)的快照分析頁面。

2、原分析快照可跳轉(zhuǎn)至?xí)捲斍?br /> 原系統(tǒng)中的體驗受損數(shù)據(jù)，可以點(diǎn)擊跳轉(zhuǎn)到該數(shù)據(jù)所屬的會話中去，查看問題前后的用戶訪問數(shù)據(jù)，更高的角度、更大的視野進(jìn)行數(shù)據(jù)分析。

3、解決端到端打通的數(shù)據(jù)壁壘
過去的端到端打通，受限于前后端各自的快照保存機(jī)制，快照文件對不上等問題，實際效果往往大打折扣。用戶會話記錄了用戶訪問的全過程，為數(shù)據(jù)關(guān)聯(lián)打下了夯實的基礎(chǔ)。

4、連接性能、交互、業(yè)務(wù)
性能數(shù)據(jù)、用戶交互數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)，首次在DEM產(chǎn)品中同框。

最后，可以用一句話來概括用戶會話的意義，就是：管理全量，連接全量，分析全量。