保存判定规则，将提案的批准与监控流程化

在本页中，你可以把出价和否定的判定规则保存到账号中，省去每次的重复指定；确认并执行优化类提示词生成的提案；设置预算超支通知或定期摘要推送；以及对符合条件的对象自动生成建议。这是一个把反复做出的相同判断规则化、让运营变轻松的页面。

本页基本信息

项目	内容
本页能做什么	保存判定规则、确认并执行提案、设置定期监控与通知、对符合条件的对象自动生成建议
适用对象	以商品推广广告（SP）为主
所需数据 / 连接	已连接的账号。通知与推送可能需要 Slack 集成等额外设置（参见下方提示）
执行范围	因提示词而异。规则 / 条件的登记＝记录／提案的批准＝批准后更改广告设置／监控 / 推送＝设置通知／判定 / 建议＝仅分析与建议。各提示词会在「设置变更」中单独说明

什么时候用

每次都要写出价或否定的判定基准很麻烦，想把它作为规则保存下来
想把优化类提示词生成的提案全部执行，或只挑选其中一部分执行
预算用得太多时希望收到通知／想定期收到每周的成绩
想对符合条件（成效低、投放停止等）的对象自动查找并生成建议

执行前需要确认的事项

目标账号 … 处理多个账号时，生成提案的账号与执行提案的账号必须一致。
判定的基准值 … 目标 ACoS、作为对象的最少点击数与订单数等。若已登记 KPI 目标则会被自动引用。
通知 / 推送的集成 … 提示词 5、6 需要额外的集成设置（参见上方提示）。

提示词速查表

想做的事	能知道什么 / 会生成什么	设置变更	提示词
把判定基准保存到账号中以便复用	登记内容与引用位置的说明	登记规则	提示词 1
确认提案内容（当前值、推荐值、理由）	提案项目的详情列表	无变更（只读）	提示词 3
找出应当结束的季节性广告活动	结束推荐的判定与理由	无变更（结束需手动）	提示词 4
预算用得太多时进行通知	通知条件与近期的超支实绩	设置通知	提示词 5
定期推送周度成绩摘要	推送计划与预览	设置推送	提示词 6
在预算有余的广告中对高成效商品提出加价建议	加价建议列表	无变更（仅建议）	提示词 7
对点击多却卖不出去的对象提出否定建议	否定候选建议列表	无变更（仅建议）	提示词 8
为投放停止的广告给出重启方案	原因与重启动作的建议	无变更（仅建议）	提示词 9

提示词 1: 保存判定规则

将出价、预算、否定关键词等判定基准保存到账号中，供之后的优化类提示词自动引用。

什么时候用 — 想停止每次都写相同的判定基准，把它固定为规则时。

执行前需要的信息 — 规则的种类，以及判定所用的基准值（目标 ACoS、最少点击数等）。

登记 {{规则种类（例: 出价优化）}} 的判定规则：
- 目标 ACoS: 15%
- 作为评估对象的最少点击数: 10 以上
- 作为评估对象的最少订单数: 1 以上
- 反映方式: 批准前不反映（作为提案返回）

可更改的条件 — 规则种类（「出价优化」「关键词出价」「预算」「展示位置倍率」「否定关键词」「搜索结果顶部展示份额」「组合」等）、目标 ACoS、最少点击数与最少订单数的阈值。若已登记 KPI 目标，目标 ACoS 可省略。

返回的内容 — 登记内容的表格，以及会被哪些优化类提示词自动引用的说明。

设置变更 — 将判定规则登记到账号中（不更改广告设置）。反映模式固定为「批准前不反映」。

术语补充 — 最少点击数、最少订单数的阈值，是为了避免对数据过少的对象误判而设的参考值（示例为 10 次点击、1 笔订单）。

接下来做什么 — 登记的规则会被调整竞价、调整预算、添加否定关键词引用。

提示词 2: 确认提案详情

从方案 ID 逐项列出各项目的内容（当前值、推荐值、理由），用于准备部分执行。

什么时候用 — 在全部执行提案之前，想逐项查看内容并加以取舍时。

执行前需要的信息 — 方案 ID。

目的: 在批准前准确把握提案内容，防止反映错误的变更。

请显示方案 ID {{方案ID（例: campaign-1787102102700-xxxxx）}} 的详情。

【必须显示】
- 项目 ID（item id）
- 当前值 / 推荐值 / 推荐的理由
- 各项目 metadata 中的设置值
- proposal 的 type 与 account_id、失效时间（expires_at）
- 已显示的项目数

【🔴 查看的位置会随 proposal 的 type 而变。务必分支处理】
A. 新建广告活动的提案（type=campaign）时
- items[] 只是摘要。务必查看 campaign_plan_raw。
  SP 的提案中，campaign_plan_raw.steps[] 里装着要发给 Amazon Ads API 的实际请求 body 的全部层级。
  实测中确认到的项目:
  ・ campaign: name / targetingType / state / budget{budget,budgetType} / dynamicBidding / portfolioId
  ・ adGroup: name / state / defaultBid
  ・ productAd: sku / state
  ・ keyword: keywordText / matchType / state / bid
  ・ 各 step 的 nameSource / nameSourceLabel（可据此得知名称是使用者指定的还是来自命名规则。例: "user-override" / "by user override"）
- 项目数在 campaign_plan_raw.summary 中（campaigns / adGroups / productAds / keywords / negativeKeywords / targets 的明细）。
  请用它给出各层级的件数。
- 🔴 各层级的 state 可能不同。 实测中 campaign 为 PAUSED，而 adGroup / productAd / keyword 为 ENABLED。
  不要把「创建时的状态」归纳成一个来写，请按层级逐一列举。
- ※ SB / SD 的广告活动提案没有 campaign_plan_raw。metadata 也只有
  {name, budget, budgetType}（SB）/ {name, budget, tactic}（SD），传入的开始日期与
  广告组合不会被回显。这时请把它们列为「不会出现在提案差分中的项目」，
  并让使用者重新提示创建提案时的请求内容后进行核对。

B. 出价・预算等调整提案（type=budget / 出价类）时
- items[] 的 metadata 中装有写入目标的父级 ID。
  在出价类中确认到 targetId / targetKind / campaignId / adGroupId，以及作为判断依据的 clicks / spend / sales / orders。
  因此不要断定「不返回父级 ID」，请先看过 metadata 再判断。
- 预算提案的 items 有时只有 id / label / current_value / recommended_value / reason。
  其中不存在 spend / sales / estimated_impact，因此不要把差额当作效果金额来提示。

【务必写明「未获取」】
只把看过上述 A / B 之后仍然取不到的项目，不做推测补全，写明「无法从 MCP 获取」。
示例（实测确认过的）:
- 新建 SP 广告活动时的开始日期 — 创建工具的 config 中本来就不存在开始日期这一项，
  因此 campaign body 中也不会有 startDate（由 Amazon 侧的默认值决定）。请写「未指定（创建时点即开始）」。
  ※ SB / SD 是把开始日期作为参数接收、只是不出现在差分中，处理方式不同。请不要混淆。
- 既有实体的当前实态（新建提案只会把 currentValue 变成 "(new)"，
  提案侧并不判定是否已存在同名广告活动）

【批准前的必须确认】
1. 若是新建提案，请对 campaign_plan_raw 的 portfolioId ・ sku ・ keywordText ・ matchType
   做实在性确认（用广告组合列表・SKU 反查・广告活动列表核对）。
   🔴 即使是不存在的 ID 也能生成 proposal（创建时不做实在性校验）。
   不要把「提案能够生成」当作「对象真实存在的证据」。
2. 若是调整提案，请用列表获取工具核对 metadata 的 campaignId / adGroupId。
3. 若从 metadata 与 campaign_plan_raw 都无法确定对象，请让使用者重新提示创建提案时指定的
   {{对象广告活动ID}} / {{对象广告组ID}}，
   并用列表获取工具核对它是否真实存在、是否是预期的对象，然后再回答能否批准。
   无法核对时请结论为「不可批准（对象未确认）」。

【有效期限】
提案自生成起 24 小时失效（务必提示 expires_at）。
由于没有事后在列表中找回提案 ID 的手段，决定不批准的提案请当场废弃，
并报告已废弃（放置不管会留下日后由其他负责人批准的路径）。

使用该结果的下一个提示词: {{连接去向（例: 批准提案并执行）}}

可更改的条件 — （无。仅作显示。）

返回的内容 — 项目 ID × 广告活动 × 对象 × 当前值 × 推荐值 × 理由的表格。

设置变更 — 无变更（只读）。不会反映任何内容。

接下来做什么 — 这里确认到的项目 ID，可以直接传给提示词 2 用于部分执行。

提示词 3: 找出应当结束的季节性广告活动

依据过去 14 天各商品（SKU）的广告利润，判定差不多该结束哪些季节性广告活动。

什么时候用 — 想判断促销或季节性商品的广告该何时停止时。

执行前需要的信息 — （对象期间默认是过去 14 天）

请依据过去{{对象期间（例: 14天）}}的实绩，判定应当结束哪些季节性广告活动。

0. 【确定数据边界】先确认入库状况，把未确定的日期（含当天）从汇总期间中排除。写明实际使用的确定期间。不要把未确定日放进推移的最后一个点。
1. 【识别】先列出作为「季节性广告活动」判定基准的季节・活动词清单（春/夏/秋/冬/雪/红叶/圣诞/情人节/白色情人节/福袋/母亲节/父亲节/万圣节/年末年初/新生活/年度最佳化妆品/限定/促销/Prime Day 等），再横跨 SP/SB/SD 全件检索。写明获取件数/总件数以及分页是否处理到最后（不要把被截断的当作全部件数）。
   - 务必排除词语偶然与商品线名称・ASIN 字符串・内部代码的一部分一致而造成的误检。候选要一直追溯到「广告组→商品广告→ASIN→商品名」，确认是季节性商品还是全年商品线之后再采用。列出被排除的候选与理由。
   - 广告活动中不存在表示季节的字段（结束日期・排程・活动关联），因此请写明识别是基于名称的推测，并把「名称中不含季节词的季节性广告活动无法检出」作为网罗性的局限写明。
   - 判定对象仅限运行中的（投放状态有效 且 广告费>0）。若为0件则说明情况后结束。
2. 【推移】把对象广告活动的销售额・ROAS，按确定期间前半/后半二分割的2个点进行比较。确认分割后的合计与整个期间的汇总一致，不一致时写明「仅为单一期间的汇总值」，并且不要使用「趋势/推移」一词。
3. 【库存】对于对象广告活动中正在投放的广告的 ASIN，并列给出库存数・周度出货・库存周数。已停止广告的 ASIN 不包含在内。
4. 【效率的基准】未接入成本数据时请写明，并把 ROAS/ACoS 注记为「效率的代理指标」。作为判定的基准线，请获取并并列给出整个账户的 ROAS。
5. 【结束判定的基准】只有全部满足以下各项的才建议结束（务必写明满足了哪些条件）:
   (a) 后半期间的销售额相对前半在{{衰减阈值（例: -30%）}}以下
   (b) 后半期间的 ROAS 低于整个账户的 ROAS
   (c) 库存周数并未低于{{库存周数下限（例: 4周）}}（以免误停为消化库存而继续的投放）
   仅满足 (a)(b) 的记为「继续观察」，都不满足的记为「维持原样」。
【约束】禁止对未确认实在性的广告活动提出建议。表格的标题与内容要一致。仅限上位N件时要写明总件数。名称推测要写明。不执行写入类操作（包括停止广告活动、自动化规则的创建・更新・删除）。

最后请输出以下 3 点。
1. 推荐操作 — 按优先度提示 建议结束/继续观察/维持原样，并对建议结束的一并给出预计可削减的广告费（把确定期间的实绩广告费按日折算后换算为月额）及其算出依据
2. 执行方法 — 建议结束的广告活动，需由用户确认・批准对象与停止理由之后再停止（本提示词不执行）
3. 测量 — 批准后执行停止起{{评估日（例: 14天后）}}，重新确认整个账户的 ROAS 与库存状况。重新确认时同样以排除未确定日的确定期间来切分

可更改的条件 — 对象期间。

返回的内容 — 广告活动 × 过去 14 天销售走势 × ROAS × 结束推荐判定 × 理由的表格。

设置变更 — 无变更（仅分析与建议）。实际结束广告活动需手动执行。

接下来做什么 — 若想结合库存状况一并判断，可搭配管理库存与销售机会。

提示词 4: 在预算用得太多时通知

监控所有在投 SP 广告活动的预算消化节奏，当日预算超出 15% 时进行通知。

什么时候用 — 想在预算用得太多时随时知晓，而不是事后才发现时。

执行前需要的信息 — 触发通知的超支比例（默认 15%）。通知的集成设置（参见上方提示）。

监控所有在投 SP 广告活动的预算消化节奏，
当一天的预算超出 15% 时通知我。

可更改的条件 — 超支比例（示例为 15%）。

返回的内容 — 通知条件的确认，以及最近一周的超支实绩。

设置变更 — 设置通知条件（不更改广告设置）。通知的推送需要额外的集成设置。

接下来做什么 — 预算本身的调整请在调整预算中进行。

提示词 5: 定期推送周度摘要

在指定的星期与时刻，自动生成并推送 SP 的周度业绩摘要。

什么时候用 — 想定期收到每周成绩，而不必手动汇总时。

执行前需要的信息 — 推送的星期与时刻（示例为每周三 13 点）。推送的集成设置（参见上方提示）。

每周三 13 点生成 SP 的周度业绩摘要，
并包含周环比（WoW）比较一并推送。

可更改的条件 — 推送的星期与时刻。

返回的内容 — 推送计划的确认，以及最近一周摘要的预览。

设置变更 — 设置推送（不更改广告设置）。推送需要额外的集成设置。

接下来做什么 — 若想自定义报告内容，请使用创建报告。

提示词 6: 在预算有余的广告中对高成效商品提出加价建议

在没能用尽预算的广告活动中，对高成效商品（ASIN）生成提高出价的建议。

什么时候用 — 想趁预算还有余量时，把预算向表现向好的商品倾斜时。

执行前需要的信息 — 预算消化节奏的阈值（默认低于 70%）。

请对预算消化尚有余力的 SP 广告活动中的高效率定向，提出提高出价的方案。

【前提】
- 分析期间设为{{分析期间（例: 最近14天・至确定日为止）}}，当天为未确定故不包含在内。
- 务必指定目标ACoS{{目标ACoS（例: 35%）}}。未指定时会把观测 TACOS 当作暂定轴，变成 down_or_maintain_only，导致增额提案为0件。

【步骤】
1. 用 start_existing_sp_campaigns_job 获取 ENABLED 的 SP 广告活动，确认 get_mcp_job_status 为 complete 且 truncated=false 之后再取 get_mcp_job_result。不要在 running 状态下就确定件数。请明示「获取件数/总件数」。该作业返回的只有广告活动单位的行，不包含广告组・商品广告的嵌套。
2. 消化率请按以下公式自己计算。不要把返回字段 budgetUtilizationRate 直接当作消化率使用（其实体是「期间合计spend ÷ 1天份的dailyBudget」，会按期间天数产生倍率偏差）。
   消化率 = 期间合计spend ÷ (dailyBudget × 分析期间的天数)
   每行并列给出分子与分母的值。
3. 把消化率低于{{消化率阈值（例: 70%）}}且 ROAS 在{{ROAS阈值（例: 3倍）}}以上的广告活动全部列举，使件数与表格行数一致。期间内 spend=0 的行作为「无投放实绩」另行列出，不要作为消化率0%的余力混进增额候选。不要写没有汇总过的件数。
4. 把符合条件的广告活动指定到 campaign_ids，带上目标ACoS 调用 optimize_target_bids。读取 target_fetch_truncated / target_fetched_pages / target_total_pages_available，用「获取页数/全部页数」明示定向的获取率。若响应中未出现这些字段，说明没有发生截断，请注明「已获取全部数据」。
5. 用 get_proposal 获取明细，使用 metadata 的 spend/sales/orders/clicks 按广告费从大到小排列（optimize_target_bids 的直接响应中不含 metadata，务必经由 get_proposal）。以金额提示 当前出价(currentValue)・提案出价(recommendedValue)・差额・算出依据(reason)。
   Amazon建议出价额不包含在出价提案的 items 中，但可以从定向实绩列表另行获取建议出价额（suggested_bid），用 metadata 的 targetId 核对后并列显示。不要仅凭出价提案工具的输出就断定「无法获取建议出价额」。对于不返回建议出价额的定向（如已停止等），请注明「建议出价额无法获取」，不要当作0处理。
   没有返回最大 CPC 的接口，因此请写明「无法获取」（不要用推测填补不存在的值）。
6. 用广告活动名称区分 Branded 面与获客面，Branded 面不要把 ACoS 低作为增额依据。增额提案优先 Branded 以外的。
7. 请写明提案的单位是「定向（关键词／商品定向）」。并写明商品定向的 ASIN 是被定向的 ASIN，而不是自家投放的 ASIN，不要把广告活动单位的消化率与 ASIN 单位的指标混为一谈。

【约束】
- 禁止用推测补全。MCP 不返回的指标写「无法获取」。但也不要把能从其他工具取到的值写成「无法获取」。
- 只做到提案的提示，一律不执行 execute_proposal / execute_ads_adjustment_workflow / update_* 等写入类操作。
- 生成的 proposal 在提示之后用 cancel_proposal 删除，并用 get_proposal 确认其已消失。

执行前务必: 提示变更内容一览（对象・当前值・变更后的值・Amazon建议出价额・广告费影响），在获得批准之前不要反映到媒体侧。
执行后: 在用户确认・批准提案内容之后再反映，并于{{评估期间（例: 14天）}}后用「施策的效果测定」比较 ROAS 与 ACoS，恶化则判定为 Revert，改善则判定为 Keep。

可更改的条件 — 预算消化节奏的阈值（示例为低于 70%）。

返回的内容 — 广告活动 × 商品（ASIN）× 当前出价 × 建议出价 × 预计消化率的表格。

设置变更 — 无变更（仅建议）。执行通过提示词 2 的批准流程进行。

术语补充 — 低于 70% 是判断「预算尚未用尽」的参考值。

接下来做什么 — 要执行建议时，请前往提示词 2。

提示词 7: 对点击多却卖不出去的对象提出否定建议

找出过去 14 天点击多却卖不出去的搜索词、商品定向，生成否定的建议。

什么时候用 — 想整理那些只花成本却带不来销售的对象时。

执行前需要的信息 — 点击数、CPC、ROAS 的阈值（默认如下）。

请从过去{{评估期间（例: 14天）}}的广告定向实绩中，洗出同时满足 点击20以上・CPC超过100日元・ROAS低于0.5（＝ACoS超过200%）的无效定向，并生成否定候选一览与否定提案（Proposal）。在批准之前一律不反映到媒体侧。

【步骤】
1. 期间的确定: 用 get_data_ingestion_status 确认「Targeting SP」为 completed 的最后一天，以该日为结束日，向前回溯评估期间来决定开始日。当天容易变成 fully_missed，直接写「过去N天」会在无提示的情况下变成实际 N-1 天，因此务必在输出中写明实际使用的 from_date / to_date。不要看 rollup_status，而要看按报表区分的 status。

2. 🔴 候选的获取务必传入 min_clicks。 调用 list_target_performance 时指定 min_clicks=20・target_types。
   min_clicks 会在上游服务器端筛选，母体一开始就会变小。
   请确认响应的 server_filter_applied 为 true 并写进输出。
   ※ 不需要「因为上游按销售额降序，所以高ACoS・低销售额会被漏掉」这类规避手段。
     指定筛选条件后排序会变为 clicks 降序，高ACoS・低销售额的行（因为有点击）会全部进入母体。
     实测: min_clicks=10 / target_types=KEYWORD / 14天，total_results 295 对应 fetched_row_count 295，网罗率100%。
     其中既有 ACoS 1578%（销售额¥800 / 广告费¥12,627）这样的行，也有销售额为0的行。
   ※ 想进一步收窄低销售额层时，请同时使用 max_sales（在获取后应用，会反映到 filtered_row_count）。
   ※ 不存在按 campaign_id 筛选的参数，因此按广告活动的明细请用返回行的 campaign_id 自行汇总。

3. 自行计算: 各行的 CPC＝spend÷clicks、ROAS＝sales÷spend 请自己算，只保留满足3个条件的行。
   响应的 roas 栏・acos 栏为百分比表示而非倍率，不要用于阈值判定
   （实测: sales 2,540 / spend 5,160.09 的行，roas 栏为 49.22。也就是 49.22% 而不是 0.4922）。

4. 前处理: (a) 确认响应的 duplicate_rows_folded 并记载。返回该值时说明工具已经折叠了重复，不需要自行去重（只有不返回时才用 target_id + ad_group_id 去重）。(b) 确认 campaign_type，把 SP / SD / SB 分开显示（因为执行否定的工具属于不同体系）。

5. 销售额为零的候选的获取: 🔴 请把 zero_sales_only=true 与 min_clicks 一起传入直接获取。
   这属于上游服务器端筛选，可以直接到达销售额为零的行
   （实测: zero_sales_only=true + min_clicks=5 时 total_results 182 / fetched 175 = 网罗率 96.2%。
   返回的行 sales/units/purchases 全部为0，而 spend 有 ¥5,357〜¥12,331）。
   「销售额为零的定向在结构上一件都取不到」这一说法是错误的。
   ※ zero_sales_only 会把 sales 未获取（null）的行也当作 0 包含进来，因此请逐行确认 sales / units / purchases 三者都为 0 之后再放入候选。
   同时使用 detect_negatives 时只作为辅助，并转记 search_term_fetched_pages / search_term_total_pages_available（即使 candidates_truncated 为 false，上游也可能已被截断）。

6. 输出: 并列给出 词句/ASIN・种别（KEYWORD/TARGET）・广告种别（SP/SB/SD）・广告活动名称・campaign_id・点击・消耗・销售额・算出CPC・算出ROAS・suggested_bid，做到可以检算。把「销售额为零群」与「低ROAS群」分成两张表，各自按消耗从大到小排列。给出比率时务必并列写明分子・分母・天数。

7. 获取率的明示: 请原样转记 total_results / fetched_row_count / filtered_row_count / returned_row_count，并按 网罗率 = fetched_row_count ÷ total_results 计算。
   传入筛选条件时的 total_results 不是「期间内的全部定向数」，而是「符合条件的总件数」。请把这一区别写出来。
   网罗率为100%时可以写「在此条件下为全部件数」；不足100%时请调高 max_pages（上限 100 页 = 10,000 行，默认 20）重新获取。仍然达不到时请写明「符合件数无法确定」。

【约束】
- 一律不执行否定登记・出价变更等写入类操作。只做到 Proposal 的生成，不调用 execute_proposal。
  生成的 Proposal 若不批准务必废弃，并报告已废弃（提案会在账户中作为待批准保留24小时，且没有在列表中找回的手段）。
- 批准前先确认回滚路径: SP 关键词否定可以用 update_sp_negative_keywords 改回 state=PAUSED，但用于查ID的 list_sp_negative_keywords 在省略 ad_group_id 时会返回 total_count=0，因此必须记下被否定的 campaign_id 与 ad_group_id。无法留下该记录的对象请从否定候选中剔除。
- 不要作为「自动否定」进行无人运营。manage_automation_rules 的 negative 规则在 Phase 1 仅有 propose_only / on_demand，无法定期自动执行。
- 上游的汇总有约4小时缓存，请写明最近的出价变更或投放实绩可能尚未反映。

【Follow-up】批准后执行了否定时，请在{{评估期间（例: 14天）}}后重新获取对象广告活动的 CTR・ROAS，确认对 CVR・销售额没有不良影响。测量请按广告组单位进行，而不是被否定的定向本身（被否定的定向必然会是 -100%）。

可更改的条件 — 点击数、CPC、ROAS 的阈值。

返回的内容 — 对象（搜索词、商品定向）× 点击 × CPC × ROAS × 推荐匹配类型的表格。

设置变更 — 无变更（仅建议）。执行通过提示词 2 的批准流程，或通过添加否定关键词进行。

术语补充 — 点击 20 以上是为了收窄到有足够数据可判定的对象的参考值；CPC 超过 100 日元、ROAS 低于 0.5 是「花费与销售不相称」对象的示例。两者都可按运营情况调整。

接下来做什么 — 否定的执行请前往添加否定关键词。

提示词 8: 为投放停止的广告给出重启方案

对过去 24～48 小时投放归零的在投 SP 广告活动，给出重启方案。

什么时候用 — 本应在运行的广告突然停止投放时，想知道原因与对策时。

执行前需要的信息 — 对象期间（默认为过去 48 小时）。

请找出过去48小时投放为零（展示量=0）的在投 SP 广告活动，并给出只挑出可以重启的那些的重启方案。一律不执行写入类操作。

【0. 对象期间的确定（最先务必进行）】
用 get_data_ingestion_status 确认已确定的日期，把 rollup_status 为 fully_missed / in_progress 的日期排除后，以「已确定的最近2天」为对象期间。务必写明所使用的期间与被排除的日期。
※ 用含未确定日的1天窗口判定时，全部广告活动看起来都会像「投放为零」。只要是含确定日的合算窗口，即便混入未确定日结果也不会变，但对象期间务必明示。

【1. 母体的确定】
用 start_existing_sp_campaigns_job（state=enabled, from_date/to_date=上述确定期间）→ get_mcp_job_status → get_mcp_job_result 获取全部 ENABLED 广告活动。同步版 list_existing_sp_campaigns 会超时，不要使用。确认 truncated / row_count，并明示已取得全部件数。
「投放为零」定义为 impressions=0。不要用 spend=0 或 clicks=0 代替（那会把正在投放只是没有点击的正常广告活动也纳进来）。请并列给出 impressions=0 / spend=0 / clicks=0 各自的件数，把定义的差异可视化。

【2. 筛选与排序】
在明示全部符合件数之后，按「每日预算降序」选出前{{件数（例: 10件）}}。请写明每日预算终究只是机会规模的代理指标，而不是可回收金额。禁止任意截取开头。并写明所选前N件占母体每日预算合计的百分之几。

【3. 各广告活动的原因切分（务必按下列顺序全部确认）】
(a) 预算上限 — impressions=0 的广告活动 spend=0，因此预算上限不可能成为原因。只有 spend>0 时才纳入研讨。
    ※budgetUtilizationRate 是「spend ÷ dailyBudget」，没有除以期间天数。在2天以上的窗口中会膨胀到实态的天数倍，务必先正规化为「期间spend ÷（dailyBudget × 对象天数）」再判定。
(b) 广告（商品）侧的停止 — 用 list_sp_product_ads 获取各广告组 product ad 的 state。若 ENABLED 的广告为0件，或大半为 PAUSED / ARCHIVED，那么动出价或预算也不会恢复投放。请最优先确认这一点。
(c) 库存 — 用 get_fba_inventory 确认与 ENABLED 广告关联的 ASIN。若 daysOfSupply 低于评估期间，或 sellableInventory 极少，则判定为「不重启（先确保库存）」。不要在未确认库存的情况下建议重启。
(d) 定向收得过窄 — 用 list_sp_keywords 实际获取定向并明示 total_in_period。若为0件请写明「未能获取定向」，且不要写出价值。keyword_fetch_truncated 为 true 时，并列写明获取页数与总页数。
(e) 出价不足 — 给出 current_bid 与 suggested_bid 的偏离率。由于存在 suggested_bid 为 null 的定向，务必并列写明能算出偏离率的件数／样本件数，算不出的不要下定论。
(f) 以上都无法解释时，写明「原因不明」。不要用推测填补。
※IS%（展示份额）无法按定向单位获取，因此不作为依据使用。

【4. 有意停止的处理（不可省略）】
广告活动没有结束日期字段，manage_event 也没有与广告活动的关联，因此无法机械判别「季节性举措结束」「停产品」等有意停止的情况。所以请对全部件数写明「是否为有意停止无法判定」，并把重启执行前的运营者确认设为必须。对于从广告活动名称或广告的 PAUSED 状况来看疑似有意停止的，请连同依据作为「需确认」另行列出。

【Guardrail】
一律不执行出价变更・状态变更・自动化规则的创建／更新等写入类操作。只在批准之后执行。

最后请输出以下 3 点。
1. 推荐操作 — 依据【3】的判定结果，分为「建议重启」「需确认（疑似有意停止／原因不明）」「不建议重启（库存不足・广告停止）」3 类，只对建议重启的按每日预算规模顺序排优先度，并按原因给出对策（提高出价／重新启用广告／扩大定向）。逐件写出预期效果（可恢复展示量与预估销售额的依据），没有依据数据时写明「无法估算」
2. 执行方法 — 提案由用户确认・批准之后再反映（本提示词不执行）
3. 测量 — 重启后{{评估日（例: 7天后）}}重新获取展示量与 ACoS。重新获取时同样适用【0】的确定数据边界，不要包含未确定日。若已恢复且 ACoS 在允许范围内则 Keep，恶化则 Revert