一 growingIO

1  android半自动采集浏览事件

半自动浏览事件能够携带用户添加的自定义事件和变量，当View从屏幕中出现则自动发送事件。

半自动浏览事件介绍

新版方案：用户标记一个 View 并提供自定义事件和变量，SDK 负责监控，当此 View 对象可见时发送用户配置的自定义事件和变量。

新版用户浏览事件半自动究竟指什么？

不再全量采集所有 View 的浏览事件，改为只采集用户主动标记 view 。事件类型使用自定义事件类型 cstm （custom），不再使用 imp （impression）。需要用户在代码中埋点并且在官网配置自定义事件和变量。

SDK 将 View 对象在当前屏幕是否可见，是否滚动出屏幕又再次出现纳入采集发送策略，并取消浏览事件与页面的关联。即：共享 View 对象的不同页面不会重复发送，并且 view 对象不在当前屏幕又再次滑入会再次发送。后文详细举例说明.

半自动指：用户提供 View 的自定义事件和变量内容，SDK 根据当前 view 对象是否在屏幕上可见，自动发送一个自定义事件。即：需要用户标记 View 并且提供自定义事件和变量，SDK 在 View 对象出现在屏幕上时自动发送，不同于 track 接口发送的 cstm 事件，调用即发送。

下面我们将从三个方面介绍此方案。

1. 标记View并设置自定义事件和变量

在旧版无埋点 SDK 中，如果想查看某个广告位的具体某个商品的曝光次数，通过圈选广告位的 view 元素的 imp 事件是无法做到的，仍需要您埋点自定义事件。

在埋点元素曝光时，开发人员需要对 View 在当前屏幕上的可见性做逻辑判断，需要监控 View 对象是否在当前可见或者是否再次出现在屏幕上，有一定代码实施难度。

此方案将监控 View 的可见和埋点的触发时机交给 GIO SDK ， 开发者只需要将自定义事件的变量传递给 SDK 即可。

2. 元素的浏览事件相对于旧版更准

对于用户主动标记 imp 采集的元素，相对于旧版本自动采集会更加准确，我们举例以下两个场景来说明。

场景1 ： 不同的页面共享同一个元素

imp场景1

底部的导航栏在 Tab 页面中是共享元素，即切换 Tab ，底部的导航栏持续可见，在不同的 Tab 页面中是共享元素。

旧版本：

导航栏的 imp 事件会分别在对应的四个页面中发送，切换 Tab 页面时虽然底部导航栏持续可见，但是会重复发送。

为什么旧版本会这么统计呢？ 因为 imp 事件的归因和 page 事件强关联，切换了页面，就认为导航栏是这个页面中的元素，不支持多个页面共享元素的情况。

新版本：

在用户标记导航栏需要采集后，无论切换 ab 多少次，我们只会在用户第一次可见导航栏，发一次元素浏览事件。

可以认为新版本方案只关心当前元素对于用户是否可见，和页面访问事件 page 无关联。更贴近实际场景，相对旧版本更准。

总结：

1 上报机制的区别，旧版本没有考虑到实际的情形上报全部信息。新版本发送人工选择之后的信息。

场景2 ： 列表元素的展现统计

imp场景2

旧版本：

GIO 推荐广告位在 ScrollView 的最底部，需要用户滑动才能看到，但是页面初始化的时候绘制，只是当前屏幕不可见。

旧版本中只会发送一次 imp 事件，无论随着用户的滑动元素是否再次可见，只有在页面初始化的时候发送此元素的 imp 事件。

新版本：

随着用户的滑动手势，元素进入屏幕则触发自动埋点事件，滑动出屏幕后，再滚动回来 View 再次可见依然会发送自动埋点事件。

即为元素对于用户可见几次则发送几次事件。

新版本浏览事件采集的列表，内部的元素展现次数的统计更加准确，更符合业务场景。

总结：新版本改为展示上传。

3. 提升用户浏览事件采集的性能

旧版本中，无埋点 SDK 将自动采集所有 View 的信息，最终分析时不会分析所有 APP 中的 View，在APP的性能、用户流量上都是一种浪费。

新版本中，SDK 非全量采集所有列表中的元素，只采集用户配置的元素，性能有较大提升。

总结：growingio由全自动切换到半自动，触发条件与采集上报机制。

二 埋点方案

从位置上分为前端埋点和后端埋点，从形式上分为显性埋点和隐性埋点，从路径上又可以分为路径埋点和独立埋点，从需求上分为业务埋点和监测埋点。

1.  前端埋点

前端埋点是在用户端(APP、Web、客户端)等嵌入数据采集代码，比如友盟等均采用的是前端埋点，比如通过嵌入一段代码就就可以对网页数据的访问数据进行采集。相比于后端埋点，前端埋点能方便收集到用户在界面上的行为数据，比如用户点了哪个按钮、页面之间的跳转次序、停留时长等，这些数据是后面进行数据分析的主要来源。

前端埋点技术有以下三类：

代码埋点

代码埋点是直接将采集SDK集成在终端，然后不断在此基础上添加调整采集方案，是目前主流的埋点采集方案，其优缺点如下：

优点：

高度定制、控制精准、采集的数据丰富准确

缺点：

首先是每当有采集需求，需要开发人员不断添加采集代码，工作量大；

其次变更采集策略，需要发布新版本，代价巨大，存在滞后效应；

最后由于采集代码常驻终端，不断将采集的用户行为数据进行记录和上报，对于终端尤其是移动终端来说还有耗电、消耗数据流量等负载，此外在数据上报传输的过程中也存在丢失数据的风险。

可视化埋点

由于代码埋点需要终端开发人员来执行采集方案，对业务的功能开发侵入性较高。有的公司开发出了可视化埋点技术，只需要产品与运营人员通过GUI界面进行鼠标简单点击，就可以随时增加、取消、调整采集数据的位置和方式，此种埋点方式避开了终端开发人员的介入，由需求人员直接执行采集，减轻了需求传递过程中的信息损耗和误解，另外可视化埋点技术往往由服务端直接下发采集的配置文件，而不用跟随版本发布，从而加快了数据采集的流程。

具体实现方式参考：

具体实现是SDK定时做界面截图，在截图的同时从界面UI的根对象开始遍历所有的可视化子对象，得到其层级关系。根据截图和UI元素的可视化信息重新渲染页面，识别可埋点的控件。当产品人员在后台管理端的截屏画面上点击可埋点控件，设置事件关联方面的配置，服务器保存这些配置，客户端在获取到这些配置信息以后，按照新配置采集数据。

无埋点

无埋点与可视化埋点原理基本一致，区别在于无埋点是先遍历所有的控件和操作行为的组合情况，然后将这些组合情况交给埋点后台，由数据分析人员选择对哪些组合的埋点数据进行分析，其优缺点如下：

优点：

1  可视化展示界面最基本度量，满足基本数据分析需求。无埋点可视化展示界面PV、UV等最基本度量。

2  技术门槛低，使用与部署较为简单。无埋点极大程度避免了因需求变更、埋点错误等原因导致的重新埋点繁复工作。

3 用户友好性好。

缺点：

1  无埋点只能采集到用户交互数据，且适合标准化的采集，自定义属性的采集仍旧需要代码埋点来辅助。例如在电商行业中，用户点击“购物车”是一次交互行为，无埋点会忽略用户信息、商品品类信息等其他维度的信息。

2  无埋点兼容性有限。例如对安卓系统进行埋点时，不同工程师对不同APP可能会对相同的button起不同名称的ID，当运营人员想要筛选所需数据时，不同名称会给运营人员带来困扰。

3  无埋点具有前端埋点的固有缺陷。无埋点是前端数据采集方式之一，因此具有前端埋点的天然缺陷，如数据采集不全面、传输时效性较、数据可靠性无法保证等问题。无埋点的技术原理依赖网站或者APP后端技术开发的严谨性与规范性、网络状态、网络口径等。

前端埋点的注意事项：

页面和控件标示上报要从顶层进行合理的设计，层次感要明显

埋点数据的漏报和重复上报如何衡量

前端埋点不仅可以处理不需要和服务器交互的曝光和点击事件，也可以将与服务器交互的结果，比如关注成功、分享成功、优惠券领取成功等原属于后端埋点里的事件放在前端来上报。

2. 后端埋点

后端埋点为了避免前端埋点的以下问题：

前端埋点需要对采集的数据压缩、暂存，为减少移动端的数据流量，除一些需要实时上报的重要事件不限制网络环境，其它事件一般只在wifi情况下上报，因此数据会有延迟，丢数据等弊端，而在后端采集数据，由于数据是在内网传输，数据传输的即时性强，丢失数据的风险小。

前端埋点采集程序由于需要常驻，监测实时和延迟埋点上报，不可避免的带来额外的耗电。

前端埋点若要新增或调整采集方案，需要开发人员修改客户端代码，然后发版之后才能解决，受发布周期的影响较大，而且通常用户的版本更新并不会及时，这将导致新方案不能及时覆盖所有用户。虽然现在部分埋点管理后台也支持热配置更新，但功能一般都很弱，只支持一些基础的埋点事件热更新部署，

注意：

很多时候并不把后端埋点独立出来，而是混合在前端埋点中，等用户和服务器端的交互返回结果之后，将结果进行上报。

对一下需要精确采集的数据，比如代金券发放等，实施的时候尽量采用后端埋点，除非后端无法采集到所需要的数据，前端埋点只是用来参考。此外也可以将业务数据库代金券领取数据同步到数据仓库中进行分析。

参考资料

数据埋点之认识埋点 https://www.jianshu.com/p/e3a315b8849e

如何做到不必埋点即可采集到齐全的用户行为点击流数据? - 乔一鸭的回答 - 知乎 https://www.zhihu.com/question/38000812/answer/233650905

growingio https://docs.growingio.com/