资讯专栏INFORMATION COLUMN

web 埋点实现原理了解一下

MASAILA / 1554人阅读

摘要:前言埋点,是网站分析的一种常用的数据采集方法。缺点是流量和采集的数据过于庞大,服务器性能压力山大,主流的就是这种实现方案。我们暂时放弃可视化埋点的实现,在手动埋点和无埋点上进行了尝试,为了便于描述,下文我会称采集脚本为。

前言

埋点,是网站分析的一种常用的数据采集方法。我们主要用来采集用户行为数据(例如页面访问路径,点击了什么元素)进行数据分析,从而让运营同学更加合理的安排运营计划。现在市面上有很多第三方埋点服务商,百度统计,友盟,growingIO 等大家应该都不太陌生,大多情况下大家都只是使用,最近我研究了下 web 埋点,你要不要了解下。

现有埋点三大类型
用户行为分析是一个大系统,一个典型的数据平台。由用户数据采集,用户行为建模分析,可视化报表展示几个模块构成。现有的埋点采集方案可以大致被分为三种,手动埋点,可视化埋点,无埋点

手动埋点
手动代码埋点比较常见,需要调用埋点的业务方在需要采集数据的地方调用埋点的方法。优点是流量可控,业务方可以根据需要在任意地点任意场景进行数据采集,采集信息也完全由业务方来控制。这样的有点也带来了一些弊端,需要业务方来写死方法,如果采集方案变了,业务方也需要重新修改代码,重新发布。

可视化埋点
可是化埋点是近今年的埋点趋势,很多大厂自己的数据埋点部门也都开始做这块。优点是业务方工作量少,缺点则是技术上推广和实现起来有点难(业务方前端代码规范是个大前提)。阿里的活动页很多都是运营通过可视化的界面拖拽配置实现,这些活动控件元素都带有唯一标识。通过埋点配置后台,将元素与要采集事件关联起来,可以自动生成埋点代码嵌入到页面中。

无埋点
无埋点则是前端自动采集全部事件,上报埋点数据,由后端来过滤和计算出有用的数据,优点是前端只要加载埋点脚本。缺点是流量和采集的数据过于庞大,服务器性能压力山大,主流的 GrowingIO 就是这种实现方案。

我们暂时放弃可视化埋点的实现,在 手动埋点无埋点 上进行了尝试,为了便于描述,下文我会称采集脚本为 SDK。

思考几个问题
埋点开发需要考虑很多内容,贯穿着不轻易动手写代码的原则,我们在开发前先思考下面这几个问题

我们要采集什么内容,进行哪些采集接口的约定

业务方通过什么方式来调用我们的采集脚本

手动埋点:SDK 需要封装一个方法给业务方进行调用,传参方式业务方可控

无埋点:考虑到数据量对于服务器的压力,我们需要对无埋点进行开关配置,可以配置进行哪些元素进行无埋点采集

用户标识:游客用户和登录用户的采集数据怎么进行区分关联

设备Id:用户通过浏览器来访问 web 页面,设备Id需要存储在浏览器上,同一个用户访问不同的业务方网站,设备Id要保持一样,怎么实现

单页面应用:现在流行的单页面应用和普通 web 页面的数据采集是否有差异

混合应用:app 与 h5 的混合应用我们要怎么进行通讯

我们要采集什么内容,进行哪些采集接口的约定

第一期我们先实现对 PV(即页面浏览量或点击量) 、UV(一天内同个访客多次访问) 、点击量、用户的访问路径的基础指标的采集。精细化分析的流量转化需要和业务相关,需要和数据分析方做约定,我们预留扩展。所以我们的采集接口需要进行以下的约定

{
    "header":{ // HTTP 头部
        "X-Device-Id":" 550e8400-e29b-41d4-a716-446655440000", //设备ID,用来区分用户设备
        "X-Source-Url":"https://www.baidu.com/", //源地址,关联用户的整个操作流程,用于用户行为路径分析,例如登录,到首页,进入商品详情,退出这一整个完整的路径
        "X-Current-Url":"", //当前地址,用户行为发生的页面
        "X-User-Id":"",//用户ID,统计登录用户行为
    },
    "body":[{ // HTTP Body体
        "PageSessionID":"", //页面标识ID,用来区分页面事件,例如加载和离开我们会发两个事件,这个标识可以让我们知道这个事件是发生在一个页面上
        "Event":"loaded", //事件类型,区分用户行为事件
        "PageTitle":  "埋点测试页",  //页面标题,直观看到用户访问页面
        "CurrentTime":  “1517798922201”,  //事件发生的时间
        "ExtraInfo":  {
         }    //扩展字段,对具体业务分析的传参
    }]
}

以上就是我们现在约定好了的通用的事件采集的接口,所传的参数基本上会根据采集事件的不同而发生变化。但是在用户的整一个访问行为中,用户的设备是不会变化的,如果你想采集设备信息可以重新约定一个接口,在整个采集开始之前发送设备信息,这样可以避免在事件采集接口上重复采集固定数据。

{
    "header":{ // HTTP 头部
          "X-Device-Id"  :"550e8400-e29b-41d4-a716-446655440000"  ,      //  设备id
    },
    "body":{ // HTTP Body体
              "DeviceType":  "web" ,   //设备类型
             "ScreenWide"  :  768 , //  屏幕宽
             "ScreenHigh":  1366 , //  屏幕高
             "Language":    "zh-cn"  //语言
    }
}
业务方通过什么方式来调用我们的采集脚本

埋点应该让调用的业务方,尽可能少有工作量,最好是什么都不用做,

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/95089.html

相关文章

  • Android 性能监控系列一(原理篇)

    摘要:全称应用性能管理监控后面我会通过一系列的文章来介绍的原理框架设计与实现等等。在应用构建期间,通过修改字节码的方式来进行字节码插桩就是实现自动化的方案之一。 showImg(https://segmentfault.com/img/bVbbRX6?w=1995&h=1273); 欢迎关注微信公众号:BaronTalk,获取更多精彩好文! 一. 前言 性能问题是导致 App 用户流失的罪魁...

    yacheng 评论0 收藏0
  • 前端监控实践——FMP的智能获取算法

    今天来给大家介绍下前端监控中一个特定指标的获取算法,有人会问,为啥就单单讲一个指标?这是因为,目前大部分的指标,比如白屏时间,dom加载时间等等,都能通过现代浏览器提供的各种api去进行较为精确的获取,而今天讲的这个指标,以往获取他的方式只能是通过逻辑埋点去获取它的值,因此在做一些前端监控时,需要根据业务需要去改变页面对这个值的埋点方式,会比较繁琐,恰巧最近刚刚好在做一些前端监控相关的项目,遇到这...

    xzavier 评论0 收藏0
  • 前端网页加载渲染链路优化

    摘要:所以,关于优化实战我们主要分为两部分加载渲染链路优化和编程代码优化。加载渲染链路优化从访问到页面呈现,整个链路可以做优化的思路。资源缓存这一节我们单独介绍缓存,是的,利用好缓存可以解决很多问题,包括页面加载和渲染的问题都能得到很好的优化。 优化实战 本文属于思否课堂VirtualDOM到AST玩转前端性能原理解析与代码实战课程官方博客:fed123.com 我们已经全面分析总结了评估页...

    zhaofeihao 评论0 收藏0

发表评论

0条评论

MASAILA

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<