design-kpis

设计 KPI

设计 KPI 框架、设定目标并制定衡量计划，帮助团队制定产品或业务决策。

何时先处理数据质量

如果任务是核对现有指标、仪表板、表格、负责人或事实来源，请先使用 $analyze-data-quality。

只有当用户要求定义后续指标、重新设计 KPI 框架、选择护栏指标或设定目标时，才回到此技能。

技能配置

来源发现与验证

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

1. 探索所有可能的来源。 搜索所有可能包含任务相关数据或会影响解读的已连接或已提供来源。对于每个结构化数据来源，针对相关架构、数据集、表、视图、模型和指标，重新执行目录或元数据发现。已知来源、表、仪表板和语义映射仅是起点，而非终点。
2. 比较重复项与冲突。 当来源重叠或存在分歧时，比较其所有权、新鲜度、定义、粒度、覆盖范围和直接性。选用最权威的来源，或按需结合互补来源。指出重要冲突，解释为何所选来源具有决定性，并在得出结论前通过实时读取验证所选数据。

来源访问护栏

在查询来源、创建产物或得出结论前，判断答案是否需要特定事实来源。

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

如果缺失来源仅用于可选补充，则依据现有最有力证据继续；当这一缺口会对答案产生实质影响时，应明确标注。

当缺失信息会实质改变分析框架或建议时，请向用户澄清。否则，做出合理假设，说明假设后继续。

工作流

1. 明确决策与运营背景

了解指标需要支持的决策、指标接受评审的背景，以及谁会根据结果采取行动。当目标、运营节奏或衡量限制缺失或含糊不清，且会改变建议时，请用户予以澄清。

2. 提出指标建议前先收集证据

当提示词未提供足够背景以判断成功意味着什么时，请先收集背景，再提出指标或目标。使用 $gather-business-context 了解目标、当前状态、受众、限制、风险、现有定义、过往决策，以及可能影响指标体系的任何基线或目标背景。

设计 KPI 时，利用这些背景明确成功的含义、相关指标以往的定义方式，以及哪些限制或风险应影响推荐的 KPI、驱动指标、护栏指标或衡量计划。

3. 生成更广泛的候选集

在缩小范围前，先列出候选结果指标、驱动指标和护栏指标。 每个候选指标都应有明确的定义，并且与决策存在合理关联。需要时可将下方的示例指标形式作为灵感，而非必须遵循的模板。

4. 比较并选择指标

比较候选指标，判断它们是否：

• 体现目标：指标应代表预期成果。使用代理指标时，应说明它为何能反映实际进展，以及在哪些情况下可能产生误导。
• 能为实际决策提供依据：指标的变化应影响团队的行动、优先级或调查方向。
• 能在决策周期内提供有用信号：指标在概念上可能不错，但对于其支持的决策而言，变化可能过慢或噪声过大。例如，年度留存率可能是正确的成果指标，但除非结合更早期的指标，否则可能无法帮助团队进行每周发布评审。
• 能由团队影响：团队应有可行的影响手段，或者应将指标与团队能够影响的驱动因素配对。
• 能在实际工作中衡量：团队应能以一致的方式埋点、计算和跟踪指标，而不需要临时手动操作。
• 不易通过误导性方式提升：提升指标不应明显掩盖对质量、信任、留存率、成本或其他重要成果的损害。

只有在有助于说明取舍时，才使用轻量级评分。建议选择 1-3 个核心 KPI；在有助于诊断时，为每个 KPI 配置 1-2 个驱动指标；在可能存在取舍时，配置 1-2 个护栏指标。除非额外指标能显著改善决策，否则不要推荐。

对于每项推荐指标，应提供足够的信息供团队使用：它衡量什么、为何重要、如何计算、数据来源、依据上述选择标准衡量的主要优缺点，以及需要注意的条件或护栏。

5. 必要时设定目标

将目标设定视为独立于指标选择的判断。先决定要衡量什么；只有在用户提出要求，或建议需要阈值才有用时，再设定目标。

根据证据选择最合适的目标设定方法：

• 自上而下：从基准、历史表现、可比产品、竞争对手或市场背景出发，或者基于合理判断，确定该决策所需达到的良好水平。
• 自下而上：从团队能够实际做到的事情出发，例如即将发布的内容、预期的采用情况，或应推动指标变化的运营手段。

使用数据来设定或评估目标。明确目标设定方法后，指出需要哪些数据，例如已提供的输入、内部表现数据、外部基准或市场数据，以及类似过往工作的结果。

比较有挑战性的目标与团队通过计划中的工作、可触达的受众、预期采用情况和历史变化能够实际影响的范围。好的目标应对决策有意义，并且足够可行，能够指导行动。说明目标的依据、关键假设和置信度。如果最可靠的目标设定方法需要尚未提供的输入，应说明方法，并询问用户能否提供或确认相关数据。如果现有证据仍足以支持方向性目标，则以临时范围的形式给出；否则，建议先进行必要的衡量，再设定明确目标。

6. 给出建议

最终建议应简洁、以决策为导向，默认直接给出。不要仅仅因为 KPI 框架使用了证据、对比了候选指标或包含多项指标，就加载 $build-report。如果数据可视化能显著提升答案质量，例如展示拟议目标与历史表现或基准的对比，或厘清取舍或候选指标评分，则使用 $visualize-data 和 $build-report。如果用户明确要求报告、仪表板、笔记本、电子表格、原生文档或幻灯片，应将其作为主要交付成果。建议应包括：

1. 计划摘要
2. 推荐的候选指标及其定义和理由
3. 目标建议（如有），以及其锚点、假设和方法
4. 已审阅的证据
5. 假设和缺失的背景信息
6. 风险和防护措施
7. 尚待解答的问题

指标形式示例

不同情境需要不同形式的指标。以下仅供参考，不是模板：

• 产品发布或采用：将衡量采用或价值实现的结果指标，与衡量激活、参与度、重复使用或价值实现时间的驱动指标配对，并添加体验质量方面的防护指标。
• 增长工作：选择团队希望改善的业务结果，例如激活、留存或变现；添加能说明预期增长路径的驱动指标，并设置质量防护指标。
• 漏斗工作：选择代表成功的流程推进或完成结果；添加用于衡量用户在哪些环节继续推进或流失的驱动指标，并设置下游质量防护指标。
• 运营评审：重点关注健康状况、进度和行动导向的指标，说明业务是否按计划推进，以及哪些方面需要关注。
• 实验或干预：使用一个与决策相关的主要成功指标，辅以解释变化的诊断指标和防范意外影响的防护指标。
• 数据、模型或分析计划：将技术表现与其改善的决策或工作流联系起来，并在相关时设置采用率、可靠性、成本或公平性方面的防护指标。
• 平台、可靠性或运营工作：衡量服务健康状况、吞吐量、质量、成本效率和客户影响，并采用负责团队可据此采取行动的指标。