数据埋点:数据埋点方式与策略

埋点方式

  • 展现埋点
    • 通俗来说,某个页面里的内容被展现了;
      • 怎么定义展现,其实就是一个服务端的触发;
      • 服务端如果触发了,用户侧就会展现内容;
    • 展现埋点需要记录的,是页面展现的内容信息。
      • 也就是说,服务端下发的内容都包含什么;
      • 这些东西一定是当前页面主要内容,不包含一些交互信息。
  • 曝光埋点
    • 比如:广告(用于计算曝光数)
    • 有效曝光 / 逻辑可见:
      • 停留时间大于 2 秒;
    • 曝光逻辑:
      • 一个模块只曝光一次、且上报一次(如果已经上报,就不做二次上报);
      • 标题曝光,即视为模块模块曝光;
  • 交互埋点
    • 比如:
      • 用户点击登录按钮;
      • 用户给视频点赞、播放、暂停;
    • 只要用户“消费”了可交互内容,都可以记录埋点。

前端埋点 & 后端埋点

  • 前端埋点为主,后端埋点为辅;
  • 后端数据作为标准,前端数据作为参考;
  • 很多时候,需要相互配合;
    • 比如:
      • 判定用户登录是否成功,需要后端判定登录状态,结合前端的登录行为才能判定;
      • 获取用户的支付信息,前端只展示标出来的价格,但实际支付的时候可能会有优惠,需要结合后端的支付数据才能确定实际价格;

前、后端埋点的区别

  • 在实际过程中,有些埋点是不用特意区分前后端的,用户的一个埋点事件在前端埋点或后端埋点都可以实现;
  • 但是需要注意的是,在实际埋点上报、数据收集等过程中会有数据丢失的情况,从这个角度来看的话,其实后端埋点要比前端埋点更有优势;
  • 前端埋点会因为一些网络问题、适配问题等等容易出现上报异常造成数据丢失且丢失后排查困难,因为前端相关的是没有记录相关操作的,只负责上报,上报成功与否没有记录
  • 而如果是后端埋点,无论是自己的数据系统、还是第三方数据系统,都是可以通过自己系统本身相关的数据库查询、或记录日志等操作进行埋点数据的校验排查;
  • 所以针对一些比较重要的埋点,还是建议以后端埋点为主,必要时通过记录日志或记入数据库等方式对相关数据进行二次记录以便进行数据核实。

代码埋点

  • 指令式埋点:
    • 命令式埋点需要开发人员在需要埋点的 dom 节点处手动加入代码。
    • 用户在埋点位置触发事件,由预先定义的函数上报事件相关数据。
    • 示例:点击事件埋点
      • 如页面按钮的点击,页面的跳转时都会加入回调函数,以这种方式埋点采集数据。
        // 页面加载时发送埋点请求
        $(document).ready(function(){
           // ... 这里存在一些业务逻辑
           sendRequest(params);
        });
        // 按钮点击时发送埋点请求
        $('button').click(function(){
           // ... 这里存在一些业务逻辑
           sendRequest(params);
        });
        
    • 指令式埋点缺点:
      • 侵入业务代码
        • 埋点代码侵入业务代码,这使整体业务代码变得繁琐;
      • 业务耦合度高
        • 每增加需求都要做版本更新迭代,代码开发的工作量比较大;
        • 开发成本较高;
      • 代码冗余
        • 在业务逻辑中插入埋点代码会导致代码冗余;
      • 后期维护升级困难
        • 项目越到后期代码就难优化冗余度就越高,不利于项目后期维护和升级;
  • 声明式埋点:
    • 预先声明埋点类型(提前封装好自定义的指令),在 DOM 或者组件上,通过设置即可以完成事件的统一上报;
    • 声明式埋点是基于 vue 框架的自定义指令,可以一定程度的减小代码冗余解决代码耦合的问题。
    • 示例:购买事件埋点
      <button v-focus="{type:"click",key:"shop"}" @click=”handleShop”>购买</button>
          
      // 自定义指令
      directives:{
          focus:{
              bind:function(el,binding,vnode){
                  el.addEventListener('click',()=>{sendRequest(binding.value)}) }
          }
      }
      
      • type
        • 事件类型,这个事件类型、指当前元素添加的事件 click;
      • key:
        • 埋点标识,这里代表埋点标识位置为购买 shop;
      • 埋点实现过程
        • 用户点击购买按钮时,前端页面会将当前的事件类型(click)和埋点标识(shop)传到服务端。
    • 声明式埋点优点:
      • 埋点和业务代码实现了解耦,提高代码可维护和可阅读性;
      • 提高代码可维护和可阅读性;
      • VUE 比较流行的埋点方式;
    • 声明式埋点缺点:
      • 需要手动在需要埋点的节点中添加指令。

全埋点(无埋点)

  • 全部免采集用户的行为;
  • 如国内的神策数据等;
  • 优点:
    • 数据全部采集,不会有遗漏;
    • 全生命周期的采集和分析;
  • 缺点:
    • 后端日志服务器亚历山大;
    • 占用网络资源,对用户浏览体验也会有影响;

可视化埋点

  • 通过可视化的自定义埋点;
  • 如开源的 Mixpanel;
  • 优点:
    • 操作简单;
    • 支持自定义属性;
    • 适用于非技术人员进行埋点工作;
  • 缺点:
    • 覆盖的功能有限,不支持后端埋点;
    • 可视化埋点并不能准确的加入埋点,只能通过可见的按钮添加埋点,分析较难、针对性埋点较弱。
    • 开发难度大,需要在 web 短提前解析 DOM,并将解析后的 DOM 进行可视化,并能实现准确的自定义配置,对开发要求比较高。

第三方 SDK 埋点

  • 神策
  • 诸葛
  • Growing IO
  • 只需要集成 SDK 就可以实现埋点;
  • 基本都提供私有化部署,不用担心数据安全问题。

  • 第三方工具存在的问题
    • 非实时反馈
    • 数据波动难以定位
    • 与第三方沟通成本太高
    • 没有自己的核心数据存储
    • 电商时间埋点方案示例