滚动：测量深度并理解其局限

发布 02/05/2026 · 更新 01/11/2026 · 数据与绩效分析 · 6 分钟阅读 · 作者 Cyber Intelligence Embassy

内容摘要

滚动跟踪记录页面上到达的位置，不能证明阅读、理解或注意。分析应明确阈值、测量范围与分母。

本文目录

滚动跟踪记录页面上到达的位置，不能证明阅读、理解或注意。分析应明确阈值、测量范围与分母。

区分自动测量与自定义阈值

GA4增强型衡量在页面垂直90%深度首次可见时触发scroll，不会自动提供25%、50%、75%节点。自定义阈值需要独立埋点及去重，也应记录高度变化、延迟加载和动态导航。

结合任务解释信号

快速滚动或锚点链接可能不经连续阅读就到达底部；答案也可能位于顶部。应比较相似结构，并结合任务完成、错误与定性反馈。事件数、页面浏览量和用户数是不同单位。

界定收集范围

法国CNIL对某些受众测量跟踪器规定严格条件下的同意豁免。告知或汇总结果本身不能证明豁免。应记录目的、访问与保存期限；未测量访问不等于否定观察。

虚构示例：仅在测量范围内计算比例

虚构示例：仅在测量范围内计算比例
项目	数值	解释
已测量页面浏览量	100	仅包含已埋点且符合条件的范围。
到达90%的页面浏览量	60	每次页面浏览去重计算。
此范围内的比例	60 / 100 = 60%	不是独立用户数或阅读率。

来源

编辑核验日期：2026年11月1日。

滚动深度代表的是曝光度，而不是理解度。

滚动到某个页面深度并不能表明注意力集中或理解程度。当该信号与内容长度、可用时间和后续操作相关联时，它才更有意义。

明确阈值是应用于整个文档还是某个可见部分。
测试短页面、延迟加载、移动设备和回访情况。
将信号呈现为旅程指示器，而非阅读完成的证明。

一手资料：Google Analytics — Set up events. 相关方法：阅读实用指南.

数据连接完整性

连接可能增加行数并扭曲总计。

订单表的一行代表一笔订单，明细表的一行代表该订单中的一项商品。合并前检查重复键与空键。
按订单键汇总明细，再将结果关联到订单，避免每项商品都重复订单金额。与原订单表的合计核对。
LEFT JOIN保留没有明细的订单，但针对右表的WHERE条件可能再次排除这些订单。未匹配不等于金额为零。

可复现的验收案例

虚构示例：数据不代表客户或实际观察结果。

查看案例输入

{
    "orders": [
        {
            "id": 1,
            "total": 100
        },
        {
            "id": 2,
            "total": 200
        }
    ],
    "line_order_ids": [
        1,
        1,
        2
    ],
    "sum_before": 300,
    "sum_after_raw_join": 400
}

预期判断

400重复计算了一笔订单。先按订单汇总明细，恢复总额300。另测两笔各100的虚构订单：总额应为200。SUM(DISTINCT total)会返回100，删掉一个合法值。应核查标识符与连接基数，而非对金额去重。

可复现的SQL查询

虚构示例：两笔订单金额为100和200，三条明细关联到1、1、2。查询只使用VALUES，请在测试环境执行。

WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2))
SELECT COUNT(*) AS rows, SUM(o.total) AS total
FROM orders o JOIN lines l ON l.order_id = o.id;

WITH orders(id, total) AS (VALUES (1, 100), (2, 200)),
lines(order_id) AS (VALUES (1), (1), (2)),
per_order AS (
  SELECT order_id, COUNT(*) AS line_count
  FROM lines GROUP BY order_id
)
SELECT COUNT(*) AS orders, SUM(o.total) AS total
FROM orders o LEFT JOIN per_order l ON l.order_id = o.id;

直接关联得到三行、总额400；先汇总可恢复两笔订单、总额300。

WITH orders(id, total) AS (VALUES (1, 100), (2, 100))
SELECT SUM(total) AS correct_total,
       SUM(DISTINCT total) AS distinct_total
FROM orders;

金额为100和100时，正确合计为200，而SUM(DISTINCT total)返回100。

验证步骤

定义订单和明细的粒度。
连接含两条明细的订单。
保留键、行数及核对后的总额。

PostgreSQL — Table expressions and joins

SUM(DISTINCT total)能解决问题吗？

不能。两笔金额100的订单合计为200，而SUM(DISTINCT total)只返回100。应修正键的关联关系，而非按金额去重。

一手资料：PostgreSQL — Table expressions and joins. 相关方法：阅读实用指南.

无障碍数据表

移动端也应能够理解单元格关系。

用caption标识表格，用th标记表头。简单表中scope="row"和scope="col"明确方向；保留数值对应的单位和期间。
横向滚动区域应可用键盘到达，并能查看全部列。改为卡片时重复标签和单位，不删掉比较所需的信息。
用键盘和屏幕阅读器寻找某单元格、行、列及单位。排序或筛选后再次测试；外观正确不能证明朗读的对应关系正确。

可复现的验收案例

虚构示例：数据不代表客户或实际观察结果。

查看案例输入

{
    "column_headers": [
        "2025",
        "2026"
    ],
    "row_headers": [
        "A",
        "B"
    ],
    "cell": {
        "row": "B",
        "column": "2026",
        "value": 42
    },
    "layout": "mobile"
}

预期判断

移动端中，数值42也必须保持与B和2026的关联。

验证步骤

识别行头、列头及单位。
用键盘和辅助技术读取单元格。
移动适配及缩放后保留关联。对关键单元格，在滚动后仍需找回行、列和单位；脱离表头的可读数值也可能被误解。

W3C WAI — Tables tutorial

一手资料：W3C WAI — Tables tutorial. 相关方法：阅读实用指南.