我碰巧将 Google 分析报告与 Apache 访问日志进行了比较，结果显示了惊人的 250% 的下降。
我们在 aws 上托管了一个 wordpress 安装，其中有 2 个 Web 服务器、一个 ELB 和一个 NFS 服务器、RDS 和一个弹性缓存。
我进行分析的方式如下：
- 在所有页面上放置一个简单的 JavaScript，它会在 PageReady 即 OnDomContentLoaded 事件上 ping 我的服务器，然后我会记录 IP 地址和页面 URL。由于这是最简单的 JavaScript 代码，我假设它应该可以在大多数浏览器上运行，并且结果与生成的结果非常接近谷歌分析。
- 我检查访问日志中的合法请求（消除没有用户代理+没有引荐来源 URL 等的请求）并仅检查生成 200、206、301、302 响应代码的请求。
当我比较客户端生成的服务器 ping（1 提到的自定义 JavaScript）和 apache 访问日志时，下降幅度似乎接近 250%。
因此，这意味着这些缺失 IP 上的客户端没有执行 JavaScript，但令人费解的是服务器发送了 200 状态代码。所以我得出结论，服务器对大多数人发送了一个空响应。（我已经考虑了少数关闭 JavaScript 的用户、一些错误等）但我无法测试这个假设。（如果情况确实如此）。
mod_dumpio不允许我将响应主体映射到客户端IP。审计日志似乎不支持记录响应主体。
考虑到这些因素，有人能给我指明正确的方向吗？
澄清：
由于我没有资格发表评论，所以我想在这里补充几点。
我确实只查看了文档请求，即排除了所有 CSS 和 JS 以及图像文件，并且过滤掉了谷歌机器人和其他可疑的爬虫。考虑到所有这些因素，下降幅度明显高达 250%。
答案1
仅检查生成 200、206、301、302 响应代码的请求。
这会导致计数过高。计数过高的数量取决于您提供的 301 和 302 的数量。收到 301 或 302 的浏览器将重定向而不发送您的 JavaScript ping，并且可能稍后会生成 200，因此会产生重复计数。
过滤掉来自机器人的请求以及对 css、javascript 和图像的请求很容易出错。相反，我建议选择您网站上的单个页面，您知道 JS 分析正在运行（例如，主页），并且只计算该页面的查询。此外，从您的日志中选择一个通常代表真实浏览器的常见用户代理，并且只计算该页面的查询。如果数字更接近匹配，您可以稍微扩大范围。
您的 JS 也可能无法在每个浏览器中正常运行。尝试设置您网站的测试实例，然后使用类似https://www.browserstack.com/在多个浏览器中加载它。按用户代理对日志进行分组。任何发出主要请求但不发送 ping 的用户代理都可能在执行您的 JS 时出现问题。启动该用户代理的副本并测试您的 JS。
答案2
你的阿帕奇日志将报告一些事情分析不算。这些包括：
- 样式表，JavaScript的，图片以及内容页中包含的其他内容。这些内容应该被缓存，因此重复访问者不需要在后续页面上检索它们。但是，
HEAD如果他们启动新的浏览器会话，您应该会看到请求。 +http://索引您网站的机器人扫描的内容。虽然并非所有蜘蛛都遵循此标准，但请在用户代理字段中查找。- 有些用户会使用禁用脚本的工具，因此这些合法流量将会丢失分析報告。