一、概述
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数量限制
作者：京东零售周慧娴
来源：京东云开发者社区 转载请注明来源
服务器托管，北京服务器托管，服务器租服务器托管网用 http://www.fwqtg.net
