先给结论：看到 AI 流量，不等于已经完成 AI 归因
AI 搜索流量归因，真正要回答的是“这次访问来自哪条可观察路径、证据能支持到哪一层”，而不是把所有没有来源的访问都归给 AI。一个访问可能带着明确的 AI 产品来源，也可能因为应用内打开、隐私处理、复制粘贴链接或中间跳转而丢失来源；没有可用来源时，系统只能记录为来源未知或 direct，不能补写成 AI 引荐。
对 GEO 站点来说，至少要分开记录四件事：AI 回答中是否出现品牌或页面、是否产生可识别的站内访问、访问是否完成目标行为、是否能把行为归因给某一次回答。前两项可以互相提供线索，但都不能单独证明后一项。归因报告应保留原始来源、UTM、落地页、时间、会话和事件定义，并把“已识别”“用户自报”“来源未知”分成不同状态。
只把有明确来源证据的访问计入“已识别 AI 引荐”；把 direct、缺失 Referer、复制粘贴和无法确认的平台访问保留为“来源未知”；把回答引用、访问和转化分别建表，再用时间窗口和页面版本做关联。
先分四层：引用、访问、会话和业务行为
归因混乱通常不是数据太少，而是把不同事实写进了同一个字段。AI 平台回答中的来源卡片属于答案层，浏览器请求属于访问层，分析系统中的会话属于统计层，注册或询盘属于业务层。它们可以通过 URL、时间和实验 ID 建立关联，但一条记录不能自动替代另一条记录。
| 层级 | 要回答的问题 | 主要证据 | 不能直接推出 |
|---|---|---|---|
| 答案引用 | 固定问题下，回答是否提到品牌或给出页面链接？ | 问题、完整回答、来源区、平台和观察时间 | 一定产生访问或转化 |
| 请求访问 | 服务器是否收到来自某个客户端的页面请求？ | 时间、路径、状态码、IP、User-Agent、Referer | 这是人而不是爬虫，或一定来自引用页面 |
| 站内会话 | 访问是否形成可分析的用户会话？ | 会话 ID、落地页、来源、设备、同意状态和去重规则 | 用户一定看过回答或只受一次引用影响 |
| 业务行为 | 是否完成注册、下载、询盘等预先定义的事件？ | 事件日志、时间窗、去重规则和转化路径 | 全部价值都由 AI 产生，或存在单一因果 |
Google 对搜索工作流程的公开说明将抓取、索引和结果呈现分成不同阶段。类似地，AI 回答出现一个 URL、浏览器产生一次请求和统计系统记下一次会话，也应保持分层。即使三件事发生在相近时间，也只能先记录为相关观察，不能直接写成因果证明。
三种来源状态：已识别、自报和未知
建议后台把来源状态做成枚举，而不是只留一个 source 字符串。状态本身要能说明证据强弱，不能用平台名称掩盖判定依据。
| 状态 | 判定条件 | 可公开的写法 | 不应写成 |
|---|---|---|---|
| 已识别 AI 引荐 | Referer、平台标记、受控 UTM 或其他可复核字段明确指向某个 AI 产品，并通过机器人排除规则。 | 本窗口记录到 N 个可识别的 AI 引荐会话。 | 全部 AI 流量、全部 AI 用户。 |
| 用户自报 AI 来源 | 问卷、反馈或访谈中用户主动说明来自某个平台，但没有请求级来源字段。 | N 位用户自报曾通过某平台发现本站。 | 平台带来了 N 个已验证会话。 |
| 来源未知 | direct、Referer 缺失、来源被清理、复制粘贴或链路无法恢复。 | N 个会话来源未知，不能分配给 AI。 | AI 带来了 N 个 direct 会话。 |
“已识别”也只说明来源字段满足当前规则，不代表你看到了用户在 AI 平台中的完整路径。来源规则应保存版本号；当平台域名、跳转方式或 UTM 规则变化时，旧数据不能用新规则悄悄重算。
Referer、UTM、落地页和服务器日志分别能证明什么
Google Analytics 的流量来源文档把来源、媒介、广告系列参数和 direct 等概念放在统计采集语境中。实际接入时，还要结合浏览器是否发送 Referer、平台是否经过中间页、链接是否被复制，以及站点是否在隐私同意前阻止统计。不要把一个参数当成完整的用户旅程。
| 字段 | 能支持的判断 | 限制 | 建议保存 |
|---|---|---|---|
| Referer | 本次 HTTP 请求在客户端提供了一个来源页线索。 | 可能被浏览器策略、应用内浏览器、跳转或隐私设置省略；不能证明用户实际阅读过来源页。 | 原始值、解析后的主机、接收时间和解析规则版本。 |
| UTM 参数 | 链接创建者在 URL 中附加了一个可控的活动标记。 | 可能被转发、手工修改、截断或重复；标记存在不等于用户真的从该平台点击。 | 原始 URL、规范化字段、首触点与末触点策略。 |
| 落地页 | 会话首次进入的页面，可连接到页面主题和内容版本。 | 只能说明进入了哪页，不能证明发现来源或引用是否准确。 | 规范 URL、页面版本、首访时间和会话 ID。 |
| 服务器日志 | 服务器收到请求的时间、路径、状态和客户端自报信息。 | 必须排除蜘蛛、健康检查、预取和重复请求；IP 也不等于用户身份。 | 请求 ID、状态码、User-Agent、Referer、客户端分类和保留期限。 |
| 用户自报 | 用户记忆或主动说明的发现渠道。 | 存在回忆偏差，不能与请求级来源混为一张精确报表。 | 问题版本、回答选项、自由文本和同意记录。 |
UTM 怎么设计：可控链接和自然引用要分开
UTM 适合你能控制的链接，例如社交文章、邮件、合作页面或自己的推广材料。它不适合伪造 AI 平台自然引用，也不能因为 URL 带有 utm_source=deepseek 就声称平台已经推荐了页面。自然回答中的链接与人工投放链接应在数据模型中用不同的 linkOrigin 区分。
utm_source=baijiahao、utm_medium=owned_content、utm_campaign=geo-research-202611。平台名称、渠道类型和活动批次分别表达；不要把日期、页面标题和自由文本混在一个字段里。
对每个受控链接记录创建人、用途、目标页面、规范 URL、过期时间和是否允许外部转发。接收端保留首次来源和当前来源时，要先决定使用首触点、末触点还是多触点模型；模型改变后重新计算的数字不能直接与旧报表拼接。
先排除蜘蛛：请求不是用户访问
GEO 站点经常同时观察搜索蜘蛛、AI 爬虫、监控探针和真实用户。如果把这些请求混进会话，PV、UV、AI 引荐和转化率都会被污染。User-Agent 是自报信息，不能单独证明身份；应按已知官方规则、IP 或正反向 DNS 核验方案标记候选，并保留“待核验”和“未知”。
| 请求类型 | 默认处理 | 保留用途 |
|---|---|---|
| 已核验搜索蜘蛛 | 排除用户会话和 UV | 单独统计抓取次数、状态码和路径分布 |
| AI 爬虫或答案代理 | 排除业务会话，单独记录身份与用途 | 观察抓取资格，不能写成 AI 用户访问 |
| 健康检查、监控探针和预取 | 排除 PV、UV 和转化 | 用于可用性和响应状态监控 |
| 身份未知的自动程序候选 | 暂不计入用户指标 | 进入待核验队列，保留原始日志 |
访问排除规则需要记录在报告中。某个请求被排除并不代表它是恶意请求，也不代表目标平台一定没有读取页面；它只表示这次请求不应进入“真实用户流量”的分母。
最小数据模型：把答案记录和访问记录关联起来
如果只在后台显示“AI 流量：12”，后续无法复核这个数字来自哪里。建议至少建立四张逻辑表，哪怕早期实际存储仍使用 JSON 或 SQLite，也按稳定字段组织。
| 表 | 关键字段 | 用途 |
|---|---|---|
| answer_observation | observationId、platform、questionId、answerAt、answerText、sourceUrls、pageVersion | 记录固定问题下的回答和来源，不把回答直接当访问。 |
| request_event | requestId、receivedAt、path、status、referer、userAgent、clientClass、botStatus | 保存服务器请求以及蜘蛛和监控排除结果。 |
| session_event | sessionId、landingPage、sourceState、utm、consentState、pageVersion、eventName | 统计会话、页面阅读和关键事件。 |
| attribution_link | observationId、sessionId、linkOrigin、linkEvidence、matchRule、confidence | 记录一次回答观察与一次会话之间为何建立或未建立关联。 |
关联关系也要允许“未关联”。例如某轮回答明确给出 ZenLeak URL，但服务器在观察窗口没有匹配到访问；这应记录为“回答层有显式引用，访问层未观察到匹配会话”，不能把引用次数直接变成访问次数。
一套可复跑的归因流程
- 冻结回答基线。保存问题原文、平台入口、联网和登录状态、观察时间、完整回答、来源 URL 与目标页面版本。
- 标记链接来源。区分平台自然来源、受控 UTM、站内内链、用户自报和未知，不让人工推广链接冒充自然引用。
- 接收并分类请求。记录请求原文，先判断是否为已核验蜘蛛、监控、预取或未知自动程序，再决定是否进入用户统计。
- 生成会话与事件。按照统一的会话、同意、去重和关键事件规则记录落地页、阅读、下载、注册和询盘。
- 建立保守关联。只有来源字段、时间窗口、目标 URL 和受控标记满足规则时，才建立回答观察到会话的关联；无法匹配就留空。
- 分层汇总。分别公开回答引用数、已识别 AI 引荐会话、自报来源会话、来源未知会话和关键事件，不用一个总数覆盖缺失项。
- 复核异常。抽查来源值、访问日志、机器人分类和事件记录，发现规则变化时冻结旧报表并新建规则版本。
后台应该显示什么
一个有用的后台不是只显示“AI 流量趋势”。它应让你从趋势点回到原始记录，同时提醒哪些数字只是线索。
| 模块 | 建议展示 | 必须有的边界 |
|---|---|---|
| 答案观察 | 平台、问题、回答时间、品牌提及、页面引用、内容采用、准确状态 | 标明人工观察、平台接口或用户提供材料 |
| 访问概览 | 已识别 AI 引荐、自报、来源未知、普通搜索和排除请求 | 显示分母、排除规则和时间窗口 |
| 来源明细 | 原始 Referer、规范主机、UTM、落地页、会话 ID 和匹配规则 | 权限控制 IP、设备和敏感字段，按隐私策略保留 |
| 关联队列 | 已关联、未匹配、待核验和规则冲突的记录 | 未知不能自动改成否，人工修正要有审计记录 |
| 业务事件 | 下载、注册、询盘等事件及其来源状态 | 时间相邻不是因果证明，支持导出原始事件 |
指标和分母：先报告可识别覆盖，再谈效果
归因数据通常不完整，最重要的不是把比例算得很精细，而是让读者知道有多少访问真正具备可判定来源。可以使用下面这组最小指标，名称和分母固定后再长期比较。
已识别 AI 引荐覆盖率 = 已识别 AI 引荐会话数 ÷ 全部有效用户会话数
来源未知率 = 来源未知会话数 ÷ 全部有效用户会话数
AI 引荐关键事件率 = 发生关键事件的已识别 AI 引荐会话数 ÷ 已识别 AI 引荐会话数
回答到访问匹配率 = 已匹配会话的回答观察数 ÷ 有显式页面引用的回答观察数这些指标只能描述当前数据集中的可观测结果。回答到访问匹配率尤其容易被误读：同一个用户可能换设备、复制 URL 或从应用内打开，导致回答确实产生了影响但没有可匹配字段；反过来，一个带 UTM 的链接也可能被转发后由其他人访问。因此报告需要同时公开未匹配数和匹配规则。
某窗口有 1,000 个有效用户会话，其中 34 个被识别为 AI 引荐，210 个来源未知；AI 引荐中 6 个发生关键事件。可以写“记录到 34 个已识别 AI 引荐会话，6 个发生关键事件”，不能写“AI 带来 34% 流量”或“AI 贡献了全部未知流量”。
案例：引用存在，但访问和转化仍然未知
假设固定问题“如何判断 AI 引用是否准确？”在一次观察中出现了 ZenLeak 的页面 URL。答案记录可以把这次结果标为“页面引用”，并进一步对来源内容做声明级核验；如果服务器日志中没有同一时间窗口的用户请求，访问层应记录“未观察到匹配会话”。如果有一个带 utm_source=deepseek 的会话，则只能在该链接确实由 ZenLeak 受控投放时建立受控活动关联，不能把它与平台自然引用混为一谈。
| 层级 | 观察 | 建议状态 |
|---|---|---|
| 答案 | 来源区显示目标文章 URL。 | 页面引用：是；引用准确：待声明级核验。 |
| 请求 | 没有匹配的用户请求，只有一个搜索蜘蛛请求。 | 用户访问：未知；蜘蛛访问单独记录。 |
| 会话 | 没有有效用户会话。 | AI 引荐会话：0 个已观察，不写成平台没有带来访问。 |
| 业务 | 没有会话就没有可归因的注册或询盘。 | AI 转化：不可计算，不是 0% 的效果判断。 |
隐私与数据保留不能事后补
IP、设备信息、来源 URL、会话标识和自由文本可能组合成访问者画像。后台需要先确定收集目的、权限范围、脱敏方式、保留期限和导出删除流程，再决定保留哪些字段。公开研究可以展示聚合计数、脱敏后的路径和判定规则，不应把可识别的原始访问明细直接放到前台。
统计同意状态也应进入数据模型。未同意时未采集到的字段不能补写成“来源未知 AI”，同意后得到的会话也不能与之前缺少标识的访问随意拼接。隐私策略变化时，分段报告并注明规则版本，保持历史数字可解释。
能自动化什么，哪些判断要人工完成
| 可以自动化 | 需要人工或平台证据 |
|---|---|
| 解析 Referer、UTM、落地页、状态码和请求时间。 | 判断一个来源是否代表自然 AI 引用，还是受控链接、转发或中间页。 |
| 按版本排除已知蜘蛛、监控和重复请求，生成待核验队列。 | 确认自报蜘蛛身份、处理边界和是否应从用户指标中排除。 |
| 按固定分母计算会话、事件、覆盖率和未知率。 | 判断回答是否准确采用页面，以及访问是否能与回答观察建立可信关联。 |
| 保存原始记录、摘要、哈希和审计日志。 | 解释因果、评估业务价值和对外发布结论。 |
发布前检查清单
- 已把回答引用、服务器请求、用户会话和业务事件分开建模。
- 已定义已识别 AI 引荐、用户自报来源和来源未知的状态条件。
- 已记录原始 Referer、UTM、落地页、时间、页面版本和规则版本。
- 已排除或单独保存搜索蜘蛛、AI 爬虫、监控和预取请求。
- 已决定首触点、末触点或多触点策略，并没有把不同策略混在同一报表。
- 已为每个关键事件定义去重规则、时间窗口和同意状态。
- 已将未匹配、待核验和未知保持为空或单独状态，没有补成 0。
- 已提供从汇总数字回到原始记录的权限受控入口。
- 公开结论限定在平台、问题、时间、页面版本和可观测来源范围内。
常见问题
direct 流量是不是 AI 流量？
不能这样判断。direct 通常表示分析系统没有拿到可用来源信息，可能包含手动输入、书签、复制粘贴、应用内跳转或被清理的来源。它应保留为来源未知，除非有额外的用户自报或受控实验材料。
看到 AI 爬虫访问，能否算 AI 给我带来了用户？
不能。爬虫访问说明某个自动程序请求了页面，不能证明有用户看到了回答或点击了链接。爬虫记录应进入抓取观察，与用户会话和转化分开。
没有 Referer 还能做 AI 流量分析吗？
可以，但要降低结论强度。你仍可使用受控 UTM、用户自报、固定问题的页面引用观察和时间窗口进行分层分析；没有请求级来源时，不要把未知会话补成某个平台。
多久复盘一次比较合适？
按页面改版、平台变化和业务周期预先设置窗口。每次复盘都要保留规则版本，固定核心问题，并把探索性问题单独列出，避免为了得到更高比例临时改变分母。
结论边界
AI 搜索流量归因能提高站内数据的可解释性，但无法恢复已经丢失的来源，也无法仅靠统计字段证明模型内部使用了哪一段内容。它更适合回答“哪些访问具备可复核来源、哪些行为与固定观察相匹配”，不适合把所有增长归因给某个平台或某篇文章。
下一步可以阅读GEO 效果衡量框架了解四层指标，阅读GEO 效果复盘安排窗口，阅读百度蜘蛛身份核验处理自动请求，再用AI 搜索引用证据归档保存回答层材料。只有这些记录彼此分开、又能通过稳定字段关联，归因结果才有复核价值。