看似合理的分析事件API-防止操纵

问题描述

根据Plausible Analytics docs，可以对/events/api端点进行POST请求，记录页面浏览量。我的自托管看似可行，令我惊讶的是，我可以使用Postman使用一些虚拟数据简单地对端点执行一些POST请求，并且它被记录为实际的页面视图。

我查看了另一个站点(使用云版本)，似乎我也可以操作那里的数据。这是正常的，还是我设置错了？如何防止分析数据被篡改，或者这只是这项技术的工作原理？

推荐答案

1. 这与似是而非无关。它涉及到几乎所有基于前端的分析跟踪系统。Matomo、Adobe Analytics、Google Analytics：它们在这方面都非常脆弱。更不用说跟踪转换以优化流量分段的第三方服务大军了。

2. 但是：2.1没有人足够在意，不会费心破坏他人的数据。嗯，没有人足以让人们不去关心它。这种情况很少发生。2.2要以可靠的方式破坏数据是相当困难的。你必须研究跟踪模式，获取代理，设置分布式事件泛洪，合理地随机化每一个有机设置的维度。这很难。2.3即使您足够优秀，可以破坏数据，优秀的分析师和数据科学家如果不从垃圾中清除数据，也至少能够检测到攻击。2.4像这样的攻击比建立相当好的跟踪要花费更多。因此，从业务角度来看，破坏所有竞争对手的数据代价太高。

3. 最后，是的，您可以使其安全。但目前它的价格很高。这里的想法是使用一种服务器端标记管理器。Adobe Launch(现在称为Tages)、Matomo、Tealium和GTM都提供服务器端选项。它不仅提供了隐藏您的分析端点的机会，还允许您绕过广告拦截器，这些广告拦截器通常会阻止5%到75%的所有跟踪，具体取决于受众。

然而，服务器端现在要求跟踪实现专家不仅了解一些JS和DOM，而且还需要了解服务器端，以及一些API技能。而且服务器端的TM不允许您在服务器上执行泛型代码，所以现在您必须准备好编写自己的后端代码。

显然，您可以忽略服务器端TMS，转而使用测量协议，直接将事件从您的服务器端点发送到跟踪端点，绕过TMS。TM提供了价值，但服务器端的TMS只是变成了一台漂亮的、文档齐全的路由器。

您的跟踪方案现在如下所示：

查看您的跟踪变得多复杂？

如果不是跟踪终结点，您仍将刷新后端终结点。仍然有可能入侵它，但现在需要深入挖掘一堆可能混淆的JS来寻找加密逻辑。因此，您现在可能希望尽可能多地混淆您的加密代码：使用evals和Base64，或者可能使用函数构造函数来隐藏val。或者在后台使用一些代码来完成加密。

再说一次，这不值得。我从来没有见过任何人足够关心这种攻击来经历所有的麻烦，无论它看起来多么有趣。

这篇关于看似合理的分析事件API-防止操纵的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！