本文将全部以Q&A的形式来进行描述

Q1：为什么需要埋点？

采集用户浏览次数
采集用户交互行为
采集商品曝光...

先别管采集了什么，重点就是采集二字

Q2：采集来有什么用啊？

~~前端：上报用户行为啊！~~
~~前端：产品说要这些啊！~~
公司：服务于大数据业务！

思考埋点，不应从前端角度出发，但怎么就和大数据业务扯上关系了呢？

Q3：什么是大数据业务？

上图是一个标准的大数据业务的上下游
可以看到数据采集是第一环节

但什么时候开始准备采集呢？

Q4：什么时候需要埋点？

一款新产品规划完成需要看数据时
某个功能改版规划完成需要看数据时
想看两个方案A\B对比数据时
想看活动H5页面数据时
将内容投放到第三方希望看到引流效果时
想看某个广告位曝光数据时
~~前端：产品要看隔壁老王昨天...~~

重点：

埋点不应该是产品需求
应该是前端的日常工作之一
no data no bb，无论是后期的复盘，还是明确业务价值，还是用来反怼产品，都是一把神器

Q5：埋点该采集点什么？

~~前端：公司有现成的sdk，我只要知道api就行了啊~~
~~前端：产品想啥姿势就啥姿势呗~~
大数据：小朋友才做选择，我全都要
1. 数据采集是否丰富
2. 采集的数据是否准确
3. 采集是否及时

从大数据层面，对埋点数据的要求分为

基础层（sdk来解决）
业务层（基于sdk，由前端开发来解决）

ok，又来了一个概念sdk

Q6：什么是sdk？

就是一段js，没什么出奇的：
1. 全局事件监听
2. 暴露一些方法，供业务方调用
一般sdk的理论基础：
1. who：行为背后的人，具有哪些属性
2. when：什么时候触发的这个行为？
3. where：事件发生的地点，城市地区甚至GPS
4. what：描述用户所做的事件的具体内容
5. How：用户进行事件的方式
一般sdk的采集内容：
1. 页面浏览数据
2. 用户点击数据
3. 页面加载性能
4. JS报错
5. 接口出错上报
6. 自定义测速

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

Q7：sdk还有分类？

埋点是基于sdk，那找个sdk一把梭不就好了吗？

然而，并不行，因为平台不用，sdk也不同，分为：

Web
移动端（IOS/Android）
小程序（微信、支付宝、百度）
App第三方框架（RN,Flutter,Weex)

所以，想要埋还是要case by case的去看，什么业务平台，用什么sdk

Q8：那市面上有什么现成的sdk吗？

自主研发（大公司的必经之路）
百度统计（免费）
TalkingData（收费）
GrowingIo（全埋点）
Google Analytics（免费）
Mixpanel（可视化埋点）
友盟（收费）
神策（收费）

分析上面的产品，多了几个关键词：

免费
1. 功能不够强大
2. 或等着你买服务
收费
1. 全套解决方案
2. 价格贵
全埋点
可视化埋点

为什么会有全埋点、可视化埋点这些分类呢？

这要从埋点存在的问题说起

Q9：埋点存在的问题？

埋点，最low也最简单的方式，就是在代码里直接写上埋点代码，然后随着时间，埋点问题就会爆发

埋点代码与业务代码写在一起，如果埋点代码远多于业务代码，造成阅读困难
埋点代码书写复杂，复杂度大于业务代码，成为开发者的一个大负担。
业务代码改动后，埋点代码也需要相应的改动
埋点代码不能支持新业务，需要新业务新增埋点

妈蛋，想想都头疼啊，不过还是需要仔细思考一下，埋点的痛点是：

代码埋点工作量大
埋点出错导致的数据问题，修复周期长（需要发版）
同一业务在多端多平台情况下容易发生埋点口径不一致

Q10：埋点痛点的解决方案？

想要解决埋点痛点，需要从两个方面入手：

多埋点方案组合
埋点平台化、系统化

又来了新概念，多埋点方案是啥？埋不就行了，怎么还要有这么多方案？

Q11：那埋点究竟有多少种方案？

随着时间的发展，埋点存在4种方案：

代码埋点
可视化埋点
无埋点
后端埋点

Q12：什么是代码埋点？

概念：所谓的代码埋点就是在你需要统计数据的地方植入N行代码，统计用户的关键行为。
优点：
1. 使用者控制精准，可以非常精确地选择什么时候发送数据
2. 使用者可以比较方便地设置自定义属性、自定义事件，传递比较丰富的数据到服务端。
缺点：
1. 埋点代价比较大
  - 每一个控件的埋点都需要添加相应的代码，不仅工作量大，而且限定了必须是技术人员才能完成；
2. 更新代价比较大
  - 每一次更新，都需要更新埋点方案，然后通过各个应用市场进行分发，而且有的用户还不一定更新，这样你就获取不到这批用户数据。
3. 数据传输的实效性，网络原因
4. 数据不可回溯

Q13：什么是可视化埋点？

概念：利用可视化交互手段，通过可视化界面配置控件操作与事件操作发生关系。
优点：
1. 可视化埋点解决了代码埋点埋点代价大的问题。
  1. 手动埋点到不侵入代码
  2. 学习成本低
  3. 统一采集技术，提供标准化埋点实现
  4. 所配即所得
  5. 埋点流程简化
2. 可视化埋点解决了代码埋点更新代价比较大的问题。
  1. 埋点配置独立发布
缺点：
1. 可视化埋点能够覆盖的功能有限，目前并不是所有的控件操作都可以通过这种方案进行定制；
2. 数据不可回溯

Q14：什么是无埋点？

无埋点也叫全埋点

概念：用户展现界面元素时，通过控件绑定触发事件，事件被触发的时候系统会有相应的接口让开发者处理这些行为。
优点：
1. 可视化展示界面
2. 技术门槛低，使用部署简单
3. 用户友好性强
4. 数据可回溯
缺点：
1. 不能灵活地自定义属性，行为记录信息少
2. 传输实效性和数据可靠性欠佳
3. 由于所有的元素数据都收集，传输压力大，会给数据传输和服务器带来较大的压力。

Q15：什么是后端埋点？

概念：在后端采集数据，例如采集后端的日志。
优点：后端采集数据到分析系统中则是通过内网进行传输，这个阶段不存在安全和隐私性问题。同时，内网传输基本不会因为网络原因丢失数据，所以传输的数据可以非常真实地反应用户行为在系统中的真实体现
缺点：缺少用户交互行为数据，需要与前端埋码相结合

Q16：那究竟该用哪种埋点呢？

Q17：有哪些适用的埋点场景吗？

Q18：埋点平台化，系统化又是什么？

前面了解的只是埋点方案的不同，但事实上，想要把埋点实施好，还需要系统层面的解决方案，应包含：

埋点规范
1. 埋点规范代码生成平台
埋点管理
1. 注册埋点，添加、删除埋点
2. 埋点可视化
埋点验证
1. 测试埋点平台，可生成报告
埋点发布
1. 独立的埋点发布平台
埋点监控
1. 埋点数据回流
2. 埋点错误上报

这些内容，需要平台化来支撑，也是各大公司埋点部门在做的事情，同时也是行业上这些数据公司生存的土壤。