经过一些实验，我注意到可以通过HTTP请求将事件直接发送到服务器容器，而不是推送到数据层(连接到web容器)。这种设置的一大优点是前端不需要加载任何GTM脚本。然而，我有一些疑虑，因为我找不到太多关于这个设置的文档。这种设置也带来了一些挑战，比如实现自动收集的事件(例如page_view)。有没有人有这种设置的经验，或者能够告诉我为什么我不应该走这条路？
问候，Thomas
这绝对不是最佳实践，尽管这实际上是一条技术上更有益的路径，因为。。。实际上有几件事：
- 可以使您的追踪完全免疫广告阻滞剂
- 具有防止恶意分析垃圾邮件的潜力，也使第三方更难破坏您的数据
- 不会向公众展示您的分析堆栈和库
- 通常比GTM库轻得多
- 你对所发生的事情有更好的控制力，并且在跟踪方面有更大的权力
但这只有在你有能力开发它的情况下，这实际上是罕见的。通常情况下，网络开发人员对分析的了解不足以使其正常工作，而分析开发人员缺乏技术知识。现在，您突然不能只雇佣初级或中期实施专家来帮助跟踪。许多自称老年人的人也无法维护原始的JS跟踪库。
正如您所提到的，您将无法依赖GTM或gtag库的自动跟踪。事实上，没有自动事件并不是问题所在。更重要的是手动收集所有维度，包括正确维护客户端ID和会话ID。
一旦您的前端准备就绪，需要注意的是，您不想公开服务器端GTM的端点。我的意思是，你可以，但这将大大违背目的。您想在后端制作一个镜像，将事件重新路由到sGTM。
最后，您可能需要在镜像上为数据设置某种数据加密/保护/验证/身份验证逻辑。你可能会认为这只是因为在不暴露端点的情况下，你现在可以进一步隐藏你正在做的事情，从而避免了很多潜在的数据篡改。当然，这并不会让你无法了解自己在做什么，但它会让任何随意的干扰几乎不可能发生。
最终，人们不会这样做，因为这将有效地使跟踪的货币成本翻倍，因为足够多的专家将收取常规分析人员大约两倍的费用。然而，数据的清晰度只会增长约10-20%。这样的交换通常没有商业意义，除非你是一家大型公司，即使是像Adobe analytics这样的企业分析解决方案也不够好。亚马逊可能就是一个很好的例子。
此外，如果你已经在重新定义用户和会话，那么你就离使用Segment这样的工具进行跟踪，然后将所有这些ETLing放到数据仓库中，并使用适当的BI工具进行进一步分析不远了。现在，如果你可以将你的事件从镜像实时流式传输到Segment，然后它可以无缝地将这些数据重新集成到GA、Firebase、AA、Snowflake、Facebook以及数十个甚至数百个目的地，这一切都是服务器端的，那么拥有sGTM仍然有意义。
你想知道在哪里停下来，最好的方法是评估你的公司对用户行为数据进行分析/数据科学的深度。在99%的情况下，它还不够深入，甚至不足以考虑sGTM。
响应@BNazaruk
所以已经有一段时间了……我一直在研究这个设置，因为它太酷了。我还深入了解了CGTM，以更好地了解SGTM的好处。老实说，所有有可能取代CGTM的东西都应该考虑在内。我的主要原因是：；
网络安全-通过注入可以插入恶意软件，如键盘记录程序。唯一保留这一点的是CGTM的登录详细信息。相对而言，有针对性的网络钓鱼很容易做到这一点。
速度-一个CGTM设置，大约有10-15个标签，意味着灯塔的平均性能损失40点。
质量——就像你说的；因为浏览器限制，如cookie策略和拦截/操纵/阻止CGTM信号的广告拦截程序：平均10-20%的事件没有以正确的方式注册。
错误-在适当的开发过程之外开发代码，限制了对代码影响的深入了解，可能会导致错误或性能损失。
到目前为止，我已经为在线营销人员和开发人员创建了一个标准化的设置(容器模板、测量计划、库)。在设置中，我们维护自己的客户端和会话ID。开发人员能够优化使用SGTM并大幅提高生产效率。设置的唯一缺点是，我们仍然使用CGTM来实现page_view和异常。这很遗憾，因为我离完整的服务器到服务器设置不远了。我想，各家公司仍然对SGTM持怀疑态度，无法完全承诺。不过，我的感觉是，5年后，高端应用程序将不再使用CGTM。