埋点设计与规范总结

1. 埋点的来源和存储

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

2. 埋点命名规范

  • 埋点命名规范是工作亮点之一，在面试时可主动引导话题。
  • 埋点应采集的信息包括：
    • 用户 UID（唯一识别号）
    • 埋点上报时机（点击、曝光、退出）
    • 信息：
      • 公共信息：每个埋点都需要的数据
      • 私有信息：只有该埋点涉及的数据

3. 为什么需要埋点？

  • 新功能上线后需要通过埋点进行数据验收。
  • 埋点能力是工作技能要求的一部分：
    • 仔细阅读并理解交互设计和 PRD。
    • 梳理用户行为的逻辑链路。
    • 确保前期埋点覆盖产品经理期望的数据。

4. 埋点前期工作

了解产品交互：

  • 下载安装所负责的应用，进行实际操作体验。
  • 初步划分产品模块，建立基本认知。

梳理产品信息流结构：

  • 抽象产品功能为若干实体。
  • 描绘用户操作如何驱动这些实体流动、展示及交互入口。

✅ 埋点应在产品开发前完成。

5. 角色与职责

  • 产品经理：输出策划文档和报表需求，是埋点设计的重要参考依据。
  • 数据分析师：负责埋点方案设计与埋点完整性，按策划和报表需求定义事件。
  • 业务开发：按设计文档在前端/客户端上报事件，保证触发正确、数据完整。
  • 数据测试：通过抓包验证埋点数据，上报符合预期后出具埋点验收报告。

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

  • 能获取想要的数据。
  • 命名规范、简单易用。

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

  • 主要： 用户有感知的行为（如点击、页面曝光）。
  • 次要： 用户无感知的行为（如心跳、性能上报）。

心跳埋点：

  • 用于测量用户在线时间。
  • 一般每隔 5 秒上报一次，只要用户仍在 App 内就持续上报。

8. 设计埋点的两个阶段

  1. 前期规划阶段：
    • 明确业务场景与埋点需求。
    • 设计埋点方案与参数。
  2. 实施阶段：
    • 完成埋点植入。
    • 进行抓包验证和数据验收。

9. 设计埋点的几要素

9.1 埋点名称（事件 ID）

  • 由分析师定义，遵循命名规范：
    • 使用业务缩写开头，例如：douyin_activity_show
    • 使用 click 或 show 结尾表示事件类型

9.2 上报时机

  • 用户点击按钮时
  • 用户进入页面时
  • 心跳事件时间满足条件时

9.3 埋点参数：4W1H 模型

维度 描述
Who 用户属性（如 UID、手机号、设备 ID）
When 时间信息（session ID、客户端时间等）
Where 页面或按钮名称、位置
What / How 用户行为内容（点击、搜索、浏览等）

9.4 公共参数与私有参数

  • 公共参数： 每个事件都会自动上报的参数，例如：

    • uid: 用户 ID
    • did: 设备 ID
    • ts: 上报时间戳
    • os: 操作系统类型

  • 私有参数： 针对某类业务场景特定的参数，例如：

    • enter_from: 页面来源
    • location: 点击位置
    • user_type: 用户类型（创作者/消费者）
    • action_type: 动作类型（点击、曝光等）

📌 总结：埋点是衡量用户行为和业务效果的重要数据基础，必须在产品设计阶段就参与进来，结合交互流程，合理规划事件、参数、命名和埋点逻辑。