我在这里警告您前端用户跟踪的危险。不是因为谷歌在跟踪你，而是因为它没有很好地跟踪你。
下面是一个分三部分的故事：我掉进的前端跟踪陷阱，我们是如何把自己挖出来的，以及你如何才能完全绕过陷阱。
我们花了一个月的时间将我们的登录页面从Rails的巨石迁移到一个闪亮的新Next.JS应用程序。新网站速度更快，因此转化率会更高，每年为我们节省数百万美元的Facebook和Google广告成本。
为了负责任，我们将推出作为A/B测试运行，将一半的流量发送到旧站点，这样我们就可以量化我们的影响1。
我们造成的影响让事情变得更糟。更糟的是。新网站被摧毁了。
WTF。谷歌告诉我们，我们的新页面要好得多。新网站甚至让人感觉更时髦了。
“想想办法吧。”REVERAPP上的工程师们和一位数据科学家结对，然后去搞清楚到底是怎么回事。他们开始挖掘重新发布的每一个角落和缝隙。
一个星期过去了。我们的导演好奇地走到了顶峰。关于推迟大型发射的小道消息开始流传开来。体重增加了，头发掉了。
最终，破获此案的线索是弹跳。新网站上的退票率(例如，人们马上就离开了)很高。但很明显，新网站的加载速度要快得多。弹跳率应该是下降的，而不是上升的。
当主页加载时，前端跟踪代码记录一个“页面查看”事件。如果记录了“页面查看”事件，但随后没有发生任何其他事件，分析将认为该用户已“反弹”。
原来，这个老网站太慢了，以至于很多人在他们的“页面浏览”被记录下来之前就离开了。换句话说，旧网站严重低估了反弹。
这就好比比较了两个节食计划，然后说一半的受试者放弃的那个更好，因为幸存者往往会减肥。
如果前端少报反弹，我们能不能找到一种方法来跟踪“页面浏览量”，而不依赖于客户端？
曾经有过。它在服务器上-尽管在我们的示例中，我们跟踪了Cloudflare中的事件，我们已经在我们的A/B测试设置中使用了它。
我们开始记录关于要查看的页面事件，而不是页面查看事件，这实际上是page-viewed-long-enough-for-the-tracking-javascript-to-load事件。我们更新了退回指标计算。
你瞧，新的基础设施毕竟好多了！在这段时间里，我们对我们的老版面给予了太多的信任，但没有人受到激励去喊狼来了。
放弃前端。这是一个追踪东西的可怕的地方，至少有三个原因。
登录页面上的JavaScript(尤其是第三方)越少越好。这是更好的客户体验，并且提高了页面的转换率和质量分数。
我们计算出，在我们的登录页面上去掉Segment和Google Tag Manager将产生大约10-15个点的Google PageSpeed。谷歌将PageSpeed考虑到质量分数，这反过来会让您的黑石物理服务器/CPC更便宜。
大约有一半到四分之一的用户安装了广告拦截器。如果您依赖像素事件来通知Google/Facebook关于转换的信息，那么您并不是在告诉他们每个人的信息。这使得他们的机器学习更难优化将哪些客户发送给您。这意味着你要为同样的交通支付更高的费用。
您想要相信您可以控制页面上运行的JavaScript，但是用户有多少个浏览器扩展呢？实际装了多少？等等，此人使用的是什么版本的IE？
页面浏览之类的东西的边缘(不过，如果你亲吻一下，这里的服务器就可以了)。
对于付费流量转换的出版商，如果可行，请通过其服务器端API通知Google/Facebook，而不是试图加载像素。
我们使用Segment来识别匿名用户；更改只是在Cloudflare中调用.Identify()(并在那里处理用户cookie)。
我听说谷歌和Facebook的服务器端转换跟踪性能不佳。
我也听说过(也经历过)这件事。我们正在进入黑魔法领域，…。试试看。
想告诉我我被误导了吗？给我打个电话。
我们只显式地更改了为我们的登录页面提供服务的基础设施，并保持内容(HTML/CSS/JS)相同。一旦新的基础设施显示有效，我们将开始对网站本身进行试验。--↩