品牌提及追踪

1. 品牌提及追踪是什么

品牌提及追踪是一套可以重复运行的测量方法：固定一份提问集，确定引擎范围和采样周期，找出每条答案中的自家品牌名和竞品品牌名，核验后把结果写入统一的日志结构（schema）。持续采样后，时间序列数据会显示品牌被提及的频次、在答案中的位置和情感倾向。

本手册与 AI 引用追踪 配套使用。两者的测量方法相同，但要找的对象不同。引用是引擎以字段形式直接提供的网址（Perplexity 的 search_results[]、OpenAI 的 url_citation 标注、Gemini 的 groundingChunks），几乎不用检测，主要工作是后续的数据归一化。品牌提及则出现在答案正文各处，所有主流引擎都不会专门标出生成文本中的品牌实体，因此要自行搭建检测器，误差也几乎都来自检测过程。无链接提及为何值得测，机制见 品牌提及；引用、提及与链接这三种署名结果的区别，见 引用 vs 提及；本手册所采集指标的公式见 GEO 指标。

提及追踪的难度更高，主要有三个原因：

• 没有任何一家引擎的 API 提供 mentions[] 字段。 我们核对了 Perplexity（Chat Completions 参考）、OpenAI（Responses API web_search）、Google AI Overviews（Search Central — AI features）和 Gemini（Grounding with Google Search）。它们都会提供来源网址，有时也会提供引用对应的片段，却都不会在生成正文中标出品牌实体。
• 必须说清楚用什么单位统计「一次提及」，因为没有默认口径（§4.3）。对于「Acme 很快。Acme 接入了 X。Acme 更便宜。」这段答案，可以整段计 1 次、按句计 3 次，也可以逐次统计实际出现次数；三种方法会得出三个不同的数字。
• 品牌名可能还有其他含义（Apple 公司与 apple 水果；Meta 平台与英文修饰词 meta；自家子品牌与竞品同名等等），所以精确率比召回率更难保证。引用追踪正好相反，因为引擎不会凭空编造一个 URL。

2. 测量前要定下的五件事

下面五项决定了后续每个数字究竟代表什么。只要有一项没有说清楚，数据就无法解释。

四个核心提及指标都在 GEO 指标 中定义：§3.4（声量份额）、§3.6（提及频次）、§3.7（回答包含率）、§3.9（品牌情感）。本手册还会涉及其他指标，公式也可在其中找到。

3. 第一步：搭建提问集 ＋ 竞品集

提问集的设置规则与引用追踪一致：准备 30–50 条来自真实用户意图、类目分布均衡的提问，固定内容、标注版本号，再纳入版本控制（提问集是数据，不是配置）。详细做法见 AI 引用追踪 §3。

提及追踪还要设置竞品集，而引用追踪不一定需要这一步。竞品集有两种模式：

• 封闭式：预先确定 N 家竞品。SOV 分母保持稳定，因此可以比较不同采样轮次。
• 开放式：统计答案中出现过的所有品牌。这种模式更适合观察行业全貌，但分母会随每次采样变化。除非明确重新校准基线，否则不同轮次的 SOV 不能比较。

如果不说明竞品集，「声量份额」就没有明确含义。这也是各家厂商的 SOV 数字互不一致的根本原因（Otterly 公开公式、Ahrefs 按曝光加权、Profound 与 BrightEdge 不披露，详见 GEO 指标 §3.4）。竞品集属于哪种模式、包含哪些成员，都要写明并标注版本号。

最后会得到一份与 prompts.csv 同步做版本管理的 brands.yaml：

# brands.yaml — 与 prompts.csv 同步打版本号
my_brand:
  canonical: "Acme"
  aliases: ["Acme Inc.", "Acme Corp", "Acme.ai"]
  negative: ["acme"]                  # 常名词义碰撞
  disambiguation: ["SaaS", "CRM", "acme.com"]   # 必须共现的语境词
  parent: null
  brands_set_v: v1
  added_date: 2026-05-20

competitor_set:
  mode: closed
  members: [my_brand, competitor_a, competitor_b, ...]
  competitor_set_v: v1

4. 第二步：手工方法（务必从这里开始）

着手自动化之前，先手工完成一次完整流程。手工采样能让你看清各个引擎如何提及品牌。日后无论是校验采购工具，还是发现并排查检测器的计数错误，手工流程都是唯一可靠的办法。AI 引用追踪 §4 的规则在这里同样适用，下面只列提及追踪特有的步骤。

4.1 检测规则：别名、大小写、边界

把标准品牌名和别名清单都写入 brands.yaml，并明确规定以下四种边界情况，此后保持不变：

• 大小写：默认不区分大小写，但日志中要保留原始形式（情感标注可能用到，因为「ACME LAUNCHED」和「acme launched」的语感不同）。
• 所有格与复数：默认把 Acme’s、Acmes 算作匹配；如需排除，要在排除清单中写明规则。
• 连字符与空格变体：Acme AI、Acme.AI、Acme-AI 都算，除非 brands.yaml 另有约定。
• 正文中 URL 和邮件地址造成的误匹配：一律排除。答案的来源条目属于引用，不属于正文提及；网址中即使含有品牌字符串，也应记为引用，而不是正文提及。

这些规则也要按数据管理，不要写死在代码里。边界规则应与 brands.yaml 一起保存，并共用同一版本号。

4.2 消歧：确保精确率

提及追踪容易因名称重合而误判：品牌名可能同时是普通名词（Apple、河流名 Amazon、英文修饰词 meta）、人名或竞品子品牌。误判会抬高提及频次，让 SOV 偏离实际。采购工具常见的问题之一，就是检测器看似运行正常，却从未校准，使用者也未必能看到内部的判定逻辑。

如果别名本身有歧义，就必须结合上下文判断。只有同句或上一句出现相关产品名、域名或话题词，才能接受这次命中。把规则写入 brands.yaml 的 disambiguation: 字段，不要硬编码。§5.2 第三阶段的 LLM 判定主要处理这类情况。

4.3 去重单位：一次定下，长期沿用

在本手册的所有决策中，去重单位对数字含义的影响最大。同一段答案按以下三种方式统计，会得到三个不同的值：

• 句级：一句话中只要检出品牌，同一品牌就在这句计 1 次。最能直观反映一段答案用了多少篇幅谈论某个品牌。默认按句统计。
• 整答级：同一段答案中的同一品牌最多计 1 次。最接近厂商所说的「这段答案是否出现品牌」。Otterly 的首要 KPI Brand Mentions 就使用这种口径（见 Otterly Brand Report KPI 定义），本质上就是 回答包含率 这一指标。
• 短语级：品牌每出现一次就计 1 次。这会让提及频次偏高，只适合衡量「句内密度」，实际场景中很少使用。

每份报告都要在开头写明去重单位，不能只在脚注中注明这项统计口径；这与 AI 引用追踪 §7 要求注明位置定义 A、B、C 的道理相同。为了日后能按三种单位分别汇总，还要记录每个命中句中的实际出现次数（数据结构见下文 §4 末），查询时再选择所需单位。

4.4 情感：采样时标注，公式见 GEO 指标

每条保留的提及都要标上情感标签：pos / neg / neu / comparative（comparative 表示品牌在竞品比较中被提到，例如「X 比 Acme 更快」）。多数场景不必使用机器学习（ML）检测，以下几条经验规则已经足够：

• 同一句中，带有褒贬色彩的形容词与品牌字符串是否相距 ≤ 4 个 token；
• 前后一句内是否出现比较句式（「比 X 快」「不像 X」「相对于 X」）；
• 在「X vs Y」「X 的替代品」这类列表答案中，品牌位于什么位置。

品牌情感 的聚合公式见 GEO 指标 §3.9。情感标签必须在采样时添加，日志一旦汇总就无法再补充；采样时漏掉，之后只能重新采样。因此，手工采样时就要完成这一步。

4.5 逐条核验提及（确保精确率）

这一步对应 AI 引用追踪 §4.1 中的 citation_verified。检出的每条提及只有同时满足以下两点，才能记为 mention_verified = true：

• 这处具名指称确实指向你的实体，已经通过消歧，并非同词异义，并且
• 这句话确实在谈论这个品牌，而不是顺带提到。比如，Acme.com 不能只嵌在某个竞品的 URL 中；品牌不能只在描述另一家公司时一带而过；转折句的实际语义也不能与你的判定相反。

核验和未核验的计数要分开统计、分开报告。在 AI 系统中，「使用了来源 ≠ 正确标明出处」；Liu 等 2023 已在引用场景中证实两者可能脱节，提及场景也是同样的道理：引擎给出的名称只是它生成的一种表述，不能据此认定有关这个实体的内容属实。大量未核验提及会抬高 SOV。采购工具尤其容易出现这种隐蔽问题，因为检测器的内部逻辑通常并不透明。报告应以核验后的数据为主，未核验数据只作补充。

下面是每行日志的结构。它可以直接关联 AI 引用追踪 §4 中的引用日志；合并两类数据后，就能判断某个品牌是否获得过任何形式的署名：

run_date            采样日期（UTC）
prompt_id           外键 -> prompts.csv
prompt_set_v        提问集的版本号（固定下来的那一份）
brands_set_v        brands.yaml ＋ 竞品集的版本号
engine              perplexity | chatgpt | google-aio | gemini | ...
brand_id            外键 -> brands.yaml（my_brand 或 competitor_x）
unit                sentence | answer | phrase  （去重单位）
occurrence_count    单位内的命中次数（>= 1）
mention_position    在答案文本中的 1-indexed 位置
sentiment           pos | neg | neu | comparative
mention_verified    true | false   （见 §4.5）
detector_v          规则包版本 ＋（可选）评审模型 ＋ 评审提示词
snippet             这条提及出现在的那一句（或几句）

5. 第三步：自动化方法（重点是检测器）

只有经过验证的手工流程才能转成自动化流程，这与 AI 引用追踪 §5 的要求完全一致。不同之处在于，引用追踪使用引擎提供的检测结果，只需编写封装逻辑；提及追踪则要自己搭建最关键的检测器。

5.1 各引擎的 API 现状（提及版）

下表所列平台与引用追踪相同，但提及数据更难获取：没有一家主流引擎提供「正文中被提及的品牌实体」字段。

这些平台都要自行搭建检测器，具体方法见 §5.2。

5.2 检测器：三阶段流程

检测分为三个阶段，成本逐步提高。多数生产流程只需前两个阶段；第三阶段更适合用于 QA 比对，通常不必长期启用。

• 第一阶段（纯规则）。使用别名清单、带单词边界限制的正则表达式、§4.1 的边界规则和排除清单。优点是成本低、结果可复现，规则也便于审查；缺点是无法识别改写后的指称（「做出 X 的那家公司」），也不擅长处理同词异义。
• 第二阶段（规则 ＋ 语境消歧）。完成第一阶段后，再检查 brands.yaml.disambiguation 中规定的语境：对于有歧义的命中，只有同句或上一句出现相关语境词，才算有效提及。多数品牌用这一阶段作为生产标准即可。
• 第三阶段（由 LLM 评审处理剩余歧义）。第二阶段会标出仍有歧义的命中，QA 比对也要定期抽取整体样本。遇到这两种情况，把完整句子和候选品牌交给一个成本较低、型号固定且用途明确的小模型：「句子里这个 Acme 指的是 SaaS 公司，还是另外的意思？返回是、否、不确定，并附一句理由。」固定模型和提示词，分别标注版本号，再写入 detector_v。只有 Apple、Amazon，以及与 Facebook 共用同一词根的 Meta 等容易大量产生歧义的别名，才需要长期启用第三阶段。

只要 LLM 评审影响了不同运行轮次的统计结果，就必须留下记录。每次升级评审模型或提示词，都相当于升级 detector_v，必须重新校准基线；具体做法与 AI 引用追踪 §3 中升级提问集相同。

下面的自动化伪代码沿用 §4 的数据结构，不依赖任何特定引擎：

for engine in engines:
  for prompt in prompt_set_v:                          # 固定下来的那一份，带版本号
    answer = engine.ask(prompt)                        # 全新会话，无历史
    for s in split_sentences(answer):
      for brand in brands_set_v:
        hit, occ = rule_match(s, brand.aliases, brand.negative)
        if hit:
          ok  = disambiguate(s, brand) and llm_judge(s, brand)   # 5.2 阶段
          tag = tag_sentiment(s, brand)
          log.append(run_date, engine, prompt.id, prompt_set_v,
                     brands_set_v, brand.id, "sentence",
                     occ, position(s, answer), tag,
                     mention_verified=ok, detector_v=detector_v, snippet=s)

5.3 采购方案：厂商检测器的现状

无论自建还是采购，都要先回答一个定义问题：你认可哪家厂商对「提及」的定义？先确定定义，再选择厂商，顺序不能颠倒。下表列出各家定义和出处（公式都在 GEO 指标 §3.4）：

不要把两家厂商的 SOV 数字并列在同一份报告中，当成同一个指标。Ahrefs 按曝光加权的 SOV 与 Otterly 按原始计数计算的 SOV 回答的是不同问题；Profound 与 BrightEdge 又没有公开可验证的方法。GEO 指标 §3.4 已说明这一区别，报告数据时不要混用。

6. 第四步：归一并存储数据，计算变化量

存储规则与引用追踪完全相同：保留原始答案，不作修改；所有指标都通过计算得出，不能手工修改。如果某个数字看起来不合理，应检查并修改生成它的查询，而不是直接改表格里的单元格。需要运行三条查询（公式都在 GEO 指标）：

-- 提及频次  （GEO 指标 §3.6）
SELECT engine, brand_id,
       SUM(occurrence_count) FILTER (WHERE mention_verified) AS mentions
FROM mention_log
WHERE prompt_set_v = 'v3' AND unit = 'sentence'
GROUP BY engine, brand_id;

-- 声量份额，封闭式竞品集，按原始计数  （GEO 指标 §3.4）
WITH m AS (
  SELECT brand_id, SUM(occurrence_count) AS n
  FROM mention_log
  WHERE prompt_set_v = 'v3' AND mention_verified
    AND brand_id IN (SELECT member FROM competitor_set_v3)
  GROUP BY brand_id
)
SELECT brand_id, n * 1.0 / SUM(n) OVER () AS sov FROM m;

-- 回答包含率  （GEO 指标 §3.7）
SELECT engine,
       COUNT(DISTINCT prompt_id) FILTER
         (WHERE brand_id = 'my_brand' AND mention_verified) * 1.0
       / COUNT(DISTINCT prompt_id) AS air
FROM mention_log
WHERE prompt_set_v = 'v3'
GROUP BY engine;

可以用 DuckDB 直接对 mention_log.parquet 运行这些查询，不需要关系型数据库。

这个变化是否真实？ 在对外报告指标变化之前，先逐项检查以下内容（前几项与引用追踪相同，提及追踪特有的项目以粗体标出）：

• 两次采样的提问集版本一致吗？
• 两次采样的 brands.yaml 和竞品集版本一致吗？
• 检测器版本一致吗（规则包 ＋ 评审模型 ＋ 评审提示词）？
• 样本中的提及总数够不够？少于约 30 条时，同样要留意 GEO 指标 §3.7 针对 AIR 提出的小样本问题。
• 两次采样之间，某个引擎的运行方式是否发生过变化？
• mention_verified 比例是否变化？如果「增长」只是未核验提及增多造成的，就不是真实增长。

7. 第五步：报告数据时写明口径

对外报告的每个数字都要注明统计口径，否则就无法与其他结果比较。提及追踪要说明以下内容：

• 提问集版本（如 v3）
• 品牌集版本 ＋ 竞品集模式（封闭式或开放式） ＋ 成员名单
• 检测器版本：规则包 ＋ LLM 评审模型 ＋ 评审提示词
• 引擎集（列明具体引擎，而不是笼统地写「AI」）
• 时间窗（如 7 天、每周采样）
• 去重单位（句级、整答级或短语级）
• 情感标注方案的版本号

如果报告只写「声量份额 18%」，却漏掉上述任何一项，这个数字就不能算有效指标。

不要把指标变化直接解释成业务结果，也不要夸大结论：提及频次变化不等于营收变化。要从可见度推算业务收益，需要另一套模型，见 GEO ROI 模型。GEO 审计 第 6 层会用到两类数据：本流程生成的提及日志和引用日志。追踪适合日常监测，审计适合定期复核。

8. 常见误差与陷阱

发布报告前，逐项检查以下问题。提及追踪特有的问题以粗体标出；与引用追踪共用的问题则附有相关说明：

• 提问集偏差，见 AI 引用追踪 §3
• 时间窗偏差，见 AI 引用追踪 §6
• 品牌名与其他词义重合：这是影响精确率的主要问题，可用 §4.2 的语境消歧和 §5.2 第三阶段的 LLM 评审处理
• 去重单位漂移：上个月按句统计，这个月改为按整答统计。如果不明确披露这项变化，就相当于在未说明的情况下更换统计口径，数据会因此失真
• 竞品集漂移（开放式模式下）：答案中不断出现新品牌，SOV 分母也会随之变化，因此必须固定名单并标注版本号
• 把厂商的 SOV 数字简单叠加：见上文 §5.3 与 GEO 指标 §3.4
• 未识别负面提及：提及频次很高但情感为负，不能算成功；没有 §4.4 的情感标注，就无法发现这一点
• 多语言混用：中文与英文的提及数据不能相加，见 GEO 指标 §7
• 误用 Aggarwal 结果：Aggarwal 等 2024 度量的是页面改写带来的呈现度提升，不是无链接提及的数量。论文中备受关注的最高 40% 并非本手册中提及频次的预期值；论文条目对这一数字适用范围的说明，在这里同样适用。
• 不要外推单方面测得的提升：C-SEO Bench（Puerto 等 2025） 发现，许多对话式 SEO 改写在有竞争对手时会相互抵消。这一点也适用于提及追踪：即使单方面测得 SOV 增长，如果竞品也在优化同一批提问，增长也未必能保持。

9. 延伸阅读

• 指标与定义：GEO 指标、品牌提及、引用 vs 提及
• 业务视角：GEO ROI 模型
• 对应手册：AI 引用追踪，测量方法相同，处理的是引用数据
• 相关操作：GEO 审计，第 6 层会使用本手册生成的提及日志
• 各引擎细节：Perplexity AI、ChatGPT Search、Google AI Overviews
• 学术来源与适用边界：Aggarwal et al. 2024

参考资料

学术：

1. Aggarwal, P. et al. (2024). GEO: Generative Engine Optimization. KDD ‘24. arXiv:2311.09735 · ACM DL
2. Liu, N., Zhang, T., Liang, P. (2023). Evaluating Verifiability in Generative Search Engines. Findings of EMNLP ‘23. arXiv:2304.09848
3. Puerto, H. et al. (2025). C-SEO Bench: Does Conversational SEO Work? NeurIPS ‘25 D&B. arXiv:2506.11097

API 与平台文档（已于 2026-05 核对）：

• Perplexity — Chat Completions API Reference · Changelog
• OpenAI — Web Search tool (Responses API)
• Google Search Central — AI features and your site
• Google — Grounding with Google Search (Gemini API)

厂商 KPI 方法论（用于采购比较，汇总见 GEO 指标 §3.4）：

• Otterly.AI — Brand Report KPI Definitions
• Ahrefs — Brand Radar Methodology
• Profound — How to Track Your Visibility in AI Search
• BrightEdge — What Share of Voice Really Means for Search in 2026