京东到家App端精准埋点实践

目录

1. 背景与目标
2. 埋点系统架构
3. 新精准曝光系统
4. 埋点验证可视化
5. 成果与展望

1 背景与目标

如图所示，京东到家埋点的研发链路可以大致分为四步：

• 首先是在埋点需求平台进行埋点需求的收集

• 然后在需求平台（天河系统：基于web前端的到家埋点需求管理平台，产品的埋点需求在这个平台与开发对齐）上按照埋点数据模板进行开发

• 开发完成后，通过上报日志对埋点进行人工验证

• 最后测试通过埋点数据展示平台，通过数据的回溯进行埋点数据验证

开发和验证阶段是对埋点数据准确性影响最大的两个节点。从到家埋点落地以来，准确性一直不高。目前的App端埋点系统已经不足以支撑越来越复杂的业务需求，冗余埋点参数一直得不到有效的清理，埋点系统对业务的侵入性也越来越大，开发过程中要写很多与业务无关的代码来适配埋点的需求，清晰的模块化结构因此产生了不少的耦合。

对埋点链路的各个节点的痛点进行了总结：

• 无效埋点数据：露出上报并没有反映真实用户行为，由于精准曝光规则的缺失，在页面滑动过程中，用户没看见的元素也被当成曝光行为进行上报，产生了大量无效埋点数据
• 曝光局限性：由于埋点规则不可调整的局限性，可视区域的规则区分粒度比较粗，所以导致埋点不准确
• 开发效率低：埋点需求占用了大量的开发时间，同时埋点与业务模块间耦合严重
• 准确性不高：依靠人工验证埋点，很难对已上线的埋点进行二次校验。而埋点的需求迭代又有可能影响到已有埋点，导致线上埋点数据使用的过程中，大约有10%的埋点数据不准确，不能有效对产品需求进行支撑

通过原链路各个节点的痛点分析，我们对需要解决的问题进行了合并和归纳，总结出来项目核心目标。

核心目标

到家精准埋点系统旨在实现三个业务上的目标：

• 统一埋点规则设计，将埋点的各种行为进行区分和细化。（埋点数据的业务定义，通过整理所有历史的埋点，将不规则的埋点进行优化调整，以达到埋点规则的统一）
• 提升埋点准确率达到99%以上
• 过滤埋点无效数据，更加精准进行上报，降低埋点数据成本（硬件成本和网络成本）

技术实现将围绕三个目标：

• 降低埋点开发成本
• 曝光规则可配置，不同埋点规则灵活可变
• 埋点可以进行有效的机器校验以及可视化校验

2 埋点系统架构

埋点规则与新系统架构设计

目前，App端埋点采集策略分为点击、页面以及曝光埋点三种：

• 点击埋点与业务耦合性最高，但是触发条件以及使用上是最简单的一个，可优化的地方并不多。

• 页面埋点主要负责记录页面的生命周期，用以还原页面使用的完整轨迹。功能实现由基础模块统一处理，这块业务耦合性最低，对业务的侵入性也最低，在业务开发的时候对于此类埋点几乎无感知。

• 曝光埋点则较为复杂，各种业务的埋点规则各不相同，有的重复露出不需要埋点上报，而有的重复露出就需要多次上报，对业务代码的侵入较大，也是占用开发时间最多的埋点种类。

原先的曝光系统以控件的露出作为上报时机，以全局唯一标识id对相同曝光埋点进行聚合，当App端收集满十条，切页或切后台时，将收集的埋点文件上报，最终将数据上传到埋点数据库。由于对控件露出判断以及各种埋点参数的传递，影响到正常业务模块的逻辑实现，所以解决埋点露出判断和埋点参数的传递就成为架构设计中的重要考量。

如上图所示，我们将整个埋点系统架构拆分为了埋点适配层，埋点验证层，埋点服务层三个层级。

埋点适配层

埋点适配层（埋点上层服务层）主要用以消除不同应用之间的差距，针对不同业务进行参数的传递适配。结合客户端自身业务，提供曝光、PV和Click的埋点服务协议声明，不负责具体埋点服务的实现。

埋点验证层

埋点验证层与埋点需求平台进行联动，通过埋点需求平台提供的埋点模板数据，与客户端上传的真实数据进行数据正确性校验。实现方式上我们选择以AOP形式切入，降低埋点验证与业务的影响，将验证与埋点系统隔离。

埋点服务层

埋点服务层（埋点底层服务层）包括精准曝光系统、曝光聚合系统以及埋点数据文件上传等服务功能。

精准曝光系统将所需要的服务进行封装，接入App配置系统下发的曝光规则来进行曝光规则的调整，然后通过埋点适配层的调用以及容器的传入来监听客户端曝光容器（EPView）的曝光事件，触发曝光埋点上传，最终流向到家埋点数据库，进行数据归档。

3 新精准曝光系统

以曝光举例，之前的埋点流程：

原先的曝光系统痛点：

• 开发成本大，业务方需要编写大量的代码来添加埋点，往往添加一个埋点成本就需要至少50行代码，并且同一容器的不同埋点代码中存在许多重复的代码逻辑
• 精准曝光的缺失，不支持对露出比例以及时长的判断
• 不支持对可见区域不同的判断，如有的页面带导航栏，有的没有导航栏，一律按照没有导航栏处理，埋点不够精确
• 针对部分埋点计算没有优化，将传入的所有追踪实例遍历计算，计算效率低
• 不支持云端配置下发，曝光规则单一

如果可以将大量的重复性的代码收口统一管理，开发只需要一行代码搞定，那么埋点开发测的效率就提高了许多。但是中间有比较多的问题需要解决。App端控件容器种类较多，想要收口统一管理，需要适配不同类型的容器控件。原系统之所以没能收口，就是因为无法在黑盒的情况下适配各种业务场景。

新精准曝光系统

新精准曝光系统在原有的系统上进行优化，新增功能点支撑：

• 过滤掉业务端的重复添加曝光
• 将跟踪加入的业务视图滑动/拖动/动画/隐藏等，与UE相关行动因子内置进曝光系统内部
• 数据可配置，露出比例/时长/云端配置等功能内置
• 埋点聚合/文件写入/文件上传

该系统最初的核心设计目标就是将大量业务重复逻辑植入到系统内部，针对不同的滑动控件进行匹配判断，实现容器的自动追踪；针对不同的刷新模式，自动进行是否重复上报逻辑判断；提供不同的接口以适应不同业务；对容器的展开和收起的自动判断等。

而将业务的大量代码，通过无痕方式切入，存在许多需要攻克的技术难点：

• 滑动控件并不是统一的，有滑动的控件，也有非滑动控件。如何适配并且无痕自动追踪滑动/切页而产生的控件露出事件？

我们的方案是针对不同的容器的种类进行判断匹配，通过KVO的方式追踪容器本身属性的变化作为露出的触发点，而计时器作为页面无滑动时的补充手段，从而达到无痕追踪的效果。

• 作为黑盒系统，需要追踪所有埋点业务视图的露出事件，所以要保存埋点业务视图与埋点行为的对应关系。如何保证埋点业务视图与埋点数据的对应？

在前期系统适配模型中建立输入口，通过传入系统初始化模型，来进行业务视图埋点数据key的传入。

• 为了避免造成控件生命周期混乱的问题，如何管理对象强弱引用，保证内部引用与外部生命周期一致？

通过对关系的梳理，确定从滑动容器/滑动容器模型 --> 事件模型的绑定关系，将内部模型生命周期与外部视图进行绑定，来实现外部视图销毁后，事件追踪模型也会销毁。下面会进行详细展开说明。

• 曝光追踪是否存在性能问题？

在计算追踪的时候，因为需要调用UIKit的frame进行位置获取，这一步必须在主线程完成，为了不影响性能，需要进行计算量的优化。为了尽量减少需要计算的数量，我们设计了两层漏斗进行过滤：第一层过滤是通过递归判断容器及其父容器是否隐藏，排除掉不活跃的容器；第二层过滤是在活跃的容器中，排除掉其内部不活跃的子容器。最后剩余的容器才进行frame的计算，这样每次滑动的时候，计算量均值大约在10个左右，对性能影响降到最低。

上述技术难点的实现细节受限于篇幅不再一一展开。下面列举iOS端，来说明如何通过管理引用机制来解决生命周期混乱的问题。

iOS端追踪与引用机制

通过分析整体埋点机制可知，埋点视图(EPView)存在从数据模型(Model)到埋点数据(EPModel)的对应关系，所以建立埋点控件到埋点数据的映射关系是可行的，顺着这个切入点来进行整个生命周期管理的设计。

新版埋点系统提供了两种埋点追踪方式：埋点视图(EPView)或者埋点数据(EPModel)来与埋点行为进行一一对应，通过建立内部EPView/EPModel → UUID → 埋点行为模型(TrackerObj)的映射对所有埋点状态进行追踪。业务方将需要追踪的容器传入，通过容器类型判断进行滑动/拖动/动画/隐藏等行为的监听。

系统为了不影响外部生命周期，对外部引用重新做了梳理。

图中绿色代表弱引用，红线代表强引用。如图所示，系统内部使用两个弱引用map表来储存所需的信息，而每个子容器的滑动容器则通过追踪模型来追踪。这样建立起从EPView --> 追踪模型 --> 滑动容器的绑定关系。当外部业务视图(EPView)或者业务模型(EPModel)被释放的时候，业务不需要回调曝光系统进行相应的销毁，该键值会被自动释放，这样极大地缩减了接入的成本。

对外收口的部分，通过精准曝光埋点提供的API来明确埋点追踪的绑定关系：

/// 添加ep进入追踪 需要传入该资源位唯一识别码
/// 适用场景：刷新之后，刷了模型，但是资源位没变化，不需要重新报的场景
/// @param epView 需要追踪的epView
/// @param epUID epUID为该资源位唯一识别码，只要这个码不变，并且在屏幕内，即使多次添加不会再次回调
/// @param userAction 与此epview绑定的数据model的userAction
/// @param containers 底部需要追踪的滚动容器
/// @param visibleRect 需要曝光的可视区域 坐标系相对于UIWindow
/// @param callback 埋点回调，此处需要手动去处理数据拼接以及埋点
- (void)addEPView:(UIView *)epView
       epUniqueID:(NSString *)epUID
       userAction:(NSString *)userAction
       containers:(NSArray<UIView *> *)containers
      visibleRect:(CGRect)visibleRect
  epEventCallback:(void (^)(UIView * _Nonnull epView))callback;

/// 添加ep进入追踪 需要传入数据Model
/// 适用场景：刷新之后，模型发生了改变并且需要重新曝光的场景
/// @param epView 需要追踪的epView
/// @param model 与此epview绑定的数据model，模型一旦发生改变（对同一个资源位来说模型地址发生变化），则会再次触发回调
/// @param userAction 与此epview绑定的数据model的userAction
/// @param containers 底部需要追踪的滚动容器
/// @param visibleRect 需要曝光的可视区域 坐标系相对于UIWindow
/// @param callback 埋点回调，此处需要手动去处理数据拼接以及埋点
- (void)addEPView:(UIView *)epView
            model:(NSObject *)model
       userAction:(NSString *)userAction
       containers:(NSArray<UIView *> *)containers
      visibleRect:(CGRect)visibleRect
 epEventCallback:(void (^)(UIView * _Nonnull epView))callback;

iOS使用系统的KVO机制，辅助针对视图的动画/隐藏等监听来实现。系统KVO机制虽然好用，但是存在一个致命的缺陷，就是监听实体释放的时候，需要监听者手动释放，不然就会导致崩溃。而代理KVO机制则很好地解决了这个问题，使用代理代替原先的监听者进行监听，而代理者与被监听的控件生命周期保持一致。这样便无需主动解除监听，弥补了被监听的实体释放而无法通知监听实体释放问题。

业务方传入的无论是业务视图(EPView)或者业务模型(EPModel)，都采取统一转换为UUID的形式，保证了KV键值的统一，提升排查问题的便捷性。

接口层上，区分了曝光的追踪服务、曝光节点的回调服务以及底层上报服务三个接口，分别由三个不同的实例实现，保证不同业务服务之间的隔离。

针对曝光埋点设计了两个追踪的节点，目的是判断是否需要上报曝光埋点：

• 第一个是每0.5秒钟触发定时timer，此timer会轮询所有的已添加进来的需要曝光的视图进行计算
• 第二个是追踪节点为容器滑动回调（KVO机制实现），此回调仅会将滑动容器所绑定的EPView进行计算

在节点触发的时候，会从两个EPMap中直接获取所需数据，不需要额外的过滤操作，降低了计算的次数，提高整体计算效率。

4 埋点验证可视化

业务侧痛点收集和分析

• 埋点测试效率较低：一次滑动产生大量埋点数据。之前的验证方式是通过打日志方式、抓包或者数据展示平台直接查看来进行验证，数据无直观关联，需要人眼主动进行关联，验证效率非常低
• 多次上报的曝光次数验证困难：有很多其他数据干扰，直接抓包或者数据展示平台无法区分不同的session，只能通过时间节点方式进行人工关联，容易出错
• 相关数据难以查找：在数据展示平台上只提供了一级信息的搜索，没办法更加详细的相关信息的筛选

技术侧痛点

1. 缺乏验测模型数据：要做数据验证，没有相关的数据模型进行支撑，无法对本次埋点结果进行自动化的机器校验
2. 很难做数据挂钩：通过AOP切面方式接入埋点验证，最大化不干扰业务端，带来的弊端就是很难做数据挂钩，捕捉到的埋点视图也很难与埋点数据进行匹配识别。数据平台上的数据密集且难寻，用肉眼验证相当复杂且容易出错

埋点验证功能设计

埋点验证主要包含以下功能点：

1. 曝光埋点状态、数据以及上报次数可视化验证
2. 埋点数据列表展示以及埋点搜索筛选
3. 天河模板下发以及数据自动校验 曝光埋点状态、数据以及上报次数可视化验证

为了尽可能追踪埋点状态，根据曝光埋点链条的不同节点，将曝光埋点行为状态化分拆成三种状态：

• 追踪中【红色】：埋点已经添加进来，还未判断为露出状态
• 控件露出【黄色】：控件根据精准曝光条件判断为露出，但未上报状态
• 已上报【绿色】：曝光时长满足延迟时间，已经回调并且上报

在业务端这三种状态以不同颜色来表示，通过给埋点控件染色，以达到状态可视化效果。验测的时候，只需要判断颜色的变化是否符合预期，则可以判定埋点节点的准确性。

通过对控件的上报埋点回溯绑定当前控件的埋点数据，可以实现使用过程中，长按控件即显示该控件目前的埋点数据。这样快速追踪控件的埋点数据，极大地缩短在海量数据中寻找控件数据的时间。并且在控件最上层添加信息label，展示当前已经上报过埋点的次数，方便进行上报次数的正确性校验。

埋点可视化验证

埋点数据列表展示以及埋点搜索筛选

开发过程中，上报的埋点数据列表，以时间为单位进行排序，并且提供搜索功能。搜索的加入能够方便进行埋点数据的归类查找。而筛选功能可以方便验测人员直接进行埋点日志的过滤。

App端内部埋点日志展示与筛选查询

天河模板下发以及数据自动校验

前端系统与天河系统打通，通过下载天河系统的数据模板和上报数据进行比对，提前发现埋点问题。App端拿到天河系统提供的Key值进行校验，最终验证该埋点数据的准确性，如果key值缺失，进行toast提示提醒，这样在开发验测阶段就可以轻易发现有问题的埋点。

5 成果与展望

业务渗透

目前在App端，已完成80%相关页面的切换

成本节约

统计近5期的版本，清理15.08%的冗余埋点数据，节约了成本

埋点准确率提升

准确率从原先的90%提升至98%

开发提效

代码行数极大得缩减，从原先的平均50行到1行，代码缩减比例达到98%。从而将3天/期/人的埋点开发时间缩短至0.5天/期/人的埋点开发时间。目前到家3个ToC端App已经全面接入使用，针对不同app环境均作了适配，实现系统的复用。

验测提效

验测时间缩短了60%，效率提升了两倍以上

展望

到家新版埋点系统已经稳定运作多版本，目前已经初步达到技术侧以及业务侧定的目标。当然，在埋点链路的优化建设上还有许多不足的地方，如：

• 埋点实践只在App端进行了落地，而针对H5、RN的两端的落地，现在还在改造中，很快就会实现三端的对齐
• 结合已有能力进行拓宽，借助数据模型到数据下发的闭环，提升至100%的埋点准确率
• 在效率方面，针对标准化后的埋点进行基类统一处理的方案，将最后的一行代码也优化掉

到家App团队接下来会在这几个方面继续深耕，探索并落地更加完善的埋点系统实践。