數據上報分析一

背景：

• mpc管理臺業務配置愈來愈多，特別是貨架管理，卡產品管理，卡券管理三大模塊配置信息眼花繚亂，
• 屏幕的展現空間有限，須要合理排布配置信息才能最大化利用頁面空間，減小業務配置信息，
• 採集用戶操做行爲數據，分析高頻操做，繪製出熱力圖等供產品/運營/設計同窗參考，優化參數配置，有效提升點擊轉化。

數據上報：

• 埋點貨架管理，卡產品管理，卡券管理頁面，監聽全局click事件
• 上報信息：點擊事件的元素惟一的selector，時間，當前頁面hash值

• 關鍵點：

  • 爲了不頻繁上報，只有用戶離開特定頁面或者log數據超過規定長度時才作一次上報
  • selector是由當前元素出發遞歸尋找父元素直到在頁面中querySeletorAll爲惟一元素

數據分析：

• 從數據庫撈出的一個月有效上報數據（指特定頁面數據）有將近2000條，每一條的log數據都有多條點擊的明細數據。由於數據量大，先抽取某個時間段高頻操做做爲分析樣本。以日期爲橫座標，時間爲縱座標，畫出熱力圖。
  

• 從熱力圖能夠明顯看到點擊率超過兩百時間段分別爲：

  • 10月15日：9-10點 216次
  • 10月17日：15-16點 256次
  • 10月18日：10-11點 218次
• 統計這三個時間段頁面上報數據的次數

• 能夠發現貨架編輯（shelf_edit）這個頁面操做次數在三個時間段都是最多的，因而計劃重點分析這個頁面。

  1. 將貨架編輯頁面的log數據篩選出來，使用nightmare（一個瀏覽器模擬器）渲染頁面

  2. 根據上報的seletor復現操做，同時採集繪製熱力圖數據，

     • x ：點擊事件觸發相對於 document 的橫座標，主要取自於 event.pageX ；
     • y ：點擊事件觸發相對於 document 的縱座標，主要取自於 event.pageY ；
     • screenWidth ：點擊事件觸發時屏幕的寬度；
     • screenHeight ：點擊事件觸發時屏幕的高度；
     • 而後在頁面加載前，注入熱力圖heatmap.js繪製熱力圖

• 可是在使用nightmare復現時遇到了問題：

  • 用戶的權限未知，測試環境數據與生產不一致，視圖會有很大的差異。
  • 在生產上獲取的惟一的seletor由於視圖問題在測試環境卻不惟一，而操做步驟是關聯的，上一步獲取的seletor錯誤，後續全部的操做都走不下去。
• 權限問題比較好解決，只要在測試環境中新建一個只有貨架管理權限的用戶便可。可是數據不一致的問題就比較頭疼，不可能將生產數據同步過來，即便同步過來，在後續的增刪改操做環境數據也仍是不一致。
• 錄屏中出現的就是由於數據不一致致使，選擇模擬操做的元素不一致，最後selector對應不上而沒法繼續。

問題總結與改進：

• 如今的用戶行爲數據上報代碼是無侵入性，在特定高頻操做頁面統一監聽事件，不影響原來的代碼邏輯，統一上報操做的dom元素。

  • 改進：這種作法太理想化，由於視圖不一樣上報不能詳細到具體某個元素，只能上報固定的非動態的某些操做（按鈕），但這樣的話就是具體的去監聽這些元素的事件，對代碼邏輯有依賴屬於侵入式。

• 此次由於openid涉及到用戶信息安全問題，沒能將數據導出，多條數據有多是多個用戶上報的，在復現是也會出現問題。此外研究單個用戶的操做行徑會更有意義，屢次操做並不意味着交互上必定有可改進的地方，也有多是某個業務有多個用戶須要頻繁操做，單個用戶場景下的頻繁修改則須要引發注意。

  • 改進：將上報的openId根據用戶名md5加密，對於分析數據來講，拿到的只須要是一個對應用戶的id值。

結論

• 目前雖然因爲數據問題熱力圖還沒法繪製，但用nightmare能復現的步驟中已經能夠了解到一些用戶行爲，來改進交互：

  • 頻繁點擊的資源位在屏幕上的位置若是不會隨着數據的變化而改變是否是體驗更好，好比說增長卡券的按鈕
    
  • 頻繁點擊的資源有沒有可能合併成一個固定的操做，好比說此次上報的數據有短期內屢次點擊刪除卡券，若是頻繁須要總體更改能夠增長一鍵刪除？
  • 用戶屢次點擊菜單列表有可能由於如今菜單過多，沒法快速找到，新增長一個個人工做臺本地記錄用戶高頻的菜單項