为何你统计 PV 的方式是错的？

翻译自 Google 工程师 Philip Walton 的文章。共 3754 字，读完需 7 分钟。合格的工程师要能认识到数据和功能同样重要，由于准确的数据收集是产品迭代、市场营销的决策基础。本文会帮你剖析为何你经常使用的统计方式是错的？而后给出可行的解决方案。

直言不讳的说，目前市面上的 Page View（常说的PV，即用户浏览页面的次数）统计工具没法准确统计愈来愈多的新站点，且已经和 WEB 技术的演进方向彻底脱节。

由于在大多数状况下，这些工具假设每次页面浏览（Page View）对应一次页面加载（Page Load），且每次页面加载完成后都会运行一些统计代码，将 Page View 事件发送到后端服务器。任何不符合这种模式的网站都须要工程师作额外的工做才能统计到正确的结果，然而大多数前端工程师彷佛不具有这方面的专业知识，或者干脆没有时间。

现实是，WEB 技术在过去 10 年间发生了巨大的变化，愈来愈多的网站已经不符合传统的网站模式，而咱们的分析工具演化并无跟上。

问题在哪儿？

举个具体的例子，考虑 mail.google.com（Gmail），使用 Gmail 的大多数人在首次打开后会保持它在后台运行，每隔一段时间去检查是否有新消息，若是有新消息，会直接打开阅读，整个过程无需刷新页面。

因为绝大多数 Gmail 用户几乎历来不刷新页面，从统计分析的角度就产生了一些很是有趣但重要的疑问：

• 若是用户打开 Gmail 一次，而在接下来的几天以内使用数百次，可是并无刷新页面，这种状况应该只算一个 Page View 么？
• 若是用户点击 Gmail 左上角的 Logo 来刷新页面内容，或者移动端的下拉刷新，是否应该算一个新的 Page View？这种动做与彻底刷新页面有何不一样？
• 若是用户打开并阅读一封新邮件，实际上无需刷新页面，是否应该计算为一个新的 Page View？
• 若是两个用户天天访问 Gmail 的次数彻底相同，可是其中一个每次刷新，而另外一个保持页面在后台运行，这两种使用模式的 Page View 统计结果应该有很大的不一样么？

列举这些疑问想说明的问题是，对于某些站点，继续使用传统的 Page View 统计方法会致使不许确的统计结果，而在 WEB 应用的技术实现方案随时间推移不断演进的状况下，这种不许确会变的很是离谱。

试想，你在传统的 WEB 网站中添加了统计代码，几个月后，你将该网站更新为单页应用（SPA，或 Single Page Application），而没有修改统计代码代码。再过几个月，你又将网站更新为渐进式 WEB 应用（PWA，或 Progressive Web Application），这种技术能够在后台从新加载内容并脱机工做），这时候你仍然没有更新统计代码。若是这段时间应用的访客数量及使用模式没有变化，你确定会指望统计结果不出现大幅度波动。

不幸的是，在上述状况下，即便你改善了用户体验，但 Page View 的统计结果能够确定是降低的。这是一个很是糟糕的状况：你但愿改善网站的交互体验，可是没法用数听说服任何人这样作是值得的，由于统计数据给出的结果是彻底相反的。

该怎么解决？

任何技术问题总会有解决办法，本文提出的解决方案则须要回归 Page View 这个指标的本原。咱们须要追踪的不是页面被加载（loaded）的次数，而是被浏览（viewed）的次数。

咱们能够利用 Page Visibility API 达成目的，实际上该 API 已经存在了很长时间，而且几乎全部的主流桌面和移动浏览器都支持。

事实证实，统计页面被浏览的次数而不是被加载的次数能优雅地解决掉传通通计方式不能处理的不少问题：

• 当用户打开的某个选项卡转入后台，而后在几小时或几天以后再切回来，但不从新加载页面；
• 当用户打开某个页面做为参考，并来回切换以快速浏览其中的内容，但不从新加载页面；
• 当用户在后台选项卡中打开页面，而后忘记了，历来没有实际浏览页面内容；

Page Visibility API 由 document.visibilityState 属性以及 visibilitychange 事件组成。基于这两个 API，你能够确保只会在页面的 visibilityState 可见时才发送 Page View 统计。此外，你还能够监听 visibilitychange 事件，在用户从新切回到在后台运行有段时间的应用时发送新的 Page View 统计。Page Visibility API 很好的解决了加载完成后几乎不须要刷新的 WEB 应用的 Page View 统计问题。

解决方案的第二部分是 History API，这是 SPA 应用构建的基础技术，目前主流浏览器都支持（详见），所以统计工具能够经过监听 URL 变化来发送相似于传统网站的页面统计。

该怎么实现？

利用 Page Visibility 和 History API 来准确统计 Page View 的基本思路以下（这种思路适用于传统网站、SPA、PWA）：

1. 页面加载时，若是页面的 visibilityState 是可见的，发送 Page View 统计；
2. 若是页面的 visibilityState 是隐藏的，就监听 visibilitychange 事件，并在 visibilityState 变为可见时发送 Page View 统计；
3. 若是 visibilityState 由隐藏变为可见，而且自上次用户交互以后已通过了“足够长”的时间，就发送新的 Page View 统计；
4. 若是 URL 发生变化（仅限于 pathname 或 search 部分发送变化, hash 部分则应该忽略，由于它是用来标记页面内跳转的) 发送新的 Page View 统计；

上述步骤 3 是最重要的，但同时也是最模糊的和颇具争议的，关键的问题是：究竟多长才算是“足够长”？一方面，你可能并不想在每次 visibilityState 发生变化的时候都发送新的 Page View 统计，由于对于用户来讲，在选项卡之间来回切换是很是常见的，而实际状况是，某些应用同时在多个选项卡中打开使用是最方便的，而这就伴随这大量的选项卡切换。另外一方面，你又指望统计到在一段时间没有和应用交互以后用户的回访（returning）行为，也就是说须要统计到用户屡次使用的行为。

幸运的是，全部的统计工具都定义了一种区分屡次使用的方式，即会话，或者叫 Session。会话是在给定时间窗口中发生的用户交互的集合，当某个预设的时间段过去时会话就结束了。好比，默认状况下 Google Analytics 的会话在 30 分钟无交互的状况下结束。而大多数统计工具都提供了会话时长自定义的功能。

因此回到上面列表中的第三步，个人建议是，若是用户会话已结束，而且页面的 visibilityState 从隐藏变为可见，则应发送新的 Page View 统计。在会话内发生的 visibilityState 变动不该被视为不一样的 Page View。

注意：若是你使用 autotrack（特别是 pageVisibilityTracker 和 urlChangeTracker 插件），你就无需本身实现上面的逻辑。这些插件能够自动处理全部这些状况，固然你可使用配置项来自定义插件的行为）。

如何减小误报？

在为 autotrack 建立 pageVisibilityTracker 插件时，我对基于 Page Visibility API 的多种实现方案进行了大量完全的测试，发现利用启发式信息在避免误报上是很是必要的。

例如，用户使用键盘快速在一堆打开的标签页中来回切换，结果是不少页面的 visibilityState 从隐藏变为可见，可是很快又恢复原状。在个人测试中，有至关比例的 Page View 是因为在会话超时后 visibilityState 变为可见致使，可是紧接着 visibilityState 又恢复为隐藏。而 99% 相似这种的页面从可见恢复为隐藏状态的间隔都在 5 秒之内。

当我分析本身的使用模式以后，这种现象的存在并不奇怪，很常见的操做有：意外的切换到一个选项卡，可是很快就离开了；切换到一个选项卡，只由于我要切换到其余的选项卡，而这个选项卡恰好在夹在中间（这里使用键盘切换）；切换到某个选项卡，只是为了关闭它。在全部这些状况下，发送新的 Page View 并无任何意义，而在上报 Page View 统计以前设置 5 秒的超时能够防止 99％ 以上的误报。

Page View 和 Page Load

有时候你可能想了解你的网站加载（Page Load）了但从未被浏览过的频率，你可能还想知道页面浏览是由初始页面加载触发仍是由 visibilityState 或 URL 变化致使的。

显然你能够建立一个自定义维度来统计页面加载（实际上我一般会这样作），可是透过这个问题咱们能清楚的认识到，咱们真正须要的是两个独立的指标：页面浏览（Page View）和页面加载（Page Load）。幸运的是，现在的大多数统计工具容许用户自定义指标来统计他们想要的任何数据，而 autotrack 支持经过配置项 帮你把页面浏览与页面加载的统计分开。

经过将页面浏览与页面加载解耦，咱们就能彻底掌握 Page View 这个指标的真实含义：测量用户实际浏览页面的次数，而不管页面加载了多少次。

Page View 和 Session

有些读者可能会嘀咕：只要你正确的统计到了初次页面加载后用户的全部交互，只统计首次页面加载又有什么关系呢？Page View 的正确统计为何相当重要呢？

虽然看起来彷佛是一个合理的问题，但若是你了解大多数统计工具使用的数据模型，你将很快意识到这些问题自己是站不住脚的。

大多数分析工具假定每一个会话都至少包含一个 Page View，该 Page View 用于肯定诸如 Landing Page（落地页）和 Exits（跳出页）等指标。若是你仅仅统计了初次页面加载，而后后续全部会话只包含事件统计，则大多数会话报告变得一团糟。而几乎全部的传统 WEB 统计工具都使用这种模型来计算，这也从侧面印证了传统模型的局限性。

暂且把工具限制放在一边，另一个让你信服的论据是：全部包含了用户交互事件的会话都应该至少包含一次 Page View，毕竟，若是没有打开页面，你怎么跟它交互呢？在会话超时、visibilityState 变为可见时发送新的 Page View 能好好的解决这个问题。

总结和 TIPS

但愿你读完这篇文章，能从新思考 Page View 的正确姿式，若是你在本身项目中使用了统计工具，能够结合本文的建议把统计作到准确。

统计工具应该衡量的是用户参与度，而不该该与网站的技术实现相耦合。当用户体验改善时，咱们应该能够经过统计工具的分析报告来证实。这是利用技术推进业务发展最直接的方法。

若是你使用的是 Google Analytics，则能够经过使用 autotrack（强烈建议 SPA 或 PWA 项目使用）来将本文的解决方案运用到项目中，要查看如何配置 autotrack 的示例？请移步 analyticsjs-boilerplate 仓库。

One More Thing

本文译者王仕军，商业转载请联系做者得到受权，非商业转载请注明出处。若是你以为本文对你有帮助，请点赞！若是对文中的内容有任何疑问，欢迎留言讨论。想知道我接下来会写些什么？欢迎订阅知乎专栏：《前端周刊：让你在前端领域跟上时代的脚步》。