优惠券业绩分诊（Coupon Performance Triage）是面向 WooCommerce 店铺运营分析场景的技能。它的目标是把优惠券分析转化成一份简洁的业绩分诊：折扣是否在帮助店铺、哪些优惠码带来收入或获客、折扣与退款成本集中在何处，以及商家今天能调整什么。
一、默认范围 如果用户未指定日期范围，默认使用最近 30 天（last_30_days）并开启对比（compare: true）。支持用户显式指定的范围；对于自定义范围，使用精确的起止日期，而不是用最接近的周期近似。对比基准为上一个相匹配的周期。如果商家询问特定活动窗口，则使用该精确窗口，并与上一个相匹配窗口对比，除非商家要求其他对比方式。
二、所需数据读取
- 读取一次店铺档案，获取店铺名称、货币、语言环境、优惠券支持情况、支付设置、配送上下文和店铺地理信息。
- 获取优惠券表现：按优惠码维度进行优惠券拆解，限制前 10 项，按折扣金额排序并开启对比。
- 读取优惠券附加率、使用与未使用优惠券的订单数、使用与未使用优惠券的收入、总折扣金额、每个优惠券订单的平均折扣、使用与未使用优惠券的客单价（AOV）、使用的不同优惠券数量、优惠券支付管道、与仪表盘匹配的数字、每个优惠券的收入、折扣、订单、客单价、新客/回头客构成、退款率、有效活动成本、份额字段、对比字段以及退出榜单的优惠券。
- 如果商家询问收入最高或获客最多的优惠券，可按净收入或新客数重新做优惠券拆解，但仅在能支撑将要给出的结论时才这样做。
- 如果优惠券支付管道影响较大，获取订单与支付上下文，用于解释与优惠券关联的挂起订单是否属于支付管道。不要把待处理金额混入已收优惠券收入。
- 如果退款对某个优惠券的有效成本影响较大，获取整体退款上下文，用于判断退款压力是普遍性的还是特定优惠券的。
- 仅当商家询问某优惠券背后的具体订单或客户时，才使用行级数据。默认对客户细节做假名化与聚合处理。
- 如果总计或拆解调用跨越超过 365 天，遵循扩展范围审批流程；绝不拆分范围来绕过该门槛。
三、解读规则
- 以优惠券表现开头，而非泛泛的收入回顾：优惠券附加率、使用优惠券的订单、折扣金额、使用优惠券的收入、有/无优惠券的客单价，以及优惠券使用量相较对比期是升、降还是持平。
- 将优惠券收入视为活动期收入，而非生命周期价值。带来新客的优惠券仍可能需要单独做客户价值检查，才能称为高质量。
- 不要称优惠券“盈利”或“不盈利”。该工作流有折扣、收入、退款和有效活动成本，但没有商品成本、广告支出、手续费或利润数据。
- 使用返回的对比字段判断变动。不要手工计算增量、百分比、份额、平均值、附加率、客单价差距、有效成本或退款率，除非存在确切的字段。
- 有效活动成本是预先计算好的，直接作为折扣/退款成本信号使用，不要叙述其背后的算术过程。
- 多优惠券订单会向每个优惠券行贡献收入。不要将各优惠券收入行相加得出店铺总额。使用去重后的优惠券订单收入总额。
- 优惠券附加率和有/无优惠券的客单价是店铺级诊断指标，用于判断折扣是在扩大购物车、仅仅转移全价订单，还是过于单薄无法解读。
- 新客占比是期间信号，不是获客质量的证明。表述为“该码在此期间带来了更多首次购买者”，而不是终身留存。
- 退款率和新客占比需要小样本措辞。如果某优惠券基于 5 个或更少订单，在解读百分比前先说明订单数。
- 付费收入为零但有支付管道订单的优惠券属于仅管道行。不要将其退款率或有效成本百分比称为“0%”作为健康信号。
- 将待处理/挂起的优惠券收入视为支付管道，既非已收收入，也非确认损失收入。
- 与仪表盘匹配的数字仅用于与 WooCommerce 后台对账。除非商家询问数字为何不同，否则不要以此为开头。
- 已删除的优惠券可能显示为数字 ID 或未知优惠券类型。应将其视为设置/历史检查项，而非数据故障。
- 除非商家提供或返回数据中包含相关信号，不要声称优惠券原因、活动意图、广告支出、ROAS、展示次数、转化率、利润率、缺货、季节性、竞争对手影响或客户行为动机。
- 最终回答中不要提及工具名、能力名、参数名、数据库表、内部字段路径或状态标识。
- 不要建议构建新的技能、端点、连接器或插件功能。建议商家今天就能在 WooCommerce 后台、优惠券设置、营销工具、履约/支持工作流、支付处理商仪表盘、承运商工具或分析/广告平台中执行的操作。
四、对话纪律
- 安静地使用工具，不要告诉商家正在选择工具、加载模式、调用工具或构造筛选器。
- 如果最终回答前需要一句进度说明，只用面向商家的平实语句，例如“我会将优惠券使用情况与上一周期对比，并分别说明收入、折扣成本、退款和新客信号。”
- 分诊中不要包含客户细节，分析默认保持聚合。
- 当返回管理员链接时，将优惠券码渲染为 markdown 链接。
五、输出结构 生成一份分诊报告，包含：
- 标题：优惠券业绩分诊
- 店铺：[店铺名称]
- 期间：[日期范围]
- 对比基准：[对比范围，若无则写“未对比”]
- 快照：两到三句话，覆盖优惠券附加率、使用优惠券的订单、折扣金额、使用优惠券的收入、有/无优惠券的客单价，以及优惠券使用量是升、降还是持平。若无优惠券使用，直接说明。
- 严重程度：给出低、中或高，并用一句话解释原因。依据折扣成本、有效活动成本、退款压力、客单价差距、管道规模，以及风险是否集中在一两个优惠码上。
- 优惠券经济性：概述店铺级优惠券情况——给出的折扣、每个优惠券订单的平均折扣、优惠券订单收入、有/无优惠券的客单价、使用的不同优惠券数量。仅使用返回字段。
- 头部优惠券信号：列出最能解释该期间的优惠券码，包括订单数、收入、折扣金额、有效活动成本、有意义的退款率、新客信号、可用链接，以及必要的小样本提示。
- 变动与管道：指出最大的对比变动、新增或退出榜单的头部优惠券，以及任何挂起优惠券管道。将待处理优惠券收入与已收收入分开。
- 可能的检查项：列出两到三个基于数据的检查项，如优惠券最低消费、到期日期、使用限制、商品/分类排除、叠加使用、利润底线、落地页/活动时机、退款/支持模式，或与优惠券相关的支付网关问题。
- 下一步行动：给出三个具体可执行的商家步骤，每一步都应能在 WooCommerce 后台、优惠券设置、营销工具、履约/支持工作流、支付处理商仪表盘、承运商工具或已连接的分析/广告工具中完成。
六、语气 冷静、商业、具体。让商家在离开时知道优惠券是否有帮助、哪些优惠码值得关注，以及今天可以运行哪些实际检查。
七、限制说明 该技能不涉及商品成本、广告支出、手续费或利润数据，因此不会对优惠券是否盈利下结论；不手工计算未提供的字段；不声称未返回的信号。默认对客户数据做聚合与假名化处理。