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

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

一、數(shù)據(jù)采集的重要性

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

數(shù)據(jù)對于線上問題排查的作用：

• 用戶行為數(shù)據(jù)還原“現(xiàn)場”，幫助分析和定位問題，提高問題定位效率
• 對于問題分析提供有力證據(jù)

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

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

數(shù)據(jù)對于業(yè)務(wù)增長的作用：

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

二、采集數(shù)據(jù)劃分梳理

從第一大點，我們總結(jié)了數(shù)據(jù)的重要性，不同的業(yè)務(wù)項目對于數(shù)據(jù)重要性的側(cè)重點會有不同，那數(shù)據(jù)采集到底要采集哪些數(shù)據(jù)呢？

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

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

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

三、數(shù)據(jù)上報方式

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

1. 第一類是代碼埋點，即在需要埋點的節(jié)點調(diào)用接口直接上傳埋點數(shù)據(jù)，友盟、百度統(tǒng)計等第三方數(shù)據(jù)統(tǒng)計服務(wù)商大都采用這種方案；

2. 第二類是可視化埋點，即通過可視化工具配置采集節(jié)點，在前端自動解析配置并上報埋點數(shù)據(jù)，從而實現(xiàn)所謂的“無痕埋點”， 代表方案是已經(jīng)開源的 Mixpanel ；

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

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

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

對于數(shù)據(jù)產(chǎn)品來說：

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

對于開發(fā)來說：

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

3.2無埋點優(yōu)勢

與手動埋點相比較，無埋點優(yōu)勢便不用多解釋。

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

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

4.1 無埋點數(shù)據(jù)需求

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

  

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

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

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

4.3 微信小程序無埋點sdk設(shè)計

數(shù)據(jù)層設(shè)計：

 

數(shù)據(jù)流走向設(shè)計：

采集方式設(shè)計：

接入方式：

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

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)注的方法執(zhí)行和自定義打點名稱})

無埋點結(jié)合埋點：

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

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

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

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

有了無埋點上報獲得數(shù)據(jù)，后續(xù)便可以利用數(shù)據(jù)來解決很多問題。對于數(shù)據(jù)的利用請期待下節(jié)——數(shù)據(jù)的應(yīng)用篇。