品牌提及追踪

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 那条 Brand Mentions 头号 KPI 就是这一类（见 Otterly Brand Report KPI 定义），本质上就是 回答包含率 这个指标。
• 短语级：每次出现都算。会把提及频次抬高，只在要追「句内密度」时才用得上，这种需求很少。

每份报告抬头都要写明用了哪种去重单位（这是一项口径，不是脚注），就像 AI 引用追踪 §7 必须写明位置定义 A、B、C 一样。同一份日志能按三种单位分别汇总，这个余地要留着：在每条命中所在的句子上同时把出现次数也记下来（schema 见下文 §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：

• 这处具名指称确实指向你的实体（通过了消歧，不是撞词），并且
• 这句话是在讲这个品牌，而不是顺带提到（不是嵌在某个竞品 URL 里的 Acme.com，也不是在描述另一家品牌时一带而过，更不是一句与你解读相反的转折）。

核验过和未核验的计数要分开统计上报。AI 系统里「来源被用 ≠ 出处被正确署名」这层脱钩，Liu 等 2023 在引用一侧测过，提及这边逻辑相同：引擎给出的名字只是它的一种说法，并不等于关于你这家实体的事实。靠一堆未核验提及堆出来的 SOV 增长，是采购工具里最常见的一种隐性失效，何况其检测器内部对你并不透明。报告里以核验过的那一份为主数字，未核验的作为脚注。

下面是这条流水线的日志行 schema，设计上可以与 AI 引用追踪 §4 的引用日志直接连接（把两侧 join 一下，就能回答「这家品牌究竟有没有得到过任何形式的署名」）：

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 的同一套 schema，设计上与具体引擎无关：

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;

这些查询在一份 mention_log.parquet 上用 DuckDB 直接跑就行，不需要关系型数据库。

这个变化是真的吗？ 对外说「指标动了」之前，先过一遍这张清单（前几条沿用引用追踪那一侧，提及独有的几条用加粗标出）：

• 两次采样的提问集版本一致吗？
• 两次采样的 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