一、概述

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數量限制

作者：京東零售 周慧嫻

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