全埋点概念

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

无埋点技术的优劣

一、无埋点的优势：

全局的，不需要重新部署，配置完成就可以生效
不需要额外针对某个模块开发
用户动作收集完整，不会漏失

二、无埋点的痛点：

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

有用、没用的数据都会收集
不具有代码埋点的灵活性和深度，无法采集到特殊的行为动作、业务参数，绝大多数达不到产品所需要求，因此获得收益较低。
只能采集到用户肉眼可见的数据，不能灵活地自定义属性，行为记录信息少，无法获取内存里的数据
采集到的信息需要进行二次标注，才可以被用户识别
当按钮的位置不固定、名称存在重复或页面重构时，无法做到准确的标识
无法适应页面结构的变化，所以在实际生产中，要选择性地在合适的地方使用无埋点技术
由于所有的元素数据都收集，传输压力大，及时上传的话会给数据传输和服务器带来较大的压力

综上可得出：

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

无埋点方案：

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

埋点是基于sdk

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

GrowingIo（全埋点）
神策（收费）
百度统计（免费）
TalkingData（收费）
Google Analytics（免费）
Mixpanel（可视化埋点）
友盟（收费）

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

无埋点技术方向

一、项目情况分析

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

二、无埋点目标

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

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

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

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

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

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

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

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

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

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

参考文档