# 根据已核查的公开证据建立竞品功能矩阵

比较竞品时，先明确一项买方任务，核查各厂商的官方来源，再记录各来源能支持什么结论，避免凭空判断功能是否存在。使用功能矩阵：以买方任务为行、产品为列的表格。将证据状态标为“有文档支持”“你已测试”或“未知”。搜索没有找到答案，只表示问题尚未解决，不能证明产品不提供某项功能。

先人工核查官方产品页面和帮助页面。需要时，再通过搜索寻找这些页面。最终应得到一张注明日期的对照表，包含来源链接、明确的限制和未解决的问题。文档中的支持说明，与产品在你自己的使用环境中有效运行的证据，应分开记录。

## 1. 搜索前先明确买方任务

提供的公开买方提问想了解：对于团队也计划开发的软件功能，竞品是如何实现的。要回答这个问题，需要比较任务的具体完成方式。仅列出功能名称并不足够。这篇公开帖子提供了有用的背景，但不能证明这一需求有多普遍。[公开买方提问，发表于2024年7月5日；检索于2026年10月25日；仅作背景参考](https://www.reddit.com/r/ProductManagement/comments/1dw40o7/how_do_you_all_manage_competitor_research/)。

用一句话说明买方要完成的任务，写清操作和所需结果。例如，买方可能需要将报表导出为 CSV。CSV 指逗号分隔值，是一种存储表格数据的文本格式。买方也可能需要查看谁审批过报表的历史记录。这是两项不同的要求，应各占一行。

搜索前，先记录：

1. 买方要完成的任务及所需结果。
2. 要比较的具体产品。
3. 判断每项要求所需的证据。
4. 需要满足的订阅方案、地区或软件版本条件。
5. 比较日期，以及明确的研究结束条件。

订阅方案指产品的订阅档位。版本用于标识某一次具体的软件发布。这些条件会影响来源能否回答你的问题。如果某项必要条件尚不明确，应将其记为待确认。

每一行的范围都要足够具体，便于核查。“报表功能”过于宽泛。“官方文档将 CSV 列为导出格式”则是一项可核查的标准。如果导出文件是否包含买方所需的列也会影响决策，就应另设一项标准。

收集结果前，先确定范围。如果之后出现新要求，应记录变更，并将新要求用于所有产品。不要仅因某家厂商对某项功能介绍得很详细，就为它增加一行。

这张表比较的是与买方任务有关的证据。如果你需要比较竞品网站在搜索中的位置，请使用另一套[固定竞品查询组](/zh-Hans/articles/%E5%9B%BA%E5%AE%9A%E5%BF%85%E5%BA%94%E5%85%B3%E9%94%AE%E8%AF%8D%E9%9D%A2%E6%9D%BF-%E7%AB%9E%E5%93%81%E5%87%BA%E7%8E%B0%E6%AF%94%E8%BE%83/)方法。搜索位置不能证明产品能力。

## 2. 明确定义证据状态

填写表格前，先定义证据状态。对每个产品使用相同的规则。

| 证据状态 | 含义 | 不能证明什么 |
| --- | --- | --- |
| 有文档支持 | 经过核查的官方文字，在其所述条件下支持这项具体标准 | 产品能在买方的使用环境中成功运行 |
| 读者已测试 | 你已执行所述测试，并保存了结果和条件 | 产品也支持其他订阅方案、版本或任务 |
| 未知 | 经过核查的证据尚不能确定是否满足该标准 | 产品缺少该功能，或应得零分 |

将文档证据和测试证据放在不同字段中。同一产品可以同时拥有两类证据。添加测试结果时，应保留指导该测试的官方来源。

用简短备注说明未知状态。例如：“格式不明确”“页面无法打开”“订阅方案不明确”或“没有经过核查的来源”。这些备注用于解释证据缺口，不是对产品作出的额外判断。

例如，页面写着“导出报表”，并不能证明支持 CSV 导出。它只能支持较宽泛的导出说明。对于更具体的 CSV 标准，状态仍为未知，直到经过核查的来源明确写出该格式，或你自己的测试给出答案。

如果官方页面说明了限制，应准确记录。某个订阅方案的限制，不代表所有订阅方案都有同样的限制。保留“仅”“除……外”“最多”等限定词。这些词可能影响决策。

## 3. 优先核查官方页面

打开各厂商的官方网站，寻找与买方任务最相关的页面。帮助页面、产品文档和订阅方案页面都是值得查看的候选来源。一手来源来自负责该产品的组织。它记录的是该组织的说法，不能代替你自己的测试。

确认页面确实属于目标厂商。评测网站、经销商网站或名称相近的网站都属于其他来源。将第三方评论与官方产品证据分开记录。

对每个相关页面：

1. 记录准确的页面地址和打开日期。
2. 阅读与核查标准有关的段落。
3. 保存一小段准确原文，以及对应的标题或章节名称。
4. 记录其中说明的订阅方案、地区、版本及其他条件。
5. 写出该段落能支持的具体证据结论，避免扩大范围。

搜索摘要是搜索结果旁显示的简短文字。应把它当作线索。在用它支持矩阵中的单元格前，先打开页面。关于[将页面段落用作证据前如何核查](/zh-Hans/articles/%E5%BF%85%E5%BA%94-%E7%BD%91%E9%A1%B5%E6%90%9C%E7%B4%A2%E6%99%BA%E8%83%BD%E4%BD%93-%E5%B7%B2%E6%A0%B8%E5%AF%B9%E9%A1%B5%E9%9D%A2%E8%AF%81%E6%8D%AE/)的单独指南，更详细地说明了这一步。

如果页面没有显示日期或版本，应写“未注明”。不要用打开页面的日期代替。核查日期告诉读者你何时检查了页面，不能证明厂商何时撰写或修改了它。

这套方法能生成一份注明日期的比较结果，不能据此确定产品发布日期或随时间发生的变化。

## 4. 用精简的搜索输入寻找候选来源

你可以通过人工研究完成比较。需要帮助寻找页面时，[Google Search Scraper](https://apify.com/chronometrica/google-search-scraper) 的文档所列输入字段和结果字段适用于寻找来源这一步。Actor 是托管运行的数据采集程序。Task 是为 Actor 保存的一组预设输入。

所提供的证据记录了对公开默认构建版本 1.0.15 的核查，核查日期为2026年10月25日。其 schema 用于定义输入结构和字段，其中声明了下文使用的字段。静态检查确认，这个示例符合该 schema。本文准备过程中没有运行 Actor。这项检查不能证明实际运行结果、完整覆盖范围或采集成功。[公开默认构建版本，核查于2026年10月25日；仅有 schema 证据，未实际运行](https://api.apify.com/v2/acts/mlmVX4amk2biciJaB/builds/default)。

可采用以下建议的精简输入：

```json
{"country":"US","engines":["google"],"language":"en","maxResultsPerExecutedQuery":3,"queries":["reporting software CSV export documentation"]}
```

4. 用精简的搜索输入寻找候选来源

查询词是发送给搜索引擎的文字。将示例查询词替换为一家具体厂商的名称，以及买方实际要完成的任务。问题要足够具体，便于找到相关官方页面。对每个产品使用相同的研究方法。

示例请求使用 Google，国家设为 US，语言设为 en。只有这些值符合研究范围时，才保留它们。每条实际执行的查询，结果上限为 3 条。上限只限制请求采集的数量，不保证返回三条结果，也不保证覆盖所有相关页面。

公开的[竞品搜索结果研究 Task，核查于2026年10月25日；仅确认页面存在](https://apify.com/chronometrica/google-search-scraper/examples/competitor-serp-research)页面当时存在，Task ID 为 `Pjq0JLkzo0wHTcabU`。SERP 指搜索引擎结果页。这个 Task 可以作为起点，但其当前保存的设置和运行行为均未经验证。上面的示例是建议使用的替代输入，并非已验证的保存设置副本。

使用搜索时，保留以下已声明的结果字段：

| 字段 | 使用方法 |
| --- | --- |
| `executedQuery` | 保留与该结果对应的完整查询词 |
| `engine` | 记录该行报告的搜索引擎 |
| `title` | 识别候选页面 |
| `canonicalUrl` | 保留返回的结果地址，再核查目标页面 |
| `resultDomain` | 辅助识别结果中报告的网站域名 |
| `snippet` | 寻找可能相关的内容；保留缺失值 |
| `isSponsored` | 让付费结果标记保持可见 |
| `rank` | 记录在已解析且受支持的结果区块中的累计顺序位置 |
| `observedAt` | 记录搜索观测时间 |

这些字段有助于追溯你如何找到来源，不能证明页面支持你对功能的说法。页面核查应另行记录。搜索排名不是产品质量评分。

## 5. 保存足够细节，为每个单元格提供依据

用汇总矩阵方便阅读，用证据表方便核查。矩阵中的单元格可以包含证据状态和证据引用。通过该引用，应能找到来源段落及其适用条件。

在证据表中保存以下字段：

| 保存的字段 | 记录内容 |
| --- | --- |
| 产品 | 准确的厂商名称和产品名称 |
| 买方任务 | 操作及所需结果 |
| 核查标准 | 这条记录要回答的具体问题 |
| 证据状态 | 有文档支持、读者已测试或未知 |
| 来源 URL | 准确的官方页面地址，或明确标记为缺失 |
| 页面标题与位置 | 页面标题及相关的小标题或章节 |
| 支持结论的段落 | 简短、准确的原文，并保留适用条件 |
| 页面日期或版本 | 页面注明的内容，或“未注明” |
| 核查日期 | 实际核查页面的日期 |
| 订阅方案与地区 | 已说明的条件，以及尚未确认是否匹配的条件 |
| 范围备注 | 段落支持哪些结论，以及哪些问题仍无答案 |
| 读者测试 | 未执行，或指向你的测试记录的引用 |
| 未解决的问题 | 作出决策所需但仍缺失的事实 |
| 下一步行动 | 一项具体的页面核查、测试或向厂商提出的问题 |

如果通过搜索找到了来源，应在来源记录旁保留搜索引用。如果多个页面共同支持一个单元格，应为每个支持页面单独保存一条证据记录。

不要用猜测值填补缺失字段。“未注明版本”不等于版本为零。“未执行测试”不等于测试失败。“没有经过核查的来源”不等于官方声明该功能不可用。

公开页面可以支持有关公开文档内容的说法，却不能揭示私有账户设置、内部审批记录或你自己的导出结果。如果你在获得授权后执行账户测试，应将账户条件和测试结果保存在单独的测试记录中。本文不包含此类记录。

## 6. 确认条件匹配后再下结论

将每个来源与买方的实际需求对照。页面可能说明了所需功能，但仍不足以确定它是否适合买方。

对每个产品核查以下条件：

1. 页面介绍的是目标产品吗？
2. 页面是否涉及这项具体任务及所需结果？
3. 所述订阅方案是否与买方的订阅方案一致？
4. 如果地区会影响结果，地区是否一致？
5. 如果软件版本会影响结果，版本是否一致？
6. 段落是否说明了会影响任务的限制？

不要因为页面未提及某项条件，就认定该条件匹配。记录缺失的条件，并缩小结论的适用范围。

如果两个官方页面的说法似乎不一致，应同时保留。注明各自的日期、范围和条件。在来源核查、厂商答复或明确说明的读者测试解决问题前，将结论标为待定。不要在未解释冲突的情况下，只选取更有利的段落。

需要测试时，先定义预期结果，再执行测试。保存步骤、测试日期、环境、预期结果、实际结果和证据。一次测试只能支持你实际核查的任务和条件，不能证明产品整体更好。

## 7. 逐步分析一个原创虚构示例

原创虚构教学示例。以下产品、买方需求和来源描述均为虚构。这不是 Actor 运行记录、客户结果，也不是实际观察到的企业研究结论。未进行任何读者测试。

虚构买方需要 CSV 导出和审批历史记录。产品 A 的官方帮助页面说明了 CSV 导出。产品 B 的营销页面提到了导出，但未注明格式。对于选定的任务，产品 C 没有经过核查的来源。这些来源描述都没有回答审批历史记录的问题。

将两项任务分开记录：

| 买方任务 | 产品 A | 产品 B | 产品 C |
| --- | --- | --- | --- |
| 导出为 CSV | 有文档支持；帮助页面说明了 CSV 导出 | 未知；导出格式不明确 | 未知；没有经过核查的来源 |
| 查看审批历史记录 | 未知；未提供支持结论的段落 | 未知；未提供支持结论的段落 | 未知；没有经过核查的来源 |

示例包含三个产品和两项买方任务：

3 个产品 × 每个产品的 2 项买方任务 = 6 个比较单元格。

1 个有文档支持的单元格 + 5 个未知单元格 = 6 个比较单元格。

执行的读者测试次数为 0。这里用零表示测试次数是正确的，因为示例明确说明未进行任何测试。五个未知单元格表示缺少证据，不表示缺少五项功能，也不能因此给出五个零分。

产品 A 的 CSV 单元格只支持一个具体说法：其虚构的官方帮助页面说明了 CSV 导出。提供的虚构材料没有给出订阅方案、地区、版本、准确原文或页面地址。这些字段仍待确认。不要为了让证据记录看起来完整而编造内容。

产品 B 的页面只支持“页面提到了导出”这一宽泛说法，没有回答 CSV 的问题。产品 C 的证据缺口仅表示尚未核查来源，不能证明是否存在 CSV 导出功能。

根据这些缺口，接下来应问：

| 产品 | 下一项证据问题 |
| --- | --- |
| A | 文档所述的 CSV 导出适用哪些条件？哪个来源说明了审批历史记录？ |
| B | 产品文档说明了哪些导出格式？ |
| C | 哪个官方页面涉及这两项买方任务中的任意一项？ |

你不能根据这张表，按完整工作流程的适用性为这些产品排名。但你可以据此确定，为作出该决策还需要哪些核查。

## 8. 分享前检查证据缺口和核查失败状态

将每个单元格与其来源记录逐一核对。确认读者能沿着每项有文档支持的说法，找到官方页面和相关段落。

明确记录未能完成核查的各种情况：

| 情况 | 记录方式 | 结论限制 |
| --- | --- | --- |
| 搜索未返回有用页面 | 未知；未找到有用来源 | 不要推断产品缺少该功能 |
| 候选页面无法打开 | 未知；页面无法核查 | 不要将搜索摘要用作证明 |
| 页面只描述了更宽泛的功能 | 对于更具体的标准，状态为未知 | 将宽泛说法单独保留 |
| 缺少必要条件 | 条件待确认 | 不要声称产品适合买方 |
| 官方页面说法冲突 | 冲突未解决 | 保留两个来源 |
| 未进行读者测试 | 未测试 | 不要暗示已有实际操作结果 |

将搜索采集问题与产品结论分开记录。采集结果为空或不完整，不能说明厂商缺少某项功能。

也要检查总结中的措辞。“我们找到了这项任务的相关文档”，比“这个产品满足我们的所有需求”范围更窄。有文档支持的功能，不能证明产品经过测试后表现更优。用矩阵说明你已知什么、哪些问题仍无答案，以及哪个证据缺口会影响下一步决策。

## 选定下一项核查

先处理最影响买方选择的未解决问题。核查一个官方页面，向厂商提出一个明确的问题，或计划一次小规模的账户测试。采取行动前，先写明预期获得的证据。只有实际执行测试并保存结果后，才能将计划中的测试记为已执行。

需要帮助寻找候选页面时，可以使用 [Google Search Scraper](https://apify.com/chronometrica/google-search-scraper)。先使用上文那组精简的替代输入。然后打开相关官方来源，补全证据记录。分享注明日期的矩阵，并附上未解决的问题，让下一步决策有经过核查的证据作为依据。

## 来源和延伸阅读

- [Google Search Scraper 公开默认构建版本 1.0.15，核查于2026年10月25日；仅核查已声明字段并进行静态验证，未实际采集](https://api.apify.com/v2/acts/mlmVX4amk2biciJaB/builds/default)
- [竞品搜索结果研究 Task，核查于2026年10月25日；已确认公开页面及准确的 Task ID，保存的设置和运行行为未经验证](https://apify.com/chronometrica/google-search-scraper/examples/competitor-serp-research)
- [公开竞品研究提问，发表于2024年7月5日；检索于2026年10月25日；仅作买方背景参考，不作为需求或产品证据](https://www.reddit.com/r/ProductManagement/comments/1dw40o7/how_do_you_all_manage_competitor_research/)