服务器端追踪

实际改变的是：事件的组装和发送位置

使用浏览器像素时，在购物者设备上运行的脚本会组装事件。它从页面读取订单价值和内容，从其自身的cookie读取点击和浏览器标识符，并从设备将有效载荷发布到平台的域。该链条中的一切都超出您的控制：脚本必须在购物者离开之前加载、执行并完成其请求，而且设备可能运行广告拦截器，浏览器也可能限制cookie的存活时间。

使用服务器端交付时，您的服务器会从其已有的记录（订单、客户、商品明细）构建事件，并将其作为通过访问令牌进行身份验证的服务器到服务器调用发布到平台的转化端点。在发送时，购物者的浏览器不参与。事件触发是因为订单已写入您的数据库，这是业务中最可靠的信号。

标识符的形态也发生了变化。服务器不再依赖浏览器可能已过期的cookie，而是发送哈希匹配键——规范化的电子邮件地址、电话号码、姓名、邮政编码——以及购物者着陆时捕获并随订单存储的任何点击标识符，再加上IP地址和用户代理。匹配质量因此取决于您在结账时收集的信息，而不是浏览器保留的信息。

它解决了什么，以及它没有解决什么

它解决了交付问题。以前因脚本被拦截、请求失败或购物者在支付重定向时关闭标签页而丢失的购买事件现在可以送达，并且它们携带的匹配键来自订单记录，而不是浏览器中残留的任何信息。它还解锁了一类浏览器根本无法看到的事件：退款、订阅续订、拒付、取消以及线下或电话订单，所有这些都发生在会话结束后很久，并且所有这些都实质性地改变了平台应该优化的方向。

它不解决同意问题。这是最常见的误解，也是代价最高昂的误解。义务附着于个人数据的处理，而不是数据传输的线路。发送关于拒绝同意的购物者的事件，只是处理路径更长而已，并且同意决定现在必须从浏览器传递到您的订单记录中，以便服务器知道是否允许发送——这是像素以前隐式完成的工作。

它不会创建您从未收集过的身份。没有电子邮件且没有存储点击标识符的访客结账，无论事件是从浏览器还是服务器发出，都无法匹配。它也不会取代页面上的行为信号：如果您想要服务器端的滚动深度或添加到购物车互动，浏览器仍然必须首先将它们报告给您。

它不提高业绩，只改善报告。启用它会立即提高报告的转化次数并降低报告的每次获取成本，因为一直发生的事件现在被计数了。那是时间序列中的一个断裂，而不是结果。在图表上标记日期，不要让任何人将启用后的月份与启用前的月份进行比较，就好像广告系列发生了变化一样。

去重：事件ID约定

一旦两条路径都上线，浏览器成功报告的每个转化也会由服务器报告。除非您告知平台它们是同一个事件，否则平台会同时计数两者，告知平台的方式是使用共享的事件标识符：双方发送相同的事件名称和相同的ID，平台会保留先到达的那个，并在其去重窗口内丢弃另一个。

用一个例子来衡量风险。假设某月有1,000笔真实购买，并且30%的浏览器事件丢失——浏览器报告700笔，服务器报告全部1,000笔。如果没有去重，平台将记录1,700次转化，而实际只有1,000次，夸大了70%，报告的每次获取成本降至真实值的约59%。优化器随后从一个信号中学习，其中一些订单计数两次，另一些计数一次，这比单独使用任何一种路径都要糟糕。

• 从双方都已知的信息中派生ID——订单ID是显而易见的选择。在每一侧独立生成随机ID会保证它们永远不匹配。
• 在重试时保持ID稳定。重新生成标识符的重试会将您自己的错误处理变成一个重复计数机器。
• 准确匹配事件名称，包括大小写和类型。平台根据这对信息进行去重，因此，仅在命名上不同的浏览器事件和服务器事件都将被保留。
• 也要将浏览器点击和浏览器标识符与服务器事件一起发送。它们是让平台将这两个报告识别为同一用户的原因，而不仅仅是同一订单。
• 遵守去重窗口。几天后才交付的事件——例如延迟的网络钩子、数据回填——将超出该窗口并会被再次计数。
• 在相信数据之前，用真实订单进行测试，并将平台报告的转化次数与您同期自己的订单计数进行核对。它们应该接近；任何方向上的系统性差异都是接线故障。

没人预算的运营成本

像素是您只需粘贴一次的标签。服务器端投放是您现在拥有的一项服务，它带有访问令牌、架构、重试策略和故障模式，而所有这些都会悄无声息地出现问题。令牌过期、平台API版本停止接受您发送的有效负载、部署时丢失了着陆页上的点击标识符捕获、哈希错误（例如电子邮件地址在哈希前未转换为小写或未修剪）——所有这些都不会抛出营销团队会看到的错误。它们表现为匹配质量的逐渐下降，或转化率的突然下降，看起来就像是糟糕的一周广告投放。

因此，监控不是可选项，而且很简单：每天比较发送的服务器事件与创建的订单，并在出现差异时发出警报。关注平台自身的事件诊断或匹配质量分数，因为匹配率下降通常是数据问题，而非受众问题。记录每次发送的响应，而不是“即发即忘”，因为被拒绝的有效负载与成功的有效负载在其他方面是无法区分的。

也要为同意机制的底层实现预留预算。该决定必须在浏览器中捕获，随订单持久化，并在服务器发送前由服务器读取——这三个组件都必须保持一致，在一个系统中，一端的失败是无声的，而另一端则会导致合规问题。

坦白地说，服务器端追踪是用一类您无法修复的不可靠性，换取一类您可以维护的问题。这通常是正确的权衡，但如果在其构建的季度之后没有人负责维护该管道，那么它就不再是正确的权衡了。