保留 AI 引流归因，兼顾网页缓存

AI 回答把用户带到网站之后，团队往往只看到了访问量，却丢掉了「用户从哪个助手过来」的线索。作者提出的办法是：在首次 HTML 请求时记录来源，让它穿过缓存、SPA 导航和表单提交，最终进入 CRM。

这是一套轻量的来源归因思路，对有 CDN、单页应用和获客表单的网站尤其有用。不过，原文给的是实施建议，没有实测数据，也没有完整说明缓存命中时如何采集，落地时需要补上这些细节。

来源要在首次 HTML 请求时留下来

作者建议在 nginx 或边缘 Worker 上，记录首次文档请求中的 $http_referer、$arg_utm_source 和请求 ID。

这几个字段各有用途：$http_referer 保留浏览器带来的来源，$arg_utm_source 读取 URL 中的 utm_source 参数，请求 ID 则方便关联同一次请求的其他日志。

采集时机比工具选择更关键。等到标签管理器触发事件，广告拦截器或用户拒绝执行 JavaScript，都可能让记录落空。对于 SPA，用户进入站点后继续切换路由，如果首次落地来源没有被保存，后面的导航也补不回它。

先留下首次落地的来源，再做分析和归类。

但首次请求也不能保证拿到来源。原文没有提供来源字段的覆盖率，因此不能把这套方案理解成「所有 AI 访问都能识别」。

缓存命中时，谁负责记录这次访问

原文标题强调不破坏缓存，真正需要检查的是：HTML 命中缓存之后，请求是否还会经过负责记录来源的那一层。

如果日志只在回源、缓存未命中时写入，大量正常访问就会漏记。作者给出的替代办法是增加一个轻量采集端点（collect endpoint），让来源记录有独立入口。

这里容易混淆两个问题：缓存决定返回哪份 HTML，归因决定记录这次访问从哪里来。我的理解是，应优先检查边缘层能否在缓存命中时照常记录，而不是直接把来源字段塞进缓存键，让同一页面产生大量缓存变体。后一种做法也不是原文给出的方案。

原文没有交代采集端点由谁触发、怎样避免重复记录。如果仍依赖页面 JavaScript 请求它，前面提到的拦截和拒绝执行问题仍然存在。具体实现必须结合自己的 CDN 和应用链路判断。

从助手域名到 CRM，中间还差两步

第一步是规范化来源。作者建议维护一张小映射表，根据主机名是否包含 chatgpt、perplexity、copilot 等内容，生成统一的 ai_source 字段，同时保留原始 referrer。

这样域名变化时，报表仍可按助手汇总；映射规则出错时，也有原始记录可以重新处理。不过，直接做字符串包含匹配只是粗略建议，原文没有提供域名校验规则或误判数据。

第二步是把首次来源带到线索提交环节。作者建议用第一方 Cookie 或服务端 Session 短期保存，设置较短的 TTL（存活时间），提交表单时再写入 CRM 联系人记录。具体保存多久，原文没有给出数值。

访问统计与销售线索由此连接起来。否则，分析看板知道有人从助手过来，销售看到的联系人却没有这条信息。

作者还提出两种复盘节奏：每周按 ai_source 查看落地访问量，观察内容实验有没有变化；每月检查页面事实、日期和不同材料之间的一致性，避免拖到季度审查才集中处理。

我的判断

这篇最有价值的地方，是把来源采集、缓存链路和 CRM 放在一起考虑。对于已有获客表单的网站，它比单独增加一个「AI 流量」图表更接近业务需要。

但它仍是经验之谈。作者没有给出接入前后的漏记率、缓存命中率或线索转化对照，也没有证明主机名包含匹配足够准确。ai_source 能标记可识别的来源，无法还原用户此前是否看过 AI 回答，更不能独自证明某篇内容带来了转化。

后半部分还转向了内容治理：让未参与写作的人复述产品、价格或费用范围、交付时间和主要风险；记录页面负责人、下次复核日期及每个数字的出处。这些做法有助于减少事实冲突，但它们与日志归因是两项工作，不能互相替代。

作者最后把这些原则关联到 PandaWM 的海外广告、多语言网站、GEO 和加密货币结账业务。这是业务关联说明，原文没有展示这些渠道的效果验证。

能拿来做什么

• 给现有站点画出首次 HTML 请求的实际路径，分别检查缓存命中和未命中时，哪一层能够记录 referrer、utm_source 与请求 ID。
• 如果 SPA 已有来源采集，确认它保存的是首次落地来源，并检查标签管理器未执行时是否还有记录入口。
• 在 Node 表单接口或现有后端中，把短期保存的首次来源写入 CRM，同时保留原始值和 ai_source，方便排查归类错误。
• 将每周来源统计与每月内容复核分开安排：前者观察访问变化，后者核对日期、费用和跨页面事实的一致性。