多年来，“服务器端与客户端”之争一直属于那种答案总是“视情况而定”的话题，而每个人都很讨厌听到这种敷衍的回答。这里为您提供通俗易懂的版本，没有供应商的推销话术，还附带一张您可以直接发给 CTO 的诚实对比表。
它们究竟是什么
客户端跟踪在访客的浏览器中运行。一段小型脚本执行后，读取发生的情况（页面浏览量、点击次数、滚动深度），并将该信息直接发送到数据收集端点。服务器端跟踪则在您的基础设施上运行。浏览器将最少的数据发送到您的服务器（或轻量级边缘节点），然后由服务器决定要将哪些数据转发到何处。
没有任何一方天生就比另一方更“保护隐私”或更“准确”。根据配置方式的不同，两者都可以做到这几点。真正的区别在于控制点位于何处——以及您能获取多少真实数据。
诚实的权衡对比表
| 维度 | 客户端 | 服务器端 |
|---|---|---|
| 设置工作量 | 低 —— 粘贴一段代码 | 较高 —— 需要一项服务和一个小型路由层 |
| 抗广告拦截能力 | 弱 —— 脚本在源头被拦截 | 强 —— 您自己域名上的第一方端点 |
| 现代浏览器上的数据丢失率 | 显著（Safari ITP、拦截器、防跟踪模式） | 很小 —— 您拥有控制权 |
| 首次渲染延迟 | 增加一个第三方请求 | 如果收集器在边缘节点缓存，则无任何影响 |
| 对离开您基础设施的数据的控制 | 完全取决于供应商脚本的决定 | 完全取决于您的决定 |
| 调试难易度 | 开发者工具的 Network 选项卡 | 服务器日志 —— 不同的技能要求，但更全面 |
| 规模化成本 | 较低，直到供应商对您实行阶梯收费 | 您能清楚看到的少量边缘节点/函数账单 |
| B2B 企业级识别 | 可行但很脆弱 | 完美契合 —— 服务器可在后端私密地将 IP 解析为企业 |
B2B 团队应该把大部分注意力放在最后一行。客户端识别依赖于脚本，而越来越多的访客要么直接拦截脚本，要么大幅削弱其功能。服务器端将识别逻辑置于您自己的基础设施上，在这里，它不会被浏览器更新悄无声息地关闭。
企业级识别的适用场景
企业级识别是天然的服务器端工作负载。浏览器只需向您自己域名上的第一方端点发起极小的请求。该端点在边缘节点上运行（在欧洲通常不到 20 毫秒），私密地执行 IP 到企业的解析，并且不会向客户端返回任何泄露处理结果的数据。用户体验保持不变，成功绕过拦截器环境，数据路径也始终处于您可控的边界内。
这不是什么花招，而是将“这位访客是谁”的问题从客户端转移到您运营的服务中所带来的直接结果。访客的浏览行为没有任何改变；改变的只是您获取答案的能力。
服务器端不是什么
服务器端跟踪并不是绕过同意的手段。如果某项处理活动需要获得同意，那么无论代码在哪里运行，都需要同意。服务器端真正改变的是数据丢失问题和控制权，而不是法律依据。
关于性能的说明
人们经常担心“跟踪”会拖慢页面加载速度。在现代架构中，这种担忧早已过时。一个构建良好的加载器只有几 KB，采用延迟加载，并且在页面可交互后才会触发；一个构建良好的服务器端点能够从最近的边缘节点在个位数毫秒内做出响应。这两者都不会导致您的核心网页指标（Core Web Vitals）恶化。真正让指标变差的，是标签管理器里那些三年来都没人审计过的 14 个第三方脚本。数据路径越少、控制越好，速度几乎总是越快。
客户端在什么情况下依然胜出
客户端并没有错。对于低风险的分析，也就是如果您可以接受由拦截器导致的数据丢失（如产品使用情况抽样、应用内 UX 事件、快速粗糙的落地页测试），客户端的部署速度更快，运行成本更低。我们的重点并不是说某种方法具有绝对优势；而是说，如果您的工作依赖于这些数据——B2B 销售管道就是一个很好的例子——那么服务器端路径更具韧性，且在数据处理上也更加诚实可靠。
正确的问题不是“哪个最好？”而是“这些数据将为哪些决策提供支持，以及该决策能容忍多大程度的数据丢失？”对于“这周谁访问了我们”这个问题——理想情况下，容忍度为零。因此，架构上的答案就不言而喻了。
Published by