一、概述

1.項目價值及成果

使用集團的統一埋點採集能力和埋點平臺，完成達達7條業務線共43個站點應用的埋點遷移，降低自研採集工具和平臺的研發投入和機器成本，打通數據鏈路，創造更多的數據分析價值。具體降本增效價值如下：

1.1 數據分析價值：與京東流量數據打通，拉齊數據口徑，流量串聯

1）信息孤島：快送與京東流量數據分離，庫表訪問成本高，也無法進行結合分析

2）數據口徑：埋點規範對齊：比如廣告位曝光、頁面瀏覽等埋點上報規則，與京東的邏輯對齊，拉齊數據口徑，提高準確度

3）用戶信息串聯：可以通過用戶基礎信息的串聯，比如device_id，用戶pin/supplier_id等，分析用戶從京東入口進入的流量鏈路、以及進入京東流量的訪問深度等等

1.2 減少迭代/維護人力成本：0.5人/年

1）天河平臺迭代成本

2）流量傳輸鏈路運維成本

1.3 節省機器/中間件費用：2w+每年

1）減少2台雲主機+估計2萬左右/年中間件費用

2.項目節奏

二、方案調研選型

1.方案衡量

在初期，我們擬定了遷移方案一，但是考慮到遷移成本巨大，我們綜合評估後，制定了方案二，基於遷移成本最小化等綜合考慮，我們選取了方案一

三、項目實現

1.上下游遷移流程

2.遷移技術架構

在接入項目之前，我們需要考慮兩點

穩定：一方面項目需要整體平穩運行，另一方面也遷移前後數據差異保持在合理的誤差範圍內

高效：本次遷移涉及客戶端、小程式、h5等數十個項目，節約開發成本也是關鍵

（1）方案選擇

1、直接替換：由於項目眾多，再加上每個項目中點位也很多，顯然我們不能直接替換業務中的埋點，工作量太大，出問題的風險也會更高

2、切麵替換：在埋點上報的某個環節中統一替換，這樣好處是只需要修改一次，代碼侵入性小，風險也可控，最重要的是工作量大大降低了

（2）方案設計

以客戶端為例，舊的埋點框架包含埋點採集、存儲、上報三個過程，並且是彼此獨立的，我們很容易的就可以在埋點採集到存儲過程之間進行切麵攔截，將原本的埋點數據進行轉換，如下圖

舊框架架構圖

（3）方案實施

在確定具體方案後，我們開始規划具體代碼實現，考慮到需要替換的項目眾多（以客戶端為例，有達達騎士、 達達快送、洪流、孔明等項目），每個項目都去實現一遍無疑是有資源的浪費，我們把項目按端分成Android、ios、小程式、h5, 這樣原本數十個項目，簡化成一套方案，四端代碼，各項目只需要簡單的集成即可，這樣節約了大量的人力資源

3.技術亮點

1、採用切麵攔截遷移方案節約人力成本

2、統一封裝與多端復用將埋點規範統一

3、數倉層：從京東實時topic直接消費落庫，在庫表層做京東和達達的數據結構相容，達到下游報表層“無感知遷移”，將業務報表的影響和下游遷移成本最小化

4.踩過的坑

1、ios不支持後臺上報埋點

問題：騎士和商家存在app退出前臺，處於後臺模式狀態時候上報埋點的情況，但是子午線最開始不支持長時間後臺上報埋點。

解決：子午線添加配置，支持不限時支持後臺上報埋點功能。

2、ios網路問題

問題：首次安裝app，在用戶沒有同意網路許可權的情況下，子午線sdk會上報dau埋點，上報失敗後重試3次再次失敗觸發2分鐘限制，2分鐘內不會在上報埋點。

解決：子午線單獨提供無2分鐘限制的包。

3、APP上報策略問題

問題：子午線預設上報策略為15s10條，導致部分用戶沒有觸發上報條件退出app後無法上報已有埋點情況。

解決：子午線更新配置為2s2條。

4、uid為空導致埋點不落表

問題：新用戶在未同意隱私協議前，不會獲取用戶的設備信息，導致appUniqueID傳空，不會落入子午線離線表。

解決：在新用戶在未同意隱私協議前，隨機生成一段字元串並加密，作為設備id傳給子午線，保證所有埋點都能落表。

5、小程式上報機制問題

問題：小程式達達sdk批量上報，子午線sdk是單條上報，會產生數據差異

解決：子午線sdk已支持批量上報

6、H5埋點量級過大時被丟棄

問題：洪流應用中，session_id大於10000次後數據會被子午線離線表丟棄

解決：同城數倉直接從實時topic消費數據，落離線表，不加session_id數量限制

作者：京東零售 周慧嫻

來源：京東雲開發者社區 轉載請註明來源