Google 代码网关是什么？用第一方域名提高 Google 数据采集稳定性

前面讲过 Consent Mode（同意模式）。它解决的是一个很重要的问题：用户进入网站之后，是否同意网站进行相关的数据收集和广告追踪。

但即使用户已经同意，也还有另外一个问题：这些数据能不能稳定地发送到 Google？

随着浏览器隐私机制不断加强，广告拦截工具越来越普遍，第三方资源和请求也更容易受到限制。对于正在投放 Google Ads、使用 GA4 的企业网站来说，这就可能出现一个比较尴尬的情况：

网站明明收到了询盘。
用户明明提交了表单。
甚至订单已经产生了。

但 Google Ads 或 Analytics 里，却没有记录到对应的数据。所以，除了 Consent Mode 之外，Google 又提供了另外一种方案: Google 代码网关（Google tag gateway for advertisers）。

传统的 Google 代码是怎么工作的？

我们平时在网站里安装 Google tag、gtag.js 或 Google Tag Manager，本质上都是浏览器直接和 Google 的相关服务进行通信。

例如：浏览器 → Google

页面加载 Google tag 时，请求 Google 的资源。用户触发事件之后，测量数据也会发送到 Google。

这种方式非常直接，也是最常见的部署方式。

但问题同样明显：浏览器看到的就是一个 Google 的第三方请求。

在某些浏览器环境、广告拦截插件或者网络策略下，这类请求更容易受到影响。一旦请求没有正常发出去，Google 自然也就收不到对应的数据。

Google 代码网关改变了什么？

Google 代码网关并没有把你的 Google Ads、GA4 或 GTM 重新做一遍。它实际上是在网站和 Google 服务之间增加了一层自己的第一方基础设施。

原来的路径是：浏览器 → Google

使用 Google 代码网关之后，则变成：浏览器 → 你的网站域名 → Google

网站首先从自己的域名加载 Google tag。当标签触发测量请求时，其中一部分请求也会通过你自己的第一方域名发送到 Google。

从浏览器的角度来看，请求首先发生在当前网站域名下。这可以减少一部分对第三方请求的依赖，从而提高测量的稳定性。Google 也将减少第三方交互和改善衡量能力作为代码网关的主要用途之一。

这和传统的服务器端埋点又不太一样。服务器端埋点通常需要服务器主动接收事件、处理数据，然后再发送给 Google。而代码网关更多是一个请求转发层。

浏览器还是执行原来的 Google tag，事件还是在客户端产生，只是原来直接发送给 Google 的部分请求，改为先经过网站自己的第一方路径。所以，对于已经使用 Google Ads、GA4 或 GTM 的网站来说，改造起来会相对简单。

怎么部署 Google 代码网关？

Google 官方目前支持通过 CDN、负载均衡器或者 Web Server 进行部署。这里以比较容易理解的 Nginx 反向代理为例。首先，需要在自己的网站上找一个没有使用的路径。

例如：

 /metrics/

这个路径只是用来承载 Google 的测量资源，具体叫什么并没有固定要求，但需要确保它没有被网站现有功能占用。Google 官方文档也要求为每个 Google tag 或 GTM 容器预留独立的测量路径。

接下来，需要获取自己的 Google Tag ID。无论使用 Google Ads 还是 Google Analytics，都可以在 Google 的相关设置页面中找到。Google 会根据 Tag ID 提供对应的专属资源地址。

例如：

aw-16811111111.fps.goog

然后在 Nginx 中增加反向代理规则。

location /metrics/ {
    proxy_pass  https://aw-16811111111.fps.goog/metrics/;
    proxy_set_header Host aw-16885608369.fps.goog;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_ssl_server_name on;
}

配置完成后重新加载 Nginx。Google 官方提供了对应的健康检查方式，可以直接访问：

  https://你的域名/metrics/healthy

正常情况下应该返回：

ok

如果需要验证地理位置信息是否正确传递，还可以访问：

  https://你的域名/metrics/?validate_geo=healthy

同样应该返回 ok。

最后修改网站里的 Google tag

代码网关配置完成之后，还需要把网站原来直接加载 Google tag 的地址改成刚才设置好的测量路径。原来 gtag.js 是：

<script async src="https://www.googletagmanager.com/gtag/js?id=AW-11111111111"></script>

使用代码网关之后，可以改成通过自己的测量路径加载。

  <script async src="/metrics/"></script>

如果使用 Google Tag Manager，也有对应的修改方式。

配置完成之后，可以使用 Tag Assistant 检查事件请求是否已经通过这个测量路径发送。

整个过程实际上并不复杂。网站原来的 Google Ads、GA4 或 GTM 配置并没有被重新设计，只是在中间增加了一层第一方的请求路径。

对于已经在使用 Google Ads 和 GA4，同时又比较重视数据采集稳定性的网站来说，这个功能值得研究一下。尤其是面向欧美市场、对广告转化数据比较敏感的网站，可以考虑把 Google 代码网关作为现有追踪体系的一部分。当然，它也不是说配置之后所有请求就一定不会受到任何限制，而是通过第一方基础设施减少一部分第三方交互，让 Google tag 的加载和测量路径更加稳定。