你的服务器容器会看到的每一个 GA4 事件，以及它们各自从哪里来

Google 代码带着你的衡量 ID 加载的那一刻，就有四个事件在流动，背后没有任何设置。Analytics 里没有关闭它们的开关，你的容器也无需请求它们。

• page_view——每次页面加载一次；在单页应用中，如果数据流的「网页变化」选项已开启，则每次路由变化一次。
• session_start——新会话的第一次命中。会话在三十分钟无活动后结束，所以两小时后回来的访客会开始另一次会话。
• first_visit——每个浏览器一次，发生在 GA4 从该浏览器看到的第一次会话。清除 Cookie 会再产生一次。
• user_engagement——页面在前台停留十秒后发送，或访客在互动后离开时发送。GA4 的互动时长就来自这里。

如果你只看到 page_view 而没有别的，代码是正常工作的。这不是故障，只是还没有人滚动到页面底部。

GA4 的增强型衡量在浏览器中另外收集九个事件，不需要为它们中的任何一个添加代码。它们在数据流上配置，而不是在 Tag Manager 中，所以服务器容器在不知道它们存在的情况下就会转发它们。

每一个的触发条件都比名字暗示的更严格。

• scroll——每个页面一次，且仅当页面高度的 90% 曾经可见时触发。不是随便滚动一下：是到达底部。比视口还短的页面永远不会触发它。
• click——出站点击，指向当前域名以外的域名。内部链接不算。事件名就是 click，带一个 outbound 参数；不存在 outbound_click。
• view_search_results——URL 中带有搜索查询参数（默认为 q、s、search、query 或 keyword）的页面加载。
• file_download——点击以文档、压缩包、音频、视频或电子表格扩展名结尾的链接。
• form_start 和 form_submit——与页面上某个表单的首次交互，以及该表单的提交。
• video_start、video_progress 和 video_complete——仅限嵌入的 YouTube 播放器，且仅当嵌入启用了 JS API 时。

接下来是让人耗掉几个星期的部分。这九个事件全都依赖数据流上增强型衡量的总开关，而通过 Analytics Admin API（而不是在 Analytics 界面里）创建的数据流，这个总开关是关着的。通过 API 读取设置时，每个单独的开关都返回 true；总开关则干脆不出现在响应里，因为它的值是 false，而 API 会省略为 false 的布尔值。于是配置看起来完全启用，实际却只送来 page_view。

我们是在自己的媒体资源上发现这一点的。SignalHost 为你创建媒体资源时会打开总开关；如果你的媒体资源是用别的方式创建的，而 scroll 始终不到达，请在 Analytics 中打开数据流，检查「增强型衡量」本身，而不是它下面的那些开关。

带来收入的事件——一笔销售、一条潜在客户线索、一次注册——是本页中唯一不会自动发送的事件。GA4 定义了它们的名称和格式；你的网站必须在事件发生的那一刻，把每一个推送到 dataLayer，名称一字不差。

每个 SignalHost 容器里，都已经有触发器和 GA4 事件代码在等待其中的十六个：

• 九个用于店铺的漏斗：view_item_list、view_item、add_to_cart、remove_from_cart、view_cart、begin_checkout、add_shipping_info、add_payment_info 和 purchase，每一个都附带一个 ecommerce 对象。
• 五个用于潜在客户线索：generate_lead、contact、schedule、submit_application 和 subscribe。
• 两个用于注册：sign_up 和 start_trial。

标准的 Shopify 主题一个都不会推送，WooCommerce 核心也不会。做这件事的是 dataLayer 应用或插件，而在 Shopify 上，结账事件需要一个 Custom Pixel，因为主题的容器从不在结账页面加载。只要你的网站推送了其中一个，转发它的代码就已经在那里——推送本身需要你来安排，关于 Shopify 和 WooCommerce 的那篇文章会精确说明该安装什么。

容器「事件」卡片上的「支持的事件」按钮列出了它们全部，以及每一个的含义和应该推送什么。如果你的容器已经用你自己的代码把其中某个事件发送给 GA4，SignalHost 会把这个事件留给你的代码，而不是把它计两次。

每一个经过你容器的衡量请求都按事件名、按天统计，保留 400 天。只保留名称——不保留 URL，不保留客户端 ID，不保留任何一个参数——正因如此，保留这么久才是安全的。这份清单就是到达你主机名的内容，所以它能回答一个 Analytics 自己回答不了的问题：浏览器到底发送了没有？

计数不均匀是正常的。每次页面加载都是一个 page_view；只有滚到底部的加载才是一个 scroll；只有超过十秒的会话才是一个 user_engagement。十次页面浏览、两次 scroll 的网站，是一个正常的网站。

有两件事会让这两份清单永远无法完全一致。没有回应横幅的访客仍然会发送每一个事件——以无 Cookie ping 的形式——容器会统计它，而 Analytics 会丢弃它；页面同时显示两个数字，让你分清哪个是哪个。另外，session_start 和 first_visit 永远不会出现在容器页面上：浏览器并不把它们当作事件发送，而是在第一个 page_view 上设置两个标记，由 Analytics 在它那一侧生成这两个事件。

在清单上方，卡片会统计这十六个事件中有多少个在过去三十天内到达过，这样你的网站忘了发送的那个就会很显眼。

两种情况，容器页面能把它们区分开。

如果事件不在容器的清单里，说明你的网站从未发送它。容器无法转发没有到达的东西。对标准事件，检查数据流的增强型衡量开关；对那十六个事件之一，检查 dataLayer 推送是否发生、名称是否正确、是否在应有的页面上。

如果事件在容器的清单里却不在 Analytics 里，说明它到达并被转发了，问题在 Google 那一侧：衡量 ID 错误、数据过滤器、媒体资源在另一个账号里而你看错了账号，或者只是报告延迟——实时报告几秒内就会显示，标准报告可能需要一天。

从零开始？请看服务器端 Google Tag Manager 分步设置指南。