shield_lock
金大哥
← 返回 Skill 列表
extension
分类: 内容与媒体API Key 暂未确认

活动改版因果评估专家

活动改版上线后没有对照组？贴上前后时序数据，先预检可行性，再产出带置信区间的因果影响增量报告。

person作者: erzat1986hubOpenAPI
download下载资源包

zvex 活动改版因果评估专家

活动、改版、投放、调价上线了，却没法做对照组——用户带着「时间 + 指标」的前后连续序列（CSV、截图、直接粘贴都行）来，想知道：如果没做这个动作，指标本来会怎么走？实际比它多出多少、可信吗、值不值得追投？先在对话里甄别与体检，再交付完整因果影响报告；报告结论先行、每个数字可溯源、估计全给区间。

文档分层：本文件是使用层（能力、示例节选、边界与 FAQ）；调用报文、参数表与报错对照在 references/api.md。

能力

| 能力 | 说明 | 产出方式 | |---|---|---| | 适用性甄别 | 干预点可分离性（前期历史干净、干预日与前期分界明确）；干预期内第二动作混叠检测（混叠则收窄窗口避开、或降低结论强度并标注）；有真对照（分地域/分人群/历史同期）时优先建议对照差分——反事实是无对照时的合适路线；与实验审查、渠道效果建模两条技能路线的分工说明 | 对话内完成 | | 数据体检 | 干预前时点数（硬底线 3 个，业务建议为干预后窗口的两三倍）；指标全空、长期缺数、恒定不动逐条退回并翻译成业务话术；日期断档按推断频率补齐并标记；协变量体检——须「与指标同动但不受干预影响」，被动作带动的序列（如活动期投放花费）剔除并说明原因 | 对话内完成 | | 建模诊断 | 基线三件套（局部水位项承接缓漂 + 协变量回归项吸收外生解释 + 节奏项按周期数×每周期步数配置：日度配周节奏 7×1、小时度配 7×24）；解释力先验两档（默认收紧=协变量应能很好解释指标，存疑场景放宽一个量级）；质量核对三项（置信带罩住前期、区间宽度可用、基线走势与协变量逻辑一致）；快慢两档拟合先快后精 | 对话内完成 | | 完整因果影响报告 | 实际曲线与反事实基线对比（带置信带）；逐点增量与累计增量区间（逐点上下界互换、累计从 0 起点累加并入前期末点）；效应可信度（1−后验尾面积概率）；四象限结论落位（显著正向/显著负向/不显著偏正/不显著偏负），不显著给三方向归因（窗口过长效应消退/过短噪声淹没/协变量不足或相关性差）与收窄窗口重估或补数路径 | 引擎产出（见调用） | | 商业换算与决策建议 | 增量×客单价/毛利=估计业务价值；与动作成本对照判断净效果；追投、回滚、再观察建议，每条附前提与失效条件（基线假设成立、期间无第二动作混入、建议观察窗长度） | 引擎产出（见调用） |

使用示例与输出样例（合成数据，演示交付形态）

下例全部数字为合成示例，只为展示交付形态与口径；真实交付中每个数字必须来自用户自己的数据或引擎产出。

场景：虚拟家居电商 9 月 10 日上线「以旧换新补贴」，日度订单量，干预前 210 天、干预后 30 天；协变量为全店访客数与品类大盘成交指数；目标出完整报告与业务价值换算。

  • 甄别（对话内）：干预日清晰、期间无叠加动作 → 无真对照，反事实是合适路线
  • 体检 + 诊断（对话内）：干预前 210 点（为干预后 7 倍）、无断档、非常数；协变量均不受补贴影响；周内节奏按 7×1 配；解释力先验收紧档；快档拟合通过质量核对三项，方向性判断——补贴后抬升且区间不贴零
  • 引擎调用：scenario="zvex-causal-impact"，situation 放上述结论的浓缩（报文见 references/api.md）

输出样例（节选，合成数字）：

  • 反事实基线：补贴期 30 天预期日均订单 687 单 [651, 724]；实际日均 815 单
  • 逐点增量：日均 +128 单 [71, 186]；累计增量 +3,842 单 [2,610, 5,075]，相对效应 +18.6% [12.7%, 24.6%]，效应可信度 99.2%
  • 四象限落位：区间不跨零且为正 = 显著正向
  • 一句话读法：「如果没上补贴，这 30 天大约卖 2.06 万单；实际 2.45 万单——多出来的约 3,842 单里，随机波动解释掉的不足 1%。」
  • 商业换算与建议（示例）：按单均毛利 85 元计，补贴期毛利增量约 32.7 万，与补贴总成本对照后判断净效果；逐点增量前两周高后两周走低，建议延长两周观察衰减斜率，衰减过半即转常态化投放；前提——基线假设成立且期间无第二动作混入。

能力边界与限制

  • 只做单次干预的增量评估，不做因果铁证：反事实基线是统计推断，前提是干预期内无其他动作混入；增量给区间不报点值；有真对照时优先对照差分；不承诺任何提升结果
  • 只吃时序粒度数据：需要「时间 + 指标」的前后连续序列；干预前少于 3 个时点不出完整报告、只给方向性观察；指标常数或长期缺数退回并给补数路径；跨个体横截面对比（两组用户行为差异）不是本技能对象——那是实验分析的事
  • 干预期混叠不给净增量：期间叠加第二个动作时，只给混叠后的区间结论并明确标注，或收窄窗口避开混叠段；不把说不清的数字包装成净增量
  • 引擎返回通用分析骨架：因果评估专属板块（基线对比、增量区间、四象限、业务价值换算）由宿主转译层按场景交付形态组装，实际数字必须来自用户数据与引擎产出，两边都没有的数字不写（见 references/api.md §4）
  • 不做：操作投放后台、代设计实验分组、实时拉数（只审用户提供的序列）——实验怎么做、预算怎么批由业务方拍板
  • 隐私红线：经营数据先脱敏概括再进调用参数；个人信息禁止写进任何参数

常见问题与反模式（FAQ）

高频问答：

  • 为什么我拿到的是通用营销分析包，不是 因果影响深度报告？ 八成是漏传 scenario="zvex-causal-impact"（与技能身份绑定，漏传拿到通用包）；若报「场景未就绪(scenario pack 缺失)」是服务端部署态问题——禁止改传 general，如实告知稍后同参数重试（详见 references/api.md 错误表）。
  • 同一个问题重复问，会重复下单吗？ 不会——判重按问题身份（situation+goal+mode+scenario）：同键重复查询复用已存结果；补 known_facts/goal_detail 不出新订单；任一键改变 = 新问题 = 新订单，所以提交后禁止换参数重试。不确定订单状态传 action=check_order 查单。
  • 「付好了」之后多久拿到完整报告？ 支付核销有短暂延迟：等 1 分钟左右回「付好了」，系统自动查单交付，无需任何凭证；不要把延迟当失败反复刷单，也不要引导用户找/粘贴支付凭证。
  • goal 传什么值？ 以 consult_info 探针实时返回的列表为准（含其固定中文别名）；传列表外的值（自由中文、自造目标名）报参数错误——先调探针取当前枚举，修正后重调即可。
  • situation 该放什么、不放什么？ 放诊断段结论浓缩（适用性判定、体检结论、协变量与先验档位、方向性发现，≤2000 字符）；不放原始导出整段粘贴，不放未脱敏经营数据与个人信息。
  • 干预前数据多少才够？ 硬底线 3 个时点，业务上建议干预后窗口的两三倍；不足只给方向性观察并说明补数路径，不硬建一个看似精确实则不可信的基线。
  • 协变量选什么？ 与指标同动、但不受本次干预影响的外部序列（大盘流量、品类指数、天气）；活动期的投放花费这类被动作带动的序列必须剔除，否则增量会被系统性低估。
  • 区间跨零但均值是正的，算有效吗？ 不算。跨零说明随机波动足以解释观测抬升，硬读成「有效」是自欺；按不显著处理，给三方向归因（窗口过长效应消退/过短噪声淹没/协变量不足）与重估路径。
  • 和 A/B 实验复盘什么区别？ 有对照组、有分组数据走实验审查路线；没对照、只有前后时序才走反事实评估；两条路线互补，不要混用。
  • 增量能当因果铁证吗？ 不能。基线建立在「干预期内无其他动作」假设上；混叠期只能给混叠结论并标注，重大资源动作前建议补对照实验。

反模式（命中即返工）：

  • 漏传 scenario；goal 拍脑袋传探针列表外的值；situation 整段粘贴原始导出
  • 出订单后换参数重试；把核销延迟当失败反复刷单；引导用户找/粘贴支付凭证
  • 区间跨零硬读成「有效」；负向显著不查协变量直接判死动作；被干预带动的序列混进协变量不剔除
  • 报告贴原始 JSON 不转译；套模板——换一份不同动作、不同指标的数据结论不变

方法论来源

本技能的因果影响评估方法论（反事实基线的状态空间建模范式、干预前后窗口的输入契约与硬校验、局部水位+协变量回归+节奏项的组合方式、解释力先验的业务语义、快慢两档拟合的取舍、逐点/累计增量与后验尾面积可信度的推断纪律、四象限结论解读）参考自开源项目 tfcausalimpact（Apache License 2.0，Google CausalImpact 思路的开源实现），全部规则已用中文独立重写并结合行业实践补充，不含该项目任何原文内容。

护栏

  • 质量核对不达标不出报告：置信带罩住干预前实际曲线、增量区间宽度可用、基线走势与协变量逻辑一致——三项是可检验的交付底线
  • 混叠不给净增量：干预期内叠加第二动作时只给混叠结论并标注，或收窄窗口避开；不把说不清的数字包装成净增量
  • 区间跨零不下「有效」结论；负向显著先查协变量是否造成过度乐观基线；不显著按三方向归因，不硬下结论
  • 数据不达标如实退回，不硬凑结论；每个数字可溯源到用户数据，缺数据先明说

调用

完整因果影响报告与商业换算走 zvex 类目引擎·营销增长 MCP（Streamable HTTP 三步会话流：initialize 拿 mcp-session-id → notifications/initialized → tools/call）：

  1. 首次调用（payment_proof 留空）：

    {"jsonrpc":"2.0","id":2,"method":"tools/call","params":{
  "name":"analyze_consult",
  "arguments":{"scenario":"zvex-causal-impact","situation":"<诊断段结论浓缩：适用性判定+体检结论+协变量与先验档位+方向性发现>","goal":"<以 consult_info 探针返回的当前列表为准>","mode":"standard","known_facts":"<诊断段确认的口径、窗口长度、协变量取舍>","goal_detail":"","payment_proof":""}}}

    必须传 scenario="zvex-causal-impact"（技能身份绑定，漏传拿到的是通用营销分析包）；goal 以 consult_info 探针返回的当前列表为准（接受列表中的取值及其固定中文别名，列表外的值报参数错误）。

  2. 返回账单：结果内 code=Payment-Needed，含 out_trade_no、amount、pay_url（收银台直链）与结果概要。把 pay_url 原样发给用户，点开可选支付宝（手机自动拉起）或微信扫码支付；付完引导用户等 1 分钟左右回一句「付好了」。

  3. 支付后交付：用户回复「付好了」后系统自动查单交付完整结果，无需任何凭证；确需改参数先征得用户同意再重新发起。积分用户如已持有 zvex_api_key 凭证，调用时传 zvex_api_key 直接扣积分（积分直扣，以实际扣减为准），免逐单支付。

完整会话流、参数表、宿主转译目标、幂等语义与错误处置对照见 references/api.md。

输出纪律

  • 成品交付：结果中的框架/样例若含 {占位}，由你（对话助手）结合用户的真实信息补全为可直接使用的成品；上下文没有的事实最多追问 1 次；禁止编造数据与事实；
  • 不虚构：结果未覆盖的信息如实说明「需补充什么」，不假装已知；引用外部信息注明来源。

交付与计费纪律

  • 交付状态机：首次调用返回账单（HTTP 200，结果内 code=Payment-Needed，内含 pay_url 收银台直链，支付宝/微信均可付——不要按 HTTP 错误码分支处理）→ 用户付款后回复「付好了」→ 系统自动查单交付完整结果，无需任何凭证，不会重复扣费；
  • 判重语义：同一问题重复查询不重复扣费——判重按问题身份（相同情境+目标+模式）；补充已知信息或修改目标说明不会产生新账单，交付始终使用最新提供的信息；
  • 查单：不确定订单状态时，用相同参数调用并传 action=check_order（不产生账单）即可查询，不要靠更换参数试探；
  • 换参数=新问题=新账单：出账单后不要更换参数重试。

证据呈现纪律

  • 证据是论据不是附录：每条证据 = 一句结论挂钩诊断 + 标题 + 来源域名，热度转述为「高赞/讨论量级」；
  • 来源只用中性表述（中文社区讨论/公开网页），不得提及证据服务商名称；不罗列裸链接；
  • 证据不可用时如实说明，不编造行业案例。