用GA4和BigQuery追踪ChatGPT、Perplexity与Gemini引荐流量

AI可见性指标（如被提及次数、被引用次数）正在成为品牌监测的标配，但所有做内容的人最终都会追问同一个问题：这些曝光到底有没有变成真实流量？

答案的一部分其实早就藏在你的分析工具里，只是被淹没在“Referral（引荐）”这一大类中。这篇文章会把它拆出来：在GA4里建一个专门追踪AI助手的自定义渠道组，用BigQuery从GA4导出数据里拉出AI引荐的会话和落地页，再把“被引用”和“被点击”两组数据做关联分析。

同时也要说清楚这类方法看不见的那部分流量——只有搞明白盲区在哪，数字才不会被误读。

AI流量是怎么出现的

当用户在AI回答里点击某个来源链接时，访问会以三种方式之一到达你的站点：

信号	示例	说明
Referrer请求头	https://chatgpt.com/、https://www.perplexity.ai/	Web端最常见
UTM参数	?utm_source=chatgpt.com	ChatGPT会给很多外链加上这个参数
什么都没有	(direct)	移动App、隐私设置、复制粘贴的URL经常会丢失referrer

需要匹配的referrer主机名有这些（建议集中放在一处维护，因为列表会变）：

chatgpt.com, chat.openai.com
perplexity.ai, www.perplexity.ai
gemini.google.com
copilot.microsoft.com
claude.ai
chat.deepseek.com

有一点需要特别注意：Google的AI Overviews和AI Mode带来的点击，在GA4里通常会归入普通Google自然搜索流量，所以不会出现在这套AI引荐统计中。

Referrer请求头是HTTP协议中的一个字段，浏览器在发起跨站请求时会自动携带它，值通常是用户此前所在页面的URL。网站分析工具（包括GA4）默认会读取这个字段来判定流量来源。当用户从 ChatGPT、Perplexity 等 AI 助手页面点击外链跳转到你的站点时，浏览器就会把 https://chatgpt.com/ 之类的地址写入 Referrer，GA4 据此把这次访问归类为来自该主机的引荐流量。

需要留意的是，Referrer 并不可靠。出于隐私考虑，很多浏览器和网站会通过 Referrer-Policy 主动裁剪或屏蔽该字段，移动 App 内的 WebView 也经常不发送 Referrer。这解释了为什么同一批 AI 引荐流量有时表现为 Referrer，有时表现为 UTM 参数，有时则彻底丢失——只能落到 Direct 里。

第一步：在GA4里创建自定义渠道组

进入 Admin → Data display → Channel groups，复制默认分组，然后新增一个名为 AI assistants 的渠道，条件设置为：

• Source matches regex：

^(chatgpt\.com|chat\.openai\.com|(www\.)?perplexity\.ai|gemini\.google\.com|copilot\.microsoft\.com|claude\.ai|chat\.deepseek\.com)$

然后把这个新渠道拖到“Referral”上方。GA4的渠道是按顺序匹配的，第一个命中的规则生效——如果Referral排在它前面，AI流量仍然会被Referral截走。

因为规则匹配的是 source 字段，所以它同时能抓到基于referrer的访问和带utm_source=chatgpt.com的访问。自定义渠道组在GA4报表中还会追溯生效，也就是说建好之后立刻就能看到历史数据。

GA4 渠道组是一套按顺序匹配的规则集合，用来把原始来源（source / medium）归入「自然搜索」「引荐」「付费搜索」等大类。系统对每个会话逐条比对规则列表，第一条命中的规则决定该会话的归属，后续规则不再评估。因此规则顺序本身就是逻辑的一部分：把 AI assistants 放在 Referral 之前，AI 引荐才会被单独识别，否则会先被更宽泛的 Referral 规则吃掉。

默认渠道组是 GA4 内置且不可修改的，自定义渠道组则允许你复制一套再增删规则，并指定它在报表中的生效范围。规则支持精确匹配、包含匹配和正则，本文用的是 Source 字段的matches regex。

第二步：从BigQuery导出中拉出原始AI会话

看趋势用GA4界面就够了，但要分析落地页、做数据关联或写自定义逻辑，就得用BigQuery导出。下面这段SQL会找出每个来自AI助手的会话的首次 page_view，referrer和UTM source两种信号都覆盖：

DECLARE ai_re STRING DEFAULT
  r'(chatgpt\.com|chat\.openai\.com|perplexity\.ai|gemini\.google\.com|copilot\.microsoft\.com|claude\.ai|chat\.deepseek\.com)';

WITH pv AS (
  SELECT
    PARSE_DATE('%Y%m%d', event_date)                                   AS day,
    user_pseudo_id,
    (SELECT value.int_value    FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_location,
    (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_referrer') AS page_referrer,
    collected_traffic_source.manual_source                              AS utm_source,
    event_timestamp
  FROM `my-project.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 28 DAY))
                          AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())
    AND event_name = 'page_view'
),
landing AS (
  SELECT *,
    ROW_NUMBER() OVER (PARTITION BY user_pseudo_id, session_id ORDER BY event_timestamp) AS rn
  FROM pv
)
SELECT
  day,
  COALESCE(REGEXP_EXTRACT(page_referrer, ai_re), REGEXP_EXTRACT(utm_source, ai_re)) AS assistant,
  REGEXP_REPLACE(REGEXP_EXTRACT(page_location, r'^https?://[^/]+([^?#]*)'), r'/$', '') AS landing_path,
  COUNT(*) AS sessions
FROM landing
WHERE rn = 1
  AND (REGEXP_CONTAINS(IFNULL(page_referrer, ''), ai_re)
       OR REGEXP_CONTAINS(IFNULL(utm_source, ''), ai_re))
GROUP BY day, assistant, landing_path
ORDER BY sessions DESC;

几个实用提醒：

• collected_traffic_source 字段在2023年中期之后的导出数据里才有，更早的数据只能靠referrer。
• REGEXP_EXTRACT 返回的是匹配到的主机名，所以 www.perplexity.ai 和 perplexity.ai 都会归一为 perplexity.ai。
• 用 _TABLE_SUFFIX 做过滤能把扫描范围和费用控制在需要的日期区间内。
• 如果你同时开启了intraday导出，events_* 也会匹配到 events_intraday_* 表，最近一天可能被重复计数。改成 events_2* 可以只匹配日表。

查出来的结果会按助手和落地页聚合，ChatGPT、Perplexity、Gemini、Copilot、Claude各自贡献了多少会话一目了然。数据布局上，适合用堆叠柱状图看各助手的份额变化，再用卡片展示单个助手的绝对量。

GA4 的 BigQuery 导出把每一次事件写成一行，存放在按天分表的 events_YYYYMMDD 表中，同一数据集下所有日表可以用通配符 events_* 一次查询。因为 GA4 是事件模型，会话级的维度（session_id、landing page 等）并不会直接作为列出现，而是嵌套在 event_params 这个键值数组里，需要用 UNNEST 展开后再按 key 取值——这就是 SQL 里反复写 (SELECT value.string_value FROM UNNEST(event_params) WHERE key = ...) 的原因。

collected_traffic_source 是较新版本导出中新增的顶层结构，存放 GA4 采集到的归因来源，manual_source 对应 UTM 的 utm_source。它比 traffic_source 系列字段更贴近原始采集值，也更适合做自定义归因。

第三步：把“被引用”和“被点击”关联起来

如果你在采集引用数据（比如记录每个页面被AI回答引用了多少次），现在又有了每个页面从AI助手带来的会话数，就可以把它们并排放在一起看：

WITH cited AS (
  SELECT landing_path, SUM(citations) AS citations
  FROM `my-project.ai_visibility.page_citations_28d`
  GROUP BY landing_path
),
clicked AS (
  SELECT landing_path, SUM(sessions) AS ai_sessions
  FROM `my-project.ai_visibility.ai_sessions_28d`
  GROUP BY landing_path
)
SELECT
  COALESCE(c.landing_path, k.landing_path) AS landing_path,
  IFNULL(c.citations, 0)    AS citations,
  IFNULL(k.ai_sessions, 0)  AS ai_sessions,
  SAFE_DIVIDE(k.ai_sessions, c.citations) AS sessions_per_citation
FROM cited c
FULL OUTER JOIN clicked k USING (landing_path)
ORDER BY citations DESC;

四个象限才是真正能指导行动的部分：

• 高引用、高会话：说明这套内容策略在起作用，保护这些页面并保持更新。
• 高引用、低会话：AI把你的页面当来源，但用户不需要点进来——答案本身已经完整了。定义类和简单事实类页面常出现这种情况。要想清楚页面是否给了用户一个非来不可的理由（工具、模板、更深的数据）。
• 低引用、高会话：这部分流量用现有prompt集解释不了。说明你的prompt监测列表漏掉了用户真正在问的问题，补上它们。
• 双低：大多数页面都在这。除非是你必须要拿下的页面，否则不用特别处理。

引用数和会话数放在同一张散点图上，用中位数或均值划分象限，就能快速看出哪些页面“叫好不叫座”，哪些页面“闷声来流量”。

这套方法测不到什么

有三块盲区，需要提前跟相关方讲清楚：

1. Referrer丢失。 App内点击和隐私设置会丢掉referrer，这些访问会落到Direct里。所以测到的AI流量是下限，不是全量。
2. 零点击影响力。 很多用户看完AI的推荐后，直接去Google搜品牌名或手动输入网址。这在数据上表现为品牌搜索或直接流量，跟AI没有任何归因关系。如果品牌搜索量上升和AI可见度上升同时发生，那只是间接证据——就应该按间接证据来看待。
3. AI Overviews和AI Mode 在GA4里被折叠进Google自然流量，无法单独拆出来。

这也是为什么单看引荐流量会低估AI搜索的价值，它必须和可见性指标并排看，而不是替代后者。

把可见性和结果放进同一个视图

最有用的报表，是把可见性（提及、引用、声量份额）和结果（AI会话数、转化数）放在同一批人面前、用同一个节奏来看。

Vista AI的Brand Visibility Dashboard覆盖可见性这一侧：按引擎和地区看可见度、与竞品对比的声量份额、情感倾向、按查询维度的排名，以及30/90/365天趋势，还支持每周邮件报告。它也支持多品牌独立查询集，方便代理商按客户分别汇报。把它和上面GA4里建的渠道配合起来，两半就齐了：AI有多经常推荐你，以及这些推荐有多经常变成一次访问。