AI 生成页面上线前，补验 GA4 事件链路

你用一个周末，通过 vibe coding 做出了一个带潜客收集表单的落地页。演示一切正常：提交表单，看到成功提示，然后继续忙别的。两周后，你打开 GA4，发现明明提交了四十次的表单，只记录了三个事件——更糟的情况是，一个都没有。

这种问题在 AI 构建的应用中反复出现，原因在于开发流程本身，而不只是粗心。AI 一次性生成 UI 和埋点代码，却没人为一个“已经触发”的事件编写测试，毕竟事件有没有正常上报，页面都能照常加载。而且，分析埋点的故障天生就是静默的：按钮坏了会显示错误，generate_lead 事件坏了却什么都不会显示。你的漏斗就这样悄无声息地变得无法衡量。

下面这套人工验证流程，是在引入任何工具之前，如今就能切实奏效的方法。这些经验，都是在生产环境的 GA4 媒体资源中排查重复转化和毫无动静的 DebugView 时踩坑换来的。

1. DebugView 几乎证明不了什么。但还是要用，只是得用对。

GA4 DebugView 是大家首先查看的地方，也是最先误导你的地方。DebugView 只显示来自处于 debug 模式的浏览器或设备的事件，例如使用 GTM Preview、在 gtag 中设置 debug_mode: true，或者启用 GA Debugger 扩展。下面三种故障，几乎人人都会遇到：

• 事件出现在 DebugView 中，却始终没有进入标准报告——通常是 consent mode 默认设为 denied，或者混用了另一套媒体资源或 measurement ID，导致事件被发送到了测试媒体资源。
• DebugView 什么都没有显示，事件却在正常上报——你正在测试的环境根本没有设置 debug 标记。
• DebugView 在 GTM Preview 中正常工作，从正式站点访问却不行——预览环境与生产环境中的触发条件不同，例如用户同意状态、data layer 时序。

所以，用 DebugView 确认事件结构，也就是名称和参数；不要用它确认事件在生产环境条件下确实送达。

2. 检查实际的网络请求

真正可靠的依据是请求本身。打开 DevTools → Network，按 google-analytics.com/g/collect 筛选，提交表单，然后检查请求：

• en=——事件名称。这里的拼写错误是头号隐形杀手：generate_leads 永远匹配不上你构建报告时使用的 generate_lead。
• cid= / _ga cookie——客户端 ID。如果它在每次页面加载之间都会变化，那么每次提交看起来都像是一个全新的用户。
• ep.*——自定义参数。确认潜客的 value/label 确实随请求传了出去。
• gtm=——确认此次提供该标签的是哪个 GTM 容器版本。

对于 SPA，要检查两遍：一次在冷启动加载时，一次在客户端导航之后。路由切换产生的 page_views 和重复注册的监听器，只有在第二遍检查时才会暴露出来。

3. 检查重复事件：这个问题真的会让你花冤枉钱

如果每次提交都会触发两次 generate_lead，就会虚增转化次数，并污染后续所有出价策略。可靠的重复事件统计方法，不是盯着 DebugView 凭肉眼判断，而是在一个时间窗口内，按客户端 ID 计数：

• 使用 BigQuery 导出时，GA4 免费版也支持导出：查询最近一天的 events_*，按 user_pseudo_id、event_name 和 60 秒时间桶分组，统计每个桶内的事件数量。对于转化事件，任何计数 > 1 的时间桶，都可能存在重复。
• 不使用 BigQuery 时：进入 GA4 Explorations → 打开单次会话 → 检查这次会话中的转化事件数量，是否是预期的两倍。方法比较粗糙，但能抓出常见的 React StrictMode / double-render / retry 导致的重复事件。

每次发布埋点变更，都要做一次检查，而不是检查一次就一劳永逸。GTM 容器版本会变化。

4. 发布前的 10 项检查清单

在你宣布 AI 构建的应用已经“完成”埋点之前：

1. 每个计划中的事件都会触发，而且名称与文档完全一致（en=）。
2. 参数能够送达（ep.*），类型也正确，例如 revenue 应为 number，而不是 string。
3. 客户端 ID 在完整用户旅程中保持稳定：落地页 → 表单 → 感谢页。
4. 双击不会产生重复事件，重新进入 SPA 路由也不会产生重复事件。
5. 用户同意状态确实控制了你认为它应该控制的行为。
6. 事件能在生产环境中触发，而不只是在 preview/debug 环境中触发。
7. 感谢页只触发一次转化事件，并且尽可能以服务端确认的结果为依据。
8. 跨域链接，例如结账页、文档站，能够保持会话连续。
9. bot/preview/admin 路径上不会触发任何事件。
10. 你能在 10 分钟内从头复现第 1–9 项检查——否则，这套检查就不会再有人做，最终会逐渐失效。

我正在做的工具

这样的事情我经历得足够多了。其中一次，我审计了一个已经上线的电商部署，发现配置漂移导致折扣行为出现了可以量化的偏差，又是静默故障。因此，我开始围绕第 10 项开发一个开源工具：只需定义一次用户旅程，它就会驱动真实浏览器走完整个流程，底层基于 Playwright；在检查 API 和数据库状态的同时，对应该触发的分析事件进行断言，包括名称、参数、重复事件和用户同意状态，最后生成一份可以附在 PR 或发布记录中的证据包。

项目还处于早期阶段，尚未公开发布，所以目前没有链接可提供，也没什么值得过度宣传的。如果上面的第 2–3 节就是你这一周的写照，我很想知道，哪一部分最让你头疼：重复事件检测、参数断言，还是 consent-mode 验证？这会决定优先开发什么。欢迎留言或私信。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。