一、概述
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.方案衡量
在初期，我們擬定了遷移方案一，但是考慮到遷移成本巨大，我們綜合評估後，制定了方案二，基於遷移成本最小化等綜合考慮，我們選取了方案一
| 方案詳情 | 工作量 | |
|---|---|---|
| 方案一 | APP、小程式、PC&H5各業務線分別進行改造和遷移 | 需做43個站點應用的SDK層適配 |
| 方案二 | 1）APP進行SDK封裝，其他業務線只需接入即可 2）PC&H5在SDK層適配，其他35個應用方只需接入即可 | 需做3個SDK層適配，其他業務線接入即可 |
三、專案實現
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數量限制
作者：京東零售 周慧嫻
來源：京東雲開發者社群 轉載請註明來源