埋点该怎么埋？

1. 埋点的来源和存储

  • 埋点是数据来源渠道之一，另一个比较重要的来源是服务端后台的记录数据，和用户行为不严格挂钩，需要数仓同事帮助取。
  • 埋点用于收集用户真实的在 App 上的操作，前端和客户端负责，以 JSON 形式存储，需要清洗，数据量较大，一般会聚焦到单个用户。

2. 埋点命名规范

  • 埋点命名规范可以作为工作亮点，面试时可以引导面试官问相关问题。
  • 埋点所需采集的信息包括：
    • 用户 uid（唯一识别号）
    • 埋点上报时机（点击、曝光、退出）
    • 信息（公共信息：每个埋点都需要的数据；私有信息：只有该埋点涉及的数据）

3. 为什么需要埋点？

  • 新功能需要数据验收效果时，需要埋点支持。
  • 工作技能要求：
    • 仔细阅读理解交互和 PRD，梳理逻辑链路。
    • 前期工作：尽可能保证拿到产品经理想要的数据。

4. 埋点前期工作

  • 了解产品的交互：
    • 亲自下载安装负责的应用，随意操作点击，体验产品的功能和服务。
    • 初步划分产品的几个模块，建立基本感知。
  • 梳理产品的信息流结构：
    • 在感知的基础上，将产品功能抽象为几个实体。
    • 画出这些实体如何随着用户操作流动，以何种形式展现，提供哪些交互入口。
  • 埋点时间：在产品开发前进行。

5. 角色与职责

  • 产品经理：输出策划文档、统计需求（一般以报表需求的形式呈现，也是数据产品埋点转换的重要参考）。
  • 数据分析师：负责埋点转化，对埋点完整性负责。
    • 参考策划文档，增加曝光、点击等埋点事件。
    • 参考报表需求文档，完善或增加埋点支持报表需求。
  • 业务开发：
    • 根据数据开发输出的埋点设计文档，在触发时机上报事件及附属信息。
    • 负责埋点植入的正确性，确保数据采集完整性。
  • 数据测试：
    • 通过抓包方式验证数据上报是否符合埋点设计。
    • 验证一致后发起埋点验收报告。

6. 什么样的埋点是好埋点？

  • 能拿到想要的数据。
  • 命名简单易用。

7. 什么时候需要加入埋点？

  • 主要：用户有感知的行为，如点击、页面曝光。
  • 次要：用户无感知的行为，如状态上报（心跳埋点、性能埋点）。
    • 心跳埋点（测量用户在线时间）：每隔五秒上报一次，只要用户仍在 APP 内，就持续上报。

8. 设计埋点的两个阶段

  1. 前期规划：明确埋点需求，设计埋点方案。
  2. 数据埋点实施：完成埋点植入，并进行数据验证。

9. 设计埋点的几要素

9.1 埋点名称

  • 事件 ID，通常由分析师自定义。
  • 需遵循团队和业务的数据规范，如：
    • 事件 ID 以业务缩写开头（如 douyin_activity_show）。
    • click 和 show 需作为 ID 结尾。

9.2 埋点上报时机

  • 用户点击某个按钮时。
  • 用户进入某个页面时。
  • 心跳埋点满足时间间隔要求时。

9.3 埋点参数

  • 按需收集目标信息，涉及 “埋点需要收集什么数据”。
  • 4W1H 数据模型（Who, When, Where, What, How）
    • WHO: 用户属性相关信息（用户 ID、手机号、设备 ID）。
    • WHEN: 时间相关信息（session ID、客户端时间）。
    • WHERE: 事件属性相关信息（页面名称、按钮名称、按钮位置）。
    • WHAT & HOW: 事件相关信息（按钮点击、搜索点击、页面浏览）。

9.4 公共参数 vs 私有参数

  • 公共参数：
    • 每个埋点都会自动上报的参数，如：
      • uid（触发埋点的用户 ID）。
      • did（设备 ID）。
      • ts（上报时间）。
      • os（设备操作系统）。
  • 私有参数：
    • 业务场景特定的参数，如：
      • enter_from（页面来源）。
      • location（用户点击位置）。
      • user_type（用户类型：创作者/消费者）。
      • action_type（动作类型，如点击或曝光）。