互联网产品数据埋点方案

埋点分析，是网站分析的一种常用的数据采集方法。数据埋点分为初级、中级、高级三种方式。数据埋点是一种良好的私有化部署数据采集方式。本图介绍互联网行业产品的数据埋点方案的主要构成，适合产品经理、数据分析师、运营人员使用，欢迎收藏！

数据埋点方案

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