Google Tag Manager Server-side Tagging究竟是良药还是苟且？
8月，谷歌的跟踪代码管理器Google Tag Manager（GTM）推出了Server-side Tagging（服务器端标签模式）。由于内容较多，极诣将仅在概念层次在本篇尽量用大白话进行介绍，以便于读者了解GTM-SST的精髓。具体来说我们要解决的问题是：
- Server-side Tagging是什么？和传统做法有什么区别？
- Server-side Tagging的优缺点是哪些？
- Server-side Tagging的意义何在？
[notification type=”alert-success” close=”false” ]您可以在谷歌开发者网站找到官方文档，也可以借一步阅读Simo Ahava的SST指南。本文会覆盖其中部分内容。[/notification]
Server-side Tagging是什么？和传统做法有什么区别？
服务器端标签模式SST是相对于Client-side Tagging（CST）的新的GTM的部署方法，它通过在客户端（如浏览器）和终端节点（Endpoint）之间架设一个代理来解决CST部署的一些问题。说起来有些拗口，我们用一个例子来解释：
当你访问极诣数字营销网站的时候，会下载网页。网页中的GTM容器代码会去下载gtm.js。这个gtm.js就会在你的网页中决定什么条件下触发什么标签。
比如当页面载入时会触发Google Analytics的pageview标签，该标签会去www.google-analytics.com请求一个1×1的gif图片，请求方式为GET。通过请求这个图片时带上的参数，GA就可以获取所有该访客的信息。下图我们可以看到t=pageview，这就是GTM触发了一个GA的pageview标签。
以上是传统的部署，当我们使用了SST后，这个GET请求就不是向www.google-analytics.com了，而是一个我们自己定义的服务器（新的域名叫Transport URL，以后会讲，通常这个服务器使用与网站域名相匹配的子域名。）下面Simo网站的一个例子中我们可以看到请求的终端节点改变了。
注意上图Response中的set-cookie字段，我们后文会讲。
这个服务器就是我们前面称之的代理，这个代理上部署了一个GTM的服务器容器-Server Container（区别我们传统的Web Container）。这个Server Container上有着一些我们叫做Clients的“小朋友”他们会把浏览器发来的上面这种HTTP请求翻译成event。
我们知道GTM是基于event和datalayer的，有了event，Server Container便可以给真正的终端节点请求数据了。
简化后的比较可以这样表示：
- CST：客户端触发标签，标签直接请求www.google-analytics.com给GA推送数据。
- SST：客户端触发HTTP标签，标签请求subdomain.yourdomain.com去通知它请求www.google-analytics.com给GA推送数据。
Server-side Tagging的优缺点是哪些？
那么读者会问，这种插入一个代理的做法是否会多此一举呢？并不是这样，Simo为我们总结了至少有下面几个优点。
- 延长Cookie的生命周期。传统的CST模式下，GA会通过JavaScript在你的网站下新建第一方Cookie。我们不久前曾经介绍过在ITP的环境下，这种第一方Cookie的生存期只有7天。七天后就相当于换了个访客，我们便无法识别了。而在SST模式下，利用HTTP Response的set-cookie字段方式我们可以自定义其生存期。
- 过滤spam信息。传统的CST模式下，GA数据可以轻易被垃圾信息污染。spammer只需要不停发带上你的GA ID（UA-XXXXX-YY）的collect请求信息就可以对你的GA数据进行污染。比如极诣曾经介绍过的referral spam。在SST模式下，Server Container可以和GA约定一个secret，通过Custom Dimension和Filter的组合将这些垃圾信息过滤掉。
- 减少第三方库的下载。传统的CST模式下，访客浏览器需要下载各种第三方的JS脚本。这会大幅降低网页读取速度进而影响用户体验。SST模式下，这些工作都会在Server Container上完成。访客客户端不再需要下载这些脚本库。
- 过滤敏感信息保护用户隐私。CST模式下，当请求第三方资源时，请求会通过HTTP Request的各字段，如User-Agent和referer，暴露访客的一些个人信息。第三方还可以获得用户的IP地址。SST模式下，我们可以充分控制这些信息向终端节点流动，用户信息将会对终端节点变得不可见。
总之，在SST下，你可以完全控制哪些你愿意推送给其他终端节点。
下面我们再来看看SST模式的缺点：
- 被墙的风险。目前仅支持Google Cloud Platform (GCP)作为部署Server Container。这一下子会劝退很多墙内的小伙伴。和Firebase Analytics一样悲剧。
- GCP需要氪金。这至少是一笔额外的开销。
- GCP的性能决定了你能处理多少请求。原来客户端的请求全都转移到了Server Container，这让GCP的性能成为了关键因素。
- 跟踪屏蔽的风险。现在还无法保证未来的浏览器是否会对这些第一方子域名的跟踪请求进行屏蔽。ITP和ETP始终在发展。
所以，哪有十全十美的事？我们最后总结一下SST的意义。
Server-side Tagging的意义何在？
GTM的SST从根本上为跟踪代码管理提供了新思路，它为提高数据质量、增进用户体验、加强隐私和安全提供了结构基础。虽然目前对墙内的网站和APP来说可能还是一种奢望，但是依然存在自建服务器，自由选择托管服务的可能。
短时间看SST的部署有许多优越性，如果你的服务面向海外用户，那么积极尝试GTM的SST或许是非常有必要考虑的。
