首先我们要先了解数据埋点，到底有什么用处？
1、对设计师而言
根据埋点统计出页面元素的点击，页面按钮的点击转化，有助于在后续中作进一步视觉调优。
2、对产品/运营/推广而言
可作为产品/运营/推广当次产品功能/运营活动/渠道推广的部分效果评估指标；也可作为其下次产品/运营/推广需求的数据支撑。
3、对整体项目而言
将适量的数据，同步给项目组内的其他成员，能适当提高团队的荣誉感（数据表现好时）、危机感（数据表现差时）。
常见的数据埋点方式有以下三种：
- 代码埋点
- 全埋点
- 可视化埋点
一、代码埋点
代码埋点出现的时间很早了，在 Google Analytics 年代，就已经出现了类似的方案了。目前，国内的主要第三方数据分析服务商，如百度统计、友盟、TalkingData 等都提供了这一方案。Sensors Analytics 也一样提供了 iOS、Android、Web 等主流平台的代码埋点方案。
它的技术原理也很简单，在APP或者界面初始化的时候，初始化第三方数据分析服务商的SDK，然后在某个事件发生时就调用SDK里面相应的数据发送接口发送数据。例如，我们想统计APP里面某个按钮的点击次数，则在APP的某个按钮被点击时，可以在这个按钮对应的 OnClick 函数里面调用SDK提供的数据发送接口来发送数据。
优点：
一方面使用者控制精准，可以非常精确地选择什么时候发送数据；同时使用者可以比较方便地设置自定义属性、自定义事件，传递比较丰富的数据到服务端。
缺点
首先，埋点代价比较大，每一个控件的埋点都需要添加相应的代码，不仅工作量大，而且限定了必须是技术人员才能完成；其次是更新的代价比较大，每一次更新埋点方案，都必须改代码，然后通过各个应用市场进行分发，并且总会有相当多数量的用户不喜欢更新APP，这样埋点代码也就得不到更新了；最后，就是所有前端埋点方案都会面临的数据传输时效性和可靠性的问题了，这个问题就只能通过在后端收集数据来解决了。
适用场景
- 需要采集一些非点击的、 不可视的行为，或需要整合用户身份信息和行为附带属性信息的；
- 对于前端、 服务端均能采集到的信息，优先选择服务端埋点。
二、无埋点
无埋点、无痕埋点、自动埋点，指的都是全埋点。这种埋点方式想要实现的效果是全自动化埋点，将客户端的用户行为尽可能地全面采集，然后通过界面配置的方式对关键行为进行定义。
使用这种方案，只需要在产品中嵌入 SDK，等于做了一个统一的埋点，每次有用户行为分析的需求，都不用再走一次完整的埋点流程。
优点：
- 统一埋点，高效。
缺点
- 只能覆盖基本的点击、展示等用户行为；
- 采集的数据量非常大，随着数据量上升，可能会导致客户端崩溃的概率也会上升，更多的数据量同时也意味着更多的电量、流量和内存消耗；
- 采集回来的数据需要二次梳理和加工，因为机器无法在采集时按照我们想要的方式对全部事件进行有意义的命名，甚至无法保证采集上来的事件都正好是正确的；
- 不支持用户身份信息和行为附带的属性信息的整合。
适用场景
- 业务/产品相对比较简单，只看PV/UV等数据。
三、可视化埋点
通过可视化交互的手段，代替代码埋点。将业务代码和埋点代码分离，提供一个可视化交互的页面，输入为业务代码，通过这个可视化系统，可以在业务代码中自定义的增加埋点事件等等，最后输出的代码耦合了业务代码和埋点代码。
可视化埋点听起来比较高大上，实际上跟代码埋点还是区别不大。也就是用一个系统来实现手动插入代码埋点的过程。
优点
- 无需研发人员介入，产品运营可以直接在网站或移动应用的真实界面上操作埋点 ；
- 埋点之后立即可以验证埋点是否正确；
- 埋点部署到所有客户端也是几乎实时生效的。
缺点
- 只针对点击可见元素的，一些动态页面、不可见的行为是采集不到的；
- 对于点击操作附带的业务属性，比较难实现；
- 为了确保埋点准确性，可视化埋点也逐步整合了更为复杂的高级设置，操作起来也很低效。
适用场景
- 业务/产品相对比较简单，只看一些不和服务端交互的行为统计。
更多文章__> >> 码砖猿的技术博客
