更新时间：2025年9月8号
这一篇介绍Google Tag Manager（GTM）的服务端跟踪（Server-side Tagging，简称 SST）。服务端跟踪并非新概念，此前Tealium，Ensighten等工具已将其作为核心功能，但近年来随着浏览器隐私保护加强以及第三方跟踪受限，Google 和 Adobe 也相继推出了自己的服务端跟踪方案，使其成为数据采集领域的重要趋势。
什么是服务端跟踪
服务端跟踪（SST），又称服务端标签、云端标签交付，GTM 的服务端部署简称为 sGTM。
其核心思想是：数据不再由浏览器直接发送给第三方平台，而是先发送到你控制的服务器，再由服务器统一转发给第三方平台。
数据流转路径变化如下：
在这个过程中，你可以在服务器层面对数据进行控制、清洗、增强与过滤，从而掌握数据流向的主动权。
也就是说，数据流转路径从传统的：浏览器 → 第三方平台 变为：浏览器 → 自有服务器 → 第三方平台
服务端跟踪兴起的原因
服务端跟踪的兴起主要源于两方面：
- 法律法规日趋严格：GDPR、CCPA 等法规对用户隐私保护要求越来越高。服务端跟踪让你对数据拥有完整控制权，可以决定哪些数据发送给第三方平台，实现“数据可控，而非黑盒传输”。
- 浏览器隐私保护持续加强：苹果的 ITP、Firefox 的 ETP 等在浏览器本地通过机器学习识别并屏蔽第三方跟踪。采用服务端跟踪后，请求通过自有域名发出，被浏览器识别和拦截的概率显著降低，从而提升数据的完整性与稳定性。
客户端跟踪 VS 服务端跟踪
客户端跟踪（Client-side Tagging，CST）
这是最常见、最传统的部署方式。
典型流程：在页面中安装 GTM 基础代码，用户打开页面时从 Google 服务器加载容器配置，容器在浏览器中运行，触发不同分析工具的代码，将数据直接发送至各个第三方平台。如下图：
特点：部署简单，但数据完全暴露在浏览器环境中，易被拦截或篡改。
服务端跟踪（Server-side Tagging，SST）
服务端跟踪将数据先发送到自有的 sGTM 服务器，再由 sGTM 将数据转换成不同平台所需的格式，通过 API 发送至第三方收集服务器。在此过程中，你可以对发送的字段进行控制，例如移除敏感信息或进行哈希脱敏。
一个典型的服务端跟踪架构包含：
- sGTM 服务器：所有数据请求的入口，负责接收、解析、处理和转发数据。
- Web GTM 容器：客户端容器，负责在浏览器中触发事件并将数据发送至 sGTM（也可通过直接 API 等方式发送数据，不一定必须使用 Web GTM）。
简要对比
| 维度 | 传统GTM | 服务端GTM |
|---|---|---|
| 数据发送 | 浏览器 → 第三方 | 浏览器 → 自有服务器 → 第三方 |
| 服务器 | 不需要 | 必须 |
| 域名 | Google域名 | 可使用自有二级域名 |
| 被拦截风险 | 高 | 低 |
| 成本 | 免费 | 有服务器成本 |
服务端跟踪的核心优势
显著提升数据准确性
- 绕过广告拦截器：许多拦截插件会阻止浏览器向第三方脚本发送请求。sGTM 使用第一方域名，拦截器难以识别和阻止。
- 对抗 ITP/ETP：Safari 的 ITP 和 Firefox 的 ETP 会屏蔽被识别为第三方跟踪的请求。使用第一方域名可有效避开这些限制。
实际案例中，启用服务端跟踪后，数据丢失明显减少，转化回传更稳定，转化率提升10%以上并不少见。
提高数据安全性与隐私保护
- 数据脱敏：敏感数据可在服务器端进行哈希、脱敏或过滤后再发送给第三方。
- 完全掌控权：由你决定哪些数据发给谁，而不是让第三方脚本在页面上“自由采集”。
- 降低安全风险：减少页面中嵌入不受信任的第三方代码，从源头降低 XSS、数据泄露等风险。
优化网站性能（加载速度）
- 减少浏览器负载：无需在用户浏览器中加载数十个庞大的第三方 JavaScript 库。
- 降低带宽消耗：客户端只需发送最小请求，复杂计算由服务器处理后再分发。
- 更稳定的数据传输：服务器之间的请求比浏览器请求更稳定，不易受网络波动或页面加载失败影响。
sGTM支持的主要部署方式
sGTM本质上是一个Docker服务，部署方式可分为三大类。
部署方式一：Google Cloud（官方推荐）
Google Cloud Run 是 Google 官方推荐的 sGTM 部署方式。在 GTM 后台创建服务端容器时，系统会自动通过 Cloud Run 启动一个可弹性伸缩的服务器。
优点：
- 官方支持最完整：文档、示例、更新节奏全部以GCP为主。
- 一键自动部署：在GTM后台即可直接创建server container。
- 弹性伸缩：流量高时自动扩容，低流量几乎零维护。
- 与GA4/Ads延迟最低：网络路径最短、稳定性最好。
缺点：
- 成本不可控风险：流量大或配置不当时，Cloud Run 费用可能快速上涨。
- 依赖GCP生态：对不熟悉Google Cloud的团队学习成本偏高。
- 计费逻辑复杂：请求数、CPU、内存、执行时间都会影响费用。
适用场景：希望快速上线、不折腾运维的团队。
布署方式二：自行托管（AWS/Azure/VPS/私有云）
将 sGTM 容器以 Docker 服务形式运行在企业自有或指定的云环境中，需自行完成服务器配置、HTTPS、负载均衡及运维管理。
优点：
- 完全控制权：网络、日志、安全策略、扩展逻辑全在自己手里。
- 成本可预测：固定服务器费用，不容易“爆账单”。
- 符合企业合规要求：适合有数据主权或内网要求的公司。
缺点：
- 没有官方一键部署：需要自己拉Docker镜像、配置HTTPS、负载均衡。
- 运维成本高：扩容、监控、异常处理都要自己来。
- 出问题缺乏官方支持：Google文档基本不覆盖这类环境。
适用场景：已在 AWS/Azure 深度使用且具备较强技术实力的团队。
布署方式三：第三方托管（Stape等）
通过 Stape、TAGGRS、Tracklution 等托管型服务平台运行 sGTM，无需自行配置云服务器或Docker环境。
优点：
- 上手最快：几乎不需要云计算或Docker知识。
- 费用相对固定：对中小站点预算友好。
- 内建常用功能：域名映射、日志、模板、备份等。
缺点：
- 可控性有限：网络、扩展、底层架构不可定制。
- 平台依赖风险：一旦迁移，需要重新部署。
- 企业级合规弹性较低：不适合对安全审计要求高的组织。
适用场景：中小网站或没有专职技术团队的场景。