竞品分析的依据要能回答三个问题：判断从哪来、证据怎么留、结论怎么复核。可执行的依据体系由五类材料组成：竞品公开信息、可观察的产品行为、用户侧证据、市场与渠道证据、内部依据。每类材料都记录来源、获取日期、获取方式和可信度等级，形成可追溯的证据台账，再据此填写对比表并得出结论。
要点总览（TL;DR）
- 竞品分析的依据分为五类：竞品公开信息、可观察的产品行为、用户侧证据、市场与渠道证据、内部依据，每类材料按证明力分级，第三方转述只作线索。
- 取证从分析问题倒推：明确决策用途、圈定竞品与维度、按维度拆分取证项并指派负责人、设定时间窗与截止点。
- 证据台账固定七个字段，截图与原文摘录同时留存，重要结论由两条以上独立证据支撑，单一来源的判断标注待核实。
- 取证人与复核人分离，产品经理、市场研究、销售、客户成功、技术支持按维度分工，复核记录完成前结论不发布。
- 交付前逐项核对证据编号、有效期、不确定项标注与复核记录；无来源的价格、版本、认证信息不写入结论。
竞品分析依据的五个来源与可信度分级
竞品分析的依据按来源可分为五类。分类的目的在于让取证有清单可依，同时让每类材料的证明力有明确区分，避免把转述当成事实、把线索当成结论。
| 来源类型 | 典型材料 | 可信度等级 | 核实方式 |
|---|---|---|---|
| 竞品公开信息 | 官网功能页、版本说明、定价页、帮助文档、公开财报与公告 | 高（官方一手） | 记录页面地址与获取日期，价格、版本类信息回到官方渠道确认 |
| 可观察的产品行为 | 试用账号操作路径、演示环境、公开演示视频 | 较高（可复现的一手观察） | 按固定步骤复现，截图并注明账号类型、版本与操作时间 |
| 用户侧证据 | 公开评价、社区讨论、工单反馈、访谈记录 | 中（一手反馈但样本有限） | 记录样本数量与来源渠道，访谈保留原始记录 |
| 市场与渠道证据 | 招投标公告、合作伙伴名单、应用市场信息 | 中（公开但间接） | 核对公告原文与应用市场页面，注意发布时间 |
| 内部依据 | 销售输单原因、客户流失记录、支持工单归类 | 中高（内部一手，需归类口径一致） | 由对应团队按统一字段导出，注明统计区间 |
一手证据指直接来自竞品官方或直接观察、直接访谈所得的材料；二手证据指经过他人转述、整理或评论的材料。可信度分级的基本口径是：官方文档与公告高于可复现的产品行为观察，产品行为观察高于用户侧一手反馈，用户侧反馈高于第三方转述与社区讨论。同一层级内，能复现、能回到原始出处的材料优先。
第三方转述、行业文章中的功能描述、社区里对价格的讨论，都只宜作为线索。使用这类材料时，要回到官网、帮助文档或实际试用中二次核实，核实通过后再进入台账并提升可信度等级；无法核实的，保留为线索并在结论中标注。
从分析问题倒推取证清单：四步操作
取证清单从分析问题出发，而不是从“能收集到什么”出发。四步操作把决策用途逐层拆到可指派、可截止的具体任务。
第一步：明确分析问题与决策用途
输入是本次分析的发起背景，动作是把问题写成一句可判断的表述，例如“某功能维度上我们与主要竞品的差距是否影响续约客户的选择”。输出是分析问题清单与用途说明，完成标志是每个问题都能对应一个将受影响的决策，例如版本规划优先级或销售话术调整。
第二步：确定竞品范围与对比维度
输入是分析问题清单，动作是圈定纳入对比的竞品名单并列出对比维度，如功能覆盖、定价结构、交付方式、目标客户。输出是竞品名单与维度表，完成标志是每个维度都能说明它与分析问题的关系，范围外的竞品和维度明确排除。
第三步：按维度拆分取证项并指派负责人
输入是维度表，动作是把每个维度拆成具体取证项，注明预期来源类型与负责人。输出是取证任务清单，完成标志是每个取证项都有唯一负责人和明确的取证方式。
第四步：设定取证时间窗与截止点
输入是取证任务清单，动作是为每项设定开始时间、截止时间和复核时点，价格、版本类时效性强的项目单独标注复查日期。输出是带时间节点的任务清单，完成标志是所有任务都有截止时间，且整体截止点早于结论评审时间。
| 分析问题 | 对比维度 | 取证项 | 预期来源 | 负责人 | 截止时间 |
|---|---|---|---|---|---|
| 示例：功能差距是否影响续约 | 功能覆盖 | 核心流程功能清单与操作路径 | 官网文档＋试用观察 | 产品经理 | 评审前一周 |
| 示例：功能差距是否影响续约 | 用户选择理由 | 近半年输单原因归类 | 内部销售记录 | 销售负责人 | 评审前一周 |
取证任务分派后，负责人、截止时间和交付物需要有一个共同可见的载体。团队可以把每个取证项建成工作项，按维度分组，把证据文档挂在对应工作项下，评审时直接按工作项核对完成情况；具体用哪种工具，按团队现有的协作方式确定。
证据台账怎么记：字段与填写规则
证据台账是依据可追溯的核心载体。每条证据一行，字段固定，填写口径统一，复核人才能按编号回查。
| 字段 | 填写规则 |
|---|---|
| 证据编号 | 按“维度缩写-序号”编制，全表唯一，结论引用时直接写编号 |
| 来源链接或出处 | 网页记录完整地址，访谈记录注明对象类型与日期，内部数据注明系统与统计区间 |
| 获取日期 | 记录实际获取当天日期，不写“近期” |
| 获取方式 | 注明官网查阅、试用操作、访谈、内部导出等具体方式 |
| 对应维度 | 与取证任务清单中的维度名称一致 |
| 可信度 | 按分级口径填写等级，并说明理由，如“官方帮助文档”“第三方转述待核实” |
| 核实状态 | 填写待核实、已核实、无法核实三种状态之一 |
截图与原文摘录要同时留存：截图保留页面全貌与时间信息，原文摘录保留关键句，两者放在同一证据条目下。涉及版本或价格的材料，摘录中注明对应版本号或页面标注的生效时间。
结论支撑规则：重要结论宜由两条及以上相互独立的证据支撑，例如官方文档加试用观察，或试用观察加用户访谈。只有单一来源支撑的判断，在结论中显式标注为待核实，并说明补证计划。
信息过期与版本变化用两种方式标注：一是在台账中新增一条新证据并注明“替代某编号”，保留旧记录不删除；二是在结论引用处标注证据获取日期，超过约定有效期的证据在评审时重新确认。
角色分工与各环节交付物
取证人与复核人分离，是避免依据来源单一和判断偏差的基本安排。取证人对材料真实性负责，复核人核对来源与引用是否一致，结论由分析负责人统稿。
| 角色 | 取证职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 产品经理 | 定义分析问题与对比维度，负责功能维度的试用观察 | 分析问题清单、维度表、功能对比初稿 | 取证启动前交付问题与维度，评审前交付初稿 |
| 市场研究 | 收集官网、版本说明、定价页、公告等公开信息 | 公开信息类证据条目 | 截止时间前录入台账 |
| 销售 | 整理输单原因与客户提及的竞品选择理由 | 输单原因归类表 | 截止时间前提交，注明统计区间 |
| 客户成功 | 提供流失记录与客户反馈中的竞品相关信息 | 流失原因摘录 | 截止时间前提交 |
| 技术支持 | 按统一口径归类工单，提取与竞品对比相关的反馈 | 工单归类统计 | 截止时间前提交 |
| 复核人 | 抽查证据编号与来源是否对应，核对结论引用 | 复核记录与签字 | 评审前完成 |
评审环节的参与角色包括分析负责人、各取证负责人和复核人。评审输入是完整台账、对比表和结论初稿；输出是结论确认、待核实项清单和补证安排。复核人未完成复核记录的，结论不进入正式发布。
示例：一次功能对比的完整取证过程
以下为演示情景，用于说明从问题到结论的依据链条，不涉及任何具体竞品的能力判断。
分析问题设定为“某核心流程的功能覆盖差距是否影响续约客户的选型”。对比维度确定为功能覆盖与用户选择理由两项。针对功能覆盖维度，收集三类证据：竞品官网功能页与帮助文档（公开信息）、试用账号按固定步骤走完核心流程的观察记录（产品行为）、近半年客户访谈中提及该功能的反馈（用户侧证据）。
取证过程中出现冲突：官网功能页描述该能力已提供，试用观察发现该能力在特定配置下才可用，用户访谈中有客户反映实际使用受限。处理方式是三条证据分别录入台账，试用观察条目注明账号类型与配置条件，官网条目注明页面获取日期，冲突本身作为一条分析记录写入结论，不合并成单一说法。
| 证据编号 | 来源 | 获取方式 | 可信度 | 核实状态 |
|---|---|---|---|---|
| GN-01 | 竞品官网功能页 | 官网查阅 | 高 | 已核实 |
| GN-02 | 试用账号操作记录 | 试用观察 | 较高 | 已核实 |
| GN-03 | 客户访谈记录三份 | 访谈 | 中 | 已核实 |
推导过程：官网材料说明能力存在，试用观察说明能力有配置前提，用户反馈说明该前提在实际使用中构成限制。结论写为“该能力在标准配置下覆盖核心流程，在特定配置下存在使用限制，对续约选择的影响需结合更多样本判断”。不确定项标注为：访谈样本仅三份，配置前提的适用范围待补充试用验证；官网页面信息以获取日期为准，后续版本变化需复查。
完成检查：依据是否足以支撑结论
交付前逐项核对以下清单，全部通过才进入结论发布。
- 关键结论是否都标注了可追溯的证据编号，编号能在台账中查到对应条目。
- 是否存在仅凭单一来源支撑的重要判断；如有，是否已在结论中标注待核实并安排补证。
- 证据获取日期是否在约定有效期内，价格、版本类信息是否在评审前重新确认。
- 不确定项与假设是否已显式标注，包括样本量、配置条件和适用范围。
- 复核人是否完成复核并留下记录，取证人与复核人是否分离。
- 阻断项检查：无来源的价格、版本、认证信息一律不写入结论；发现即退回补证，不进入发布。
这份清单同时可作为评审会的核对议程：按结论逐条对照证据编号，确认支撑强度，记录待补证事项和责任人，形成下一轮取证的输入。
常见问题
竞品分析中，官网功能页和试用观察结论不一致时怎么处理？
两条证据分别录入台账，不合并成单一说法。官网条目记录页面地址与获取日期，试用观察条目注明账号类型、版本和配置条件，冲突本身作为一条分析记录写入结论。结论表述为“在标准配置下具备该能力，在特定配置下存在使用限制”，并说明需要补充哪些验证来缩小分歧。这样处理保留了双方证据的原始状态，复核人可以按编号分别回查。
内部销售输单记录和客户访谈样本量有限，能作为竞品分析的依据吗？
可以作为依据，但要按用户侧证据和内部依据的可信度等级使用，并在结论中标注样本量与统计区间。样本量小时，宜把这类材料用于提出假设和解释现象，与官方文档、试用观察等独立证据交叉印证后再下判断。只有单一来源支撑的重要结论，标注为待核实并写明补证计划，例如扩大访谈范围或增加试用复现次数。
价格和版本信息变化快，台账里怎么记录才不会过期？
台账中记录实际获取日期，不写“近期”这类模糊表述，并注明页面标注的生效时间或版本号。信息更新时新增一条证据并注明“替代某编号”，旧记录保留不删除，便于追溯判断依据的变化。价格、版本类时效性强的项目，在取证任务清单中单独设定复查日期，评审前重新回到官方渠道确认一次。
小团队人手有限，取证人和复核人无法完全分开怎么办？
分离的核心是让复核动作独立发生，可以由不同角色交叉承担。例如产品经理负责功能维度的取证，由市场研究复核该维度的来源与引用；市场研究收集的公开信息，由产品经理抽查。关键是复核人按证据编号逐条核对来源与结论引用，并留下复核记录。同一人既取证又复核的条目，在评审时由其他参与者重点抽查。
取证任务和证据文档放在哪里，评审时怎么核对？
常见做法是把每个取证项建成工作项，按对比维度分组，负责人、截止时间和交付物写在任务里，证据文档挂在对应工作项下。评审时按工作项逐条核对完成情况和证据编号，未完成的直接列为待补证事项。团队可以用现有的项目协作与文档工具承载这套结构，选择时看它能否按维度分组、能否把文档与任务关联、能否保留修改记录。
