AI 引荐访问监测：自己确认 AI 有没有带来访客

在线教程：https://madeinred.com/monitor 原始 Markdown：https://madeinred.com/monitor.md

跟着这份教程，在自己的网站和统计工具里查看：用户是否从 ChatGPT 等 AI 回答中点击了链接、进入哪个页面、有没有注册、咨询或购买。这里监测的是人的引荐访问，不是 AI 爬虫抓取。

开始前，你需要自己的网站，以及已经接入的分析工具（如 GA4、Plausible）或可查看的服务器日志。没有接入统计时，先完成数据接收，再验证来源。

先分清两件事

被 AI 引用：ChatGPT、Perplexity、Claude 等回答中出现了你的网站链接。MadeInRed 的「被 AI 引用体检」负责检查网站是否具备被抓取、理解和引用的基础条件。
AI 引荐访问：用户点击 AI 产品回答中的链接，浏览器真的打开了你的网站。它是访问归因问题，通常要结合 UTM、HTTP Referer、落地页和后续转化来观察。

一次引用不保证一定带来访问；一次访问也不代表 AI 一定引用了页面正文。引用体检的就绪分也不证明已经发生引用。AI 爬虫抓取、真实引用和人类访客点击，要分开记录和验证。

第一步：生成一个测试链接

在 https://madeinred.com/monitor 输入自己的落地页地址，选择 AI 来源，生成并打开测试链接。例如：

https://your-site.example/pricing?utm_source=chatgpt.com&utm_medium=referral&utm_campaign=ai-referral-test

utm_source=chatgpt.com：给访问标记来源。
utm_medium=referral：标记为引荐。
utm_campaign=ai-referral-test：明确这是手动测试，方便从正式报表排除。

生成器在你的浏览器本地处理地址，保留其他查询参数和 #定位，替换原有的这三个 UTM 字段。它不会为你的站点接入统计。

手动打开带参数的链接，只验证统计链路，不证明 AI 已经推荐你。 ChatGPT 有时会传来源参数，但你不能强制它或其他 AI 产品一定添加 UTM。真实访问的参数以实际请求为准。

进入网站后，把 utm_source、utm_medium、utm_campaign 交给你的分析系统或后端保存。最小统计维度是：

来源（source）
媒介（medium）
进入的页面（landing page）
会话是否完成目标（注册、提交表单、购买等）
首次访问时间

注意：你不能强制 ChatGPT 或其他 AI 产品一定自动添加 UTM。 只有请求实际带到你的网站时，才能把这个参数当成正向证据。不要把“所有来自 ChatGPT 的点击”写成已经被完整统计。

第二步：在自己的统计工具里确认

在新浏览器会话中打开测试链接，检查跳转后参数是否仍在，再到自己的统计工具查看。地址栏有参数，不代表分析系统已收到。

GA4

先用“实时”报告确认测试访问被收到。随后在“报告 → 获客 → 流量获取”中切换到“会话来源/媒介”，筛选 chatgpt.com / referral；再用“会话广告系列”找 ai-referral-test。常规报告有处理延迟，新标签不一定会改写已有会话的来源；需要按新会话及实际收集结果复核。未取得分析同意或被拦截时，可能无法看到这次测试。

官方文档：https://support.google.com/analytics/answer/12923437?hl=zh-Hans

Plausible

打开 Sources（来源），筛选 chatgpt.com；打开 Campaigns（广告系列），找到 ai-referral-test。点击来源，查看落地页和已配置的目标转化。

官方文档：https://plausible.io/docs/top-referrers 参数支持：https://plausible.io/docs/custom-query-params

自建统计或服务器日志

确认首次请求收到 UTM，保存来源、落地页和时间。后续转化由已有会话或事件机制关联，单条访问日志不会自动完成转化归因。

测试访问和来源都能找到，才说明基础收集链路可用。用 ai-referral-test 单独标记这些访问，从真实 AI 引荐统计中排除。

第三步：没有 UTM 时，查看 HTTP Referer

当链接没有 UTM 时，服务器有时仍能从请求头里的 Referer（历史拼写）看到上一个页面。例如请求可能带有：

Referer: https://chatgpt.com/

在边缘函数、应用服务器或 Web 服务器日志里记录它。Nginx 的最小示例：

log_format ai_ref '$time_iso8601 $request $status ref=$http_referer';
access_log /var/log/nginx/ai-referrer.log ai_ref;

在应用代码里，读取请求头的方式是：

const referer = request.headers.get('referer');
let referrerHost = '';

try {
  const url = new URL(referer || '');
  if (['https:', 'http:'].includes(url.protocol)
      && !url.username && !url.password) {
    referrerHost = url.hostname.toLowerCase();
  }
} catch {
  // 空值或无效的请求头，按来源未知处理。
}

const aiHosts = new Set([
  'chatgpt.com', 'chat.openai.com', 'perplexity.ai',
  'claude.ai', 'gemini.google.com'
]);
const aiSource = aiHosts.has(referrerHost)
  ? referrerHost : 'unknown';

示例只负责安全解析与分类，不负责写入数据库或识别人类访客。来源参数和请求头可以手动设置或伪造，不能用于认证身份。UTM 和 Referer 冲突时保留各自的观测依据。原始日志可能包含敏感参数；按站点日志策略设置访问权限、脱敏和保留期限，优先保存规范化后的主机名。

把来源归一化

先保存原始观测值一小段时间，再建立归一化规则。常见候选包括：

chatgpt.com、chat.openai.com
perplexity.ai
claude.ai
gemini.google.com

不要因为域名“看起来像 AI”就自动归类，也不要假设所有 AI 产品都使用稳定的 Referer。建议保留两个字段：

raw_referrer：仅在隐私政策允许的期限内保存，用于排查
attribution_source：例如 chatgpt、perplexity、unknown

第四步：记录落地页与转化

你可以在分析工具、日志管道或自己的数据库中记录类似下面的字段：

字段	示例	用途
source	chatgpt.com	来源主机或 UTM 来源
medium	referral	区分引荐、自然、付费
campaign	ai-referral-test	标记手动测试，从正式报表排除
evidence	utm / referer	保存归因依据
landing_path	/pricing	哪个页面接住了访问
session_id	随机 ID	关联后续行为，不放邮箱或姓名
converted	true / false	是否完成目标
observed_at	2026-10-08T12:00:00Z	复盘时间范围

不要用请求次数代替会话数或人数。重复刷新、机器人、内部测试都可能影响计数。一次测试转化成功，只说明事件链路可用；业务效果需要观察真实访客和一段时间的数据。

验证清单

建一个你自己控制的测试链接，带上 utm_source=chatgpt.com 和 utm_campaign=ai-referral-test。
在真实浏览器中打开它，确认落地页没有丢掉查询参数。
查看浏览器网络请求、边缘日志或应用日志，确认参数被收到。
完成一次测试转化，确认来源能和转化事件关联。
用受控请求测试不带 UTM 的 Referer 解析，包括空值、无效 URL 和相似域名。
对照原始日志和分析面板，检查时区、去重和跨页面传递是否一致。
将 ai-referral-test 测试数据从正式统计中排除。

第五步：正确解读结果

可以说：

“我们观察到带 utm_source=chatgpt.com 的访问。”
“我们观察到 Referer 主机为 chatgpt.com 的访问。”
“这些可观察到的访问中，有多少完成了目标。”

不能说：

“我手动打开测试链接，所以 ChatGPT 已经推荐了我的网站。”
“没有 UTM，所以这个用户一定不是从 AI 来的。”
“没有 Referer，所以 AI 没有带来访问。”
“一次带参数的访问就证明 AI 让业务增长。”

浏览器隐私设置、跳转、应用内浏览器、复制粘贴、Referrer-Policy 和广告拦截都可能移除这些信号。UTM 与 Referer 是正向证据，缺少它们只是“来源不可观察”，不是反向证据。

隐私与安全

UTM 中不要放邮箱、姓名、订单号等个人信息。
只保留完成归因所需的字段，设置明确的日志保留期限。
完整 Referer 可能包含路径和查询参数；默认优先保存主机名，必要时再短期保存原值。
按你所在地区的隐私法规、Cookie 同意机制和隐私政策执行。
不要把来源字段直接当作授权条件，也不要用它处理账号安全决策。

交给你的 AI 助手实施

请在当前网站项目中接入 AI 引荐访问归因。先阅读 https://madeinred.com/monitor.md，然后检查项目已有的分析工具和数据收集方式。

记录实际到达的 utm_source、utm_medium、utm_campaign；没有 UTM 时，尝试读取 HTTP Referer。处理空值和 URL 解析失败，只接受 http/https，并按已知 AI 来源域名白名单归一化。
UTM 和 Referer 分别保留观测依据；发生冲突时保留冲突，不把请求头或参数当作身份认证。
关联落地页、会话与已有的注册、咨询或购买事件。遵守项目现有同意机制，不记录邮箱、姓名或 URL 中的敏感参数，优先只保留 Referer 主机名。
用 utm_campaign=ai-referral-test 验证接收和转化链路，把测试数据单独标记并从正式报表排除。测试不能当成真实 AI 引荐。
给出实际修改、验证结果和查看数据的位置。没有来源信号时记录 unknown，不推断为没有 AI 访问；不要声称已覆盖全部 AI 流量。

和 MadeInRed 的关系

先用被 AI 引用体检检查网站是否能被 AI 抓取和引用，再用本教程在你自己的分析或日志系统中验证“可观察到的 AI 引荐访问”。体检回答“能不能被看见和引用”，本教程回答“点击发生后，我能看到哪些访问信号”。

原始 Markdown 地址：https://madeinred.com/monitor.md

AI 引荐访问监测

需要提供什么

你会得到什么