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

营销增量定向专家

预算只够触达一部分用户？交上随机分组实验数据，先判适不适用，再产出增量定向名单与最优投放规模。

person作者: erzat1986hubOpenAPI
download下载资源包

zvex 营销增量定向专家

预算只够触达一部分用户、全员群发转化越来越差、不知道该把券发给谁——用户带着随机分组实验数据（处理/对照两组 + 用户特征 + 是否转化）来，想知道：谁是因为被触达才买的？哪些人不发反而更好？预算花在哪一段最划算？先在对话里甄别与体检，再交完成后整增量定向报告；报告结论先行、每个数字可溯源、打扰禁区显式圈出。

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

能力

| 能力 | 说明 | 产出方式 | |---|---|---| | 适用性甄别 | 目标行为「不触达也自然大量发生」才值得做增量定向（推热门品/续费/召回）；不推不会发生的冷门品 → 如实建议改道响应率路线；与相似人群路线的分工说明；没有随机分组数据时给小规模随机试投方案（两组规模、观察窗口、试投比例） | 对话内完成 | | 实验数据体检 | 分组真随机性（非按活跃度/等级分）；处理标记二值、两组非空；特征/触达/结果三列等长核对；分组比例（近对半 vs 悬殊决定路线）；转化定义与窗口清晰化 | 对话内完成 | | 建模路线匹配与横评 | 标签翻转法（结果二分类 + 分组近对半）；倾向得分修正的转换结果法（分组悬殊）；双模型稳妥基线（弱信号时差分易被噪声淹没的局限说明）；评估曲线对随机基线与理想曲线归一成 0~1 分数（Qini/AUUC 双口径，体量不均衡时 Qini 更稳健）；训练/验证分档增量偏差（过拟合）与排序后处理组占比（随机性）两项稳定性核查 | 对话内完成 | | 完整增量定向报告 | 十分位增量报告表（按预测增量降序，逐档两组样本量、转化率、增量）；负增量档显式圈为打扰禁区（易反感人群，发了反而流失/投诉/退订）；Top-K 定向名单（整体混排与分组内各取两种口径）与名单规模、预期增量转化 | 引擎产出（见调用） | | 利润最优化与投放决策 | 累计利润=触达人数×增量×单客收益−激励成本×转化数−触达成本×人数−固定成本，曲线取峰值；产出最优触达规模/预期增量转化/净增量利润三要素；全员群发对照；上线保留随机对照组的迭代回流建议与失效条件 | 引擎产出（见调用） |

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

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

场景：虚拟在线教育平台对 8 万名到期会员做「续费优惠券」投放决策，随机试投处理组 4.0 万 / 对照组 4.0 万，窗口 30 天，按「是否续费」记录；目标出定向名单与最优投放规模。

  • 甄别（对话内）：续费是不打折也会自然发生的行为 → 符合增量定向适用前提；真随机分组、两组各 4 万 → 可开工
  • 体检 + 诊断（对话内）：处理标记二值、三列等长；对照组各预测分档续费率稳定在 6.8%~7.0%，随机性健康；三条路线横评——标签翻转 0.34、倾向修正 0.31、双模型 0.26（归一化 Qini），主选标签翻转；训练/验证分档增量偏差 ±0.4 个百分点内
  • 引擎调用：scenario="zvex-uplift-targeting"，situation 放上述结论的浓缩（报文见 references/api.md）

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

  • 十分位增量表（按预测增量降序，每档 8,000 人，节选）：第 1 档处理组续费率 14.6% vs 对照组 6.8%（+7.8 个百分点）；第 3 档 +3.6；第 6 档 +0.1；第 7~10 档为负增量（−0.9 ~ −2.8），圈为打扰禁区
  • Top-K 名单（整体混排口径）：取前 30% = 2.4 万人，预期增量续费约 +1,330 人（该段平均增量约 +5.5 个百分点）
  • 利润最优化三要素（单客续费毛利 120 元、券成本 15 元/转化、触达成本 0.2 元/人、固定成本 5,000 元）：累计利润曲线峰值在前 6 档 ≈ 4.8 万人——预期增量续费约 1,560 人，净增量利润约 14.9 万元；全员群发 8 万人净增量利润仅约 8.0 万元（打扰禁区倒贴约 7 万元）。结论：发前 6 档，后 4 档进不打扰名单
  • 回流建议（示例）：正式投放保留 10% 随机对照组核真实增量并沉淀下一轮训练数据；前提——人群、渠道、券面与试投一致，换渠道或加码激励需重估

能力边界与限制

  • 只回答「发给谁、发多少」，不承诺提升结果：增量是统计估计不是保证——名单给到后实际转化受渠道、文案、券面影响；发不发、发多少由业务方拍板
  • 只吃带分组标记的个体级数据：需要「特征 + 是否触达 + 是否转化」对得上的实验数据；没有随机分组数据时不硬跑——给补实验方案（两组规模、观察窗口、试投比例）或建议改道响应率路线；只有总转化率的汇总报表无法做增量定向
  • 实验场景漂移如实提示：实验与未来投放的人群、渠道、激励差异大时，明示结论需打折或重估，不把失真数字包装成可信名单
  • 引擎返回通用分析骨架：增量定向专属板块（十分位表、Top-K 名单、利润峰值、回流建议）由宿主转译层按场景交付形态组装，实际数字必须来自用户数据与引擎产出，两边都没有的数字不写（见 references/api.md §4）
  • 不做：操作投放后台、代设计完整实验执行、实时拉数（只审用户提供的实验数据）——实验怎么跑、预算怎么批由业务方拍板
  • 隐私红线：经营数据先脱敏概括再进调用参数；带手机号、证件号等个人信息的原始列禁止写进任何参数

常见问题与反模式（FAQ）

高频问答：

  • 为什么我拿到的是通用营销分析包，不是 增量定向深度报告？ 八成是漏传 scenario="zvex-uplift-targeting"（与技能身份绑定，漏传拿到通用包）；若报「场景未就绪(scenario pack 缺失)」是服务端部署态问题——禁止改传 general，如实告知稍后同参数重试（详见 references/api.md 错误表）。
  • 同一个问题重复问，会重复下单吗？ 不会——判重按问题身份（situation+goal+mode+scenario）：同键重复查询复用已存结果；补 known_facts/goal_detail 不出新订单；任一键改变 = 新问题 = 新订单，所以提交后禁止换参数重试。不确定订单状态传 action=check_order 查单。
  • 「好了」之后多久拿到完整报告？ 支付核销有短暂延迟：等 1 分钟左右回「好了」，系统自动查单交付，无需任何凭证；不要把延迟当失败反复刷单，也不要引导用户找/粘贴支付凭证。
  • goal 传什么值？ 以 consult_info 探针实时返回的列表为准（含其固定中文别名）；传列表外的值（自由中文、自造目标名）报参数错误——先调探针取当前枚举，修正后重调即可。
  • situation 该放什么、不放什么？ 放诊断段结论浓缩（适用性判定、体检结论、路线横评与稳定性结论、方向性发现，≤2000 字符）；不放原始导出整段粘贴，不放未脱敏经营数据与个人信息。
  • 没有随机实验数据能不能做？ 不能硬做。增量只能从随机分组的组间对照里来——先补一轮小规模随机分组试投（处理/对照各留足样本，跑完观察窗口再评），或如实改道响应率路线；拿按运营规则分的历史数据硬跑，出来的「增量」是混淆偏差。
  • 全员转化率明明涨了，为什么还要看增量？ 全员口径里混着大量「不发也会买」的用户，涨的那部分未必是触达的功劳；只有组间差分才能把「发了才买」剥出来，也才能看到「发了反而流失」的负增量档。
  • 两组人数不相等还能算吗？ 能，但路线要换：接近对半用标签翻转法；悬殊比例改用倾向得分修正的转换结果法；评估口径里 Qini 对体量不均衡更稳健。
  • 和响应率模型、相似人群模型什么区别？ 响应率模型回答「谁会买」，相似人群模型回答「谁像已转化的人」，增量定向回答「谁是因为被触达才买」——推冷门品用响应率路线，找种子人群用相似路线，省预算要增量路线。
  • 名单取前多少怎么定？ 不拍比例——把增量货币化后画累计利润曲线取峰值：单客收益×增量转化，减激励、触达与固定成本，曲线最高点对应的触达规模就是最优名单。
  • 增量能当承诺吗？ 不能。增量是统计估计，前提是分组随机、实验与投放场景一致；换渠道、换券面、换人群都要重估，正式投放保留随机对照组核真实效果。

反模式（命中即返工）：

  • 漏传 scenario；goal 拍脑袋传探针列表外的值；situation 整段粘贴原始导出
  • 出订单后换参数重试；把核销延迟当失败反复刷单；引导用户找/粘贴支付凭证
  • 把响应率分数当增量分数；裸曲线面积不归一就横比；负增量档照发不圈禁区
  • 无随机分组数据硬跑增量；分组悬殊硬用标签翻转；报告贴原始 JSON 不转译；套模板——换一份不同行为、不同行业的数据结论不变

护栏

  • 稳定性核查不达标不出定向名单：归一化横评完成、训练/验证分档增量偏差可用、排序后处理组占比均匀——三项是可检验的交付底线
  • 打扰禁区必须显式圈出：负增量档（易反感人群）对投放是净伤害，宁可少发不发；不把「模型分数低」轻描淡写成「可以不发可以发」
  • 增量是差分不是转化率：响应率分数不能冒充增量分数；全员口径的转化上涨不能当作触达功劳的证据
  • 数据不达标如实退回，不硬凑结论；每个数字可溯源到用户数据，缺数据先明说

调用

完整增量定向报告与利润最优化走 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-uplift-targeting","situation":"<诊断段结论浓缩：适用性判定+体检结论+路线横评与稳定性结论+方向性发现>","goal":"<以 consult_info 探针返回的当前列表为准>","mode":"standard","known_facts":"<诊断段确认的口径：分组比例、转化定义、窗口长度、成本量级>","goal_detail":"","payment_proof":""}}}

    必须传 scenario="zvex-uplift-targeting"（技能身份绑定，漏传拿到的是通用营销分析包）；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（不产生账单）即可查询，不要靠更换参数试探；
  • 换参数=新问题=新账单：出账单后不要更换参数重试。

证据呈现纪律

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