阅读时长
一个页面可能吸引用户浏览，也可能在三秒内被弃之不顾。阅读时长就是区分这两种情况的指标——而且大多数分析工具都会把这个指标算错，只有查看原始数据时才会发现这一点。
你将获得什么#
文档中的每个页面都会显示平均阅读时间，并且可以按该时间对“页面”和“标题”卡片进行排名。没有测量数据的页面会显示破折号，而不是 0——显示零会让人以为“没有人停留”，但实际情况是“没有进行测量”。
阅读时间按每个页面，而不是每次访问计算：读者打开三个页面时，每个页面都会获得各自的秒数，而不是让三个页面看起来都像最繁忙的那个页面一样。
阅读此报告不会消耗项目余额，并且所有方案均可使用。
它是如何构建的#
一个片段，而不是一个秒表。跟踪器会在页面打开时启动计时器，并在读者离开页面时读取计时——在 pagehide 时、站内导航到另一个页面时，以及在 iOS 上的 visibilitychange → hidden 时，此时 pagehide 不可靠。每次读取都会发出一个携带这段秒数的 docs.read_time 事件，并重置计时器。因此，隐藏标签页后又返回的读者会产生两个片段，而不是一个被重复计算的时间段。
少于 3 秒的片段永远不会被发出。低于这个时长，说明读者只是经过；记录它只会给页面平均值增加噪声，而不会增加一次有效阅读。
通过信标发送。阅读时间、标题查看次数和离开事件通过 navigator.sendBeacon 发送到同源端点，每个信标最多批量发送 100 个事件，因为普通日志传输会在 fetch 上进行两秒防抖，并且无法在标签页关闭后继续工作。每个收集器都是幂等的：它只返回尚未发送的事件，因此 iOS 隐藏状态下的刷新随后再加上真正的离开不会重复计算，而从后退/前进缓存恢复的页面也可以再次刷新。
每个片段在进行任何求和之前都会被截断到 300 秒。整个报告都建立在这个数字之上。当桌面标签页处于后台时，发射器仍会继续计时；在一次针对7 个工作区的 11,176 个真实会话的校准扫描中：有 40 个独立片段超过了两小时，第 99 百分位数为81,342 秒——22 小时——而将原始片段相加，会把总阅读时间从真实的42,160 秒膨胀到 1,268,422 秒，大约是三十倍。
截断规则只在一个无导入的模块中定义一次，并重新导出给所有引用时间数值的组件——每页平均值、访问摘要、聊天表格的“站点停留时间”列、目标层和 MCP 工具。第一个“站点停留时间”定义旁边的另一列采用更宽松的定义，正是导致关于同一位读者的两个数字开始不一致的原因。
平均值按片段数计算，而不是按访问次数计算。一位切换到其他标签页后又返回的读者，会为一次访问贡献两个片段；按访问次数计算平均值会让这次访问被计算两次。
机器人使用与仪表板其他部分相同的 User-Agent 过滤器排除，因此页面的阅读时间能够与查看次数对应起来。行为爬虫闸门——没有 JavaScript 发出事件的访问，无论其 User-Agent 声称是什么，都是爬虫——需要完整的会话重建，因此会在访问层应用；请参阅测量方式。
页面阅读时间告诉你的信息#
阅读时间是一种比较，而不是结论：它必须结合页面长度 以及页面所承担的任务来解读。
| 形态 | 可能的阅读情况 | 改进措施 |
|---|---|---|
| 复杂页面的阅读时间较短 | 不清晰、过长或结构不佳 | 在重写前先重新组织结构 |
| 简短页面的阅读时间较长 | 读者是在反复阅读，而不是享受阅读 | 澄清他们卡住的段落 |
| 教程中阅读时间一致 | 读者正按预期推进 | 无需改动 |
| 浏览量高，阅读时间接近于零 | 页面赢得了点击，却失去了读者 | 开头没有回应吸引他们前来的问题 |
将其与标题浏览量结合起来：阅读时间说明他们停留了多久，标题浏览量 说明他们读到了多深。较长的阅读时间集中在前两个标题中，说明读者卡住了，而不是投入其中。
为什么这是正确的方式#
| 规则 | 原因 | 来源 |
|---|---|---|
退出时事件必须通过 beacon 发送，而不是使用防抖的 fetch |
Beacon 请求“可确保在页面卸载前启动，并且允许运行至完成” | W3C Beacon API |
监听 pagehide，并额外监听可见性变化 |
unload“仍然不可靠，因此除非绝对必要，否则应避免使用”；pagehide“会在 unload 事件触发的所有情况下触发”，并且还会在进入 bfcache 时触发 |
web.dev：bfcache |
| 页面在隐藏时仍持续计数，测量的就是错误的对象 | 之所以存在 Page Visibility API，是因为开发者“一直以来都将网页设计得仿佛它们始终可见” | W3C Page Visibility Level 2 |
| 最佳实践的目标是前台时间 | GA4 将用户参与度定义为“某人在聚焦于您的网页时所花费的时间” | GA4：用户参与度 |
| 按页面记录的阅读时长优于从会话推导出的时长 | Universal Analytics 将没有参与度命中的会话中最后一个页面的时长计算为“最后一个页面的第一个命中时间 - 第一个页面的第一个命中时间”——最后一个页面，也就是读者选择结束阅读的页面，完全没有贡献数据 | Universal Analytics：会话时长 |
| 短横线胜过零 | 在未测量的页面上自信地显示 0，无法与已测量的放弃行为区分开来，而这两者中只有后者可以采取行动 |
机制，本页 |
最后一行正是 Docsbook 发出自身退出事件，而不是根据页面浏览之间的间隔推断时间的全部原因。一次访问的最后一个页面——读者停留的页面，通常也是您最想评估的页面——恰恰是基于间隔的测量无法观察到的页面。
限制与未决问题#
- 阅读时间会被截断，而不是根据可见性进行限制。在桌面设备上，后台标签页 会持续累计秒数，直到 300 秒的截断机制停止计时。因此，误差的方向（偏高）和 上限（每个区段 300 秒）都是已知的，这也是该数据可用的原因——但它并不等同于 根据焦点限制的参与时间，本页面也没有声称二者相同。如果您的读者习惯于将文档 停留在后台标签页中，请将该数值视为上限。
- 单次连续打开时间超过五分钟的页面会被记录为五分钟。对于读者确实完整阅读的 长篇教程，这会导致数据偏低。与闲置标签页造成的三十倍高估相比，该截断机制以 罕见的长时间阅读所造成的有限低估作为代价。
- 尚待明确：“平均阅读时间”并不等于“平均注意力”。可以验证的是上述机制——区段、 下限、截断值和除数。无法从这些数据中验证的是读者是否正在注视屏幕。没有任何 网站分析产品能够测量这一点，也不应有产品暗示自己能够测量。
- 禁用 JavaScript 的读者以及爬虫完全不会贡献阅读时间。他们的页面浏览量仍会计入， 因此，被大量爬取的页面可能会显示较高的浏览量，但阅读时间样本却很少。
- 三十天就是全部历史数据。无法据此绘制长期阅读时间趋势。
如何打开阅读时长报告#
- 打开您的文档网站。
- 浮动小部件 → 分析选项卡。
- 按
Reading time对页面或标题卡片进行排名。
Reading time 仅在页面和标题中提供。对于表示文档中某个位置的行，它有实际含义；而对于表示国家或浏览器的行，它没有实际含义，因此仅在这些位置提供，在其他任何位置都不提供。