微信小程序無埋點數據採集方案

做者：lxj，點餐終端團隊成員

前言  

相信業務團隊對這樣的場景不會太陌生：

• 打點需求： 每新上一個功能，數據產品便會同步加上打點需求，當數據打點上線後一段時間，數據產品/業務產品便會針對數據的轉化率分析和對業務需求的調整；
• 打點正確性驗證：當某一天數據轉化率大幅度變化不符合預期，數據產品/業務產品便會和開發確認打點的位置是否出現紕漏;
• 線上問題排查： 接到上報一個線上問題，然而開發們卻沒法重現該case，此時須要有線上對應該case的數據才能進一步分析問題，假若沒有數據，那這個問題極可能將變成一樁「懸案」，便會遭受多合做方的質疑和對於業務穩定性的安全感大大下降。

由此數據是很重要的，咱們接下來從數據採集的重要性、數據的劃分、採集方式以及在微信小程序中的埋點方案几個方面來一塊兒詳細聊一下數據採集。

1、數據採集的重要性

本篇咱們重點討論數據採集，暫不詳細論證數據的做用，先概括總結一下數據對於性能優化、業務增加和線上問題排查的重要做用，這也是咱們爲何須要埋點的緣由。

數據對於線上問題排查的做用：

• 用戶行爲數據還原「現場」，幫助分析和定位問題，提升問題定位效率
• 對於問題分析提供有力證據
  

數據對於性能優化的做用：

• 幫助發現和監控在線業務的關鍵成功指標
• 幫助發現最須要優化環境及其優先順序
• 幫助發現所面臨的挑戰的信息和改進決策
• 幫助提供對應用測試和優化更好的分析

數據對於業務增加的做用：

• 幫助衡量市場營銷效果
• 幫助發現激活轉化效果的策略
• 幫助發現用戶留存和用戶活躍分析
• 幫助產品營收變現分析

2、採集數據劃分梳理

從第一大點，咱們總結了數據的重要性，不一樣的業務項目對於數據重要性的側重點會有不一樣，那數據採集到底要採集哪些數據呢？

首先閉環數據包括：

1. 用戶行爲
2. 用戶信息、CRM（客戶關係）
3. 交易數據、服務端日誌數據

以上三項數據，纔算是一個完整數據流閉環，固然不一樣的業務場景中數據還能夠再更細劃分，大致的關鍵點基本不超出這三項。對於前端的數據收集來說，閉環數據中前兩項主要由客戶端上報數據，而第三點主要由服務端記錄數據，客戶端輔助，由於交易請求真正到達服務端完成處理纔算是完成交易的一個閉環。用戶行爲數據又包括——時間（when）、地點（where）、人物（who）、交互（how）、交互內容（what）五個要素，和新聞五要素有點相似；用戶信息有的業務涉及到用戶敏感信息和隱私等須要受權，因此用戶信息由業務場景定奪具體維度，最基本的數據需求是能惟一標識用戶；CRM、交易數據和用戶信息相似，具體所需數據細節由業務場景定奪，CRM基本數據需求是登錄信息、會員相關信息，交易數據包括——交易時間、交易對象、交易內容、交易金額、交易狀態。

3、數據上報方式

聊完數據，下一步即是須要知道如何獲取到咱們真正所須要的數據。數據上報方式大致上能夠歸爲三類：

1. 第一類是代碼埋點，即在須要埋點的節點手動調用接口上傳埋點數據，友盟、百度統計等第三方數據統計服務商大都採用這種方案；

2. 第二類是可視化埋點，即經過可視化工具配置採集節點，在前端自動解析配置並上報埋點數據，從而實現所謂的「無痕埋點」， 表明方案是已經開源的Mixpanel；

3. 第三類是「無埋點」，它並非真正的不須要埋點，而是前端自動採集所有事件並上報埋點數據，在後端數據計算時過濾出有用數據，表明方案是國內的GrowingIO。

重點討論無埋點，可視化埋點其實能夠算是無埋點的一個衍生故可視化埋點在此不討論，主要對比代碼埋點與無埋點。

3.1代碼埋點或Capture模式的埋點缺點

對於數據產品來講：

1. 依賴人的經驗和直覺判斷。
   業務相關的埋點位置須要數據產品或者業務產品主觀判斷，技術相關的埋點則須要技術人員主觀判斷。
2. 溝通成本高
   數據產品肯定所須要的數據，須要提出需求與開發溝通，且數據人員對技術不是特別熟悉，還需與開發人員明確相關信息否能上報的可行性。
3. 存在數據清洗成本
   隨着業務更迭變化，以前主觀判斷所需的數據會存在更改變化，此時對以前打點的數據就須要手動清洗，且清洗的工做量佔比並不小。
   

對於開發來講：

1. 開發人員精力消耗
   埋點對於業務團隊來講，經常被相關開發人員所詬病。開發技術人員不能只關注技術，還需分散精力作埋點這樣高度重複且機械性的任務。
   
2. 埋點相關代碼侵入性強，對系統設計和代碼可維護性形成負面影響
   大部分的業務相關數據點都須要手動埋點完成，埋點代碼不得不與業務代碼強耦合在一塊兒。即便業界已有無埋點sdk，數據產品關注的業務特殊點也逃離不了手動埋點。
   在業務不斷變化下對數據的需求變動，埋點相關代碼也須要跟着變化。進一步增長開發和代碼維護成本。
   
3. 易錯、漏
   因爲人工打點存在主觀意識差別，打點位置的準確度難控，且易漏數據
   
4. 存在打點流程成本
   當數據漏採或錯採時，又要經歷一遍開發流程和上線流程，效率低下。

3.2無埋點優點

與手動埋點相比較，無埋點優點便不用多解釋。

1. 提升效率
2. 數據更全面，按需提取
3. 減小代碼侵入

4、微信小程序無埋點sdk方案

4.1 無埋點數據需求

• 小程序的初始化執行狀況上報
• 接口請求上報
• 錯誤上報
• 用戶行爲上報
  

  
  

       因爲小程序不一樣於web服務，不存在js /css資源加載一說，因此更關注的是小程序初始化狀態和執行狀況的記錄和捕獲上報狀況，圖中資源完整性檢查對應初始化完成性檢查。線上小程序中的請求域名都必須是https協議的，故dns劫持機率大大下降甚至不大可能發生，且從客戶端監控DNS劫持可行性較低（存在悖論），暫不考慮DNS劫持捕獲狀況。

4.2 針對微信小程序開發無埋點sdk的難點及重點

• 沒法直接攔截/監聽請求
  微信請求統一經過微信API完成 ，請求模塊已被微信方封裝，且小程序的運行環境不是瀏覽器對象，不像web應用那樣重寫封裝很自如。
• 三種運行環境的監控兼容性保證
  
  • Android 上，js運行環境是 X5 內核
  • iOS 上，js 運行環境是 JavaScriptCore
  • 開發工具上， j s運行環境是 nwjs（chrome內核）
  
  
• 用戶行爲沒法直接監聽
• 強拓展性
  須要適用於多種架構設計場景（小程序）下使用
• sdk需輕量
  每一個小程序的包存在2M的限制，而且小程序並不支持在代碼中引入npm包，故sdk自己會佔用2M的大小限制。雖然小程序有分包的內測，但該功能未徹底放開，再者做爲一個sdk體積過大也是不合理的。
  
• 數據收集量大，儘可能減小性能損耗
• 不影響業務（基本需求）

4.3 微信小程序無埋點sdk設計

數據層設計：

數據流走向設計：

採集方式設計：

接入方式：

   在小程序初始化代碼以前引入sdk npm包代碼，小程序打包代碼時將sdk代碼引入到項目中初始化後便可自動打點收集數據。初始化例子以下：

import Prajna from './lib/prajna-wxapp-sdk.js';

Prajna.init({channel: 'channel',env: config.IS_PRODUCION ? 'product': 'beta',project: 'yourProjectName',methodConfg: {} // 業務特殊關注的方法執行和自定義打點名稱})複製代碼

無埋點結合埋點：

    小程序的無埋點方式，能夠獲取到大量的數據基本能夠作到用戶使用場景的高度還原。SDK打點的粒度是到某個方法的執行，對於業務特殊關注點的粒度小於SDK粒度時沒法單純靠SDK無埋點徹底解決，可採用無埋點和埋點相結合，故咱們的小程序無埋點SDK也提供手動埋點的API接口，完善數據的完整程度，進而解決更多的問題（回顧參照數據重要性提到的做用）。

5、小程序無埋點SDK中遇到的問題

除了解決了前文提到的針對微信小程序開發無埋點sdk的難點及重點所面臨的問題外，還遇到了一些新的問題。

1. SDK自己會對業務性能形成必定成都影響，數據暫存放在了小程序的localstorage中，屢次較頻繁的存/取小程序的localstorage在業務方自己較耗費性能的狀況下會暴露出操做卡頓問題。減小localstorage的存/取操做，只在頁面關閉時未上傳的數據才存入localstorage
   
2. 全量無埋點的數據量龐大，灰度上線時遇到過服務器過載致使服務器可用性降低的問題。後續對於數據上報的量有所控制，只自動上報關鍵節點數據，其餘業務關注節點可經過接入初始化時針對性配置再上報，避免上報過多冗餘數據。此外對於上報數據結構的設計也須要尤其注意，結構目標是要清晰、簡潔、便於數據檢索（區分）。
   
3. 初期本來想針對灰度上線作一個SDK使用與否的「開關」，避免小程序回滾流程。因爲「開關」依賴server接口控制，而請求是異步的，意味着初始化過程以及小程序啓動都必須等到控制開關的接口返回纔可進行，不然「開關」就至關於失效的。 考慮到SDK不能影響到業務性能，丟棄「開關」，在SDK內部作好try、catch，避免對業務可用性形成影響。
   
   

有了無埋點上報得到數據，後續即可以利用數據來解決不少問題。對於數據的利用請期待下節——數據的應用篇。

參考文獻：

[1] 【美】培基，譯者：姚軍等，《深刻理解網站優化》，出版社:機械工業出版社，出版時間:2013-08

[2] 張溪夢，《首席增加官》，出版社:機械工業出版社，出版時間:第1版 (2017年11月6日)