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