Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

前端展示类埋点的坑

  在产品设计上常常需要了解页面上的某个部分到底给用户展现了多少次,然后根据这些数据来进一步优化产品。比起一般的交互事件埋点,这些展示类的埋点就麻烦得多。首先它的概念就很不明确,也没有一个规范。浏览器更不可能提供一个 onvisit 之类的事件来做这些。
  我觉得应该先明确一下概念。展示类的监控大概可以分为三个级别:
  • 元素存在
  • 元素为可见状态
  • 元素在可见区域内
  「元素存在」这种程度的监控大概是 PV 的级别,只要页面被浏览,并且页面渲染后存在相应的元素则记录下来。这对于后端渲染的架构而言,和 PV 几乎就是等价的。但如果是前端渲染可能就比较麻烦。因为元素可能是由于某个 API 请求完成后动态生成的 DOM。
  展示类埋点的难点就在这里,如何记录动态生成的元素?如果前端完全基于某个带 View 层的框架,那么监控到元素变化就是有可能的。比如 Angular、React、Polymer 等,我们完全可以监控某个组件的生命周期。但是如果只是 jQuery 甚至原生,要兼容地实现元素监控就很困难(不考虑兼容性的话可以用 MutationObserver)。这个问题我考虑了很久,直到目前也没有一个漂亮的解决方案。最终唯有以计时器对 DOM 做轮询这种恶心的方案来实现,如果大家有什么更好的做法跪求分享!
  有时候元素存在文档中并不代表它是展示状态,比如 banner 幻灯片、tab 控件之类的东西。元素可能在某个时间点才会显示,或者用户做了某些操作后它在会显示。对于这类东西的监控,就算是 MutationObserver 也很难做到了,因为它不仅和 DOM 树结构有关,还和 CSS 有关。而且元素显示状态的定义也是奇奇怪怪的。比如 opacity: 0 算显示么?z-index: -1 被别的元素挡住又算什么?具体细节是很复杂的,不过通常不会考虑到那么丧心病狂的程度,我自己的实现只会考虑 display: none、visibility: hidden (包括其容器的状态)这两种情况。
  最后一个级别也许是最能反映出用户行为的,但也是最麻烦的。不仅要考虑之前这些问题,还要考虑当前窗口的可见区域。这可能和滚动操作有关。有时候元素确实是显示的,只是用户没有将滚动条滚动到相应位置,所以即使元素是显示状态也未必看得见。而且,有些页面的数据根本就是滚动到底部时才加载更多,所以需要考虑的问题也会变得更多。
  其实如果能接受 DOM 轮询这种恶心的东西,实现下来也并不是很困难。首先是 DOM 轮询判断元素存在,当元素存在时判断它的显示状态、最后判断元素是否在可见区域内。
  总之对展示类的东西做监控本来就是个坑。或许可以转换一下产品上的统计指标来绕过这些需求?
网名:
54.158.194.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^