埋点技术可行性初探

# 数据埋点是什么

数据埋点是一种常用的数据采集方法，主要采集用户在网站或APP的使用情况、行为习惯等，方便产品/运营系统性的统计分析复杂的用户数据。简而言之，通过技术手段采集用户留痕的行为数据。

埋点中的一些术语：

事件用户的行为记录（eg：我们有个落地页，我们想知道有多少人来到了落地页，多少人看完了落地页的文案素材，多少人点击了转化按钮最终完成了转化。那么我们就需要记录每一个用户的访问记录、浏览行为记录、转化按钮点击记录等等）
属性：事件中的有用数据字段以及进一步深入分析事件的拓展信息字段

事件+属性，就构成了埋点的基础。数据埋点无法采集所有的用户数据，所以如何合理，丰富的采集用户有价值的数据则是我们需要注重设计思考的过程，也就是我们常说的埋点流程设计。

# 数据埋点的方式

# 全埋点（无埋点）

全埋点会自动采集所有的数据点位。

实现方式：通过\SDK实现，将预先定义的某类事件（通常包括这四种事件类型：APP启动、APP关闭、页面访问、元素点击），通过SDK实现完全自动上报；
优点：几乎可以监测和分析用户在App端的所有行为数据，并且可追溯；
缺点：
- 数据存储、计算、分析成本高昂，对用户在前端的加载也有影响。主流App几乎都不会采取此种方式。
业面和按钮名称需要尽可能统一好理解。实现全埋点时，需要规范页面和元素的命名规则。

实现技术方案参考：

# 可视化埋点

通过点击交互，在产品界面上直接进行埋点。先分析，再圈选，是一种所见即所得的埋点方式。

实现方式：本质上也是前端全埋点；
实现流程：
- 事先在产品上埋一个 SDK
- 客户代码已经确定改成SDK的接口规范
- 通过可视化的方式，生成配置信息，也就是事件名称之类的定义
- 将采集的数据按照配置重命名，进而就能做分析了
优点：跳过技术部署，集成简单，小白也能很快上手；能够监测产品前端用户交互数据；
缺点：所采集的数据，属于前端浅层数据，而侧重属性的数据带不回来。例如，对于新闻类App，能监测到用户点击标题的行为，但作者、细分标签、发布时间等数据无法采集，且无法进行数据追溯。

# 代码埋点

通过技术代码在App接口中进行埋点，需产品、技术、运营的通力配合。

实现方式：
- 前端埋点：基本上是由客户端、前端页面，直接将用户的行为记录下来，进行上报。因此可以记录得非常详细齐全，一些本地完成的操作，也可以得到上报；
- 后端埋点：是将用户与服务端的交互记录进行上报。由于服务端记录比较精准，因而这种数据一般都比较可靠。而且一些没有发生在用户界面上的操作变化，也能通过后端埋点记录下来，比如商品库存的变化。通过导入工具或系统，将数据（通常是后端日志）直接进行上报。从经验上判断，后端采集适合结合深度业务数据的挖掘，而前端采集适合基于用户行为的产品运营。
  - 优点：做为“独立”的上报通道，其安全性、准确性较高。（前端通过用户层面的上报，可能会因为各种环境丢失数据、可能在传输途中被劫持）；可结合相关业务数据，将整个业务过程进行更全面的描述；同质化的采集，使用后端替代前端采集，可提升因前端采集带来的性能流失，给用户带来更好的体验。
  - 缺点：有些纯前端的行为，没有记录对应的后端日志，这部分数据无法采集和获知。
优点：代码埋点可以采集到你想要的所有数据（服务端、客户端）；前期需要系统性规划，数据分析会更贴合业务场景；且数据维度更丰富和深入，适合精细化分析和用户行为洞察；
缺点：前期工作量会稍大，包括埋点规划和技术实施。产品新增功能后，需要技术埋点并且发布App后才能统计到数据。

埋点注意事项：无论采用哪种埋点方式，都应该根据业务场景和产品阶段，梳理和构建数据分析体系。埋点规划混乱、数据采集无序、数据分析断层，最终将会让企业陷入“有数据而无价值”的境地。

埋点优劣势