作者：lxj

前言

相信業(yè)務(wù)團隊對這樣的場(chǎng)景不會(huì )太陌生：

• 打點(diǎn) 需求 ： 每新上一個(gè)功能，數據產(chǎn)品便會(huì )同步加上打點(diǎn)需求，當數據打點(diǎn)上線(xiàn)后一段時(shí)間，數據產(chǎn)品/業(yè)務(wù)產(chǎn)品便會(huì )針對數據的轉化率分析和對業(yè)務(wù)需求的調整；
• 打點(diǎn)正確性驗證 ：當某一天數據轉化率大幅度變化不符合預期，數據產(chǎn)品/業(yè)務(wù)產(chǎn)品便會(huì )和開(kāi)發(fā)確認打點(diǎn)的位置是否出現紕漏;
• 線(xiàn)上問(wèn)題排查 ： 接到上報一個(gè)線(xiàn)上問(wèn)題，然而開(kāi)發(fā)們卻無(wú)法重現該case，此時(shí)需要有線(xiàn)上對應該case的數據才能進(jìn)一步分析問(wèn)題，倘若沒(méi)有數據，那這個(gè)問(wèn)題很可能將變成一樁“懸案”，便會(huì )遭受多合作方的質(zhì)疑和對于業(yè)務(wù)穩定性的安全感大大降低。

由此數據是很重要的，我們接下來(lái)從數據采集的重要性、數據的劃分、采集方式以及在微信小程序中的埋點(diǎn)方案幾個(gè)方面來(lái)一起詳細聊一下數據采集。

一、數據采集的重要性

本篇我們重點(diǎn)討論數據采集，暫不詳細論證數據的作用，先歸納總結一下數據對于性能優(yōu)化、業(yè)務(wù)增長(cháng)和線(xiàn)上問(wèn)題排查的重要作用，這也是我們?yōu)槭裁葱枰顸c(diǎn)的原因。

數據對于線(xiàn)上問(wèn)題排查的作用：

• 用戶(hù)行為數據還原“現場(chǎng)”，幫助分析和定位問(wèn)題，提高問(wèn)題定位效率
• 對于問(wèn)題分析提供有力證據

數據對于性能優(yōu)化的作用：

• 幫助發(fā)現和監控在線(xiàn)業(yè)務(wù)的關(guān)鍵成功指標
• 幫助發(fā)現最需要優(yōu)化環(huán)境及其優(yōu)先順序
• 幫助發(fā)現所面臨的挑戰的信息和改進(jìn)決策
• 幫助提供對應用測試和優(yōu)化更好的分析

數據對于業(yè)務(wù)增長(cháng)的作用：

• 幫助衡量市場(chǎng)營(yíng)銷(xiāo)效果
• 幫助發(fā)現激活轉化效果的策略
• 幫助發(fā)現用戶(hù)留存和用戶(hù)活躍分析
• 幫助產(chǎn)品營(yíng)收變現分析

二、采集數據劃分梳理

從先進(jìn)大點(diǎn)，我們總結了數據的重要性，不同的業(yè)務(wù)項目對于數據重要性的側重點(diǎn)會(huì )有不同，那數據采集到底要采集哪些數據呢？

首先閉環(huán)數據包括：

1. 用戶(hù)行為
2. 用戶(hù)信息、CRM（客戶(hù)關(guān)系）
3. 交易數據、服務(wù)端日志數據

以上三項數據，才算是一個(gè)完整數據流閉環(huán)，當然不同的業(yè)務(wù)場(chǎng)景中數據還可以再更細劃分，大體的關(guān)鍵點(diǎn)基本不超出這三項。對于前端的數據收集來(lái)講，閉環(huán)數據中前兩項主要由客戶(hù)端上報數據，而第三點(diǎn)主要由服務(wù)端記錄數據，客戶(hù)端輔助，因為交易請求真正到達服務(wù)端完成處理才算是完成交易的一個(gè)閉環(huán)。用戶(hù)行為數據又包括——時(shí)間（when）、地點(diǎn)（where）、人物（who）、交互（how）、交互內容（what）五個(gè)要素，和新聞五要素有點(diǎn)類(lèi)似；用戶(hù)信息有的業(yè)務(wù)涉及到用戶(hù)敏感信息和隱私等需要授權，所以用戶(hù)信息由業(yè)務(wù)場(chǎng)景定奪具體維度，最基本的數據需求是能唯一標識用戶(hù)；CRM、交易數據和用戶(hù)信息類(lèi)似，具體所需數據細節由業(yè)務(wù)場(chǎng)景定奪，CRM基本數據需求是登陸信息、會(huì )員相關(guān)信息，交易數據包括——交易時(shí)間、交易對象、交易內容、交易金額、交易狀態(tài)。

三、數據上報方式

聊完數據，下一步便是需要知道如何獲取到我們真正所需要的數據。數據上報方式大體上可以歸為三類(lèi)：

1. 先進(jìn)類(lèi)是代碼埋點(diǎn)，即在需要埋點(diǎn)的節點(diǎn)調用接口直接上傳埋點(diǎn)數據，友盟、百度統計等第三方數據統計服務(wù)商大都采用這種方案；

2. 第二類(lèi)是可視化埋點(diǎn)，即通過(guò)可視化工具配置采集節點(diǎn)，在前端自動(dòng)解析配置并上報埋點(diǎn)數據，從而實(shí)現所謂的“無(wú)痕埋點(diǎn)”， 代表方案是已經(jīng)開(kāi)源的 Mixpanel ；

3. 第三類(lèi)是“無(wú)埋點(diǎn)”，它并不是真正的不需要埋點(diǎn)，而是前端自動(dòng)采集全部事件并上報埋點(diǎn)數據，在后端數據計算時(shí)過(guò)濾出有用數據，代表方案是國內的GrowingIO。

重點(diǎn)討論無(wú)埋點(diǎn)，可視化埋點(diǎn)其實(shí)可以算是無(wú)埋點(diǎn)的一個(gè)衍生故可視化埋點(diǎn)在此不討論，主要對比代碼埋點(diǎn)與無(wú)埋點(diǎn)。

3.1代碼埋點(diǎn)或Capture模式的埋點(diǎn)缺點(diǎn)

對于數據產(chǎn)品來(lái)說(shuō)：

1. 依賴(lài)人的經(jīng)驗和直覺(jué)判斷。
   業(yè)務(wù)相關(guān)的埋點(diǎn)位置需要數據產(chǎn)品或者業(yè)務(wù)產(chǎn)品主觀(guān)判斷，技術(shù)相關(guān)的埋點(diǎn)則需要技術(shù)人員主觀(guān)判斷。
2. 溝通成本高
   數據產(chǎn)品確定所需要的數據，需要提出需求與開(kāi)發(fā)溝通，且數據人員對技術(shù)不是特別熟悉，還需與開(kāi)發(fā)人員明確相關(guān)信息否能上報的可行性。
3. 存在數據清洗成本
   隨著(zhù)業(yè)務(wù)更迭變化，之前主觀(guān)判斷所需的數據會(huì )存在更改變化，此時(shí)對之前打點(diǎn)的數據就需要手動(dòng)清洗，且清洗的工作量占比并不小。

對于開(kāi)發(fā)來(lái)說(shuō)：

1. 開(kāi)發(fā)人員精力消耗
   埋點(diǎn)對于業(yè)務(wù)團隊來(lái)說(shuō)，常常被相關(guān)開(kāi)發(fā)人員所詬病。開(kāi)發(fā)技術(shù)人員不能只關(guān)注技術(shù)，還需分散精力做埋點(diǎn)這樣高度重復且機械性的任務(wù)。
2. 埋點(diǎn)相關(guān)代碼侵入性強，對系統設計和代碼可維護性造成負面影響
   大部分的業(yè)務(wù)相關(guān)數據點(diǎn)都需要手動(dòng)埋點(diǎn)完成，埋點(diǎn)代碼不得不與業(yè)務(wù)代碼強耦合在一起。即使業(yè)界已有無(wú)埋點(diǎn)sdk，數據產(chǎn)品關(guān)注的業(yè)務(wù)特殊點(diǎn)也逃離不了手動(dòng)埋點(diǎn)。
   在業(yè)務(wù)不斷變化下對數據的需求變更，埋點(diǎn)相關(guān)代碼也需要跟著(zhù)變化。進(jìn)一步增加開(kāi)發(fā)和代碼維護成本。
3. 易錯、漏
   由于人工打點(diǎn)存在主觀(guān)意識差異，打點(diǎn)位置的準確度難控，且易漏數據
4. 存在打點(diǎn)流程成本
   當數據漏采或錯采時(shí)，又要經(jīng)歷一遍開(kāi)發(fā)流程和上線(xiàn)流程，效率低下。

3.2無(wú)埋點(diǎn)優(yōu)勢

與手動(dòng)埋點(diǎn)相比較，無(wú)埋點(diǎn)優(yōu)勢便不用多解釋。

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

四、微信小程序無(wú)埋點(diǎn)sdk方案

4.1 無(wú)埋點(diǎn)數據需求

• 小程序的初始化執行情況上報
• 接口請求上報
• 錯誤上報
• 用戶(hù)行為上報
  

  

  由于小程序不同于web服務(wù)，不存在js /css資源加載一說(shuō)，所以更關(guān)注的是小程序初始化狀態(tài)和執行情況的記錄和捕獲上報情況，圖中資源完整性檢查對應 初始化完成性檢查。 線(xiàn)上小程序中的請求域名都必須是https協(xié)議的，故dns劫持概率大大降低甚至不大可能發(fā)生，且從客戶(hù)端監控DNS劫持可行性較低（存在悖論），暫不考慮DNS劫持捕獲情況。

4.2 針對微信小程序開(kāi)發(fā)無(wú)埋點(diǎn)sdk的難點(diǎn)及重點(diǎn)

• 無(wú)法直接攔截/監聽(tīng)請求
  微信請求統一通過(guò)微信API完成 ，請求模塊已被微信方封裝，且小程序的運行環(huán)境不是瀏覽器對象，不像web應用那樣重寫(xiě)封裝很自如。
• 三種運行環(huán)境的監控兼容性保證
  
  • Android 上，js運行環(huán)境是 X5 內核
  • iOS 上，js 運行環(huán)境是 JavaScriptCore
  • 開(kāi)發(fā)工具上， j s運行環(huán)境是 nwjs（chrome內核）
• 用戶(hù)行為無(wú)法直接監聽(tīng)
• 強拓展性
  需要適用于多種架構設計場(chǎng)景（小程序）下使用
• sdk需輕量
  每個(gè)小程序的包存在2M的限制，并且小程序并不支持在代碼中引入npm包，故sdk本身會(huì )占用2M的大小限制。雖然小程序有分包的內測，但該功能未完全放開(kāi)，再者作為一個(gè)sdk體積過(guò)大也是不合理的。
• 數據收集量大，盡量減少性能損耗
• 不影響業(yè)務(wù)（基本需求）

4.3 微信小程序無(wú)埋點(diǎn)sdk設計

數據層設計：

數據流走向設計：

采集方式設計：

接入方式：

在小程序初始化代碼之前引入sdk npm包代碼，小程序打包代碼時(shí)將sdk代碼引入到項目中初始化后即可自動(dòng)打點(diǎn)收集數據。初始化例子如下：

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

Prajna.init({channel: 'channel',env: config.IS_PRODUCION ? 'product': 'beta',project: 'yourProjectName',methodConfg: {} // 業(yè)務(wù)特殊關(guān)注的方法執行和自定義打點(diǎn)名稱(chēng)})

無(wú)埋點(diǎn)結合埋點(diǎn)：

小程序的無(wú)埋點(diǎn)方式，可以獲取到大量的數據基本可以做到用戶(hù)使用場(chǎng)景的高度還原。SDK打點(diǎn)的粒度是到某個(gè)方法的執行，對于業(yè)務(wù)特殊關(guān)注點(diǎn)的粒度小于SDK粒度時(shí)無(wú)法單純靠SDK無(wú)埋點(diǎn)完全解決，可采用無(wú)埋點(diǎn)和埋點(diǎn)相結合，故我們的小程序無(wú)埋點(diǎn)SDK也提供手動(dòng)埋點(diǎn)的API接口，完善數據的完整程度，進(jìn)而解決更多的問(wèn)題（回顧參照數據重要性提到的作用）。

五、小程序無(wú)埋點(diǎn)SDK中遇到的問(wèn)題

除了解決了前文提到的 針對微信小程序開(kāi)發(fā)無(wú)埋點(diǎn)sdk的難點(diǎn)及重點(diǎn) 所面臨的問(wèn)題外，還遇到了一些新的問(wèn)題。

1. SDK本身會(huì )對業(yè)務(wù)性能造成一定成都影響，數據暫存放在了小程序的localstorage中，多次較頻繁的存/取小程序的localstorage在業(yè)務(wù)方本身較耗費性能的情況下會(huì )暴露出操作卡頓問(wèn)題。減少localstorage的存/取操作，只在頁(yè)面關(guān)閉時(shí)未上傳的數據才存入localstorage
2. 全量無(wú)埋點(diǎn)的數據量龐大，灰度上線(xiàn)時(shí)遇到過(guò)服務(wù)器過(guò)載導致服務(wù)器可用性下降的問(wèn)題。后續對于數據上報的量有所控制，只自動(dòng)上報關(guān)鍵節點(diǎn)數據，其他業(yè)務(wù)關(guān)注節點(diǎn)可通過(guò)接入初始化時(shí)針對性配置再上報，避免上報過(guò)多冗余數據。此外對于上報數據結構的設計也需要尤為注意，結構目標是要清晰、簡(jiǎn)潔、便于數據檢索（區分）。
3. 初期原本想針對灰度上線(xiàn)做一個(gè)SDK使用與否的“開(kāi)關(guān)”，避免小程序回滾流程。由于“開(kāi)關(guān)”依賴(lài)server接口控制，而請求是異步的，意味著(zhù)初始化過(guò)程以及小程序啟動(dòng)都必須等到控制開(kāi)關(guān)的接口返回才可進(jìn)行，否則“開(kāi)關(guān)”就相當于失效的。 考慮到SDK不能影響到業(yè)務(wù)性能，丟棄“開(kāi)關(guān)”，在SDK內部做好try、catch，避免對業(yè)務(wù)可用性造成影響。

有了無(wú)埋點(diǎn)上報獲得數據，后續便可以利用數據來(lái)解決很多問(wèn)題。對于數據的利用請期待下節——數據的應用篇。