为什么要埋点？#
运营层面：不久前，我们刚刚探讨了 Scrum 开发模式。在 Scrum 中，一个完备的产品会被拆分成多个 Features，并分配到 Sprint 中。而产品的上线迭代可能是在某个 Feature 完成之后，并且后续的 Product Backlog 也会根据线上的使用情况进行动态变更和优先级调整。而产品的线上使用情况就需要通过埋点的形式来收集，并经过数据分析手段还原真实的使用情况。
项目工程化：项目工程化是为了 提升系统的质量 和 开发效率，而埋点就是为了确认系统运行质量的一个常见的方式。举个例子，我们利用埋点对每个页面的 PV 做记录，当在某一个发版之后，页面 B 的 PV 几乎降为了 0，排除业务设计和市场波动的可能，那么大概率是 B 页面的前置流程有问题，比如订单提交失败了等等。
简单来说，埋点的意义主要在于两点：
- 为产品运营提供分析了解用户行为的数据源
- 及时反馈系统的运行情况，尽早的发现问题，提升系统的质量
怎么埋点？#
有哪些埋点手段#
根据 数据收集、数据分析 的不同，我们可以把埋点分为：
- 代码埋点
- 全埋点
- 可视化埋点
代码埋点#
代码埋点是最经典的埋点方式。工程师手动将埋点结合到代码逻辑中，所以理论上只要是客户端种的操作，再复杂也能采集到。因为数据内容是经过计划的，所以运营可以直接使用无需清洗。
全埋点#
也称“无埋点”、“无痕埋点”、“自动埋点”
全埋点工具会对所有页面中 一些 通用逻辑 进行 无差别 埋点，比如 PU、PV、通用元素交互记录（button 点击，input 输入等）。所以全埋点会一股脑将所有的数据都上报到服务端存起来，而运营人员需要对数据先进行清洗，获取到期望的数据后进行分析。
可视化埋点#
运营人员可以通过模拟使用的方式来标记需要埋点的位置并且标记一些额外需要上报的数据。这就是可视化埋点
相比代码埋点，可视化埋点 无需和开发人员沟通埋点细节 且 不依赖产品版本发布。
相比全埋点，可视化埋点可以对页面特有的流程进行埋点，并上报实践相关数据。
Tag Manager#
Tag Manager 主要的作用就是将 埋点逻辑和业务逻辑 进行解藕，这样业务团队和运营团队就无需互相依赖。
Tag Manager 和可视化埋点的区别在于，Tag Manager 是直接的代码层面的动态添加，所以比可视化埋点收集 更深层 颗粒度更细 的数据和交互。
怎么选择适合自己的埋点方案#
和开发技术一样，埋点也没有银弹。各种方案都有自己的优势和弊端。
| 优势 | 不足 | |
|---|---|---|
| 代码埋点 | 1. 精准埋点数据，无需二次清洗 2. 几乎任何场景都能标记到 | 1. 跨团队沟通成本高 2. 跨团队耦合，埋点迭代依赖业务发版 |
| 全埋点 | 1. 无需业务开发参与 | 1. 数据需要经过清洗才可使用 2. 数据维度非常有限，无法分析复杂的场景 3. 可能依赖 cookie |
| 可视化埋点 | 1. 无需业务开发参与 2. 相比全埋点可以记录一些简单的交互 3. 埋点版本迭代实时生效，脱离业务版本 | 1. 埋点维度依然有限 2. 无法记录一些状态属性 3. 可能依赖 cookie |
| Tag Manager | 1. 无需业务开发参与 2. 比可视化埋点可以记录更深层的状态数据，触发场景更多 3. 埋点版本迭代实时生效，脱离业务版本 4. 可以对接任意三方埋点服务 | 1. 需要一定的开发知识 2. 埋点链路中多了一环 Tag Manager 服务 3. 可能依赖 cookie |
独立开发者 推荐 代码埋点、Tag Manager#
- 因为独立开发者没有沟通成本，所以代码埋点最大的问题就不攻自破了
- 而 Tag Manager 可以做到埋点逻辑和业务逻辑的解藕，这是代码埋点没有的优势，这让业务代码更加干净。但是相对的，需要学习 Tag Manager，并且配置环节可能比代码埋点更繁琐。并且 Tag Manager 可能依赖 cookie，导致无 cookie 场景埋点失败（iframe、欧洲 cookie 限制）
