作者：lxj，點餐終端團隊成員
前言
相信業務團隊對這樣的場景不會太陌生：
- 打點需求： 每新上一個功能，資料產品便會同步加上打點需求，當資料打點上線後一段時間，資料產品/業務產品便會針對資料的轉化率分析和對業務需求的調整；
- 打點正確性驗證：當某一天資料轉化率大幅度變化不符合預期，資料產品/業務產品便會和開發確認打點的位置是否出現紕漏;
- 線上問題排查： 接到上報一個線上問題，然而開發們卻無法重現該case，此時需要有線上對應該case的資料才能進一步分析問題，倘若沒有資料，那這個問題很可能將變成一樁“懸案”，便會遭受多合作方的質疑和對於業務穩定性的安全感大大降低。
由此資料是很重要的，我們接下來從資料採集的重要性、資料的劃分、採集方式以及在微信小程式中的埋點方案几個方面來一起詳細聊一下資料採集。
一、資料採集的重要性
本篇我們重點討論資料採集，暫不詳細論證資料的作用，先歸納總結一下資料對於效能優化、業務增長和線上問題排查的重要作用，這也是我們為什麼需要埋點的原因。
資料對於線上問題排查的作用：
- 使用者行為資料還原“現場”，幫助分析和定位問題，提高問題定位效率
- 對於問題分析提供有力證據
資料對於效能優化的作用：
- 幫助發現和監控線上業務的關鍵成功指標
- 幫助發現最需要優化環境及其優先順序
- 幫助發現所面臨的挑戰的資訊和改進決策
- 幫助提供對應用測試和優化更好的分析
資料對於業務增長的作用：
- 幫助衡量市場營銷效果
- 幫助發現啟用轉化效果的策略
- 幫助發現使用者留存和使用者活躍分析
- 幫助產品營收變現分析
二、採集資料劃分梳理
從第一大點，我們總結了資料的重要性，不同的業務專案對於資料重要性的側重點會有不同，那資料採集到底要採集哪些資料呢？
首先閉環資料包括：
- 使用者行為
- 使用者資訊、CRM（客戶關係）
- 交易資料、服務端日誌資料
以上三項資料，才算是一個完整資料流閉環，當然不同的業務場景中資料還可以再更細劃分，大體的關鍵點基本不超出這三項。對於前端的資料收集來講，閉環資料中前兩項主要由客戶端上報資料，而第三點主要由服務端記錄資料，客戶端輔助，因為交易請求真正到達服務端完成處理才算是完成交易的一個閉環。使用者行為資料又包括——時間（when）、地點（where）、人物（who）、互動（how）、互動內容（what）五個要素，和新聞五要素有點類似；使用者資訊有的業務涉及到使用者敏感資訊和隱私等需要授權，所以使用者資訊由業務場景定奪具體維度，最基本的資料需求是能唯一標識使用者；CRM、交易資料和使用者資訊類似，具體所需資料細節由業務場景定奪，CRM基本資料需求是登陸資訊、會員相關資訊，交易資料包括——交易時間、交易物件、交易內容、交易金額、交易狀態。
三、資料上報方式
聊完資料，下一步便是需要知道如何獲取到我們真正所需要的資料。資料上報方式大體上可以歸為三類：
第一類是程式碼埋點，即在需要埋點的節點手動呼叫介面上傳埋點資料，友盟、百度統計等第三方資料統計服務商大都採用這種方案；
第二類是視覺化埋點，即通過視覺化工具配置採集節點，在前端自動解析配置並上報埋點資料，從而實現所謂的“無痕埋點”， 代表方案是已經開源的Mixpanel；
第三類是“無埋點”，它並不是真正的不需要埋點，而是前端自動採集全部事件並上報埋點資料，在後端資料計算時過濾出有用資料，代表方案是國內的GrowingIO。
重點討論無埋點，視覺化埋點其實可以算是無埋點的一個衍生故視覺化埋點在此不討論，主要對比程式碼埋點與無埋點。
3.1程式碼埋點或Capture模式的埋點缺點
對於資料產品來說：
- 依賴人的經驗和直覺判斷。
業務相關的埋點位置需要資料產品或者業務產品主觀判斷，技術相關的埋點則需要技術人員主觀判斷。 - 溝通成本高
資料產品確定所需要的資料，需要提出需求與開發溝通，且資料人員對技術不是特別熟悉，還需與開發人員明確相關資訊否能上報的可行性。 - 存在資料清洗成本
隨著業務更迭變化，之前主觀判斷所需的資料會存在更改變化，此時對之前打點的資料就需要手動清洗，且清洗的工作量佔比並不小。
對於開發來說：
- 開發人員精力消耗
埋點對於業務團隊來說，常常被相關開發人員所詬病。開發技術人員不能只關注技術，還需分散精力做埋點這樣高度重複且機械性的任務。 - 埋點相關程式碼侵入性強，對系統設計和程式碼可維護性造成負面影響
大部分的業務相關資料點都需要手動埋點完成，埋點程式碼不得不與業務程式碼強耦合在一起。即使業界已有無埋點sdk，資料產品關注的業務特殊點也逃離不了手動埋點。
在業務不斷變化下對資料的需求變更，埋點相關程式碼也需要跟著變化。進一步增加開發和程式碼維護成本。 - 易錯、漏
由於人工打點存在主觀意識差異，打點位置的準確度難控，且易漏資料 - 存在打點流程成本
當資料漏採或錯採時，又要經歷一遍開發流程和上線流程，效率低下。
3.2無埋點優勢
與手動埋點相比較，無埋點優勢便不用多解釋。
- 提高效率
- 資料更全面，按需提取
- 減少程式碼侵入
四、微信小程式無埋點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介面，完善資料的完整程度，進而解決更多的問題（回顧參照資料重要性提到的作用）。
五、小程式無埋點SDK中遇到的問題
除了解決了前文提到的針對微信小程式開發無埋點sdk的難點及重點所面臨的問題外，還遇到了一些新的問題。
- SDK本身會對業務效能造成一定成都影響，資料暫存放在了小程式的localstorage中，多次較頻繁的存/取小程式的localstorage在業務方本身較耗費效能的情況下會暴露出操作卡頓問題。減少localstorage的存/取操作，只在頁面關閉時未上傳的資料才存入localstorage
- 全量無埋點的資料量龐大，灰度上線時遇到過伺服器過載導致伺服器可用性下降的問題。後續對於資料上報的量有所控制，只自動上報關鍵節點資料，其他業務關注節點可通過接入初始化時針對性配置再上報，避免上報過多冗餘資料。此外對於上報資料結構的設計也需要尤為注意，結構目標是要清晰、簡潔、便於資料檢索（區分）。
- 初期原本想針對灰度上線做一個SDK使用與否的“開關”，避免小程式回滾流程。由於“開關”依賴server介面控制，而請求是非同步的，意味著初始化過程以及小程式啟動都必須等到控制開關的介面返回才可進行，否則“開關”就相當於失效的。 考慮到SDK不能影響到業務效能，丟棄“開關”，在SDK內部做好try、catch，避免對業務可用性造成影響。
有了無埋點上報獲得資料，後續便可以利用資料來解決很多問題。對於資料的利用請期待下節——資料的應用篇。
參考文獻：
[1] 【美】培基，譯者：姚軍等，《深入理解網站優化》，出版社:機械工業出版社，出版時間:2013-08
[2] 張溪夢，《首席增長官》，出版社:機械工業出版社，出版時間:第1版 (2017年11月6日)