目錄

1. 背景與目標(biāo)
2. 埋點(diǎn)系統(tǒng)架構(gòu)
3. 新精準(zhǔn)曝光系統(tǒng)
4. 埋點(diǎn)驗(yàn)證可視化
5. 成果與展望

1背景與目標(biāo)

如圖所示，京東到家埋點(diǎn)的研發(fā)鏈路可以大致分為四步：

• 首先是在埋點(diǎn)需求平臺(tái)進(jìn)行 埋點(diǎn)需求的收集
• 然后在需求平臺(tái)（ 天河系統(tǒng)： 基于web前端的到家埋點(diǎn)需求管理平臺(tái)，產(chǎn)品的埋點(diǎn)需求在這個(gè)平臺(tái)與開(kāi)發(fā)對(duì)齊 ）上 按照埋點(diǎn)數(shù)據(jù)模板進(jìn)行開(kāi)發(fā)
• 開(kāi)發(fā)完成后，通過(guò)上報(bào) 日志對(duì)埋點(diǎn)進(jìn)行 人工驗(yàn)證
• 最后測(cè)試通過(guò)埋點(diǎn)數(shù)據(jù)展示平臺(tái)，通過(guò) 數(shù)據(jù)的回溯進(jìn)行埋點(diǎn)數(shù)據(jù)驗(yàn)證

開(kāi)發(fā)和驗(yàn)證階段是對(duì)埋點(diǎn)數(shù)據(jù)準(zhǔn)確性影響最大的兩個(gè)節(jié)點(diǎn)。從到家埋點(diǎn)落地以來(lái)，準(zhǔn)確性一直不高。目前的App端埋點(diǎn)系統(tǒng)已經(jīng)不足以支撐越來(lái)越復(fù)雜的業(yè)務(wù)需求，冗余埋點(diǎn)參數(shù)一直得不到有效的清理，埋點(diǎn)系統(tǒng)對(duì)業(yè)務(wù)的侵入性也越來(lái)越大，開(kāi)發(fā)過(guò)程中要寫(xiě)很多與業(yè)務(wù)無(wú)關(guān)的代碼來(lái)適配埋點(diǎn)的需求，清晰的模塊化結(jié)構(gòu)因此產(chǎn)生了不少的耦合。

對(duì)埋點(diǎn)鏈路的各個(gè)節(jié)點(diǎn)的痛點(diǎn)進(jìn)行了總結(jié)：

• 無(wú)效埋點(diǎn)數(shù)據(jù) ：露出上報(bào)并沒(méi)有反映真實(shí)用戶(hù)行為，由于精準(zhǔn)曝光規(guī)則的缺失，在頁(yè)面滑動(dòng)過(guò)程中，用戶(hù)沒(méi)看見(jiàn)的元素也被當(dāng)成曝光行為進(jìn)行上報(bào)，產(chǎn)生了大量 無(wú)效 埋點(diǎn)數(shù)據(jù)
• 曝光局限性 ：由于埋點(diǎn)規(guī)則不可調(diào)整的局限性，可視區(qū)域的規(guī)則區(qū)分粒度比較粗，所以導(dǎo)致埋點(diǎn)不準(zhǔn)確
• 開(kāi)發(fā)效率低 ：埋點(diǎn)需求占用了大量的開(kāi)發(fā)時(shí)間，同時(shí)埋點(diǎn)與業(yè)務(wù)模塊間耦合嚴(yán)重
• 準(zhǔn)確性不高 ：依靠人工驗(yàn)證埋點(diǎn)，很難對(duì)已上線(xiàn)的埋點(diǎn)進(jìn)行二次校驗(yàn)。而埋點(diǎn)的需求迭代又有可能影響到已有埋點(diǎn)，導(dǎo)致線(xiàn)上埋點(diǎn)數(shù)據(jù)使用的過(guò)程中，大約有10%的埋點(diǎn)數(shù)據(jù)不準(zhǔn)確，不能有效對(duì)產(chǎn)品需求進(jìn)行支撐

通過(guò)原鏈路各個(gè)節(jié)點(diǎn)的痛點(diǎn)分析，我們對(duì)需要解決的問(wèn)題進(jìn)行了合并和歸納，總結(jié)出來(lái)項(xiàng)目核心目標(biāo)。

核心目標(biāo)

到家精準(zhǔn)埋點(diǎn)系統(tǒng)旨在實(shí)現(xiàn)三個(gè)業(yè)務(wù)上的目標(biāo)：

• 統(tǒng)一 埋點(diǎn)規(guī)則 設(shè)計(jì) ，將埋點(diǎn)的各種行為進(jìn)行區(qū)分和細(xì)化。（埋點(diǎn)數(shù)據(jù)的業(yè)務(wù)定義，通過(guò)整理所有歷史的埋點(diǎn)，將不規(guī)則的埋點(diǎn)進(jìn)行優(yōu)化調(diào)整，以達(dá)到埋點(diǎn)規(guī)則的統(tǒng)一）
• 提升埋點(diǎn) 準(zhǔn)確率達(dá)到99% 以上
• 過(guò)濾埋點(diǎn)無(wú)效數(shù)據(jù)，更加精準(zhǔn)進(jìn)行上報(bào)，降低埋點(diǎn)數(shù)據(jù)成本（硬件成本和網(wǎng)絡(luò)成本）

技術(shù)實(shí)現(xiàn)將圍繞三個(gè)目標(biāo)：

• 降低 埋點(diǎn) 開(kāi)發(fā)成本
• 曝光規(guī)則可配置， 不同埋點(diǎn)規(guī)則靈活可變
• 埋點(diǎn)可以進(jìn)行 有效的機(jī)器校驗(yàn)以及可視化校驗(yàn)

2埋點(diǎn)系統(tǒng)架構(gòu)

埋點(diǎn)規(guī)則與新系統(tǒng)架構(gòu)設(shè)計(jì)

目前， App端埋點(diǎn) 采集策略分為 點(diǎn)擊、 頁(yè)面以及曝光埋點(diǎn)三種：

• 點(diǎn)擊埋點(diǎn)與業(yè)務(wù)耦合性最高，但是觸發(fā)條件以及使用上是最簡(jiǎn)單的一個(gè)，可優(yōu)化的地方并不多。
• 頁(yè)面埋點(diǎn)主要負(fù)責(zé)記錄頁(yè)面的生命周期，用以還原 頁(yè)面 使用的完整軌跡。功能實(shí)現(xiàn)由基礎(chǔ)模塊統(tǒng)一處理，這塊業(yè)務(wù)耦合性最低，對(duì)業(yè)務(wù)的侵入性也最低，在業(yè)務(wù)開(kāi)發(fā)的時(shí)候?qū)τ诖祟?lèi)埋點(diǎn)幾乎無(wú)感知。
• 曝光埋點(diǎn)則較為復(fù)雜，各種業(yè)務(wù)的埋點(diǎn)規(guī)則各不相同，有的重復(fù)露出不需要埋點(diǎn)上報(bào)，而有的重復(fù)露出就需要多次上報(bào)，對(duì)業(yè)務(wù)代碼的侵入較大，也是占用開(kāi)發(fā)時(shí)間最多的埋點(diǎn)種類(lèi)。

原先的曝光系統(tǒng)以控件的露出作為上報(bào)時(shí)機(jī)，以全局唯一標(biāo)識(shí)id對(duì)相同曝光埋點(diǎn)進(jìn)行聚合，當(dāng)App端收集滿(mǎn)十條，切頁(yè)或切后臺(tái)時(shí)，將收集的埋點(diǎn)文件上報(bào)，最終將數(shù)據(jù)上傳到埋點(diǎn)數(shù)據(jù)庫(kù)。由于對(duì)控件露出判斷以及各種埋點(diǎn)參數(shù)的傳遞，影響到正常業(yè)務(wù)模塊的邏輯實(shí)現(xiàn)，所以解決埋點(diǎn)露出判斷和埋點(diǎn)參數(shù)的傳遞就成為架構(gòu)設(shè)計(jì)中的重要考量。

如上圖所示，我們將整個(gè)埋點(diǎn)系統(tǒng)架構(gòu)拆分為了埋點(diǎn)適配層，埋點(diǎn)驗(yàn)證層，埋點(diǎn)服務(wù)層三個(gè)層級(jí)。

埋點(diǎn)適配層

埋點(diǎn)適配層（埋點(diǎn)上層服務(wù)層）主要用以消除不同應(yīng)用之間的差距， 針對(duì)不同業(yè)務(wù)進(jìn)行 參數(shù)的傳遞適配。結(jié)合客戶(hù)端自身業(yè)務(wù)，提供曝光、PV和Click的埋點(diǎn)服務(wù)協(xié)議聲明，不負(fù)責(zé)具體埋點(diǎn)服務(wù)的實(shí)現(xiàn)。

埋點(diǎn)驗(yàn)證層

埋點(diǎn)驗(yàn)證層與埋點(diǎn)需求平臺(tái)進(jìn)行聯(lián)動(dòng)，通過(guò)埋點(diǎn)需求平臺(tái)提供的埋點(diǎn)模板數(shù)據(jù)，與客戶(hù)端上傳的真實(shí)數(shù)據(jù)進(jìn)行數(shù)據(jù)正確性校驗(yàn)。實(shí)現(xiàn)方式上我們選擇以AOP形式切入，降低埋點(diǎn)驗(yàn)證與業(yè)務(wù)的影響，將驗(yàn)證與埋點(diǎn)系統(tǒng)隔離。

埋點(diǎn)服務(wù)層

埋點(diǎn)服務(wù)層（埋點(diǎn)底層服務(wù)層）包括精準(zhǔn)曝光系統(tǒng)、曝光聚合系統(tǒng)以及埋點(diǎn)數(shù)據(jù)文件上傳等服務(wù)功能。

精準(zhǔn)曝光系統(tǒng)將所需要的服務(wù)進(jìn)行封裝，接入App配置系統(tǒng)下發(fā)的曝光規(guī)則來(lái)進(jìn)行曝光規(guī)則的調(diào)整，然后通過(guò)埋點(diǎn)適配層的調(diào)用以及容器的傳入來(lái)監(jiān)聽(tīng)客戶(hù)端曝光容器（EPView）的曝光事件，觸發(fā)曝光埋點(diǎn)上傳，最終流向到家埋點(diǎn)數(shù)據(jù)庫(kù)，進(jìn)行數(shù)據(jù)歸檔。

3新精準(zhǔn)曝光系統(tǒng)

以曝光舉例，之前的埋點(diǎn)流程：

原先的曝光系統(tǒng)痛點(diǎn)：

• 開(kāi)發(fā)成本大，業(yè)務(wù)方需要編寫(xiě)大量的代碼來(lái)添加埋點(diǎn)，往往添加一個(gè)埋點(diǎn)成本就需要至少50行代碼，并且同一容器的不同埋點(diǎn)代碼中存在許多重復(fù)的代碼邏輯
• 精準(zhǔn)曝光的缺失，不支持對(duì)露出比例以及時(shí)長(zhǎng)的判斷
• 不支持對(duì)可見(jiàn)區(qū)域不同的判斷，如有的頁(yè)面帶導(dǎo)航欄，有的沒(méi)有導(dǎo)航欄，一律按照沒(méi)有導(dǎo)航欄處理， 埋點(diǎn)不夠精確
• 針對(duì)部分埋點(diǎn)計(jì)算沒(méi)有優(yōu)化，將傳入的所有追蹤實(shí)例遍歷計(jì)算， 計(jì)算效率低
• 不支持云端配置下發(fā)， 曝光規(guī)則單一

如果可以將大量的重復(fù)性的代碼收口統(tǒng)一管理，開(kāi)發(fā)只需要一行代碼搞定，那么埋點(diǎn)開(kāi)發(fā)測(cè)的效率就提高了許多。但是中間有比較多的問(wèn)題需要解決。App端控件容器種類(lèi)較多，想要收口統(tǒng)一管理，需要適配 不同類(lèi)型的容器控件 。原系統(tǒng)之所以沒(méi)能收口，就是因?yàn)闊o(wú)法在 黑盒的情況下適配 各種業(yè)務(wù)場(chǎng)景 。

新精準(zhǔn)曝光系統(tǒng)

新精準(zhǔn)曝光系統(tǒng)在原有的系統(tǒng)上進(jìn)行優(yōu)化，新增功能點(diǎn)支撐：

• 過(guò)濾掉業(yè)務(wù)端的重復(fù)添加曝光
• 將跟蹤加入的業(yè)務(wù)視圖滑動(dòng)/拖動(dòng)/動(dòng)畫(huà)/隱藏等，與UE相關(guān)行動(dòng)因子內(nèi)置進(jìn)曝光系統(tǒng)內(nèi)部
• 數(shù)據(jù)可配置，露出比例/時(shí)長(zhǎng)/云端配置等功能內(nèi)置
• 埋點(diǎn)聚合/文件寫(xiě)入/文件上傳

該系統(tǒng)最初的核心設(shè)計(jì)目標(biāo)就是將大量業(yè)務(wù)重復(fù)邏輯植入到系統(tǒng)內(nèi)部，針對(duì)不同的滑動(dòng)控件進(jìn)行匹配判斷，實(shí)現(xiàn)容器的自動(dòng)追蹤；針對(duì)不同的刷新模式，自動(dòng)進(jìn)行是否重復(fù)上報(bào)邏輯判斷；提供不同的接口以適應(yīng)不同業(yè)務(wù)；對(duì)容器的展開(kāi)和收起的自動(dòng)判斷等。

而將業(yè)務(wù)的大量代碼，通過(guò)無(wú)痕方式切入，存在許多需要攻克的 技術(shù)難點(diǎn) ：

• 滑動(dòng)控件并不是統(tǒng)一的，有滑動(dòng)的控件，也有非滑動(dòng)控件。如何適配并且無(wú)痕自動(dòng)追蹤滑動(dòng)/切頁(yè)而產(chǎn)生的控件露出事件？

我們的方案是針對(duì)不同的容器的種類(lèi)進(jìn)行判斷匹配，通過(guò)KVO的方式追蹤容器本身屬性的變化作為露出的觸發(fā)點(diǎn)，而計(jì)時(shí)器作為頁(yè)面無(wú)滑動(dòng)時(shí)的補(bǔ)充手段，從而達(dá)到無(wú)痕追蹤的效果。

• 作 為 黑 盒 系 統(tǒng) ， 需要追蹤所有埋點(diǎn)業(yè)務(wù)視圖的露出 事件， 所以要保存埋點(diǎn)業(yè)務(wù)視 圖與埋點(diǎn)行為的 對(duì)應(yīng)關(guān) 系 。 如何保證埋點(diǎn)業(yè)務(wù)視圖與埋點(diǎn)數(shù)據(jù)的對(duì)應(yīng)？

在前期系統(tǒng)適配模型中建立輸入口，通過(guò)傳入系統(tǒng)初始化模型，來(lái)進(jìn)行業(yè)務(wù)視圖埋點(diǎn)數(shù)據(jù)key的傳入。

• 為了避免造成控件生命周期混亂的問(wèn)題，如何管理對(duì)象強(qiáng)弱引用，保證內(nèi)部引用與外部生命周期一致？

通過(guò)對(duì)關(guān)系的梳理，確定從滑動(dòng)容器/滑動(dòng)容器模型 –> 事件模型的綁定關(guān)系，將內(nèi)部模型生命周期與外部視圖進(jìn)行綁定，來(lái)實(shí)現(xiàn)外部視圖銷(xiāo)毀后，事件追蹤模型也會(huì)銷(xiāo)毀。下面會(huì)進(jìn)行詳細(xì)展開(kāi)說(shuō)明。

• 曝光追蹤是否存在性能問(wèn)題？

在計(jì)算追蹤的時(shí)候，因?yàn)樾枰{(diào)用UIKit的frame進(jìn)行位置獲取，這一步必須在主線(xiàn)程完成，為了不影響性能，需要進(jìn)行計(jì)算量的優(yōu)化。為了盡量減少需要計(jì)算的數(shù)量，我們?cè)O(shè)計(jì)了兩層漏斗進(jìn)行過(guò)濾：第一層過(guò)濾是通過(guò)遞歸判斷容器及其父容器是否隱藏，排除掉不活躍的容器；第二層過(guò)濾是在活躍的容器中，排除掉其內(nèi)部不活躍的子容器。最后剩余的容器才進(jìn)行frame的計(jì)算，這樣每次滑動(dòng)的時(shí)候，計(jì)算量均值大約在10個(gè)左右，對(duì)性能影響降到最低。

上述技術(shù)難點(diǎn)的實(shí)現(xiàn)細(xì)節(jié)受限于篇幅不再一一展開(kāi)。下面列舉iOS端，來(lái)說(shuō)明如何通過(guò) 管理 引用機(jī)制來(lái) 解決 生命周期混亂的問(wèn)題 。

iOS端追蹤與引用機(jī)制

通過(guò)分析整體埋點(diǎn)機(jī)制可知， 埋點(diǎn)視圖(EPView) 存在從數(shù)據(jù)模型(Model)到埋點(diǎn)數(shù)據(jù) (EPModel) 的對(duì)應(yīng)關(guān)系，所以建立埋點(diǎn)控件到埋點(diǎn)數(shù)據(jù)的映射關(guān)系是可行的，順著這個(gè)切入點(diǎn)來(lái)進(jìn)行整個(gè)生命周期管理的設(shè)計(jì)。

新版埋點(diǎn)系統(tǒng)提供了兩種埋點(diǎn)追蹤方式：埋點(diǎn)視圖(EPView)或者埋點(diǎn)數(shù)據(jù)(EPModel)來(lái)與埋點(diǎn)行為進(jìn)行一一對(duì)應(yīng)，通過(guò)建立內(nèi)部EPView/EPModel → UUID → 埋點(diǎn)行為模型(TrackerObj)的映射對(duì)所有埋點(diǎn)狀態(tài)進(jìn)行追蹤。業(yè)務(wù)方將需要追蹤的容器傳入，通過(guò)容器類(lèi)型判斷進(jìn)行滑動(dòng)/拖動(dòng)/動(dòng)畫(huà)/隱藏等行為的監(jiān)聽(tīng)。

系統(tǒng)為了不影響外部生命周期，對(duì)外部引用重新做了梳理。

圖中綠色代表弱引用，紅線(xiàn)代表強(qiáng)引用。如圖所示，系統(tǒng)內(nèi)部使用兩個(gè)弱引用map表來(lái)儲(chǔ)存所需的信息，而每個(gè)子容器的滑動(dòng)容器則通過(guò)追蹤模型來(lái)追蹤。這樣建立起從EPView –> 追蹤模型 –> 滑動(dòng)容器的綁定關(guān)系。當(dāng)外部業(yè)務(wù)視圖(EPView)或者業(yè)務(wù)模型(EPModel)被釋放的時(shí)候，業(yè)務(wù)不需要回調(diào)曝光系統(tǒng)進(jìn)行相應(yīng)的銷(xiāo)毀，該鍵值會(huì)被自動(dòng)釋放，這樣極大地縮減了接入的成本。

對(duì)外收口的部分，通過(guò)精準(zhǔn)曝光埋點(diǎn)提供的API 來(lái)明確埋點(diǎn)追蹤的綁定關(guān)系 ：

/// 添加ep進(jìn)入追蹤 需要傳入該資源位唯一識(shí)別碼
/// 適用場(chǎng)景：刷新之后，刷了模型，但是資源位沒(méi)變化，不需要重新報(bào)的場(chǎng)景
/// @param epView 需要追蹤的epView
/// @param epUID epUID為該資源位唯一識(shí)別碼，只要這個(gè)碼不變，并且在屏幕內(nèi)，即使多次添加不會(huì)再次回調(diào)
/// @param userAction 與此epview綁定的數(shù)據(jù)model的userAction
/// @param containers 底部需要追蹤的滾動(dòng)容器
/// @param visibleRect 需要曝光的可視區(qū)域 坐標(biāo)系相對(duì)于UIWindow
/// @param callback 埋點(diǎn)回調(diào)，此處需要手動(dòng)去處理數(shù)據(jù)拼接以及埋點(diǎn)
- (void)addEPView:(UIView *)epView
       epUniqueID:(NSString *)epUID
       userAction:(NSString *)userAction
       containers:(NSArray<UIView *> *)containers
      visibleRect:(CGRect)visibleRect
  epEventCallback:(void (^)(UIView * _Nonnull epView))callback;

/// 添加ep進(jìn)入追蹤 需要傳入數(shù)據(jù)Model
/// 適用場(chǎng)景：刷新之后，模型發(fā)生了改變并且需要重新曝光的場(chǎng)景
/// @param epView 需要追蹤的epView
/// @param model 與此epview綁定的數(shù)據(jù)model，模型一旦發(fā)生改變（對(duì)同一個(gè)資源位來(lái)說(shuō)模型地址發(fā)生變化），則會(huì)再次觸發(fā)回調(diào)
/// @param userAction 與此epview綁定的數(shù)據(jù)model的userAction
/// @param containers 底部需要追蹤的滾動(dòng)容器
/// @param visibleRect 需要曝光的可視區(qū)域 坐標(biāo)系相對(duì)于UIWindow
/// @param callback 埋點(diǎn)回調(diào)，此處需要手動(dòng)去處理數(shù)據(jù)拼接以及埋點(diǎn)
- (void)addEPView:(UIView *)epView
            model:(NSObject *)model
       userAction:(NSString *)userAction
       containers:(NSArray<UIView *> *)containers
      visibleRect:(CGRect)visibleRect
 epEventCallback:(void (^)(UIView * _Nonnull epView))callback;

i OS使用系統(tǒng)的KVO機(jī)制， 輔助針對(duì)視圖的動(dòng)畫(huà)/隱藏等監(jiān)聽(tīng)來(lái)實(shí)現(xiàn)。 系統(tǒng)KVO機(jī)制雖然好用，但是存在一個(gè)致命的缺陷，就是監(jiān)聽(tīng)實(shí)體釋放的時(shí)候，需要監(jiān)聽(tīng)者手動(dòng)釋放，不然就會(huì)導(dǎo)致崩潰。而代理KVO機(jī)制則很好地 解決了這個(gè)問(wèn)題，使用代理代替原先的監(jiān)聽(tīng)者進(jìn)行監(jiān)聽(tīng)，而代理者與被監(jiān)聽(tīng)的控件生命周期保持一致。 這樣便 無(wú)需主動(dòng)解除監(jiān)聽(tīng)， 彌補(bǔ)了被監(jiān)聽(tīng)的實(shí)體釋放而無(wú)法通知監(jiān)聽(tīng)實(shí)體釋放問(wèn)題。

業(yè)務(wù)方傳入的無(wú)論是 業(yè)務(wù)視圖(EPView)或者業(yè)務(wù)模型(EPModel)，都采取統(tǒng)一轉(zhuǎn)換為UUID的形式 ，保證了KV鍵值的統(tǒng)一，提升排查問(wèn)題的便捷性。

接口層上，區(qū)分了曝光的追蹤服務(wù)、曝光節(jié)點(diǎn)的回調(diào)服務(wù)以及底層上報(bào)服務(wù)三個(gè)接口，分別由三個(gè)不同的實(shí)例實(shí)現(xiàn)，保證不同業(yè)務(wù)服務(wù)之間的隔離。

針對(duì)曝光埋點(diǎn)設(shè)計(jì)了兩個(gè)追蹤的節(jié)點(diǎn)，目的是判斷是否需要上報(bào)曝光埋點(diǎn)：

• 第一個(gè)是每0.5秒鐘觸發(fā)定時(shí)timer，此timer會(huì)輪詢(xún)所有的已添加進(jìn)來(lái)的需要曝光的視圖進(jìn)行計(jì)算
• 第二個(gè)是追蹤節(jié)點(diǎn)為容器滑動(dòng)回調(diào)（KVO機(jī)制實(shí)現(xiàn)），此回調(diào)僅會(huì)將滑動(dòng)容器所綁定的EPView進(jìn)行計(jì)算

在節(jié)點(diǎn)觸發(fā)的時(shí)候，會(huì)從兩個(gè)EPMap中直接獲取所需數(shù)據(jù)，不需要額外的過(guò)濾操作，降低了計(jì)算的次數(shù)，提高整體計(jì)算效率。

4 埋點(diǎn)驗(yàn)證可視化

業(yè)務(wù)側(cè)痛點(diǎn)收集和分析

• 埋點(diǎn)測(cè)試效率 較低 ：一次滑動(dòng)產(chǎn)生大量埋點(diǎn)數(shù)據(jù)。之前的驗(yàn)證方式是通過(guò)打日志方式、抓包或者數(shù)據(jù)展示平臺(tái)直接查看來(lái)進(jìn)行驗(yàn)證，數(shù)據(jù)無(wú)直觀關(guān)聯(lián)，需要人眼主動(dòng)進(jìn)行關(guān)聯(lián)，驗(yàn)證效率非常低
• 多次上報(bào)的曝光次數(shù)驗(yàn)證困難：有很多其他數(shù)據(jù)干擾，直接抓包或者數(shù)據(jù)展示平臺(tái)無(wú)法區(qū)分不同的session，只能通過(guò)時(shí)間節(jié)點(diǎn)方式進(jìn)行人工關(guān)聯(lián)，容易出錯(cuò)
• 相關(guān)數(shù)據(jù)難以查找：在數(shù)據(jù)展示平臺(tái)上只提供了一級(jí)信息的搜索，沒(méi)辦法更加詳細(xì)的相關(guān)信息的篩選

技術(shù)側(cè)痛點(diǎn)

1. 缺乏驗(yàn)測(cè)模型數(shù)據(jù)：要做數(shù)據(jù)驗(yàn)證，沒(méi)有相關(guān)的數(shù)據(jù)模型進(jìn)行支撐，無(wú)法對(duì)本次埋點(diǎn)結(jié)果進(jìn)行自動(dòng)化的機(jī)器校驗(yàn)
2. 很難做數(shù)據(jù)掛鉤：通過(guò)AOP切面方式接入埋點(diǎn)驗(yàn)證，最大化不干擾業(yè)務(wù)端，帶來(lái)的弊端就是很難做數(shù)據(jù)掛鉤，捕捉到的埋點(diǎn)視圖也很難與埋點(diǎn)數(shù)據(jù)進(jìn)行匹配識(shí)別。 數(shù)據(jù)平臺(tái)上的數(shù)據(jù)密集且難尋，用肉眼驗(yàn)證相當(dāng)復(fù)雜 且容易出錯(cuò)

埋點(diǎn)驗(yàn)證功能設(shè)計(jì)

埋點(diǎn)驗(yàn)證主要包含以下功能點(diǎn)：

1. 曝光埋點(diǎn)狀態(tài)、數(shù)據(jù)以及上報(bào)次數(shù)可視化驗(yàn)證
2. 埋點(diǎn)數(shù)據(jù)列表展示以及埋點(diǎn)搜索篩選
3. 天河模板下發(fā)以及數(shù)據(jù)自動(dòng)校驗(yàn) 曝光埋點(diǎn)狀態(tài)、數(shù)據(jù)以及上報(bào)次數(shù)可視化驗(yàn)證

為了盡可能追蹤埋點(diǎn)狀態(tài)，根據(jù)曝光埋點(diǎn)鏈條的不同節(jié)點(diǎn)，將曝光埋點(diǎn)行為狀態(tài)化分拆成三種狀態(tài)：

• 追蹤中【紅色】：埋點(diǎn)已經(jīng)添加進(jìn)來(lái)，還未判斷為露出狀態(tài)
• 控件露出【黃色】：控件根據(jù)精準(zhǔn)曝光條件判斷為露出，但未上報(bào)狀態(tài)
• 已上報(bào)【綠色】：曝光時(shí)長(zhǎng)滿(mǎn)足延遲時(shí)間，已經(jīng)回調(diào)并且上報(bào)

在業(yè)務(wù)端這三種狀態(tài)以不同顏色來(lái)表示，通過(guò)給埋點(diǎn)控件染色，以達(dá)到狀態(tài)可視化效果。驗(yàn)測(cè)的時(shí)候， 只需要判斷顏色的變化是否符合預(yù)期，則可以判定埋點(diǎn)節(jié)點(diǎn)的準(zhǔn)確性 。

通過(guò)對(duì)控件的上報(bào)埋點(diǎn)回溯綁定當(dāng)前控件的埋點(diǎn)數(shù)據(jù)，可以實(shí)現(xiàn)使用過(guò)程中， 長(zhǎng)按控件即顯示該控件目前的埋點(diǎn)數(shù)據(jù) 。這樣快速追蹤控件的埋點(diǎn)數(shù)據(jù)，極大地縮短在海量數(shù)據(jù)中尋找控件數(shù)據(jù)的時(shí)間。并且 在控件最上層添加信息label，展示當(dāng)前已經(jīng)上報(bào)過(guò)埋點(diǎn)的次數(shù)，方便進(jìn)行上報(bào)次數(shù)的正確性校驗(yàn) 。

埋點(diǎn)可視化驗(yàn)證

埋點(diǎn)數(shù)據(jù)列表展示以及埋點(diǎn)搜索篩選

開(kāi)發(fā)過(guò)程中，上報(bào)的埋點(diǎn)數(shù)據(jù)列表，以時(shí)間為單位進(jìn)行排序，并且提供搜索功能。搜索的加入能夠方便進(jìn)行埋點(diǎn)數(shù)據(jù)的歸類(lèi)查找。而篩選功能可以方便驗(yàn)測(cè)人員直接進(jìn)行埋點(diǎn)日志的過(guò)濾。

App端內(nèi)部埋點(diǎn)日志展示與篩選查詢(xún)

天河模板下發(fā)以及數(shù)據(jù)自動(dòng)校驗(yàn)

前端系統(tǒng)與天河系統(tǒng)打通，通過(guò)下載天河系統(tǒng)的數(shù)據(jù)模板和上報(bào)數(shù)據(jù)進(jìn)行比對(duì)，提前發(fā)現(xiàn)埋點(diǎn)問(wèn)題。App端拿到天河系統(tǒng)提供的Key值進(jìn)行校驗(yàn)，最終驗(yàn)證該埋點(diǎn)數(shù)據(jù)的準(zhǔn)確性，如果key值缺失，進(jìn)行toast提示提醒，這樣在開(kāi)發(fā)驗(yàn)測(cè)階段就可以輕易發(fā)現(xiàn)有問(wèn)題的埋點(diǎn)。

5成果與展望

業(yè)務(wù)滲透

目前在App端，已完成 80% 相關(guān)頁(yè)面的切換

成本節(jié)約

統(tǒng)計(jì)近5期的版本，清理 15.08% 的冗余埋點(diǎn)數(shù)據(jù)，節(jié)約了成本

埋點(diǎn)準(zhǔn)確率提升

準(zhǔn)確率從原先的90%提升至 98%

開(kāi)發(fā)提效

代碼行數(shù)極大得縮減，從原先的平均50行到1行，代碼縮減比例達(dá)到98%。從而將3天/期/人的埋點(diǎn)開(kāi)發(fā)時(shí)間縮短至 0.5天/期/人 的埋點(diǎn)開(kāi)發(fā)時(shí)間。目前到家3個(gè)ToC端App已經(jīng)全面接入使用，針對(duì)不同app環(huán)境均作了適配，實(shí)現(xiàn) 系統(tǒng)的復(fù)用 。

驗(yàn)測(cè)提效

驗(yàn)測(cè)時(shí)間縮短了60%，效率 提升了兩倍 以上

展望

到家新版埋點(diǎn)系統(tǒng)已經(jīng)穩(wěn)定運(yùn)作多版本，目前已經(jīng)初步達(dá)到技術(shù)側(cè)以及業(yè)務(wù)側(cè)定的目標(biāo)。當(dāng)然，在埋點(diǎn)鏈路的優(yōu)化建設(shè)上還有許多不足的地方，如：

• 埋點(diǎn)實(shí)踐只在App端進(jìn)行了落地，而針對(duì)H5、RN的兩端的落地，現(xiàn)在還在改造中，很快就會(huì)實(shí)現(xiàn)三端的對(duì)齊
• 結(jié)合已有能力進(jìn)行拓寬，借助數(shù)據(jù)模型到數(shù)據(jù)下發(fā)的閉環(huán)，提升至100%的埋點(diǎn)準(zhǔn)確率
• 在效率方面，針對(duì)標(biāo)準(zhǔn)化后的埋點(diǎn)進(jìn)行基類(lèi)統(tǒng)一處理的方案，將最后的一行代碼也優(yōu)化掉

到家App團(tuán)隊(duì)接下來(lái)會(huì)在這幾個(gè)方面繼續(xù)深耕，探索并落地更加完善的埋點(diǎn)系統(tǒng)實(shí)踐。

作者:盧葦白

來(lái)源:微信公眾號(hào):達(dá)達(dá)集團(tuán)技術(shù)

出處:https://mp.weixin.qq.com/s?__biz=MzAwMzg1ODMwNw==&mid=2653796170&idx=1&sn=f1efb5623ec6a236f393df32a1c29975