全埋点预研

预研前，我曾思考过几个问题：

• 全埋点的价值和意义体现在哪？
• 全埋点要采集点什么？
• 数据采集是否丰富？
• 是否满足产品以及大数据的需要？
• 采集的数据是否准确，采集是否及时？

全埋点概念

全埋点也叫无埋点，用户展现界面元素时，通过控件绑定触发事件，事件被触发的时候系统会有相应的接口让开发者处理这些行为

无埋点技术的优劣

一、无埋点的优势：

1. 全局的，不需要重新部署，配置完成就可以生效

2. 不需要额外针对某个模块开发

3. 用户动作收集完整，不会漏失

二、 无埋点的痛点：

但是其缺点也非常明显，也会存在以下问题：

1. 有用、没用的数据都会收集

2. 不具有代码埋点的灵活性和深度，无法采集到特殊的行为动作、业务参数，绝大多数达不到产品所需要求，因此获得收益较低。

3. 只能采集到用户肉眼可见的数据，不能灵活地自定义属性，行为记录信息少，无法获取内存里的数据

4. 采集到的信息需要进行二次标注，才可以被用户识别

5. 当按钮的位置不固定、名称存在重复或页面重构时，无法做到准确的标识

6. 无法适应页面结构的变化，所以在实际生产中，要选择性地在合适的地方使用无埋点技术

7. 由于所有的元素数据都收集，传输压力大，及时上传的话会给数据传输和服务器带来较大的压力

综上可得出：

• 无埋点一般用来做粗粒度的快速业务探索。
• 对我们目前项目而言，全埋点带来的效益不大，虽然可以回溯历史的一些数据，但是只能知道一些很简单的数据，价值很少，付出的比较多。例如，一个按钮只有一个位置和信息，最后就算知道了点击的的占比很高，也没多少作用。神策数据sdk也都明确表示了，全埋点的价值并不高。
• 全量上报数据大家也知道，太不友好了，这个数据量太大，不仅前端消耗资源多，如果为了做数据回溯，后台的存储压力也会加大，而存储的数据大部分还是无效的，这个成本有点高了。

无埋点方案：

• 从大数据层面，对埋点数据要求分为： 1、基础层（sdk解决） 2、业务层（基于sdk，前端开发解决）

埋点是基于sdk

因为平台不同，sdk也不同，想要埋点还是要case by case的去分析，什么业务平台，用什么sdk。市面上也有些现成的sdk：

1. GrowingIo（全埋点）

2. 神策（收费）

3. 百度统计（免费）

4. TalkingData（收费）

5. Google Analytics（免费）

6. Mixpanel（可视化埋点）

7. 友盟（收费）

当然，有些为了满足特定需要，也有自主研发的，我们先前对曝光埋点也自主研发了一套方案。

无埋点技术方向

一、项目情况分析

在现阶段我们的RN实践是基于APP（原生），譬如将从原生某个入口进入一个通用RN容器（原生会传 actionId给 RN容器 去识别要打开哪个 RN 页面），所有的RN页面都在RN容器内部跳转。因此，如果选择接入sdk，根据我们的项目情况需要原生开发的同事配合，自然也会给原生开发的同事带来一定的工作量，那么，我们可能更多层级的是考虑js层面上的全埋点。

二、无埋点目标

对于全埋点，我分析目标可得：

采集数据 = 用户行为数据 + 前端健康度分析

我们可以从以下几个方向出发：

1. 页面浏览数据：对用户的浏览页面url收集，形成用户浏览路径；
2. 用户点击数据：对点击等行为进行收集，可以收集到的信息主要有：点击元素的xpath路径、title或约定的dom元素等
3. 页面加载性能（有待继续预研）
4. JS报错（有待继续预研）
5. 接口出错上报（有待继续预研）
6. 自定义测速（有待继续预研）

三、技术关键（后期实践）

- “无埋点”技术的关键是：

• 操作可视化配置工具，保存配置
• SDK基础代码如何根据配置上报行为

- “无埋点”技术实施预方案

1. 页面的唯一标识
2. 元素的唯一标识
3. js hook实现原理
4. 如何查找元素
5. 标记元素时的高亮效果和可视化交互实现
6. 路由跳转
7. 事件捕获 ...

以上为这次全埋点预研的一些知识积累浅谈，后续会继续展开全埋点的一些技术方案与具体实践，敬请期待。

参考文档

1. React Native无埋点SDK
2. 神策数据-React Native埋点
3. 神策数据-数据采集中无埋点的优势与劣势
4. 网易HubbleData无埋点SDK在iOS端的设计与实现
5. whats-element-唯一标识符计算