Google Tag Manager是一个TMS（标签管理系统）：它允许营销团队向网站或应用程序添加跟踪器，而无需经过开发人员。通过web界面，这些团队可以决定：
传输到这些第三方工具的数据（用户特征、导航数据、页面上的变量等）。
它不是唯一的一个（例如，我们可以引用Segment、French TagCommander或Matomo Tag Manager），但Google Tag Manager占据了绝对优势：
根据W3Techs的数据，Google Tag Manager在前1000万Alexa网站中占31.9%，但最重要的是Google Tag Manager在TMS上占99.4%的市场份额（！）
谷歌是如何再次将自己强加于人的？与Google Analytics一样，Google Tag Manager的标准版本是免费的（市场解决方案通常是付费的），它与其他Google解决方案集成得非常好，而且做得很好。
去年8月，谷歌发布了新版谷歌标签管理器，名为服务器端标签。下面是谷歌的一个图表，解释了谷歌标签管理器在客户端标签版本（历史版本）中的工作原理：
Google Tag Manager将允许直接在浏览器上触发各种第三方跟踪程序（在图表上：谷歌分析、谷歌广告和分析工具）。
在新的服务器端版本中，第三方跟踪器不再从浏览器运行，而是从"；委托书"；服务器名为"；服务器容器"；在下图中（由谷歌托管）：
javascript库（图中称为"；Tag Manager web container"；）始终在浏览器上运行，以收集您的交互和个人数据，但各种第三方跟踪程序的执行在服务器端进行。
请注意，这个新版本也适用于应用程序和"；离线"；数据收集（例如，传输店内购买）：
Simo Ahava和#39的示意图；s博客：在服务器端，"；客户"；是否需要将收到的HTTP请求转换为"；事件"；，34岁；标签"；对这些事件做出反应，发送"；点击率"；给第三方营销公司。
这种在服务器端触发第三方跟踪程序的逻辑改变了游戏规则。Simo Ahava在一篇优秀的文章中详细介绍了不同的影响，就我而言，我将总结其优点，并重点关注您的隐私问题（在服务器端操作可以让您绕过您的选择，泄露您的个人数据，而不会被揭穿）。
在大多数网站上，第三方（用于分析、广告、A/B测试等）加载的javascript库数量令人印象深刻。加载和运行这些库通常是用户体验不佳的主要原因：网站速度慢和缺乏交互性。
对提供糟糕用户体验的网站的后果：不太满意的互联网用户，他们将直接放弃浏览或不再回来。
下面是Le Bon Coin的一个例子，它调用了无数的javascript库：
Le Bon Coin主页上调用的javascript脚本的一小部分，将您的个人数据泄露给许多第三方。
在最好的情况下，网站将只安装一个javascript库（不同用途的工具之间的事件可能非常不同，网站有时会使用多个库）。这可能是Google Tag Manager的功能，但不一定是：可以创建自己的库，也可以使用市场上的其他库，如Snowplow、Matomo、AT Internet等。
然后指示该库发送"；点击率"；关键交互过程中所需的参数。然后是"；客户"；服务器容器的一部分必须翻译这些"；点击率"；这些内容将由"；标签"；它将发送"；点击率"；给第三方营销公司。请注意，如果网站上安装的javascript库是由谷歌提供的，那么"；客户"；已在Google Tag Manager中预先配置。如果网站使用另一个图书馆，它将不得不创建自己的"；客户"；在谷歌标签管理器中（例如在互联网上），等待"；客户"；为主要javascript跟踪库预先配置。
因此，它的优点是：网站上安装了一个javascript跟踪库和一个"；流量"；对于来自浏览器的数据，用户应该可以看到差异。
34岁；委托书"；在服务器端，可以控制传输给第三方的数据（当追踪器由用户的浏览器直接执行时，这会更加困难）：
默认情况下，与"不同；客户端"；用户的版本、IP地址和用户代理（浏览器名称、版本、操作系统、语言等）不会泄漏（这避免了通过指纹识别识别用户身份）。使用Google Tag Manager服务器端标签版本的发布者可能会决定将此信息传输给第三方，但这不是自动的。
通常情况下，个人信息会通过URL参数泄露给第三方（例如阅读文章"；谷歌标签管理器服务器端-如何管理自定义供应商标签"；），服务器端标记可以避免这种情况。
一般来说，出版商对其"；委托书"；给第三方（阅读谷歌的技术文档，例如注意get_cookies和set_cookies方法）。因此它可以"；清洁"；仅将严格必要的信息发送给第三方。
例如在互联网上大热"；34岁；由"；委托书"；服务器，网站可能决定不传输用户'；的IP地址和用户代理在Internet上。
通过设置内容安全策略（CSP），发布者可以更好地保护自己免受不同类型的威胁，包括XSS（跨站点脚本）攻击和内容注入。通过向web服务器的响应添加标题，该网站可以向浏览器指示允许使用哪些资源（脚本、css等）。
这意味着：浏览器只能执行直接来自所咨询网站的脚本（'；self'；）或者来自API。谷歌。通用域名格式。这里'；如果恶意脚本试图从访问的网站运行，浏览器将如何反应：
邪恶。js脚本不在访问过的站点上托管，也不在API上托管。谷歌。com:它的执行被浏览器阻止。
通过大大减少允许执行javascript代码的第三方域，CSP变得更加健壮。
虽然服务器端标签对同意营销监控（速度、安全性）的用户有好处，但它会危及对不同意的用户的保护。
34岁；委托书"；服务器托管在谷歌云（App Engine实例）中，但谷歌建议将App Engine域链接到其客户的子域#39；现场（未解释原因）：
默认的服务器端标记部署托管在应用程序引擎域上。我们建议您修改部署，改为使用网站的子域。
应用引擎域和客户之间的链接#39；s子域，由谷歌记录。
Google不建议使用CNAME类型的DNS记录（别名），但建议使用a或AAAA类型的DNS记录，直接链接到作为主机的Google App Engine的IP地址。34岁；委托书"；因此，浏览器将服务器视为第一方，因此其后果非常重要。
尤其是"；委托书"；服务器不是第三方cookie，也不是通过javascript创建的cookie，也不是由CNAME域存放的cookie。因此，他们被无限制地授权：
通过Safari创建的第1方智能分析（例如，通过Safari创建的cookies）将cookies的寿命限制为7天。多亏了"；委托书"；服务器、第三方绘图仪现在克服了这一限制。
Always Safari via ITP现在将通过CNAME域放置的cookie限制为7天。多亏了"；委托书"；服务器、第三方跟踪程序不受此限制的影响。
Brave则会阻止CNAME对已知追踪者的请求。再次感谢"；委托书"；服务器，第三方跟踪程序可以避免这种阻塞。
你的adblocker（例如Firefox上的uBlock源代码）、内容拦截器（例如iOS上的Firefox Focus或Adguard）或DNS拦截器（例如NextDNS）可以在你的设备上运行。因此，它可以检测第三方追踪者，并在你的个人数据泄露之前阻止他们。
谷歌标签管理器的服务器端标签版本中没有这一点：个人数据泄露发生在客户端'；s代理服务器（托管在谷歌云中）提供给第三方。你不再有能力避免这些泄漏。
你可以对自己说：只需阻止第一次调用，即浏览器对负责收集数据并与"通信的javascript库的调用；委托书"；服务器除了这个javascript库可以在网站的域上很好地访问（例如，不能在谷歌域上访问）。此外，谷歌已经建议其客户更换gtag。js脚本以进入代理服务器的域。这种操纵已经使得通过域名进行的屏蔽无法工作。
如果是gtag。js是一个javascript脚本，其名称为主要AdBlocker所知，当javascript库的名称被更改或站点创建了自己的库时，它们将很难运行。
Ad受体阻滞剂如何反应？主题并不明显，这里有一些想法，但我'；我不确定它们是否可行：
自动检测这些"；第一方"；致电"；委托书"；服务器通过URL发送参数。除了这些URL参数会根据使用的库、查看的页面等，在不同的站点之间发生变化。
检测负责调用"的javascript库；委托书"；服务器阻止其执行。除了你不应该简单地检测谷歌提供的javascript库，还应该检测所有的javascript跟踪库，甚至是家庭库。
阻止这些代理服务器的IP地址。除了需要手动查找这些"；委托书"；服务器，更新它们。。。或者决定屏蔽Google App Engine的所有IP地址，冒着屏蔽许多应用程序的风险。与追踪无关。更不用说谷歌可能会决定开设"；委托书"；服务器连接到其他主机。
千万不要在浏览器上运行javascript，例如使用配置过的NoScript扩展。有效的选择，除了许多网站将不再工作。
尽管如今许多网站经常在未经你同意的情况下泄露你的个人数据，但仍然可以对这些网站进行审计，证明违反同意的行为，并记录这些泄露。例如，CNIL可以履行其职责，制裁错误。这些都不需要服务器端标签，网站现在可以非常轻松地：
将个人数据泄露给多个第三方时，外部审计师无法实现（它只会看到呼叫"；第一方"；服务器"；代理"；，而不知道个人数据是否被使用、共享或出售）。
默认情况下，App Engine会记录它收到的每个请求（例如请求路径、查询参数等）的相关信息。
但这些查询中包含的个人数据并不是泄露给谷歌的唯一信息。与CNAME伪装一样，与所咨询站点的域相关的cookie被发送到"的子域；委托书"；服务器因此，如果您的会话cookie与站点域（而不是单独的子域）关联，它们将被发送到Google'；乌云。
这表明托管在其云上的数据属于客户，而不是谷歌。你还是要相信谷歌。
如果服务器端解决方案在市场上已经存在很长一段时间了，如果已经可以开发自己的#34；代理"；，谷歌解决方案的推出可能会对服务器端标签的采用产生巨大影响：
谷歌将这个版本作为TMS工具的一个发展，提高了网站的性能和安全性。
即使Google Tag Manager客户端可以继续使用客户端版本，即使服务器端版本仍然有限制（很少有第三方库，一些解决方案将难以支持，等等），即使学习这个解决方案是复杂的，即使它确实有回报（是的，你必须为"；代理"；服务器支付谷歌应用引擎账单），我们可以打赌谷歌标签管理器客户端将逐渐迁移到这个版本。
正如我们所看到的，谷歌没有解释为其"；委托书"；服务器：
默认的服务器端标记部署托管在应用程序引擎域上。我们建议您修改部署，改为使用网站的子域。
它没有'；不需要，浏览器和adblocker保护旁路已被列为"；福利#34；许多出版物：
西莫·阿哈瓦'；s"；谷歌标签管理器中的服务器端标签"；，这篇文章指出了绕过Safari的好处'；关于javascript Cookie的使用寿命的限制。值得赞扬的是，作者不想详细说明服务器端标签使绕过AdBlocker成为可能，并指出数据收集必须在获得同意后进行。
“GTM服务器端-标签的自然演变？”来自Converteo。本文列出了绕过Safari和Firefox等浏览器限制以及绕过AdBlocker的优势。
" Google Tag Manager服务器端标签介绍"；，来自Analytics mania博客。这里也列出了浏览器和AdBlocker限制解决方案的优点。
" 谷歌推出服务器端标签，好消息" Nicolas Jaimes在JDN上的报道。文章的角度是广告，因此绕过浏览器保护被列为一个好处（尽管目前缺乏第三方库意味着服务器端标签的实现仍然很复杂）。
不幸的是，它'；可以肯定的是，许多网站也会被吸引到这些"；福利"；，除了性能、安全性和控制增益。无法审计网站也将是隐私倡导者的一大损失。我们希望浏览器和广告拦截者能找到解决方案，让关心隐私的互联网用户能够继续为自己辩护。