用户洞察分析的依据通常来自四类证据：用户行为与反馈数据、业务与产品上下文、研究过程记录，以及外部与行业参考。它们共同回答“用户是谁、在什么场景下遇到什么问题、我们凭什么这样判断”。本文按“定问题—列依据—建台账—分角色—做检查”的顺序，给出可直接套用的证据清单、台账字段和完成检查表，适合产品经理与用户研究员在需求评审或版本规划前使用。
要点总览（TL;DR）
- 用户洞察分析的依据由四类证据构成：用户行为与反馈数据、业务与产品上下文、研究过程记录、外部与行业参考；四类证据分工不同，混用容易让结论站不住。
- 列证据清单从决策问题出发：把模糊需求转成可回答的决策问题，拆成现状、原因、影响三类子问题，再为每个子问题指定证据类型、来源和优先级。
- 证据台账至少记录证据编号、类型、来源、采集时间、样本说明、采集人、可信度等级和对应结论；出现冲突证据时保留双方记录并写明采信理由。
- 角色按采集、分析、评审三段划分，评审设在证据清单确认和结论评审两个节点，交付物统一归档，便于版本复盘时直接引用。
- 完成检查从证据覆盖度、样本与来源代表性、结论与证据对应、时间与口径一致性、遗留缺口五方面逐项核对；证据不足时补充采集，或将结论降级为待验证假设。
先定决策问题，再列证据清单
依据从哪里起步，取决于这次洞察要支持什么决策。把“了解一下用户”这类模糊需求转成可回答的决策问题，是列证据清单的第一步。决策问题应当指向一个具体选择，例如“下个版本是否把批量导出放到首位”“新用户流失主要发生在哪个环节，是否值得投入改造”。问题越接近真实决策，后续证据越容易收敛。
把决策问题拆成子问题，是控制证据范围的有效办法。一个决策问题通常可以拆成三类子问题：现状是什么（用户当前怎么做、遇到什么阻碍）、原因是什么（哪些因素导致这一现象）、影响有多大（涉及多少用户、影响哪个业务指标）。子问题写得越具体，越容易判断需要哪类证据来回答。
为每个子问题指定证据类型与来源，再形成清单初稿。清单至少包含四列：子问题、需要的证据类型、证据来源、优先级。优先级可按“对决策的影响程度”和“获取成本”两维判断，优先安排影响大、成本可控的证据。下表是一个清单初稿的示例结构，实际使用时按项目替换内容。
| 子问题 | 证据类型 | 证据来源 | 优先级 |
|---|---|---|---|
| 用户在导出环节卡在哪里 | 行为数据、可用性测试观察 | 埋点日志、5—8名目标用户测试 | 高 |
| 用户为什么放弃导出 | 访谈记录、工单与评论 | 深度访谈、客服工单分类 | 高 |
| 问题影响多少用户 | 行为数据、业务指标 | 埋点漏斗、版本使用统计 | 中 |
| 行业通行做法是什么 | 外部参考 | 公开报告、同类产品公开文档 | 低 |
清单初稿完成后，需要与决策方确认一次：这些问题是否就是本次要回答的，优先级是否符合决策节奏。确认后的清单即为后续采集和分析的工作底稿，避免研究过程中不断追加无关问题。
四类依据的具体内容与取数方式
四类依据各有分工，混用容易导致结论站不住。用户行为与反馈数据回答“发生了什么”，业务与产品上下文回答“这件事在业务里意味着什么”，研究过程记录回答“结论是怎么得来的”，外部与行业参考回答“边界和参照在哪里”。下表按内容、获取渠道和记录方式整理。
| 依据类别 | 具体内容 | 获取渠道 | 记录方式 |
|---|---|---|---|
| 用户行为与反馈数据 | 访谈记录、可用性测试观察、行为埋点、工单与评论 | 用户访谈、测试观察、埋点平台、客服系统、应用商店与社区评论 | 原始记录保留原话与时间戳；行为数据保留口径与统计区间 |
| 业务与产品上下文 | 业务目标、版本计划、关键指标口径、历史决策记录 | 需求文档、版本规划、指标字典、评审纪要 | 引用时注明文档版本与生效时间 |
| 研究过程记录 | 样本说明、招募筛选条件、访谈提纲、编码表 | 研究计划、招募问卷、访谈记录、编码过程 | 与原始数据一并归档，保证可复核 |
| 外部与行业参考 | 公开报告、法规与合规要求、行业通行做法 | 公开出版物、监管机构网站、行业协会资料 | 注明出处、发布时间与适用范围 |
用户行为与反馈数据的取数要点是“原样保留”。访谈记录保留受访者原话和提问语境，可用性测试记录任务完成情况与卡点位置，行为埋点记录事件定义、统计区间和口径。工单与评论需要先做分类，再统计各类占比，避免只挑几条典型反馈当结论。
业务与产品上下文决定洞察的落点。同一现象在不同业务目标下的优先级可能完全不同，因此需要明确本次分析服务的指标口径和版本范围。指标口径要写清分子分母、统计周期和过滤条件，避免分析结论与业务报表对不上。
研究过程记录是结论可复核的前提。样本说明至少写清招募渠道、筛选条件、样本量和用户类型分布；访谈提纲和编码表保留版本，便于他人理解结论的形成路径。缺少过程记录时，结论只能作为线索，不宜直接进入决策。
外部与行业参考的使用边界要提前说明。公开报告和法规要求可以作为背景和约束条件，用于校验方向或提示合规风险；它们反映的是外部一般情况，不能替代本产品的用户证据。引用时注明发布时间和适用范围，避免把过期或不同市场的结论直接套用。
证据台账：字段设计与可信度标注
依据散落在聊天记录、表格和文档里，是洞察分析最常见的失效原因。建立一份证据台账，把每条证据的来源、时间、样本和对应结论记录下来，可以让结论在评审时被逐条追溯。台账建议至少包含以下字段。
| 字段 | 填写要求 |
|---|---|
| 证据编号 | 唯一编号，便于结论引用 |
| 证据类型 | 行为数据、访谈、测试观察、工单评论、业务文档、外部参考 |
| 来源 | 具体系统、文档或受访者编号，不写“用户反馈”这类笼统描述 |
| 采集时间 | 证据产生或采集的日期，行为数据注明统计区间 |
| 样本说明 | 样本量、用户类型、筛选条件 |
| 采集人 | 负责采集和整理的人员 |
| 可信度等级 | 按来源直接性、样本代表性、时间新鲜度综合标注 |
| 对应结论 | 该证据支持或反驳的结论编号 |
| 备注 | 口径说明、冲突记录、采信理由 |
可信度分级建议用三级：高、中、低。来源直接、样本覆盖目标用户、采集时间在近期内的证据标为高；来源间接或样本偏小的标为中；仅有零散反馈或时间较久的标为低。分级的作用是让评审者知道每条结论背后证据的强度，而不是给证据贴标签后弃用低等级证据。
出现冲突证据时，保留双方记录并写明采信理由。例如访谈中用户表示愿意使用某功能，但行为数据显示实际使用率很低，此时应同时记录两类证据，分析差异原因（如意愿与行为的差距、样本差异），再决定结论表述。删除不利证据会让结论在后续验证中暴露问题。
台账需要指定维护责任人，并在每次分析结束后更新。新增证据补录编号，结论变更时同步修改对应关系，评审后的台账随分析报告一并归档。台账与结论的对应关系是洞察链条的核心，缺少这一环，结论就无法在版本复盘时被复核。
当证据台账、结论和评审记录需要在团队内长期流转时，可以把台账作为文档维护，把结论回写到需求条目并关联评审记录。ONES 的文档与需求管理可以承载这一流程：证据台账作为文档持续更新，洞察结论关联到对应需求，评审意见留在同一处，便于后续版本复盘时追溯依据。具体使用方式按团队现有流程配置即可。
角色分工与各环节交付物
洞察分析涉及采集、分析、评审三类工作，角色不清会导致证据无人认领或结论无人确认。常见分工如下表，团队规模较小时可由一人兼任多个角色，但职责边界仍需明确。
| 角色 | 主要职责 | 输入 | 输出物 |
|---|---|---|---|
| 用户研究员 | 设计研究方案、执行访谈与测试、整理原始记录和编码表 | 决策问题、证据清单 | 访谈记录、测试观察记录、编码表、样本说明 |
| 产品经理 | 提出决策问题、提供业务上下文、确认结论落点 | 业务目标、版本计划 | 决策问题说明、需求条目、结论回写记录 |
| 数据分析 | 提供行为数据、核对指标口径、校验数据结论 | 埋点定义、指标字典 | 行为数据提取结果、口径说明、数据校验记录 |
| 业务方 | 提供一线反馈、参与评审、确认业务影响 | 工单、客户反馈、业务规则 | 反馈分类记录、评审意见 |
各环节的输入输出要形成闭环。采集环节的输出是原始记录和证据台账条目；分析环节的输入是台账和业务上下文，输出是带证据引用的洞察结论；评审环节的输入是结论和台账，输出是确认意见或补充采集要求。每个环节完成时应有明确的完成标志，例如“台账中每个子问题至少有一条高或中可信度证据”。
评审与确认节点建议设在两处：证据清单确认时，确认问题范围和优先级；结论评审时，确认结论是否有足够证据支撑、是否与业务目标一致。评审记录与结论一并归档，归档位置在项目开始时约定，避免分析结束后找不到依据。交付物归档后，后续版本复盘可以直接引用同一批证据，减少重复采集。
一个完整示例：从问题到洞察结论
以下为演示情景，用于说明证据如何支撑一条洞察结论，数据为示例，不代表真实产品情况。
决策问题是“下个版本是否优先改造批量导出功能”。拆出的子问题包括：用户在导出环节的完成情况如何、卡点出现在哪一步、影响多少用户、改造的预期收益是什么。证据清单据此确定：埋点漏斗数据、6名目标用户的可用性测试、近三个月导出相关工单分类、版本使用统计。
采集结果记录在台账中：埋点数据显示导出流程从进入到完成的转化率为示例值，卡点集中在格式选择步骤；可用性测试中4名用户在格式选择处反复尝试，2名用户放弃任务；工单分类显示导出相关工单中格式问题占比最高；版本统计显示导出功能的使用用户集中在少数高频用户。每条证据标注来源、采集时间、样本和可信度，行为数据与测试观察标为高，工单分类标为中。
从证据到结论的推理分两步：先确认现象，行为数据与测试观察指向同一卡点，工单分类提供旁证；再判断影响，使用用户集中意味着改造收益主要落在高频用户身上，需要结合业务目标判断优先级。结论表述为“格式选择步骤是导出流程的主要卡点，改造可优先解决该步骤，收益集中在高频用户”，并逐条引用证据编号。结论中同时注明样本量和数据区间，说明适用范围。
结论回写到需求条目时，附上证据台账链接和评审意见，版本计划中标注该需求的依据来源。后续版本上线后，用同一埋点口径对比改造前后的转化率，形成证据闭环。这一流程中，需求条目承载结论，文档承载台账，评审记录承载确认过程，三者关联后即可追溯。
完成检查：依据是否足够支撑结论
分析结束前，用以下检查表逐项核对，判断依据是否达标。检查结果记录在分析报告中，未通过项列入后续补充计划。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 证据覆盖度 | 每个子问题是否都有对应证据 | 无子问题仅凭推测回答 |
| 样本与来源代表性 | 样本是否覆盖目标用户类型，来源是否直接 | 关键结论至少有一条高或中可信度证据，样本偏差已说明 |
| 结论与证据对应 | 每条结论是否可追溯到证据编号 | 结论中的判断均有引用，冲突证据已记录采信理由 |
| 时间与口径一致性 | 数据区间、指标口径是否统一 | 同一结论引用的数据口径一致，过期证据已标注 |
| 遗留缺口 | 未解决的问题和补充计划 | 缺口有责任人和补充时间，或明确说明不影响本次决策 |
检查中发现证据不足时，处理方式有两种：补充采集，或将结论降级为待验证假设并注明验证方式。两种方式都需要在结论中写明，避免假设被当作确定事实进入版本计划。检查通过后，证据台账、结论和评审记录一并归档，作为下一次洞察分析的起点。
常见问题
团队规模小、没有专职用户研究员，证据清单和台账还要做吗？
要做，但可以简化。角色可以由产品经理兼任，证据清单保留子问题、证据类型、来源、优先级四列即可，台账字段先保留证据编号、来源、采集时间、样本说明和对应结论五项，可信度等级按高、中、低粗标。关键在于每条结论都能指回具体证据，而不是把流程做全。团队扩大后再补充采集人和冲突记录等字段。
访谈得到的意愿和埋点数据对不上，结论该怎么写？
把两类证据都保留在台账里，分别标注来源和可信度，再分析差异原因，例如意愿与行为的差距、样本类型不同或统计区间不一致。结论可以写成有条件的表述，说明在什么范围内成立、还需要什么证据验证。直接删掉不利证据，会让结论在后续版本验证时暴露问题。
外部报告和行业资料能作为洞察结论的主要依据吗？
外部资料适合作为背景和约束条件，用来校验方向或提示合规风险，反映的是外部一般情况。它不能替代本产品的用户证据，因为样本、市场和使用场景都可能不同。引用时注明出处、发布时间和适用范围，结论的主要支撑仍应来自本产品的行为数据、访谈和测试记录。
证据清单确认之后，研究过程中又发现新问题，要不要加进去？
先判断新问题是否影响本次决策。影响决策的，补充进清单并标注新增原因和优先级，同时告知决策方；不影响本次决策的，记入遗留问题清单，留到下一次分析。这样可以避免研究范围不断扩张，也能让后续分析有接续的起点。
洞察结论回写到哪里，后续版本复盘才找得到依据？
结论回写到对应的需求条目，附上证据台账的位置和评审意见，版本计划中标注该需求的依据来源。台账作为文档持续更新，评审记录与结论一并归档。上线后用同一埋点口径对比改造前后的数据，形成证据闭环。ONES 的文档与需求管理可以承载这一流程，具体配置按团队现有流程安排。
