Ahoy项目中的Turbo 8即时点击请求排除方案解析

背景与问题场景

在Ruby on Rails应用中，Ahoy是一个流行的用户行为追踪库，用于记录页面访问和事件。随着Turbo 8的引入，其"即时点击"(instant-click)功能会在用户悬停在链接上时预加载页面内容，这可能导致Ahoy记录大量实际上未被用户真正访问的页面请求。

技术分析

Turbo 8的预加载机制会在请求头中添加特定标识：

"HTTP_X_SEC_PURPOSE" => "prefetch"

这个请求头明确表明了当前请求是预加载行为而非真实用户访问。虽然Ahoy默认不会区分这类请求，但开发者可以通过以下方式实现过滤。

解决方案

方案一：控制器层过滤

在ApplicationController中添加前置过滤：

before_action :skip_ahoy_if_prefetch

private

def skip_ahoy_if_prefetch
  ahoy.track_visits_immediately = false if request.headers["HTTP_X_SEC_PURPOSE"] == "prefetch"
end

方案二：自定义数据存储

通过重写Ahoy的数据存储逻辑，在事件持久化前进行过滤：

class CustomStore < Ahoy::DatabaseStore
  def track_visit(data)
    return if data[:headers]["HTTP_X_SEC_PURPOSE"] == "prefetch"
    super
  end
end

Ahoy.track_visits_immediately = true
Ahoy.store = CustomStore.new

方案对比

1. 控制器过滤：

   • 优点：实现简单，无需修改Ahoy配置
   • 缺点：全局生效，无法针对特定场景保留预加载追踪

2. 自定义存储：

   • 优点：更细粒度的控制，可结合其他条件过滤
   • 缺点：实现复杂度较高，需要理解Ahoy存储机制

最佳实践建议

对于大多数应用，推荐采用控制器过滤方案，因为：

• Turbo 8的预加载行为通常不需要被记录
• 实现成本低且不会影响正常追踪逻辑
• 符合"真实用户行为分析"的基本原则

如需更复杂的过滤逻辑（如部分页面允许预加载追踪），则建议采用自定义存储方案。

延伸思考

这个问题实际上反映了现代Web应用中普遍存在的"预加载行为分析"挑战。类似的场景还包括：

• 浏览器预渲染页面
• 服务端渲染时的初始页面加载
• 单页应用的路由预加载

良好的分析系统应该具备区分"潜在兴趣"和"实际交互"的能力，这正是Ahoy结合Turbo 8使用时需要注意的设计考量。