一句话结论：在国内测 ChatGPT / Perplexity / Gemini，测不准的原因几乎从来不是「没工具」，而是四个变量没锁死——出口地区、提问语言、账号与记忆状态、取数面。这四个里任何一个每轮都在漂，你拿到的就不是「品牌可见度」，而是「这次连出去恰好落在哪」。把它们各自钉成一个明确参数（哪国出口、哪种语言、干净会话、哪一面取数），同一批问题重复跑，数据才第一次变得可比。
为什么专门写这篇：中文侧搜「怎么监测 ChatGPT 里的品牌可见度」，返回的整页几乎是海外工具的机翻中文页——它们默认你人在纽约、账号在美国、网络直连，对中国团队在国内操作这件事一个字没写。而这恰恰是出海团队每天卡住的地方：报告出来了，但没人敢拍胸脯说这数字代表美国用户看到的样子。
先划三条界，免得你读错篇：
- 讲国内那套铺稿打法为什么套不到海外（信源池对照、投放规则相反）的，是《外贸 / 出海品牌的 GEO：国内那套打法为什么套不到 ChatGPT 和 Perplexity》——那篇管做什么。
- 讲海外工具看不见国内引擎（给有中国敞口的品牌）的，是《海外 AI 可见度工具在中国的盲区》——方向和本篇相反。
- 本篇只管一件事：中国团队、在国内，怎么把海外引擎的数测准。是测量方法，不是优化方法。
一、先承认一件事：你测的不是「ChatGPT」，是「某个地区某种语言下的 ChatGPT」
这是全篇的地基。海外 AI 引擎的答案不是全球统一的一份，它至少被两层地区化改写过：
第一层：引擎自己会用 IP 推断你在哪，并据此改写检索词。 OpenAI 官方帮助文档写得很直白：ChatGPT 可能用你的 IP 地址估算大致位置（国家 / 州 / 城市），用来改善本地相关的结果；文档给的例子是——你问「附近有什么好餐厅」，ChatGPT 判断你在旧金山地区，就会把提示词改写成检索词「top restaurants San Francisco」。同时，与搜索后端共享的信息里包含查询词和这个大致位置（IP 本身不共享）（OpenAI Help Center · Searching the web with ChatGPT，2026 年 8 月核对）。
换句话说：你的出口 IP 落在哪个国家，就等于替你在检索词后面偷偷加了一个地名。 这一条对「best CRM for small business」这类看似无地域的问题同样成立——它会影响哪些本地媒体、本地竞品被召回。
第二层：底层搜索本来就是分市场的。
必应的 Web Search API 用 mkt（语言码-国家码，如 en-US）定义结果来自哪个市场，cc 用国家码决定返回哪些市场的内容，两者互斥不能同时给（Microsoft Learn · Market and language codes）；谷歌侧对应的是 gl 参数。同一个查询在德国、日本、美国返回的排名和域名本来就不一样——AI 引擎坐在这层之上，自然继承了这份差异。
所以，「我们在 ChatGPT 里的提及率是 12%」这句话，在没说清哪个国家出口、什么语言之前，信息量接近零。
二、四个必须锁死的变量
| 变量 | 不锁死会怎样 | 锁死的具体做法 |
|---|---|---|
| 出口地区 | 出口漂 → 引擎推断的位置漂 → 检索词被改写成不同地名 → 召回的本地竞品与媒体全变 | 固定一个目标市场的出口节点（国家级即可），每轮不变；换地区必须当成新一轮基线 |
| 提问语言 | 中文问英文市场 → 命中的是中文信源池，和目标客户看到的是两回事 | 按目标市场语言重写（不是直译）问题集，一种语言一张表，绝不混算 |
| 账号与记忆 | 记忆 / 历史引用默认开启 → 你上一轮问过的品牌名会污染下一轮 | 用临时对话（不读取也不生成记忆），或专用干净账号并关闭个性化；每条问题开新会话 |
| 取数面 | 网页 / App / API 不是一套答案；API 不开检索工具时给的是模型记忆 | 主口径固定一面（通常是网页端），API 面单列为对照，报表里标清 |
下面逐条讲清楚「为什么」和「怎么做」。
变量 1：出口地区——最容易被当成「网络问题」的口径问题
多数团队把海外出口当连通性问题（能打开就行），实际上它是口径问题（决定了你在测哪个国家）。
判断你有没有踩坑，问自己三个问题：
- 我们每轮采集用的出口，国家是不是同一个？（很多机场/节点池会自动切换出口国）
- 这个国家是不是我们的目标市场？（在新加坡出口下测美国市场，数据没有意义）
- 换过节点之后，趋势图上有没有标注？（没标注的话，趋势断层会被误读成「优化见效了」）
如果你用 API 采集，地区可以直接写成参数，这是最干净的做法：
- OpenAI 的
web_search工具支持user_location对象，字段包括country（两位 ISO 国家码，如US）、city/region（自由文本）、timezone（IANA 时区，如America/Chicago）；官方文档同时注明深度研究类模型的 web search 不支持 user location（OpenAI · Web search 指南）。 - Perplexity 的搜索接口支持按 ISO 国家码做地区定向、按 ISO 639-1 做语言过滤（
search_language_filter接受语言码数组），若要按坐标定位则需 latitude / longitude 与 country 一起提供（Perplexity Docs · Search language filter）。
⚠️ 值得记一笔的现实：Perplexity 社区里有用户反馈，用英文提问时结果会强烈偏向英文来源，即便设置了 user location 也没能改变（Perplexity Community）。这说明地区参数不是万能开关，语言的权重可能更高——这正好引出变量 2。
变量 2：提问语言——直译问题集是出海团队最贵的一个偷懒
两个层面的坑：
问法层面：目标市场用户的问句结构和中文不一样。中文侧常见「XX 哪个牌子好 / XX 靠谱吗」，英文 B2B 买家更常直接问「best X for [具体场景]」「X vs Y for [场景]」。直译过去的问题在英文里可能根本没人这么问，你测的是一批没有真实搜索需求的句子。问题集怎么搭见《GEO 监测的提问集怎么设计》，那套方法在海外栈同样适用，只是词要重写。
语言—信源层面：AI 引擎处理多语言内容的能力参差不齐。一项对多语言查询与 hreflang 的公开测试发现，即使站点 hreflang 标注正确，ChatGPT 与 Claude 仍会返回错误语言版本的 URL；Gemini 表现较好；必应系的 Copilot 最守 hreflang 信号（GSQi · AI Search, hreflang, and translated content）。
对出海品牌的直接含义有两条：
- 测量上：语言必须作为一个明确维度分开报，「英文提及率」和「西班牙语提及率」是两个指标，不是一个指标的两次采样。
- 优化上：多语言站点被引用到错误语言版本这件事，本身就是一个应该被监测出来的问题——你以为「被引用了」，实际引用的是用户读不懂的那个版本。
变量 3：账号与记忆——被忽略最多、最容易一次性修好的一条
ChatGPT 的记忆功能默认开启，并且默认可以引用你的聊天历史来个性化回答；临时对话（Temporary Chat）不会读取已有记忆、也不会生成新记忆，不进历史、不用于训练（OpenAI Help Center · Memory FAQ、Temporary Chat FAQ）。
这对监测意味着什么，举个每天都在发生的场景：
你上午用同一个账号连问了「best project management tool」「Asana vs Monday」「我们公司 XX 怎么样」。到了下午再问一遍品类词，答案里出现了你的品牌——你会以为可见度提升了，其实是你自己刚教会它的。
最低成本的修法只有三步：每条问题开新会话；用临时对话或一个专门的、关闭个性化的采集账号；采集账号绝不用来做日常工作。
另外一条容易忘的：账号的注册国家、订阅计划、语言设置本身也是变量。采集账号的这些属性要写进采集口径文档，换了要记版本。
变量 4：取数面——决定了你的报告是「检索结果」还是「模型记忆」
这是本篇最硬的一条，也是最多海外监测报告在无声出错的地方。
大模型 API 在不显式启用检索/联网工具时，返回的是模型训练记忆里的品牌印象，不是实时检索结果。 这两个东西都有价值，但它们回答的是完全不同的问题：
| 取数面 | 实际在测什么 | 适合回答的问题 | 不能拿来回答 |
|---|---|---|---|
| 网页端（chatgpt.com / perplexity.ai） | 真实用户看到的答案 + 角标引用来源 | 「我的目标客户现在会看到什么」 | 难以大批量、可重复地跑 |
| API + 显式开启检索工具 | 检索层面的可见度，参数可写死、可复跑 | 「固定地区/语言下，谁被召回、谁被引用」 | 不完全等同网页端的最终措辞与排序 |
| API 不开检索 | 模型记忆里的品牌印象（训练数据的沉淀） | 「模型脑子里对我这个品类的默认认知是什么」 | ❌ 不能当作「AI 搜索可见度」汇报 |
| 手机 App | 移动端用户看到的答案 | 「移动侧体验」 | 精确引用 URL 常常拿不全 |
引擎面之间的差异有多大不是猜的——我们在国内栈做过同一件事的实测：豆包的 API、网页、App 引用不是同一套。海外栈的结构是一样的，只是多叠了地区和语言两个变量。
采购和自测时都要问出这一句：你这份数据是哪一面取的？如果对方答不上来，或者含糊说「调用大模型」，那大概率是第三行——模型记忆，不是可见度。
[NEEDS DATA — 人工核实：补一组我们自己的对照样本（同一条英文问题 × 美国出口 vs 新加坡出口 × 网页面，各跑 5 次），量化「换出口国」造成的提及率与引用域名差异。没有真实数据前不要写任何具体数字。]
三、绕不开的一节：可达性与合规
这一节不好看，但跳过它会让你的监测方案在公司内部过不了法务。
可达性：
- OpenAI 的支持国家与地区列表不含中国大陆和香港；官方明确说明，在支持范围之外访问或提供访问，可能导致账号被封禁或停用（OpenAI Help Center · Supported countries、ChatGPT and API services in unsupported countries）。
- Gemini 的可用国家 / 地区与语言以官方页面为准（Google 称移动端覆盖 150+ 个国家、网页端覆盖 230+ 个国家和地区，并按当地法规逐步扩展），中国大陆不在其中（Gemini Apps Help · Where you can use the Gemini web app，2026 年 8 月核对）。
合规：国内企业跨境联网的合规路径是通过获批设立国际通信出入口局的基础电信运营商开通国际专线（IPLC / IEPL 等），或使用完成主管部门审批与备案的跨境网络服务商；核心原则是限内部办公自用、不得转售经营，且未经批准不得自建或使用非法通道（参见锦天城 · 外资企业如何依法使用 VPN；具体到你公司的做法请以法务意见为准）。
从这两条推出的工程结论，其实很干净：
不要让「国内怎么翻出去」成为你监测方案的一部分。 把采集节点直接放在目标市场的海外云上（或交给海外同事 / 海外服务商），让「地区」从一个漂移的副作用，变成一个你主动写死的参数。这同时解决了三件事：地区口径固定、账号属地一致、链路来源清晰可审计。
这也是为什么「买工具还是自己搭」这道题，在海外栈上比在国内栈上更早倒向买——自建要额外承担境外节点、账号属地、账号存活这三份运维成本。这笔账怎么算见《自己写脚本监测 AI 提及，还是买工具》。
四、一套能重复跑的采集协议
把上面四个变量落成动作，最小可用版本是这样：
第 1 步：先定目标市场，再定引擎。 不要一次全开。先确定你这一季度真正要打的市场（比如「美国 + 英国」），再按市场选引擎。ChatGPT 通常是第一个必测；Perplexity 在信息型、对比型问句上占比更高；Gemini 视你的目标市场与安卓/谷歌生态权重决定。有一条公开统计值得记住：同时被 ChatGPT 和 Perplexity 引用的域名只有约 11%——测了一个不代表覆盖了另一个（数据与出处见双栈信源对照篇）。
第 2 步：问题集按市场重写，20–30 条，三类配比。 品类词（best X for…）、对比词（X vs Y）、品牌词（is X legit / X reviews）。每个市场一套，别共用。
第 3 步：把口径写成一张表，钉死。
| 口径项 | 本轮取值（示例） | 变更规则 |
|---|---|---|
| 目标市场 | 美国 | 变更 = 新基线 |
| 出口国家 | US（固定海外云节点） | 变更 = 新基线，趋势图标注 |
| 提问语言 | en-US | 一种语言一张表 |
| 引擎 × 取数面 | ChatGPT 网页面（主）；Perplexity 网页面；API 面仅作对照 | 主口径一季度内不改 |
| 账号状态 | 临时对话 / 采集专用账号、关闭个性化 | 换账号要记版本 |
| 每条采样次数 | 每条 3 次，分散在不同时段 | 次数是分母，不能中途改 |
| 会话隔离 | 每条问题开新会话 | — |
第 4 步：每条问题必记的字段。
问题 | 市场 | 语言 | 引擎 | 取数面 | 出口国 | 时间 | 是否联网检索 | 是否提到我 | 是否被推荐（进名单/被点名） | 引用域名列表 | 语境正负 | 是否推荐了本地竞品 | 答案里的语言版本 URL 是否正确
最后两个字段是海外栈特有的：前者告诉你地区口径有没有漂，后者告诉你多语言站点有没有被引到错版本。
第 5 步：报数时两栈永远分列。 国内栈和海外栈可以放进同一张表的两列，但绝不能平均。国内 60%、海外 5%，平均出 32.5% 这个数字既不能指导投放，也不反映真实处境。基准怎么定、别人的基准为什么不能抄，见《提及率 18% 算高还是低》。
第 6 步：留一条流量侧交叉验证。
在分析工具里把 chatgpt.com、perplexity.ai、gemini.google.com 等来源单独分组，和监测数据互相印证。国内那侧的对应做法见《豆包、元宝、夸克带来的流量怎么统计》。
想先手动摸一轮底再决定要不要系统化，按《怎么免费自查品牌在 AI 里有没有被提到》走一遍即可，本篇的四个变量在手动摸底时同样成立。
五、六种「测不准」的表现，各自的病因
拿这张表去对照你现在的报告：
| 症状 | 最可能的病因 | 怎么确认 |
|---|---|---|
| 同一条问题两次跑，结果差很远 | 会话未隔离 / 记忆开着 / 出口国变了 | 用临时对话重跑；核对出口 IP 归属国是否一致 |
| 答案里反复推荐一堆没听过的本地品牌 | 出口地区不是目标市场，引擎按当地口径召回 | 换到目标市场出口重跑同一条 |
| 提及率异常高，且几乎不带引用角标 | 大概率取的是未联网的 API 面，测到的是模型记忆 | 检查是否显式启用了检索工具；看返回里有没有来源 |
| 答案引用了你的站，但是错语言版本的页面 | 多语言站点的语言信号未被引擎正确处理 | 记录被引 URL 的语言版本；这本身是待修问题，不是测量误差 |
| 中文问出来「有提及」，英文问出来「查无此人」 | 语言变量没锁，两次测的是两个信源池 | 语言分表报数，别合并 |
| 换了工具/服务商后数字突然好看很多 | 口径变了（引擎面、采样次数、问题集任一项） | 逐项对齐口径表再比较，否则不可比 |
共同点：这六种没有一个是「引擎不准」，全部是口径没锁。这也是为什么，先把口径表钉死，比先买工具更重要。
六、什么时候该从手工升级到工具
手工能做完一轮摸底，但撑不住三件事，撞上任意一件就该系统化：
- 重复性：20 条问题 × 3 个引擎 × 3 次采样 = 180 次，每周一轮，手工做两周就会开始偷工减料——而偷掉的恰恰是采样次数，也就是分母。
- 口径固定：手工采集里出口国、账号状态、会话隔离全靠人记，一个人休假口径就断。
- 双栈同步：出海品牌真正要回答的是「我们在国内和海外分别处在什么位置」，两栈得同一时间窗、同一批问题逻辑、分开报数——手工几乎不可能对齐。
选型时，针对海外栈要额外问清三个问题（国内栈的选型要点见《国内 GEO 监测工具公开口径对照》）：
- 地区口径：你们的采集出口是哪个国家？能不能按市场指定？换了会不会通知我？
- 取数面：ChatGPT 是网页面还是 API 面？API 面有没有显式开检索？
- 账号隔离：多客户之间会不会共用采集账号、共享记忆？
三个问题里有一个答不清楚，那份报告就只能当参考，不能当基线。整体框架请先读《AI 搜索优化（GEO）完全指南》。
常见问题（FAQ）
在国内测 ChatGPT、Perplexity 的品牌可见度，为什么每次结果都不一样？ 四个变量没锁死：出口地区（ChatGPT 会用 IP 估算位置并改写检索词）、提问语言、账号与记忆（默认开启）、取数面（网页/App/API 不是一套）。锁死这四个，重复跑才可比。
挂个梯子在国内跑，和在海外服务器上跑，数据一样吗？ 不一样。差别不在速度，在「引擎认为你在哪个国家」。出口国一变，本地竞品和引用域名都会变。更稳的做法是把采集放在目标市场的海外云节点上，让地区成为主动设定的参数。
OpenAI 和 Gemini 在中国大陆本来就不可用，那这套还怎么做？ 可达性上，OpenAI 支持列表不含中国大陆与香港，越界访问可能被封号；Gemini 大陆不可用。合规上，企业跨境联网应走持牌运营商的国际专线或已备案的服务商，限内部自用。结论：采集节点放到目标市场的海外云，别依赖员工个人的境外工具。
问题集直接把中文版翻译成英文，够不够？ 不够。直译保语义不保问法，且语言会改变信源池——公开测试显示 hreflang 正确时 ChatGPT 与 Claude 仍可能返回错语言 URL。问题集按市场重写、按语言分表。
用 API 批量跑海外引擎，数据可信吗？
前提是知道自己测的是哪一面。不显式开检索工具时，API 给的是模型记忆而非检索结果。要模拟真实用户就得开检索并写死地区参数（OpenAI 的 user_location、Perplexity 的国家码与语言过滤）。
国内栈和海外栈的提及率能不能放进同一张表？ 可以同表两列，但不能平均。表头必须写清每栈的引擎、取数面、地区、语言、采样次数。
想让「美国出口 + 英文提问 + 网页面」这套口径每周自动跑一遍，并且和国内栈（豆包 / DeepSeek / Kimi / 千问 / 元宝 / 百度 AI）分列在同一份报告里？闻响 GeoEcho 同时监测国内与海外（ChatGPT / Perplexity / Gemini）引擎，口径可指定、两栈分开呈现提及率、推荐率与引用来源。输入域名，先免费跑一次看看底盘。
常见问题
在国内测 ChatGPT、Perplexity 的品牌可见度，为什么每次结果都不一样？
多数情况下不是引擎不稳定，是你自己有四个变量没锁死：①出口地区——ChatGPT 会用 IP 估算大致位置并据此改写检索词（官方文档举的例子是把「附近有什么好餐厅」改写成「top restaurants San Francisco」）；②提问语言——用中文问英文市场，命中的是完全另一批信源；③账号与记忆——ChatGPT 的记忆与历史引用默认开启，上一轮问过的品牌会影响下一轮；④取数面——网页端、App、API 不是一套答案，API 不显式开联网工具时给的是模型记忆而非检索结果。这四个变量锁死之后，同一批问题重复跑才谈得上可比。
挂个梯子在国内跑，和在海外服务器上跑，数据一样吗？
不一样，而且差异不在「快不快」，在「引擎认为你在哪个国家」。出口 IP 的归属国会直接改变检索的地区口径，出口一换、地区一漂，答案里推荐的本地竞品、引用的媒体域名都会跟着变。所以关键不是有没有海外出口，而是这个出口的国家是否固定、每轮是否一致。更稳的做法是把采集放在目标市场的海外云节点或海外同事的机器上，让地区变成一个你主动设定的参数，而不是一个漂移的副作用。
OpenAI 和 Gemini 在中国大陆本来就不可用，那这套还怎么做？
先分清两件事：可达性和合规性。可达性上，OpenAI 的支持国家与地区列表不含中国大陆与香港，从不支持地区访问可能导致账号被封停；Gemini 的可用地区以官方页面为准，中国大陆不在其中。合规性上，国内企业跨境联网的合规路径是通过持有国际通信出入口局资质的基础电信运营商开通国际专线，或使用完成主管部门审批与备案的服务商，且限内部办公自用。结论很简单：不要靠员工个人的境外工具去跑生产级监测，把采集节点放到目标市场的海外云上，既解决地区口径，也回避了灰色链路。
问题集直接把中文版翻译成英文，够不够？
不够。直译只保证语义对，不保证问法对——目标市场买家的真实问法和中文用户不一样，英文 B2B 买家更常直接问「best X for [具体场景]」，而中文侧更常问「XX 哪个牌子好」。另外语言本身会改变信源池：有第三方测试发现，即使站点的 hreflang 标注正确，ChatGPT 与 Claude 仍可能返回错误语言版本的 URL，Gemini 表现较好，Bing 系的 Copilot 最守 hreflang。所以问题集要按目标市场重写、按语言分开报数，别混进一张表里平均。
用 API 批量跑海外引擎，数据可信吗？
可信的前提是你知道自己测的是哪一面。大模型 API 在不显式启用联网/搜索工具时，返回的是模型训练记忆里的品牌印象，不是实时检索结果——这两者是不同的指标，不能混为一谈。如果要用 API 模拟真实用户，就必须显式开启检索工具并把地区参数写死：OpenAI 的 web_search 工具支持 user_location（country 用两位 ISO 国家码、city/region 为自由文本、timezone 为 IANA 时区），Perplexity 的搜索接口支持按 ISO 国家码做地区定向和按 ISO 639-1 做语言过滤。参数不写死，等于每轮换一个分母。
国内栈和海外栈的提及率能不能放进同一张表？
可以放进同一张表，但绝不能平均成一个数。两栈的问题集、语言、信源池、采样次数都不同，平均出来的数字既不能指导投放也不反映真实处境（国内 60%、海外 5%，平均 32.5% 这个数没有任何决策价值）。正确做法是一张表两列、各自跟自己的上一轮比，并在表头写清每一栈的口径：引擎、取数面、地区、语言、每条跑几次。