一、前言
神策數(shù)據(jù)微信小程序 SDK，是一款用于微信小程序端的數(shù)據(jù)采集埋點(diǎn) SDK。具體而言，是指開發(fā)者將 SDK 集成到開發(fā)的微信小程序項(xiàng)目中，通過配置或者在特定時(shí)機(jī)調(diào)用 SDK 提供的接口采集用戶數(shù)據(jù)并通過網(wǎng)絡(luò)發(fā)送到指定的服務(wù)端。
二、數(shù)據(jù)采集
對于 SDK 而言，數(shù)據(jù)采集是指在用戶行為觸發(fā)時(shí)（例如：小程序啟動(dòng)、點(diǎn)擊了某個(gè)按鈕等），按照既定的數(shù)據(jù)格式，將用戶的行為進(jìn)行數(shù)據(jù)化。根據(jù)采集方式的不同，可以分為代碼埋點(diǎn)、全埋點(diǎn)和自定義全埋點(diǎn)：
代碼埋點(diǎn)是指調(diào)用 SDK 提供的 track() 接口采集自定義事件；
全埋點(diǎn)是指 SDK 通過代理生命周期函數(shù)與各個(gè)事件處理函數(shù)來實(shí)現(xiàn)預(yù)置事件的采集；
自定義全埋點(diǎn)是指將 SDK 自動(dòng)采集預(yù)置事件的功能關(guān)閉，由開發(fā)者手動(dòng)調(diào)用 SDK 提供的特定接口 quick() 實(shí)現(xiàn)預(yù)置事件的采集。
神策數(shù)據(jù)微信小程序 SDK 還提供了全埋點(diǎn)版本和自定義埋點(diǎn)版本：
- 全埋點(diǎn)版本是 SDK 自動(dòng)代理了微信小程序的 App、Page 和 Component 三個(gè)接口，自動(dòng)采集預(yù)置事件依賴于全埋點(diǎn)版本的 SDK；
- 自定義埋點(diǎn)版本是指不采用 SDK 自動(dòng)采集預(yù)置事件的功能，開發(fā)者手動(dòng)調(diào)用 SDK 提供的接口完成預(yù)置事件的采集。
2.1 代碼埋點(diǎn)
2.1.1 概要介紹
代碼埋點(diǎn)又稱為自定義埋點(diǎn)。具體是指 SDK 初始化之后，在相關(guān)的事件處理函數(shù)中調(diào)用 track() 接口，將采集到的數(shù)據(jù)保存到發(fā)送隊(duì)列中，然后按照一定的發(fā)送策略將數(shù)據(jù)發(fā)送到指定的服務(wù)端。例如：小程序中某個(gè) view 元素被點(diǎn)擊，如果想采集這個(gè) view 元素的點(diǎn)擊事件，需要在 view 元素的事件處理函數(shù)中調(diào)用 track() 接口，通過代碼埋點(diǎn)采集 view 元素的點(diǎn)擊事件數(shù)據(jù)。
2.1.2 使用場景
代碼埋點(diǎn)有很多優(yōu)點(diǎn)：
精準(zhǔn)控制埋點(diǎn)位置，有針對性地對需要的數(shù)據(jù)進(jìn)行采集；
靈活的自定義事件和屬性，方便采集豐富的業(yè)務(wù)相關(guān)數(shù)據(jù)；
可以滿足精細(xì)化的分析需求。
當(dāng)然，代碼埋點(diǎn)也有相應(yīng)的缺點(diǎn)：
埋點(diǎn)成本相對比較大，每一個(gè)控件的埋點(diǎn)都需要添加相應(yīng)的代碼；
更新代價(jià)比較大，每一次更新埋點(diǎn)方案都需要修改代碼并發(fā)版；
對用戶業(yè)務(wù)代碼侵入性較大，埋點(diǎn)代碼較為分散，不好統(tǒng)一管理，可維護(hù)性較差。
因此，代碼埋點(diǎn)適用于需要精準(zhǔn)控制埋點(diǎn)位置、靈活的自定義事件和屬性等精細(xì)化需求的場景。
2.2 全埋點(diǎn)
2.2.1 概要介紹
全埋點(diǎn)也可以稱為自動(dòng)埋點(diǎn)，SDK 通過代理 App、Page 和 Component 的生命周期函數(shù)與各個(gè)事件處理函數(shù)來實(shí)現(xiàn)預(yù)置事件的采集。全埋點(diǎn)指集成 SDK，并且開啟相應(yīng)的配置項(xiàng)后，就可以自動(dòng)采集用戶的部分行為數(shù)據(jù)。微信小程序 SDK 全埋點(diǎn)的采集范圍（預(yù)置事件）包括：小程序啟動(dòng)、顯示、進(jìn)入后臺(tái)、頁面瀏覽、分享、元素點(diǎn)擊等，事件觸發(fā)與采集規(guī)則如表 2-1 所示：
2.2.2 使用場景
全埋點(diǎn)有如下優(yōu)點(diǎn)：
展示宏觀指標(biāo)，滿足基本數(shù)據(jù)分析需求。通過采集 PV、UV 等常用指標(biāo)，并對這些基本數(shù)據(jù)進(jìn)行數(shù)據(jù)分析，有助于企業(yè)了解用戶行為，為進(jìn)一步數(shù)據(jù)分析指明方向；
技術(shù)門檻低，使用與部署較簡單。只需要嵌入 SDK，極大程度地避免了因需求變更、埋點(diǎn)錯(cuò)誤等原因?qū)е轮匦侣顸c(diǎn)的復(fù)雜工作；
降低了開發(fā)者的工作量。開啟相應(yīng)的配置項(xiàng)后，自動(dòng)向服務(wù)器發(fā)送數(shù)據(jù)，避免手工埋點(diǎn)的失誤。
同時(shí)，全埋點(diǎn)也有一些缺點(diǎn)：
全埋點(diǎn)只能采集到用戶交互數(shù)據(jù)，且適合標(biāo)準(zhǔn)化的采集，自定義屬性的采集需要代碼埋點(diǎn)來輔助。每個(gè)用戶的交互行為均有許多屬性，全埋點(diǎn)無法深入到更細(xì)、更深的粒度。例如：在電商行業(yè)中，用戶點(diǎn)擊 “購物車” 是一次交互行為。全埋點(diǎn)會(huì)忽略用戶信息、商品品類等其他維度信息，此時(shí)需要配合代碼埋點(diǎn)來輔助數(shù)據(jù)采集；再如用戶上滑屏幕時(shí)，內(nèi)容瀑布流的底部載入、商品或廣告的加載展示、下拉菜單中內(nèi)容的數(shù)據(jù)點(diǎn)擊等情況，這類自定義行為的采集需要代碼埋點(diǎn)來輔助實(shí)現(xiàn)。由于全埋點(diǎn)僅適合標(biāo)準(zhǔn)的方案采集，一些數(shù)據(jù)分析平臺(tái)也開始支持用戶為每個(gè)事件添加自定義屬性，如此能大大擴(kuò)展事件分析的效能；
小程序 SDK 全埋點(diǎn)是通過代理 App、Page 和 Component 三個(gè)接口并且代理相應(yīng)的生命周期函數(shù)，在相應(yīng)的生命周期函數(shù)中加入我們的埋點(diǎn)邏輯實(shí)現(xiàn)的。因此，如果某天微信不允許重寫 App、Page 和 Component 三個(gè)接口了，那么全埋點(diǎn)功能將無法使用，不過這種可能性比較小。
因此，可以知道全埋點(diǎn)適用于以較小的埋點(diǎn)代價(jià)采集盡可能多的用戶行為數(shù)據(jù)的場景。
2.3 自定義埋點(diǎn)
2.3.1 概要介紹
有些情況下，開發(fā)者的小程序項(xiàng)目中不允許代理 App、Page 和 Component 這三個(gè)接口，或者預(yù)置事件中的自定義屬性需要異步才能獲取到，此時(shí)就需要使用自定義全埋點(diǎn)功能。
自定義全埋點(diǎn)是指集成 SDK 后，開發(fā)者關(guān)閉 SDK 自動(dòng)采集的功能，并在指定的生命周期函數(shù)內(nèi)手動(dòng)調(diào)用 SDK 提供的 quick() 接口采集預(yù)置事件。自定義全埋點(diǎn)采集的范圍（預(yù)置事件）包括啟動(dòng)、顯示、進(jìn)入后臺(tái)，事件觸發(fā)與采集規(guī)則如表 2-2 所示：
2.3.2 使用場景
自定義全埋點(diǎn)有如下優(yōu)點(diǎn)：
展示宏觀指標(biāo)的同時(shí)增加一些自定義的業(yè)務(wù)分析屬性。這些分析屬性的值通過后端接口獲取，在發(fā)送預(yù)置事件時(shí)設(shè)置，既采集了 PV、UV 又能滿足一些精細(xì)化的分析需求；
使用自定義埋點(diǎn)版 SDK 進(jìn)行自定義全埋點(diǎn)時(shí)，SDK 不會(huì)代理 App、Page 和 Component 等接口。
同時(shí)，自定義全埋點(diǎn)也有一些缺點(diǎn)：
需要開發(fā)者按照特定寫法調(diào)用 SDK 指定接口；
相較于全埋點(diǎn)會(huì)增加開發(fā)者一些工作量。
因此，自定義全埋點(diǎn)適用于需要給預(yù)置事件添加異步獲取自定義屬性值的場景，以及不能被 SDK 代理 App、Page 等接口的小程序項(xiàng)目。
2.4 預(yù)置屬性采集
預(yù)置屬性是 SDK 預(yù)先采集小程序的某些屬性，例如：頁面路徑（scene）、屏幕寬高（
screen_width ）等。這些屬性會(huì)由 SDK 自動(dòng)采集，然后和手動(dòng)采集的屬性一起發(fā)往指定的服務(wù)端。
這些屬性是自動(dòng)采集的，不需要開發(fā)者增加代碼，極大地增加了數(shù)據(jù)采集的范圍和便利性。采集的預(yù)置屬性，是數(shù)據(jù)分析中涉及的重要分析維度，自動(dòng)采集極大地降低了開發(fā)和采集的成本，是可以拿來即用的部分。
預(yù)置屬性采集功能的優(yōu)缺點(diǎn)：
優(yōu)點(diǎn)：自動(dòng)幫用戶采集了很多頁面上的相關(guān)屬性，讓數(shù)據(jù)更加全面，分析維度更加豐富。
缺點(diǎn)：自動(dòng)采集的預(yù)置屬性在 SDK 內(nèi)是已經(jīng)固定的，無法自動(dòng)采集與用戶業(yè)務(wù)相關(guān)的屬性（業(yè)務(wù)相關(guān)屬性可以通過自定義屬性采集）。
預(yù)置屬性涉及的面非常廣，屬性的種類也有很多，會(huì)在后續(xù)的專題中詳細(xì)講解，在此就不過多展開了。
三、數(shù)據(jù)發(fā)送
3.1 數(shù)據(jù)存儲(chǔ)
每個(gè)微信小程序都可以有自己的本地緩存，并通過微信提供的 API 對本地緩存進(jìn)行讀寫和清理，API 的使用如表 3-1 所示：
同一個(gè)微信用戶、同一個(gè)小程序 storage 上限為 10MB，storage 以用戶維度隔離：
1、同一臺(tái)設(shè)備上，A 用戶無法讀取到 B 用戶的數(shù)據(jù)；
2、不同小程序之間無法互相讀寫數(shù)據(jù)。
3.2 發(fā)送的順序
SDK 采集的是客戶端的數(shù)據(jù)，用戶的行為數(shù)據(jù)通過網(wǎng)絡(luò)請求發(fā)送到指定的服務(wù)端。但是，網(wǎng)絡(luò)請求是有波動(dòng)的。如果是先后連在一起觸發(fā)的數(shù)據(jù)，可能會(huì)出現(xiàn)先發(fā)后到的情況。例如：全埋點(diǎn)情況下小程序啟動(dòng)時(shí)，會(huì)連續(xù)發(fā)送小程序啟動(dòng)、小程序顯示、小程序頁面瀏覽三個(gè)預(yù)置事件，不過到達(dá)服務(wù)器的順序可能是小程序頁面瀏覽事件先到，小程序啟動(dòng)事件最后到達(dá)。直觀來看，用戶行為會(huì)非常不合理：先觸發(fā)了小程序的頁面瀏覽事件，才觸發(fā)小程序的啟動(dòng)與小程序顯示事件。
為了保證發(fā)送的順序，SDK 在數(shù)據(jù)發(fā)送之前會(huì)構(gòu)建數(shù)據(jù)發(fā)送隊(duì)列，保證用戶行為數(shù)據(jù)按照正確的順序入庫，形成正確的行為序列。這是如何做到的呢？SDK 在發(fā)送數(shù)據(jù)隊(duì)列中的數(shù)據(jù)時(shí)，默認(rèn)會(huì)按照順序發(fā)送：當(dāng)前一條數(shù)據(jù)返回發(fā)送成功的狀態(tài)后，依次發(fā)送下一條數(shù)據(jù)，這保證了大部分正常流程的數(shù)據(jù)發(fā)送正確。但是，萬一前面的數(shù)據(jù)發(fā)送卡住了，一直沒有狀態(tài)返回怎么辦？SDK 的解決方案是設(shè)置超時(shí)時(shí)間：
send_timeout: 隊(duì)列發(fā)送超時(shí)時(shí)間，默認(rèn)值 1000 毫秒，如果數(shù)據(jù)發(fā)送時(shí)間超過 send_timeout 還未返回結(jié)果，會(huì)強(qiáng)制發(fā)送下一條數(shù)據(jù)；
datasend_timeout: 數(shù)據(jù)發(fā)送超時(shí)時(shí)間，默認(rèn)值 3000 毫秒，如果數(shù)據(jù)發(fā)送時(shí)間超過 datasend_timeout 還未返回結(jié)果，會(huì)強(qiáng)制取消該請求。
因此，構(gòu)建數(shù)據(jù)發(fā)送隊(duì)列可以解決客戶端行為數(shù)據(jù)發(fā)送順序錯(cuò)亂的問題。
3.3 發(fā)送的方式
3.3.1 實(shí)時(shí)發(fā)送
微信小程序 SDK 中的數(shù)據(jù)采集默認(rèn)情況下使用的是即時(shí)采集、即時(shí)發(fā)送的策略。由于沒有使用本地緩存，減少了復(fù)雜的緩存、讀取和發(fā)送的控制流程。需要注意的是，線上小程序中使用的數(shù)據(jù)接收地址需要配置 request 合法域名（微信公眾平臺(tái) → 開發(fā) → 開發(fā)設(shè)置 → 服務(wù)器域名中進(jìn)行配置），否則 SDK 采集的數(shù)據(jù)無法發(fā)送。
通過網(wǎng)絡(luò)發(fā)送數(shù)據(jù)時(shí)，無法避免的是當(dāng)網(wǎng)絡(luò)情況不佳時(shí)，會(huì)有數(shù)據(jù)發(fā)送失敗的問題。數(shù)據(jù)一旦發(fā)送失敗，由于沒有緩存的邏輯，就會(huì)造成數(shù)據(jù)丟失。因此，微信小程序 SDK 增加了批量發(fā)送的功能。
3.3.2 批量發(fā)送
批量發(fā)送方式下，當(dāng)數(shù)據(jù)產(chǎn)生后會(huì)先將數(shù)據(jù)存儲(chǔ)在 storage 中（存儲(chǔ)的數(shù)據(jù)有條數(shù)限制，最大能存儲(chǔ) 300 條），達(dá)到發(fā)送條件后才會(huì)把存儲(chǔ)在 storage 中的數(shù)據(jù)合并發(fā)送出去。其中，發(fā)送條件包括：
時(shí)間間隔：每隔一定時(shí)間（默認(rèn) 6 秒）發(fā)送一次數(shù)據(jù)；
存儲(chǔ)數(shù)據(jù)條數(shù)：存儲(chǔ)數(shù)據(jù)達(dá)到一定條數(shù)（默認(rèn) 6 條）時(shí)發(fā)送一次數(shù)據(jù)；
進(jìn)入后臺(tái)：當(dāng)小程序進(jìn)入后臺(tái)時(shí)發(fā)送一次數(shù)據(jù)。
上述三個(gè)發(fā)送條件滿足任意一個(gè)即可發(fā)送數(shù)據(jù)。
如果數(shù)據(jù)發(fā)送不成功，會(huì)將發(fā)送的數(shù)據(jù)保存起來，滿足發(fā)送條件后，與之后的數(shù)據(jù)一起嘗試發(fā)送。這樣，可以減少網(wǎng)絡(luò)請求、節(jié)省服務(wù)器資源，并且有效地降低一些數(shù)據(jù)發(fā)送過程中的丟失問題。
四、調(diào)試事件信息
集成 SDK 并觸發(fā)一些事件后，默認(rèn)會(huì)把采集的數(shù)據(jù)實(shí)時(shí)發(fā)送至神策后臺(tái)。那么我們?nèi)绾蔚弥?SDK 采集的數(shù)據(jù)是否完整，發(fā)送是否成功呢？這里我們提供了兩種調(diào)試事件信息的方式：本地調(diào)試和實(shí)時(shí)數(shù)據(jù)查看。
4.1 本地調(diào)試
默認(rèn)情況下，SDK 會(huì)將采集的數(shù)據(jù)信息打印在微信開發(fā)者工具的 Console 面板，如圖 4-1 所示：
在開發(fā)工具的 Console 面板看到打印的數(shù)據(jù)信息后，表示 SDK 采集到了小程序中的數(shù)據(jù)，但是并不代表發(fā)送成功。查看數(shù)據(jù)的發(fā)送情況可以通過在微信開發(fā)者工具的 Network 面板查看 SDK 的數(shù)據(jù)請求，如圖 4-2 所示：
如上圖所示，Network 面板中有 SDK 的數(shù)據(jù)請求，并且請求狀態(tài)碼為 200，表示 SDK 成功地將采集的數(shù)據(jù)發(fā)送至神策后臺(tái)。
4.2 實(shí)時(shí)數(shù)據(jù)查看
4.1 節(jié)中介紹了客戶端 SDK 采集數(shù)據(jù)的過程，那么采集的數(shù)據(jù)會(huì)發(fā)送到哪里呢？可以在神策后臺(tái)實(shí)時(shí)數(shù)據(jù)中查看。在神策分析后臺(tái) → 埋點(diǎn)管理 → 實(shí)時(shí)導(dǎo)入數(shù)據(jù)查詢中，點(diǎn)擊 “開始刷新” 按鈕，可以看到有數(shù)據(jù)進(jìn)入。如圖 4-3 所示：
五、總結(jié)
本文對于微信小程序 SDK 進(jìn)行了簡明扼要的介紹，概述了微信小程序 SDK 的基本功能，旨在讓大家對于它有一個(gè)初步的了解。關(guān)于具體使用和實(shí)現(xiàn)原理等相關(guān)知識(shí)，會(huì)在后續(xù)的文章中逐步向大家介紹。
本文作者
神策數(shù)據(jù) | 微信小程序 SDK 技術(shù)顧問
我是馬慧青，神策數(shù)據(jù)微信小程序 SDK 技術(shù)顧問，主要從事小程序方面技術(shù)的研究和學(xué)習(xí)，希望通過開源社區(qū)這個(gè)平臺(tái)在與大家交流的過程中共同進(jìn)步。生活中喜歡聽音樂、跑步，盡可能充實(shí)、完善自己。
