product-business-analysis

相关技能

当建议取决于解释某项指标的变动、异常、差距或差异时，使用 $metric-diagnostics。

产品与业务分析

使用此技能，基于数据证据、背景信息和建议来回答产品或业务问题。为受众提供足够可信的证据、解读和不确定性说明，以便他们选择切实可行的下一步行动。

技能配置

来源发现与验证

将相关语义层用作起始地图，而非边界。

1. 探索所有可能的来源。 搜索所有可能包含任务相关数据或会影响解读的已连接或已提供来源。在每个结构化数据来源中，重新发现相关架构、数据集、表、视图、模型和指标的目录或元数据。已知来源、表、仪表板和语义映射只是起点，而非终点。
2. 比较重复项和冲突。 如果来源存在重叠或意见不一，请比较其所有权、时效性、定义、粒度、覆盖范围和直接性。使用最权威的来源，或在需要时结合互补来源。注明重大冲突，解释为何选定的来源具有决定性，并在下结论前通过实时读取验证所选数据。

来源访问护栏

在查询来源、构建产物或得出结论之前，先确定答案是否需要特定的事实来源。

如果无法访问必需来源，请停止该路径。告知用户需要什么来源，请其提供访问权限或经审核的替代来源，且不要将较弱的替代来源视为等同来源。

如果缺失来源只是可选的补充信息，请基于最有力的现有证据继续；当信息缺口会实质影响答案时，标明这一点。

当缺失的输入会实质改变分析框架或建议时，请向用户澄清。否则，作出合理假设，说明该假设并继续。

工作流

1. 从决策出发

在选择数据来源或指标之前，先确定分析要辅助的决策、受众和行动。

明确说明：

• 分析要辅助回答的问题和决策
• 答案的使用者及其可采取的行动
• 界定有效答案的范围和比较对象
• 对决策至关重要的结果或行为
• 继续分析所需的任何假设

不要因为范围不明确，就默认开展宽泛的探索工作。

2. 收集与决策相关的背景信息

深入分析之前，先运行 $gather-business-context。该技能负责来源选择、检索、来源权威性、冲突处理以及简明的背景信息摘要。使用此工作流来判断收集到的背景信息如何影响分析和建议。

背景信息收集的范围应与任务相称。对于自成一体的提示词，或用户已提供足够背景信息的情况，可以简要完成此步骤：确认决策框架、定义、来源假设以及明显的信息缺口，然后继续。不要把必需的背景信息收集变成宽泛的背景调查。

相关背景信息应澄清：

• 意图：这项工作原本要实现什么，以及原因
• 定义：这项工作、指标或来源如何定义和衡量
• 时间：分析期间前后发生了哪些可能影响解读的变化
• 约束：哪些决策、注意事项或限制会影响实际可行的行动

3. 构建分析框架

将问题转化为聚焦的分析框架。

定义一个基于数据回答问题的框架：

• 有助于支持或改变建议的具体数据问题
• 要检查的比较项和维度
• 与决策相匹配的分析单位
• 解读结果所需的指标定义和注意事项

用该框架提出合理的假设或解释，再将其转化为聚焦的数据问题。框架要足够具体，避免宽泛探索，并为提出建议提供支持。

当需要在分析开始前定义成功指标、驱动指标、护栏指标或衡量计划时，使用 $design-kpis。

首先用通俗的语言定义答案需要说明什么。然后选择与该含义尽可能匹配的数据，包括统计对象，以及让数值具有意义的比较方式。如果某个字段或事件只捕捉到决策所关注内容的一部分，请说明它捕捉了什么，以及遗漏了什么。

4. 开展有针对性的定量分析

开展足够的定量分析，以支持或否定已构建的假设并为决策提供依据：

• 遵循框架。 优先开展可能改变建议的分析。记录过程中出现的其他数据问题，回答那些会影响决策的问题，并将影响较小的细分分析留作后续工作，避免扩展为宽泛探索。

• 选择合适的比较方式。 在将结果转化为建议之前，先结合相关基准、分母或比较点解读结果。例如，不要仅仅因为某个群体的总使用量最高，就断定它是最佳机会。要检查使用量是否只是因为该群体规模更大、按活跃用户群归一化后这一模式是否仍然成立、该群体是在增长还是在下降、使用情况是否反映了重要的行为或结果，以及业务背景是否会改变解读。

• 衡量机会规模。 估算每个重要机会可能带来的影响幅度。说明比较的内容、代表影响的指标、使用的分母或群体，以及数据是否足够完整、值得信任。如果重要的未知或未分类群体可能改变解读，请将其保留下来。

• 确保定量分析可供检查。 使用 $jupyter-notebooks 记录查询和分析。如果源数据的新鲜度、粒度、连接、缺失值、架构漂移或异常分布可能影响可信度，请使用 $analyze-data-quality。

• 得出结论前进行验证。 在分享面向利益相关者的建议、重大结论或意外结果前，使用 $validate-data。如果仪表板和直接查询都可用，请核对两者，或说明差异原因。

5. 将证据转化为决策影响

结合更广泛的业务背景来阐释发现。不要把量化证据和业务背景当作彼此无关的两条线索来呈现。

通过最适合当前问题的决策视角来解读证据。选择确实会改变建议的视角，跳过那些只会增加干扰或造成虚假精确感的视角。常见视角包括：

• 当前规模： 这项机会或问题在当前是否足够重要，足以影响决策？
• 发展势头： 这一信号是在增强、减弱、加速，还是刚刚显现？
• 覆盖范围： 这一模式是否广泛存在，还是只出现在业务的某个狭窄领域？
• 集中度： 结论是否依赖少数大型实体、事件或异常值？
• 强度： 单位层面的行为是否足够深入，表明存在真实需求、价值或风险？
• 效率： 与所需投入相比，该选项能否带来更好的产出、利润率、转化率、生产力或质量？
• 可实现性： 团队能否凭借现有的产品、GTM、运营、政策或技术手段切实推进这一选项？
• 差异化： 这一群体或用例是否需要不同的推进方式、产品体验、支持模式或信息传达？
• 替代关系： 是否有证据表明，行为、支出、时间或工作量可能从其他路径转移过来？
• 风险或依赖： 质量、信任、合规、技术、运营或数据方面的限制是否会改变建议？
• 覆盖情况： 未知、缺失或标签稀疏的记录是否足以改变结论？

将这些视角用作思考工具，而非核对清单。说明所选视角为何与当前决策相关；只有在被省略的细分维度可能改变解读或有助于解释结果时，才提及这些维度。

利用已衡量的机会，说明哪些差异会影响决策，哪些差异需要采取不同措施。如果业务背景表明，初步估算遗漏了机会中可采取行动的部分，则补充所需的重点细分估算，使建议切实可用。

如果证据相互冲突，请直接说明，并解释哪种解读得到的支持更充分。不要淡化不同来源之间的分歧。

6. 移交建议

最后将可供决策的建议交给 $build-report，除非用户明确要求直接在聊天中回答、不生成报告的简短回复，要求不要创建报告／文件／其他产物，或选择了其他主要产物。在没有明确人工豁免的情况下，必须执行此移交；不要因为用户提出了直接问题，或没有使用“报告”一词，就自行推断可以豁免此要求。此工作流负责分析结论；$build-report 负责面向读者的结构、可视化、证据呈现位置和交付形式。

移交前，明确说明建议：

• 他们下一步应相信什么或采取什么行动
• 为什么证据支持该建议
• 哪些注意事项或依赖因素至关重要
• 哪项后续分析最能提高信心

如果证据不完整，请将建议标注为暂定，并说明哪些信息会影响信心。不要为了让答案显得果断而夸大结论。

如果方法、计算、注意事项或结论的证据依据需要在分享前审查，请使用 $validate-data。

传递给报告呈现层的应是叙述所需的内容，而不仅是结果表格：

• 直接回答和建议
• 关键证据及其解读方式
• 对决策的影响
• 尚未解决的不确定性和注意事项
• 建议的后续工作