PAYATHON 2026

Google Analytics 登录用户活动统计少报约 67%，如何排查？

数据小许

仅凭页面中的 user_id 渲染正确，无法确定 Google Analytics 是否完整收到了登录用户的活动，也无法解释约 67% 的差额。原代码在页面加载时通过 config 设置 user_id，这个思路是正确的。还需要分别检查统计口径差异、事件未发送和登录状态未及时同步的情况。

以下按 GA4 说明。原问题没有提供实际衡量指标、数据库对照方式和完整采集流程，暂时无法确定具体根因。

先确认双方统计的是同一件事

Signed in with user ID exactly matches yes 是比较通过 User-ID 识别的登录用户的有效条件，但它不能保证结果与数据库记录数量相等。Google 的 User-ID 说明

先明确“活动”指的是什么：

  • 用户数：数据库应统计同一时间段内发生目标行为的去重账户数，不能直接与累计注册账户数比较。
  • 登录次数：应比较登录成功记录与对应的 login 事件，不能与用户数比较。
  • 页面浏览量或业务操作次数：需要确认前端是否为相同行为发送了对应事件。后台请求次数通常也不等于页面浏览量。

还要检查报表使用的是 Active users 还是 Total users。二者定义不同，登录过的用户不一定满足活跃用户条件。GA4 用户指标定义

对账时统一日期、时区、生产环境和数据流，选择已经完成处理的数据区间。不要将当天仍在变化的报表与即时数据库记录直接相减。

检查实际请求，不能只看页面源码

页面源码只能证明 Rails 输出了 ID。即使 gtag.js 加载失败，初始化代码仍可能把命令留在 dataLayer 队列里。

使用一个测试账户，打开浏览器开发者工具的 Network 面板，完整执行登录、浏览、业务操作和退出流程，逐项检查：

  1. gtag.js 是否成功加载，Console 是否存在脚本错误或 CSP 拦截。
  2. 是否实际发出了 Analytics 采集请求。常见请求路径包含 g/collect；使用代理或其他部署方式时，请按实际端点查找。
  3. 请求是否发往预期数据流，相关事件是否包含正确的用户标识。直接发送的 GA4 Web 请求中通常可以看到 uid。
  4. 登录后的第一页、后续页面以及关键操作是否都能重现正确结果。

原代码中的 [GOOGLE-ID] 和 [GOOGLE ID] 看起来是占位符。应检查实际部署值是否指向预期的 Google tag 和 GA4 数据流，不能仅凭占位符的写法认定配置有误。

自己的浏览器测试通过，只能证明这一条访问路径正常。还应抽查其他浏览器、设备和用户常用入口。

排查采集被阻止的情况

如果后台记录了业务操作，但浏览器没有发送 Analytics 请求，应检查广告拦截扩展、网络限制、脚本加载失败和同意管理配置。

如果站点使用 Consent Mode，需要区分部署方式：Basic consent mode 在用户未同意时可以完全阻止 Google tags；Advanced consent mode 可以在拒绝状态下发送无 Cookie 的测量请求。因此，不能一概认为用户未同意就不会有任何请求。Consent Mode 官方说明

这些都是排查方向，不能根据 67% 的比例反推具体原因。登录网站成功和允许 Analytics 采集也是两个独立的状态。

检查登录状态是否在事件发送前更新

原来的 ERB 判断只在服务器渲染页面时执行。如果每次登录和页面跳转都会重新加载完整页面，这种方式可以在新页面设置 user_id。

如果站点使用 Turbo、Turbolinks 或局部更新，并且相关导航没有重新执行这段 head 脚本，就要检查以下情况：

  • 页面最初以未登录状态加载，登录成功后没有更新 Analytics 配置。
  • 页面或脚本片段被缓存，输出的用户状态没有随实际账户变化。
  • 事件先发送，随后才设置 user_id。
  • 退出或切换账户后，页面仍保留旧用户的 ID。

这些情况是否存在，需要结合站点实际导航和缓存行为验证，不能仅凭使用 Rails 就作出判断。

如果 Analytics 已经初始化，而登录状态在当前页面内发生改变，可以为目标数据流更新配置：

const measurementId = 'G-XXXXXXXXXX';

// 在登录成功后、发送后续业务事件前执行。
function onLoginSucceeded(userId) {
  gtag('config', measurementId, {
    user_id: String(userId),
    send_page_view: false
  });
}

// 在退出成功后执行，清除当前身份。
function onLogoutSucceeded() {
  gtag('config', measurementId, {
    user_id: null,
    send_page_view: false
  });
}

将 G-XXXXXXXXXX 替换为实际 Measurement ID，并把函数接到真实的登录、退出成功回调中。send_page_view: false 用于避免这次配置调用额外发送默认的 page_view；它不会关闭其他独立的页面浏览采集机制。页面浏览采集说明

退出时使用 JavaScript 的 null，不要使用字符串 'null'。从未登录的用户可以不设置 user_id；已登录用户应使用稳定、唯一的 ID，也不需要为 user_id 注册自定义维度。User-ID 配置说明

最后检查报表配置并定位差额

确认属性的 Reporting Identity 包含 User-ID，例如使用 Observed 或 Blended，同时检查是否存在额外比较条件或数据过滤器。User-ID 与 Reporting Identity

如果已经启用 BigQuery Export，可以按同一时间区间和目标事件检查导出的 user_id，与后台去重账户或操作记录逐项核对。不要默认 BigQuery 原始事件统计与 GA4 界面指标完全相同。User-ID 数据分析说明

定位差额时，沿同一条链路核对后台是否记录操作、浏览器是否发送事件、事件是否带正确 ID，以及导出或报表中是否出现记录，再判断差额发生在业务口径、客户端采集还是报表处理环节。现有材料不足以证明 GA4 固定漏报了 67%，也不适合直接按该比例修正统计结果。

备注：内容仅供参考。