作者:lxj
前言
相信業(yè)務(wù)團(tuán)隊(duì)對(duì)這樣的場景不會(huì)太陌生:
- 打點(diǎn) 需求 : 每新上一個(gè)功能,數(shù)據(jù)產(chǎn)品便會(huì)同步加上打點(diǎn)需求,當(dāng)數(shù)據(jù)打點(diǎn)上線后一段時(shí)間,數(shù)據(jù)產(chǎn)品/業(yè)務(wù)產(chǎn)品便會(huì)針對(duì)數(shù)據(jù)的轉(zhuǎn)化率分析和對(duì)業(yè)務(wù)需求的調(diào)整;
- 打點(diǎn)正確性驗(yàn)證 :當(dāng)某一天數(shù)據(jù)轉(zhuǎn)化率大幅度變化不符合預(yù)期,數(shù)據(jù)產(chǎn)品/業(yè)務(wù)產(chǎn)品便會(huì)和開發(fā)確認(rèn)打點(diǎn)的位置是否出現(xiàn)紕漏;
- 線上問題排查 : 接到上報(bào)一個(gè)線上問題,然而開發(fā)們卻無法重現(xiàn)該case,此時(shí)需要有線上對(duì)應(yīng)該case的數(shù)據(jù)才能進(jìn)一步分析問題,倘若沒有數(shù)據(jù),那這個(gè)問題很可能將變成一樁“懸案”,便會(huì)遭受多合作方的質(zhì)疑和對(duì)于業(yè)務(wù)穩(wěn)定性的安全感大大降低。
由此數(shù)據(jù)是很重要的,我們接下來從數(shù)據(jù)采集的重要性、數(shù)據(jù)的劃分、采集方式以及在微信小程序中的埋點(diǎn)方案幾個(gè)方面來一起詳細(xì)聊一下數(shù)據(jù)采集。
一、數(shù)據(jù)采集的重要性
本篇我們重點(diǎn)討論數(shù)據(jù)采集,暫不詳細(xì)論證數(shù)據(jù)的作用,先歸納總結(jié)一下數(shù)據(jù)對(duì)于性能優(yōu)化、業(yè)務(wù)增長和線上問題排查的重要作用,這也是我們?yōu)槭裁葱枰顸c(diǎn)的原因。
數(shù)據(jù)對(duì)于線上問題排查的作用:
- 用戶行為數(shù)據(jù)還原“現(xiàn)場”,幫助分析和定位問題,提高問題定位效率
- 對(duì)于問題分析提供有力證據(jù)
數(shù)據(jù)對(duì)于性能優(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)的信息和改進(jìn)決策
- 幫助提供對(duì)應(yīng)用測(cè)試和優(yōu)化更好的分析
數(shù)據(jù)對(duì)于業(yè)務(wù)增長的作用:
- 幫助衡量市場營銷效果
- 幫助發(fā)現(xiàn)激活轉(zhuǎn)化效果的策略
- 幫助發(fā)現(xiàn)用戶留存和用戶活躍分析
- 幫助產(chǎn)品營收變現(xiàn)分析
二、采集數(shù)據(jù)劃分梳理
從先進(jìn)大點(diǎn),我們總結(jié)了數(shù)據(jù)的重要性,不同的業(yè)務(wù)項(xiàng)目對(duì)于數(shù)據(jù)重要性的側(cè)重點(diǎn)會(huì)有不同,那數(shù)據(jù)采集到底要采集哪些數(shù)據(jù)呢?
首先閉環(huán)數(shù)據(jù)包括:
- 用戶行為
- 用戶信息、CRM(客戶關(guān)系)
- 交易數(shù)據(jù)、服務(wù)端日志數(shù)據(jù)
以上三項(xiàng)數(shù)據(jù),才算是一個(gè)完整數(shù)據(jù)流閉環(huán),當(dāng)然不同的業(yè)務(wù)場景中數(shù)據(jù)還可以再更細(xì)劃分,大體的關(guān)鍵點(diǎn)基本不超出這三項(xiàng)。對(duì)于前端的數(shù)據(jù)收集來講,閉環(huán)數(shù)據(jù)中前兩項(xiàng)主要由客戶端上報(bào)數(shù)據(jù),而第三點(diǎn)主要由服務(wù)端記錄數(shù)據(jù),客戶端輔助,因?yàn)榻灰渍?qǐng)求真正到達(dá)服務(wù)端完成處理才算是完成交易的一個(gè)閉環(huán)。用戶行為數(shù)據(jù)又包括——時(shí)間(when)、地點(diǎn)(where)、人物(who)、交互(how)、交互內(nèi)容(what)五個(gè)要素,和新聞五要素有點(diǎn)類似;用戶信息有的業(yè)務(wù)涉及到用戶敏感信息和隱私等需要授權(quán),所以用戶信息由業(yè)務(wù)場景定奪具體維度,最基本的數(shù)據(jù)需求是能唯一標(biāo)識(shí)用戶;CRM、交易數(shù)據(jù)和用戶信息類似,具體所需數(shù)據(jù)細(xì)節(jié)由業(yè)務(wù)場景定奪,CRM基本數(shù)據(jù)需求是登陸信息、會(huì)員相關(guān)信息,交易數(shù)據(jù)包括——交易時(shí)間、交易對(duì)象、交易內(nèi)容、交易金額、交易狀態(tài)。
三、數(shù)據(jù)上報(bào)方式
聊完數(shù)據(jù),下一步便是需要知道如何獲取到我們真正所需要的數(shù)據(jù)。數(shù)據(jù)上報(bào)方式大體上可以歸為三類:
-
先進(jìn)類是代碼埋點(diǎn),即在需要埋點(diǎn)的節(jié)點(diǎn)調(diào)用接口直接上傳埋點(diǎn)數(shù)據(jù),友盟、百度統(tǒng)計(jì)等第三方數(shù)據(jù)統(tǒng)計(jì)服務(wù)商大都采用這種方案;
-
第二類是可視化埋點(diǎn),即通過可視化工具配置采集節(jié)點(diǎn),在前端自動(dòng)解析配置并上報(bào)埋點(diǎn)數(shù)據(jù),從而實(shí)現(xiàn)所謂的“無痕埋點(diǎn)”, 代表方案是已經(jīng)開源的 Mixpanel ;
-
第三類是“無埋點(diǎn)”,它并不是真正的不需要埋點(diǎn),而是前端自動(dòng)采集全部事件并上報(bào)埋點(diǎn)數(shù)據(jù),在后端數(shù)據(jù)計(jì)算時(shí)過濾出有用數(shù)據(jù),代表方案是國內(nèi)的GrowingIO。
重點(diǎn)討論無埋點(diǎn),可視化埋點(diǎn)其實(shí)可以算是無埋點(diǎn)的一個(gè)衍生故可視化埋點(diǎn)在此不討論,主要對(duì)比代碼埋點(diǎn)與無埋點(diǎn)。
3.1代碼埋點(diǎn)或Capture模式的埋點(diǎn)缺點(diǎn)
對(duì)于數(shù)據(jù)產(chǎn)品來說:
- 依賴人的經(jīng)驗(yàn)和直覺判斷。
業(yè)務(wù)相關(guān)的埋點(diǎn)位置需要數(shù)據(jù)產(chǎn)品或者業(yè)務(wù)產(chǎn)品主觀判斷,技術(shù)相關(guān)的埋點(diǎn)則需要技術(shù)人員主觀判斷。 - 溝通成本高
數(shù)據(jù)產(chǎn)品確定所需要的數(shù)據(jù),需要提出需求與開發(fā)溝通,且數(shù)據(jù)人員對(duì)技術(shù)不是特別熟悉,還需與開發(fā)人員明確相關(guān)信息否能上報(bào)的可行性。 - 存在數(shù)據(jù)清洗成本
隨著業(yè)務(wù)更迭變化,之前主觀判斷所需的數(shù)據(jù)會(huì)存在更改變化,此時(shí)對(duì)之前打點(diǎn)的數(shù)據(jù)就需要手動(dòng)清洗,且清洗的工作量占比并不小。
對(duì)于開發(fā)來說:
- 開發(fā)人員精力消耗
埋點(diǎn)對(duì)于業(yè)務(wù)團(tuán)隊(duì)來說,常常被相關(guān)開發(fā)人員所詬病。開發(fā)技術(shù)人員不能只關(guān)注技術(shù),還需分散精力做埋點(diǎn)這樣高度重復(fù)且機(jī)械性的任務(wù)。 - 埋點(diǎn)相關(guān)代碼侵入性強(qiáng),對(duì)系統(tǒng)設(shè)計(jì)和代碼可維護(hù)性造成負(fù)面影響
大部分的業(yè)務(wù)相關(guān)數(shù)據(jù)點(diǎn)都需要手動(dòng)埋點(diǎn)完成,埋點(diǎn)代碼不得不與業(yè)務(wù)代碼強(qiáng)耦合在一起。即使業(yè)界已有無埋點(diǎn)sdk,數(shù)據(jù)產(chǎn)品關(guān)注的業(yè)務(wù)特殊點(diǎn)也逃離不了手動(dòng)埋點(diǎn)。
在業(yè)務(wù)不斷變化下對(duì)數(shù)據(jù)的需求變更,埋點(diǎn)相關(guān)代碼也需要跟著變化。進(jìn)一步增加開發(fā)和代碼維護(hù)成本。 - 易錯(cuò)、漏
由于人工打點(diǎn)存在主觀意識(shí)差異,打點(diǎn)位置的準(zhǔn)確度難控,且易漏數(shù)據(jù) - 存在打點(diǎn)流程成本
當(dāng)數(shù)據(jù)漏采或錯(cuò)采時(shí),又要經(jīng)歷一遍開發(fā)流程和上線流程,效率低下。
3.2無埋點(diǎn)優(yōu)勢(shì)
與手動(dòng)埋點(diǎn)相比較,無埋點(diǎn)優(yōu)勢(shì)便不用多解釋。
- 提高效率
- 數(shù)據(jù)更全面,按需提取
- 減少代碼侵入
四、微信小程序無埋點(diǎn)sdk方案
4.1 無埋點(diǎn)數(shù)據(jù)需求
- 小程序的初始化執(zhí)行情況上報(bào)
- 接口請(qǐng)求上報(bào)
- 錯(cuò)誤上報(bào)
- 用戶行為上報(bào)
4.2 針對(duì)微信小程序開發(fā)無埋點(diǎn)sdk的難點(diǎn)及重點(diǎn)
- 無法直接攔截/監(jiān)聽請(qǐng)求
微信請(qǐng)求統(tǒng)一通過微信API完成 ,請(qǐng)求模塊已被微信方封裝,且小程序的運(yùn)行環(huán)境不是瀏覽器對(duì)象,不像web應(yīng)用那樣重寫封裝很自如。 - 三種運(yùn)行環(huán)境的監(jiān)控兼容性保證
- Android 上,js運(yùn)行環(huán)境是 X5 內(nèi)核
- iOS 上,js 運(yùn)行環(huán)境是 JavaScriptCore
- 開發(fā)工具上, j s運(yùn)行環(huán)境是 nwjs(chrome內(nèi)核)
- 用戶行為無法直接監(jiān)聽
- 強(qiáng)拓展性
需要適用于多種架構(gòu)設(shè)計(jì)場景(小程序)下使用 - sdk需輕量
每個(gè)小程序的包存在2M的限制,并且小程序并不支持在代碼中引入npm包,故sdk本身會(huì)占用2M的大小限制。雖然小程序有分包的內(nèi)測(cè),但該功能未完全放開,再者作為一個(gè)sdk體積過大也是不合理的。 - 數(shù)據(jù)收集量大,盡量減少性能損耗
- 不影響業(yè)務(wù)(基本需求)
4.3 微信小程序無埋點(diǎn)sdk設(shè)計(jì)
數(shù)據(jù)層設(shè)計(jì):
數(shù)據(jù)流走向設(shè)計(jì):
采集方式設(shè)計(jì):
接入方式:
在小程序初始化代碼之前引入sdk npm包代碼,小程序打包代碼時(shí)將sdk代碼引入到項(xiàng)目中初始化后即可自動(dòng)打點(diǎn)收集數(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í)行和自定義打點(diǎn)名稱})
無埋點(diǎn)結(jié)合埋點(diǎn):
小程序的無埋點(diǎn)方式,可以獲取到大量的數(shù)據(jù)基本可以做到用戶使用場景的高度還原。SDK打點(diǎn)的粒度是到某個(gè)方法的執(zhí)行,對(duì)于業(yè)務(wù)特殊關(guān)注點(diǎn)的粒度小于SDK粒度時(shí)無法單純靠SDK無埋點(diǎn)完全解決,可采用無埋點(diǎn)和埋點(diǎn)相結(jié)合,故我們的小程序無埋點(diǎn)SDK也提供手動(dòng)埋點(diǎn)的API接口,完善數(shù)據(jù)的完整程度,進(jìn)而解決更多的問題(回顧參照數(shù)據(jù)重要性提到的作用)。
五、小程序無埋點(diǎn)SDK中遇到的問題
除了解決了前文提到的 針對(duì)微信小程序開發(fā)無埋點(diǎn)sdk的難點(diǎn)及重點(diǎn) 所面臨的問題外,還遇到了一些新的問題。
- SDK本身會(huì)對(duì)業(yè)務(wù)性能造成一定成都影響,數(shù)據(jù)暫存放在了小程序的localstorage中,多次較頻繁的存/取小程序的localstorage在業(yè)務(wù)方本身較耗費(fèi)性能的情況下會(huì)暴露出操作卡頓問題。減少localstorage的存/取操作,只在頁面關(guān)閉時(shí)未上傳的數(shù)據(jù)才存入localstorage
- 全量無埋點(diǎn)的數(shù)據(jù)量龐大,灰度上線時(shí)遇到過服務(wù)器過載導(dǎo)致服務(wù)器可用性下降的問題。后續(xù)對(duì)于數(shù)據(jù)上報(bào)的量有所控制,只自動(dòng)上報(bào)關(guān)鍵節(jié)點(diǎn)數(shù)據(jù),其他業(yè)務(wù)關(guān)注節(jié)點(diǎn)可通過接入初始化時(shí)針對(duì)性配置再上報(bào),避免上報(bào)過多冗余數(shù)據(jù)。此外對(duì)于上報(bào)數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)也需要尤為注意,結(jié)構(gòu)目標(biāo)是要清晰、簡潔、便于數(shù)據(jù)檢索(區(qū)分)。
- 初期原本想針對(duì)灰度上線做一個(gè)SDK使用與否的“開關(guān)”,避免小程序回滾流程。由于“開關(guān)”依賴server接口控制,而請(qǐng)求是異步的,意味著初始化過程以及小程序啟動(dòng)都必須等到控制開關(guān)的接口返回才可進(jìn)行,否則“開關(guān)”就相當(dāng)于失效的。 考慮到SDK不能影響到業(yè)務(wù)性能,丟棄“開關(guān)”,在SDK內(nèi)部做好try、catch,避免對(duì)業(yè)務(wù)可用性造成影響。
有了無埋點(diǎn)上報(bào)獲得數(shù)據(jù),后續(xù)便可以利用數(shù)據(jù)來解決很多問題。對(duì)于數(shù)據(jù)的利用請(qǐng)期待下節(jié)——數(shù)據(jù)的應(yīng)用篇。