产品数据埋点采集方案设计文档概要

什么是采集方案设计？采集用户行为数据，首先需要根据业务分析需求明确采集的目标行为，进一步搞清楚应该在哪些地方埋什么样的点。 这个环节的输出物一般被称之为“埋点需求文档（DRD）”。在大部分互联网公司，规范的产品迭代流程是，业务侧产品经理在输出“产品需求文档（PRD）”的同时，数据产品经理或分析师等角色需要同步输出 DRD，双方的需求同步进入开发和测试验收。

数据埋点方案

• 1.埋点方式分类
  • 前端埋点
    • 定义
      • 记录用户在客户端的使用数据，包括但不限于网页，APP，PC客户端等
    • 类型
      • 代码埋点
        • 定义
          • 在程序中加入用户统计数据的代码，当指定的触发行为发生的时候，就统计用户的使用数据
        • 优势
          • 可以根据使用者的需要任意的选择在什么时候发送什么数据，并且可以自定义丰富的数据属性
        • 劣势
          • 对于产品经理对业务的理解程度和用户的理解程度要求较高，需要知道什么数据需要被收集
          • 每一次加入埋点代码都会带来相对应的工作量，每一次更新埋点代码会引起新旧版本的不兼容问题
      • 可视化埋点
        • 定义
          • 一般由第三方数据平台提供，可以通过非常直观的形式管理数据追踪点，通过图选页面元素来实现数据的收集
        • 优势
          • 每次更新埋点的时候并不需要等待程序更新，而是把数据统计的代码在应用程序启动的时候通过网络更新配置，解决了产品临时想要加入或修改埋点的需求。
        • 劣势
          • 不能灵活的自定义事件，只能使用平台提供的一些通用性事件
      • 无埋点
        • 定义
          • 是尽可能的收集所有控件的操作数据。然后通过界面配置的方式添加一些需要统计的数据。
        • 优势
          • 可以解决数据的回溯问题，即使之前的版本没有对某一个控件做精确的埋点，那么全埋点方案也一样会收集这个控件的数据，当后续有数据分析需要的时候就可以谓出数据来查看了
        • 劣势
          • 不能灵活的自走义事件，仅能用户分析用户在产品中的交互行为
          • 因为所有的事件都在收集，有时候会产生大量不必要的数据。给服务器带来很多负载。
  • 后端埋点
    • 定义
      • 记录程序接口的凋用情况，例如接口访问次数，接囗返回各个状态次数的统计等
      • 如果希望统计的数据是实时且精准的，则往往采用接口将数据在指定的触发条件下上报至服务器，这时候就需要后端埋点来进行统计了。
• 2.选择数据平台
  • 大部分企业的前端埋点是利用第三方数据公司平台进行
  • 少数企业自主开发
• 3.埋点表
  • EventID页面
    • 定义页面的ID号和名字
  • Labe/事件
    • 用户在这个页面上的使用行为
  • 上报时机
    • 上线时间/生效时间
  • 优先级
• 4.将自定义事件的属性添加至事件中
  • 创建数据字典
    • KEY
      • 给key命名
        • 驼峰命名法
          • 第一个单词以小写字母开始；从第二个单词开始以后的每个单词的首字母都采用大写字母
          • userName
        • 下划线命名法
          • 在多个单词之间使用下划线来进行分割
          • User_name
      • 示例
    • 注释
      • 对于key字段的解释，用来说明key值代表的是什么，便于后续的查询
    • 数据类型
      • 分为名义数据、等级数据和连续数据三种
    • value
      • value是Key对应的值，有一些Key对应的是不确定的值，例user_ID，有多少个用户就有多少个值，所以Vae可以为空。但有一些Key的vaue是限制在一定范围内的，所以需要事先对ae的可选择值作出定义，例如如果想统计一篇文章是否读完，可以定义一个sRead_off的Key，那么对应的value值只有两个，是或否。
    • 全局字段Global
      • 在数据统计的过程中，有一些key值是需要所有的事件都要进行统计的，典型的例如用户的ID，为了节省时间，可以将这些key值定义为全局字段，这样就可以不用在每个事件当中重复填写了。
  • 示例
• 5.埋点文档注意事项
  • 1.埋点文档只可增加，不可修改和删除
    • 产品无法保证每个使用者都在使用同一版本，所以埋点文档不可以修改，也不可以删除，因为即使从埋点文档中删除了，已经上线了的统计代码是不会删除的。删除某个埋点文档可能会导致这个事件依然在上报，但后续的产品经理却不知道这是个什么事件了
  • 2.事件必须独立
    • 如果只把Labe写成运回则很有可能会与其他页面的返回相互混洧，造成数据结果不正确，这个问题我们已经通过给每个 EventID和Lab e加上唯一编码解决了
  • 3.数据字典不重复
    • 为了确保每个事件属性的含义保持一致，所以数据字典中的每一个k ey也都是唯一的，若多人维护统一埋点文档，需及时同步
  • 4.注意平台限制
    • 不同的第三方埋点平台可能对于事件和属性有上限的限制。所以要在选择之前确走平那台的基本供给能否满足我方实际需求
  • 5.埋点测试
    • 埋点代码编写完成后需要对埋点进行测试，这个过程一般是和测试同事一起进行，用来确保埋点的数据上报正确，该统计的属性也都添加成功了