制定广告策略

本页能生成比 ACoS、出价等战术层调整更上一层的判断材料 —— 品牌战略、预算分配、CAC / LTV 等管理层想看的内容。不仅看广告效率，还能从漏斗整体、跨产品线、新客获取的视角，面向月度到季度的战略复盘进行分析。

本页基本信息

项目	内容
本页能做什么	从 Sponsored Ads 的实绩中，将漏斗分解、品牌结构、预算分配模拟、各 ASIN 收益等战略级判断材料汇总成一览
对象	Sponsored Ads（SP / SB / SD）。各提示词以商品推广广告（SP）为主。Amazon DSP、AMC 为独立页面（见下方 note）
所需数据、连接	Picaro 持有的 Sponsored Ads 实绩数据（账户已连接即无需额外设置）。但提示词 5・9 还会使用 AMC（Amazon Marketing Cloud）的数据，因此未连接 AMC 的账户无法执行
操作范围	仅分析、仅建议（只读）。预算分配方案也仅到建议为止，不修改广告设置。实际的预算、出价、关键词变更请在相关页面的审批流程中进行

本页的提示词已在正文中写明以下注意点。改写提示词时，也请保留这些内容。

消耗率等会「膨胀」的指标要自己做归一化 — budgetUtilizationRate 等部分指标是以「期间合计 ÷ 1 天份的值」返回的，期间越长就按天数成倍膨胀（实测最大 29 倍）。请务必用「期间合计 ÷（日预算 × 有效天数）」重新计算。
当日・未确定日要从聚合中排除 — rollup_status 只要有 1 个广告类型未投放，整天就会掉成 no_data，无法用于确定性判定。请查看各报告的 status，排除 fully_missed 的日期。
CTR / CVR 要用同一数据源的 clicks 计算 — 跨工具混用指标会导致分母错位。get_dashboard 不返回 clicks，因此不要用于这个计算。
退役广告活动（名称含 old_ 等）可能混进「建议增额」里 — 不要直接使用 optimize_budget 等的建议，请按广告活动名排除。
数值可能以带格式的字符串（¥1,691,946 / 112.8% 等）返回 — 做四则运算前请去掉符号。不要以字符串状态排序。
按 ASIN 的指标要把数据源固定为 1 个 — get_amc_ntb_by_asin 的 DSP / Sponsored Brands 行存在 ad_spend 恒为 0 的已知缺陷，因此请只使用 Sponsored Products 行。
analyze_search_term_contribution 要按 period_first＝前一期间、period_second＝当期的顺序传入 — 传反会使 change / contribution 的符号反转。该工具的 change（bps）・change_value（百分点）・change_ratio（相对变化率）单位各不相同，请务必写明用的是哪个单位。它不会返回账户整体的贡献度（total.contribution 为 --）。不要把各行的 contribution 相加来代替。
不要把 get_change_history 的 0 件断定为「没有变更」 — 无错误的 0 件无法区分「确实没有变更」与「未能取得历史」。超过 90 天的开始日会被自动上调到 90 天前。
get_placement_summary 只返回当期 — 要与前一期间比较，请分两次取得。「Rest of Search」是把 Home / Off-Amazon / Placement Rest of Search / Site Amazon Business 这 4 种合成后的值。

使用场景

在新建构建前，盘点现有广告活动结构，避免命名冲突和重复构建
想判断哪个漏斗阶段（展示 → 点击 → 订单）是瓶颈
想对比品牌词与通用词哪个卖得更高效
想用 CAC / LTV 或新客视角，解释仅凭 ACoS 看不出的亏损因素
想先模拟再决定把追加预算分配给哪个广告活动
想按 ASIN 判断广告贡献额（销售额 − 广告费），或找出被点击却没卖出的商品

执行前需确认

连接的账户 … 处理多个账户时，先确认目标账户是否正确。
目标期间 … 如「过去 30 天」。看长期趋势的战略分析推荐 30 天以上。当日、前一日可能尚未确定，用已确定的近期期间更稳妥。
目标品牌、ASIN、投资组合（可选） … 想缩小到特定范围时指定。不指定则以当前连接账户整体为对象。
若在设置销售额、广告费、ACoS 目标中登记了目标 ACoS / ROAS，「效率好 / 坏」的判定基准会被自动使用。

快速参考

想做的事	能得到什么	设置变更	提示词
新建构建前盘点现有 SP 广告活动结构	广告活动名、状态、日预算一览与命名冲突提示	无变更	提示词 1
按漏斗阶段找出瓶颈	漏斗 × 广告活动的业绩表	无变更	提示词 2
对比品牌词与通用词的效率	品牌组 vs 通用组汇总与 ASIN 排名	无变更	提示词 3
从客户视角解释并改进亏损因素	亏损对象 × CAC / 预计 LTV × 改进建议的表	无变更	提示词 4
想要增加新客的预算追加分配方案	分配目标 × 分配额 × 实测 NTB CAC 的表	无变更	提示词 5
了解现有广告活动内预算追加的最优分配	广告活动 × 推荐分配额 × 实绩 ROAS 的表	无变更	提示词 6
分析预算未消化的原因	未消化对象 × 预计原因 × 应对方针的表	无变更	提示词 7
按搜索漏斗制定活动前后的预算分配方案	漏斗 × 预热期 / 当日 / 后续期的分配表	无变更	提示词 8
按 ASIN 计算广告贡献额	ASIN × 销售额 × 广告费 × 广告贡献额的表	无变更	提示词 9
获取主要 ASIN 的业绩汇总（期间合计）	ASIN × 广告销售额 / 广告费 / 广告销售件数 / ROAS 的表	无变更	提示词 10
识别点击率高但购买率低的 ASIN	ASIN × CTR × CVR × 平均比 × 原因假设的表	无变更	提示词 11
把恶化指标的原因切分为 6 个要因	检索词 / 出价 / CPC / CVR / 预算 / 广告位各自的贡献度与应对优先级	无变更	提示词 12

分析现状结构与成果

提示词 1: 确认现有广告活动结构

作为新建构建的前置步骤，获取所参照广告资料下挂的 SP 广告活动一览，避免命名冲突和重复构建。

使用场景 — 在新建广告活动前，想盘点现有结构以避免命名冲突和重复构建时。

需要准备的信息 — 广告资料 ID（已连接的广告资料 ID。仅连接 1 个时会自动引用）。

请列出与广告资料 {{广告资料ID（例: 3528945248353716）}} 关联的商品推广广告活动一览。
用于新建构建前的命名冲突检查与重复构建确认。

请显示状态・日预算（创建日期因 Picaro 无法从 API 取得，不在对象内。需要时请指引到亚马逊广告控制台的 CSV）。

请确认取得件数与总件数一致，若不一致，请通过指定期间等方式重新取得。若存在与现有广告活动相同・相似的名称，请作为候选明确指出。

使用本结果的下一个提示词: 创建商品推广广告（SP）

可调整的条件 — 目标广告资料 ID。

返回内容 — 广告活动名、状态、日预算的一览表，以及存在相似名称时的注意提示。

设置变更 — 无变更（只读）。不会向亚马逊广告侧写入任何内容。

下一步 — 确认结构后，新建请用创建商品推广广告（SP），整理命名规则请用用标签与命名规则给广告分类。

提示词 2: 按漏斗阶段分解业绩

参考搜索漏斗 KPI（展示 → 点击 → 订单），将过去期间的广告活动按漏斗阶段分解，生成业绩报告。

使用场景 — 想判断在展示、点击、订单哪个阶段发生流失，找出瓶颈时。

需要准备的信息 — 目标期间（例: 过去 30 天、2026-04）。

针对最近{{目标期间（例: 过去30天）}}的SP广告活动，请按广告活动分别用展示数・点击数・订单数算出CTR与CVR，并锁定漏斗的哪个阶段是瓶颈。
目的: 锁定瓶颈阶段，决定改进的优先顺序。

数据取得（必须・单一数据源）
- 展示数 / 点击数 / 订单数**务必从同一数据源同时取得**。
  `start_existing_sp_campaigns_job`（指定 from_date / to_date）→ 确认 `get_mcp_job_status` 变为
  `truncated=false` → 用 `get_mcp_job_result` 取得全部广告活动行。
  同步方式够用时，也可以用 `analyze_ad_type_performance`（campaign_types=["SP"]）的 `campaign_rows`，但
  `top_n` **固定按ROAS降序**，因此要与 `source_row_count` 核对有无遗漏。
- **CTR与CVR的分母/分子都含 clicks，因此不得跨多个工具取得。**
  `get_dashboard` 不返回 clicks。别的工具的CVR字段是**订单件数（销售件数）口径**，
  会比订单数口径偏高，不要使用。**务必自己计算 orders ÷ clicks。**
- 指定期间之后，每次都要确认响应返回的期间与请求是否一致。

确定数据的处理
- 取得前先执行 `get_data_ingestion_status`，把 `fully_missed` 的日期（通常是当日）**从期间中排除**。
  不排除的话，指定的天数会被无警告地缩短1天。未确定日会返回0填充的行、与实绩0无法区分，因此
  不要用 `rollup_status` 做确定性判定。请把实际聚合的天数写进输出。

算出与健全性检查
- CTR = clicks ÷ impressions，CVR = orders ÷ clicks。**每次给出比率时都要明示分子・分母・天数**。
- 基准值（平均）不取各行的平均，而是从**同一次取得的整体合计**算出
  （整体CTR = 整体clicks ÷ 整体impressions，整体CVR = 整体orders ÷ 整体clicks）。
- 请进行健全性检查并写明结果:
  (a) **有没有CVR超过100%的行**（若有，说明抓到的是订单件数口径的列，请排除并切换到订单数口径）
  (b) 各行的合计与整体合计是否一致（不一致时要怀疑取得被截断）
  (c) 订单数是否只在特定期间大幅缺失（若平均客单价与其他期间差一个数量级，要怀疑缺失）
  不得把缺失期间判定为「CVR是瓶颈」。
- **设置统计下限**: impressions 不足{{最小展示数（例: 50000）}}，
  或 clicks 不足{{最小点击数（例: 200）}}的行，请排除在「显著偏低」的判定对象之外，
  作为「样本不足」另行列出（少量点击的CVR波动很大）。
- 请确认两个阶段的母集团相同（CTR的clicks与CVR的clicks是同一个值）。

瓶颈判定与排列顺序
- 对每个广告活动求 CTR不足率 =（整体CTR − 该CTR）÷ 整体CTR、
  CVR不足率 =（整体CVR − 该CVR）÷ 整体CVR，以较大的一方作为瓶颈阶段。
- 影响度 = impressions × 不足率（较大的一方）。**按影响度降序**排列，输出前{{件数（例: 10）}}件。

输出
1. 前提 — 聚合期间（实际天数）・数据源・整体CTR/整体CVR（带分子・分母）・对象广告活动数（有实绩的数／全部数）・健全性检查的结果
2. 瓶颈一览 — 广告活动名／阶段（CTR or CVR）／impressions／clicks／orders／CTR／CVR／不足率／影响度
3. 推荐行动 — CTR侧则调整素材・出价・检索词，CVR侧则调整商品页・价格・库存，
   并连同对象・优先度（按影响度排序）・预期效果・确信度・风险一起提出。
   **预期效果要计算为「该广告活动的CTR（或CVR）恢复到整体平均时的增量点击数・增量订单数」，并并记依据的算式**（不要写推测值）。
   **确信度要根据clicks数与不足率的大小，机械地给出高／中／低三档**（要写明判定基准）。
   风险中务必包含作为Guardrail KPI的**ACoS恶化容许上限{{ACoS上限（例: 现状比+5个百分点）}}**。
4. 执行方式 — 出价调整要在用户确认并批准提案之后才反映，商品页课题则作为向商品目录负责人的确认请求（本提示词不执行变更）
5. 测量 — 使用「举措的效果测定」，在{{评估日（例: 实施4周后）}}**用与本提示词相同的数据源・相同的算式**重新取得CTR/CVR以确认改善。
   请并记举措前后的值，以及Guardrail KPI（ACoS）是否在上限之内。
   ⚠ 变更历史API实质上返回空，因此**不能把重新取得的变化断定为举措的效果**。
   举措的实施内容・实施日请由执行者另行记录。

可调整的条件 — 目标期间。

返回内容 — 漏斗阶段 × 广告活动 × 展示 / 点击 / 订单 / CVR / ACoS 的表，以及瓶颈阶段的识别。

设置变更 — 无变更（仅分析）。

下一步 — 若点击阶段偏弱，可考虑诊断商品目录并制定改进方案；若订单阶段偏弱，可考虑调整竞价。

提示词 3: 对比品牌词与通用词的成果

通过活动名称判别品牌词（Brand，含本品牌名的关键词）和通用词（Generic，通用语的关键词），识别成果最佳的 ASIN 组。

使用场景 — 想对比品牌词检索与通用词检索哪个卖得更高效，从而决定发力方向时。

需要准备的信息 — 无（可直接使用）。

请检查所有 SP 广告活动，比较名称中含品牌词的活动
与含通用词的活动，
识别成果（ROAS / ACoS / 销售额）最好的 ASIN 组。

可调整的条件 — 用于比较的指标（ROAS / ACoS / 销售额）。

返回内容 — 品牌词组 vs 通用词组的汇总表，以及 ASIN 级别的业绩排名。

设置变更 — 无变更（仅分析）。

下一步 — 品牌词 / 通用词的判别精度取决于广告活动的命名方式。想提升精度，请在用标签与命名规则给广告分类的提示词 6 中整理好命名规则。

术语补充 — 品牌词是指含本品牌名、面向指名检索的关键词；通用词是指不含品牌名的通用语关键词。

提示词 4: 从 CAC 与 LTV 视角分析亏损原因

将仅看 ACoS 看不出的亏损原因，从 CAC（客户获取成本）/ LTV（客户终身价值）视角分解，并给出改进建议。

使用场景 — 对于 ACoS 偏高的对象，想区分它究竟是单纯的效率恶化，还是对新客获取的投资时。

需要准备的信息 — 目标期间（例: 过去 90 天。为看长期趋势推荐 30 天以上）。

请识别最近 {{目标期间（例: 过去90天）}} 的亏损广告活动 / 亏损 ASIN，
从 CAC / LTV 视角解释原因。
不要只以 ACoS 为轴，请从客户视角给出改进建议。

可调整的条件 — 目标期间。

返回内容 — 亏损广告活动 × CAC / 预计 LTV / 改进建议的表。

设置变更 — 无变更（仅分析、仅建议）。

下一步 — 把改进建议落地到预算、出价时，请在调整预算或调整竞价的审批流程中执行。

术语补充 — LTV 是基于 Picaro 持有的销售历史推算的估值。

模拟预算分配与品牌结构

提示词 5: 制定增加品牌新客的预算追加分配方案

为增加新客（NTB, New-to-Brand），给出追加预算的分配方案。

使用场景 — 想把追加预算投向新客获取，而非收割既有客户时。

需要准备的信息 — 追加的预算金额（例: ¥500,000）。

请给出在广告预算追加{{追加预算（例: ¥500,000）}}的情况下、使NTB（新客）增长最大化的分配方案。
目的: 把追加预算分配给NTB获取效率高的广告活动，使新客获取最大化。
对象: {{目标广告类型（例: 仅SP）}}中正在投放的广告活动。

【步骤0｜先判定预算是否真的构成制约（必须・不可省略）】
- 用 start_existing_sp_campaigns_job → get_mcp_job_status → get_mcp_job_result 取得投放中广告活动的 dailyBudget 与期间 spend（同步版的 list_existing_sp_campaigns 响应过大可能失败）。
  若按广告组合粒度的粗略判定就够，也可以用 get_portfolio_budget_summary，但那样要注意下述分母・分子的不对称（spend 是全部 state 的合计，daily_budget_sum 仅为 ENABLED）。
- 不要直接使用响应的 budgetUtilizationRate。 它是「期间spend ÷ 1天份的dailyBudget」，会按期间天数成倍膨胀。务必自己计算 真实消耗率 = 期间spend ÷ (dailyBudget × 期间天数)，并明示分子・分母・天数。dailyBudget=0 的行会缺少该键，不要读成0。
  🔴 不要看错膨胀的规模。 实测中31天的窗口下工具返回了「消耗率2694%」「1288%」「1015%」这样的值，除以天数后分别是 86.9% / 41.5% / 32.7%。归一化之前的值即使超过100%也毫无意义。
- 若真实消耗率在{{视为制约的消耗率（例: 80%）}}以上的广告活动1件都没有，说明预算并不构成制约。这种情况下不要做分配表，而应结论为「追加预算不会增加NTB。瓶颈在出价・定向・曝光」，并给出账户整体的真实消耗率（带分子・分母・天数）后结束。

【步骤1｜NTB效率的实测（仅在步骤0判定为存在制约时）】
- 使用 get_amc_metric(metric_name="campaign_attribution")。其中按 campaign_id 持有 ntb_purchases 与 total_spend，可以计算 实测NTB CAC = total_spend ÷ ntb_purchases。
- 🔴 务必传入 max_rows_per_table。 省略的话只会返回开头几行的样本并带 truncated: true。要并列全部广告活动的NTB CAC必须取得全部行。请传入大于等于 tables[].row_count 的值，并确认变为 truncated: false 之后再聚合。不要只凭样本排序。
- 🔴 件数请使用 tables[].row_count（所选run的行数）。 metadata.tables.*.list_row_count 是横跨全部run的件数，实测中约为前者的10倍。不要把这两者混为一谈。
- 不要使用 get_amc_new_customer（只有品牌×月度、没有广告活动维度，无法用于分配）。
- 不要把 get_amc_ntb_by_asin 作为分配依据（存在按广告类型 ad_spend 全行为0的已知缺陷。total_dsp_spend 也是未经摊分的常数）。
- campaign_attribution 的窗口是固定的长期累计。务必写明返回的 report_start_date / report_end_date，不要与最近实绩混淆（实测中是约2年份的累计，数周的变化会被完全淹没）。
- 步骤0的投放中广告活动里没有AMC行的，作为「无法算出NTB CAC」排除，并明示排除件数。广告花费为0的广告类型同样排除在比较对象之外（不要把0解读为「零广告花费也能获取新客」）。
- 🔴 campaign_attribution 包含DSP行。 若要按{{目标广告类型}}筛选，请用 ad_product_type 选别行，并写明排除的广告类型与件数。DSP与SP的NTB CAC可能相差一个数量级，混在一起排列时要按行并记广告类型。

【步骤2｜分配方案】
- 只把真实消耗率达到制约水平的广告活动作为分配候选。
- 用表并记 广告活动 × 当前日预算 × 真实消耗率 × 分配额 × 实测NTB CAC × ACoS实绩，并按实测NTB CAC从低到高排列。
- 不要把「预计NTB增长数」作为确定值给出。 能够推定每追加1日元带来多少NTB增长的数据（边际CAC・预算弹性・预算导致的机会损失展示份额）在MCP中并不存在。用过去的平均NTB CAC去除追加预算，会把增长数高报一个数量级。仅在确实需要数值时，写明「假定实测NTB CAC等于边际CAC时的上限值」，并务必附上这是假定、以及在指名/Branded面上并不成立。

【Guardrail】
- 不要把现有广告活动的日预算削减到当前日预算额的{{下限（例: 80%）}}以下（是相对日预算额的比率，不是消耗率）。
- ACoS不得超过{{基准期间（例: 最近30天）}}实绩的{{上限（例: +3pt）}}。ACoS会因取得来源而有偏离，请把取得来源固定为一个并写明。
- 对于 check_budget_status 为 unconfigured、或广告组合为 NO_CAP 的账户，请写明由CAP引起的制约不在判定对象之内。
  🔴 unconfigured 时 check_budget_status 不仅 cap、连 ad_spend 也返回 null（实测）。不要把这个工具作为广告花费的取得来源。

【输出・批准】
- 请给出变更内容的一览（广告活动・当前日预算・变更后日预算・差额・实测NTB CAC・ACoS），在获得批准之前不向媒体反映。
- 不要把预算的差额合计作为效果金额呈现。optimize_budget 的 items 中只有 id / label / current_value / recommended_value / reason，并不存在 spend / sales / estimated_impact（已实测确认）。差额不是效果。
- 并用 optimize_budget 时要显式传入 target_acos（不指定会硬报错、不会生成 proposal）。响应的 target_acos_goal_resolution 中会记录传入的值与 source，请在输出中引用它。但该工具没有NTB维度，且增减判定基于上述膨胀的消耗率，因此不要作为NTB最大化的依据。
  🔴 而且该工具无法筛选为{{目标广告类型}}（实测中返回了 SP / SB / SBV / SD 混在一起的结果），还会把名称以 old_ 开头的退役广告活动作为「建议增额」提出（实测2件）。不要把提案原样罗列。生成的 proposal 若未获批准，务必 cancel。

【执行后】
- 提案内容要在用户确认并批准之后反映，并在{{评估日（例: 4周后）}}用「举措的效果测定」重新评估。
- 可用于重新评估的是 campaign_attribution_monthly（campaign_id×月度的NTB）与广告侧的ACoS。请在评估设计时写明: 该表没有 spend 列，因此无法做NTB CAC的前后比较（实测确认: 返回的只有 purchase_uv / ntb_uv / repeat_uv / total_purchases / ntb_purchases / repeat_purchases / product_sales），而持有 spend 的 campaign_attribution 是长期累计窗口，数周的变化会被淹没。
- 🔴 用 campaign_id 结合两张表是可以的，但广告类型的列名与值的写法不同。campaign_attribution 是 ad_product_type（实测值: SPONSORED_PRODUCTS / DSP），campaign_attribution_monthly 是 ad_type（实测值: sponsored_products / DSP）。不要用字符串完全一致来结合（大小写并不统一）。
- get_change_history 有时不返回变更历史，因此实施内容要另行记录（登记到 manage_measure 的举措日志中较为妥当）。
- 判定请从 Keep/Expand/Adjust/Pause/Revert/Investigate 中选择。

【数据边界】
- 当日尚未导入（fully_missed），指定期间会被无警告地缩短1天。期间请截至前一日，并写明实际聚合的天数。
- 不要用 rollup_status 做确定性判定（只要有1个广告类型未投放，整天就会掉成 no_data）。

【执行条件】
- 对于无法取得AMC的 campaign_attribution 的账户，不进行NTB CAC的算出，并写明「因未对应AMC，无法按NTB效率试算分配」。

可调整的条件 — 追加的预算金额。

返回内容 — 分配目标广告活动 × 分配金额 × 实测 NTB CAC（新客获取成本）的表。排列顺序按实测 NTB CAC 从低到高。「预计 NTB 增长数」因为 Picaro 没有边际 CAC・预算弹性的数据，不会作为确定值给出。仅在需要数值时，才会作为「假定实测 NTB CAC 等于边际 CAC 时的上限值」这一带假定的参考值呈现。

设置变更 — 无变更（仅建议）。只生成分配方案，不修改预算。

下一步 — 执行分配时，请在调整预算的审批流程中落实。

提示词 6: 求解现有广告活动内预算追加的最优分配

在现有 SP 广告活动内，模拟追加预算分配到哪里最优。

使用场景 — 不新增广告活动，想在现有广告活动中把追加预算投到最见效的位置时。

需要准备的信息 — 目标品牌名（可选，用于筛选）、追加的预算金额（例: ¥1,000,000）。

目的: 为了把追加预算分配给最有望贡献广告带来销售额的广告活动、改善账户整体的
ROAS，请研究把{{追加预算（例: ¥1,000,000）}}追加到{{目标品牌名（例: ○○品牌）}}
现有广告活动时的分配去向。
请先写明{{追加预算的单位（例: 期间总额 / 日额）}}再计算（Picaro处理的是
日预算，单位变了结论会差一个数量级）。

【对象的确定】
请用 list_accounts 的账户名解析{{目标品牌名}}，之后所有工具调用都要显式传入
account_id。广告活动没有品牌属性，广告组合是按产品线划分的，因此若无法直接按品牌
筛选，请写明「以账户整体为对象」。分配去向中务必排除以下各项，并写明排除件数。
- 🔴 隶属于已结束(ENDED)广告组合的广告活动
  ※ get_portfolio_budget_summary 即使传入 include_ended=false 也会返回 ENDED 行。
    实测中 include_ended=false 返回了8行 ENDED 广告组合，它们 spend=0，但
    daily_budget_sum 与 active_campaign_count 都非零（合计日预算近50万日元・投放中广告活动约50件）。
    不排除的话只有消耗率的分母膨胀，账户整体会被不当地看成「预算还有余力」。
    请确认各行的 status / is_ended 并自行排除。
  ※ 反过来，ENDED 广告组合之中也存在 state=ENABLED 的广告活动（实测确认）。
    仅凭广告活动的 state 无法判定，务必与广告组合一侧的 status 对照。
- {{目标广告类型（例: 仅SP / SP+SB+SD）}}以外的广告类型
  ※ get_portfolio_budget_summary 与 optimize_budget 都不接受广告类型的指定。
    前者声明了 source_contract.ad_type_scope="all_ad_types"，后者在实测中返回了 SP / SB / SBV / SD
    混在一起的结果。想筛选为SP时，请用广告活动粒度的工具选别。
- 🔴 广告活动名中含 old_ 「コピー」的退役广告活动
  ※ optimize_budget 会把它们作为「建议增额」提出（实测中有2件 old_ 广告活动进入了增额建议）。
    不要把工具的提案原样罗列。

【期间与确定数据】
请以{{目标期间（例: 最近30天）}}聚合。聚合前先用 get_data_ingestion_status 确认
确定状况，若有未确定日（fully_missed 等）请排除，并明示实际数据有多少天。
即使指定了「30天」，实际也可能只有29天。
不要用 rollup_status 做确定性判定（只要有1个广告类型未投放，整天就会掉成
no_data）。请查看各报告的 status。

【确认预算制约是否真实存在 — 最先必须做的事】
「追加预算的分配去向」只有在现有广告活动被日预算顶住时才存在。
请先按账户・广告组合整体与广告活动粒度，给出 归一化日预算消耗率。

    归一化日预算消耗率 = 期间广告花费 ÷ (日预算 × 实际数据天数)

- 务必明示分子・分母・天数。
- 工具返回的消耗率(budgetUtilizationRate 或 optimize_budget 的「消耗率」)，
  在窗口为2天以上时并没有除以天数，会按天数成倍膨胀。请不要直接使用。
  务必用上式自己重新计算。
  🔴 膨胀的规模: 实测中31天的窗口下工具返回了「消耗率2694%」「1288%」「1015%」，
     除以天数后分别是 86.9% / 41.5% / 32.7%。在同一次实测中，工具判定为「预算不足」的
     35个广告活动里，归一化之后达到100%的一个也没有。
- 🔴 使用 get_portfolio_budget_summary 时，请注意分子与分母的母集团不同。
  正如 source_contract 所声明的，spend_scope="all_states"（全部state的实际支出合计）对应的是
  control_scope="ENABLED_only"（daily_budget_sum 与 active_campaign_count 仅为 ENABLED）。
  这种不对称会使消耗率系统性地偏高。请写明使用了哪一个母集团，
  若用于判定有无制约，请把它读作「偏高之后才是这个值」。
- 使用 optimize_budget 时请显式传入 target_acos
  （在未设置的账户上不指定会硬报错）。响应的
  target_acos_goal_resolution 中会记录传入的值与 source，请在输出中引用它。
- 若归一化消耗率在任何广告活动上都足够低（例: 大致低于{{视为预算制约的消耗率下限（例: 70%）}}），
  请结论为「预算并不构成制约，因此没有追加预算的分配去向」，
  并把制约究竟在出价・定向覆盖・库存的哪一处作为下一步行动提出。
  不要硬造分配去向。
- CAP（月度上限）造成的制约是另一套体系。若 check_budget_status 为 unconfigured、或
  广告组合全部为 NO_CAP（cap_amount 0），请写明由CAP引起的制约不在判定对象之内。
  unconfigured 时 check_budget_status 不仅 cap、连 ad_spend 也返回 null，
  因此不要把这个工具作为广告花费的取得来源。

【分配去向的抽取（仅在预算制约真实存在时）】
请以 归一化消耗率高（被预算顶住）× ACoS低 × 实绩ROAS高 这3个条件抽取广告活动。
展示份额在广告活动粒度上无法取得
（只有定向粒度的IS%，且不返回按定向的展示数，因此也无法做加权汇总）。
若要把IS作为判断材料，请写明它是定向粒度的值、且并未汇总。

【呈现】
请按 Impact 顺序给出 广告活动 × 推荐分配额 × 最近实绩ROAS（广告带来的销售额÷广告花费）。
请严格遵守以下各点。
- 不要把预算的增减差额当作效果金额・销售额增长额・腾挪出的金额。
  在实际支出本来就远低于日预算的情况下，即使下调日预算，实际削减额也是¥0。
  已实测确认 optimize_budget 的 items 中不存在 spend / sales / estimated_impact。
- 针对追加预算的预期效果金额・边际ROAS无法从Picaro取得。 请写明实绩ROAS是
  过去实绩、并不是针对追加预算的边际ROAS，不要把推定值当作确定值。
- 请遵守「因为Picaro不持有利润指标，所以不用ROI，而用ROAS或广告贡献额来计算」。

【Guardrail】
- 请先算出并写明当前账户整体的ACoS（并记取得来源的工具名。
  取得来源不同会有几个百分点的偏离）。
- 请使分配之后账户整体的ACoS不超过{{ACoS上限（例: 20%）}}。
- 但若当前ACoS已经超过上限，不要全盘否决提案，
  而是把实效门槛切换为「不使当前ACoS恶化」，并并记与上限的偏离。
- 不要削减现有高ROAS广告活动的预算。

【执行与测量】
提案请在批准之后反映（不要自动执行）。预算变更与出价变更是
不同体系，请使用预算反映用的审批流程。若为了验证而用 optimize_budget
生成了 proposal，未获批准的务必 cancel。
反映{{到测量为止的天数（例: 7天）}}之后重新取得ACoS与ROAS，改善则建议Keep，
恶化则建议Revert。重新取得时同样要明示比率的分子・分母・天数，
并排除未确定日。

可调整的条件 — 目标品牌名 / 追加的预算金额。

返回内容 — 广告活动 × 推荐分配额 × 最近实绩 ROAS（广告带来的销售额 ÷ 广告费）的表。由于 Picaro 不持有利润指标，不会用 ROI 计算。会写明不把差额当作效果金额・销售额增长额，以及实绩 ROAS 是过去实绩、并不是针对追加预算的边际 ROAS。

设置变更 — 无变更（仅建议）。只生成分配方案，不修改预算。

下一步 — 执行分配时，请在调整预算的审批流程中落实。

提示词 7: 分析预算未消化的原因

解释为什么投资组合或广告活动未按计划消化预算。

使用场景 — 明明预留了预算却用不完，想区分原因时。

需要准备的信息 — 目标品牌名、目标投资组合名（未指定则为全部）。

请解释 {{目标品牌名（例: ○○品牌）}} 的 {{目标投资组合名（例: ○○投资组合）}} 未按计划
消化预算的原因。请分别列出原因（出价偏低 / 展示份额不足 / 匹配类型收得太紧 等）。

可调整的条件 — 目标品牌名 / 目标投资组合名。

返回内容 — 未消化广告活动 × 预计原因（出价高低 / 展示份额 / 匹配类型 / 竞争激烈度）× 应对方针的表。

设置变更 — 无变更（仅分析）。

下一步 — 若原因在出价，请用调整竞价；若原因在预算额度，请在调整预算的审批流程中应对。

提示词 8: 按搜索漏斗制定活动前后的预算分配方案

针对促销等活动事件的前后，按搜索漏斗（调研 / 比较 / 即将购买）制定预热前后的预算分配方案。

使用场景 — 为促销预备，想从事前认知打造到当日收割改变预算的投放方式时。

需要准备的信息 — 目标品牌名、活动日期（例: 2026-07-15）。

请针对{{目标品牌名（例: ○○品牌）}}在{{活动日期（例: 2026-07-15）}}的促销／折扣，按预热期／活动期／后续期这3个区间制定SP预算分配方案。
目的: 配合活动前后的需求波动优化SP预算分配，防止机会损失。
对象: 该品牌的全部SP广告活动。但仅以 state=ENABLED 为对象，请排除 PAUSED／ARCHIVED、以及广告活动名中含「コピー」「old_」的，并在输出中写明排除件数。
※ 🔴 即使 state=ENABLED，该广告活动所属的广告组合也可能是 ENDED（实测确认）。请不要只看广告活动的 state，还要与 get_portfolio_budget_summary 的 status / is_ended 对照后排除。

■区间的确定方法
1. 先用 action=list 调用 manage_event（仅读取，不做登记・更新），找出包含{{活动日期（例: 2026-07-15）}}、或以该日为开始日的活动。活动不是单日，而是持有 date 与 end_date 的期间。找到时取「活动期 = date〜end_date」，找不到时把活动期当作{{活动日期（例: 2026-07-15）}}这1天，并写明该情况。
2. 预热期 = 活动开始日的前{{天数（例: 7天）}}〜开始日的前一日。后续期 = 活动结束日的次日〜之后{{天数（例: 3天）}}。
3. 请在同一份 manage_event 的一览中，确认预热期・后续期是否与其他已登记活动（先行促销等）重叠。若重叠，请务必在输出中写明是排除这些日期，还是保持重叠继续使用。
   🔴 重叠不是例外而是常态。 大型促销通常会把「先行促销」与「主体」连续登记（实测确认），因此若把主体的开始日取作活动日，预热期几乎必然会侵入先行促销。这种情况下请写明「预热期中有◯天属于先行促销期间，不能当作平时的预热期来读」，并选择排除还是另切一个区间，并写出理由。
4. 请务必在输出中写出各区间的日期范围与实际天数。

■确定数据的处理
- 请以目标期间调用 get_data_ingestion_status，把 status 为 fully_missed 的日期从各区间中排除。未确定日会无警告地返回0填充的行，包含进来会被误读为「活动后投放停止了」。
- 不要用 rollup_status 做确定性判定。只要有1个广告类型未投放，整天就会变成 no_data。请查看各报告的 status。
- 请写明排除的天数，以及排除之后各区间的已确定实际天数。

■区间比较的规则
- 由于各区间长度不一致，请把所有金额・件数都归一化为「每天」之后再比较（区间合计 ÷ 该区间的已确定实际天数）。
- 每次给出比率时，都要明示分子・分母・天数。
- 不要把原始区间合计之间的比较放进输出。归一化与否会使增减的符号反转。

■代理指标
「搜索漏斗」是Picaro中不存在的字段，因此请把 品牌KW／通用KW／ASIN定向 的区分作为代理指标，在各区间改变其比重（例: 预热期提高通用词比例，活动期强化品牌KW）。取得步骤如下。
- 请用 name_filter 按区分分别调用 list_existing_sp_campaigns，确认 coverage_complete 与 be_total_results，以保证已全量扫描母集团。响应中会返回 matched_count / scanned_campaign_count / be_total_results / coverage_complete / pages_fetched。
  🔴 name_filter 的结果中包含 PAUSED / ARCHIVED（实测中18件里有3件是 PAUSED）。请查看各行的 state 自行排除，并写明排除件数。
  🔴 广告活动名的分隔符存在半角 | 与全角 ｜ 混用的情况（实测确认）。name_filter 本身会用 NFKC 归一化把两者都捞到，但若要自己切分广告活动名来判定区分，请把两种分隔符都处理。 只用其中一种切分的话，一部分广告活动会掉进「未分类」。
- 请把取得的 campaign_id 传给 analyze_ad_type_performance 的 campaign_ids，指定 campaign_types=["SP"] 与各区间的 period_start／period_end，按区间聚合。
- 🔴 不要使用 analyze_label_kpi。 标签维度（competitor／generic／branded）是SaaS正本，但 frequency 只有 weekly／monthly，切不出1天或3天的区间。
  实测中的行为: 指定4天（到4/13为止）调用时，响应的 period 原样回显了所请求的4天，数值却返回了相当于当月整体广告花费约45%的规模（相当于数周）。既没有警告，回显的期间也与请求一致，因此没有办法从响应中察觉这种吸附。 不可用于区间分析。
  另外也已实测确认，标签维度中并不存在 ASIN 定向的区分。所以才用广告活动名作为代理指标。
- 对于不遵循命名规则的广告活动（Catch All、Category、AUTO 等），请作为「未分类」另行列出，并务必在输出中写明未分类的广告花费占比。这个比例越大，代理指标的可信度越低。
- 请在输出中写明它是代理指标，且其依据是广告活动名（运营者的命名），而不是SaaS的标签正本。

■输出
- 请用 区间 × 区分 的矩阵，给出 已确定实际天数・每天广告花费・每天广告带来的销售额・ACoS・广告花费占比。
- 请并记各区间的预计预算分配比率（按区分・合计100%），并写出相对当前比率的增减pt。
- 请给出变更内容的一览（区间・广告活动・现行日预算・建议日预算・差额）。但不要把差额作为效果金额・腾挪出的金额呈现（在实际支出远低于日预算的情况下，即使下调日预算，实际削减额也是¥0）。

■Guardrail
- 平时基线 = 在 manage_event 的一览中与已登记活动一天也不重叠的、最近连续{{天数（例: 7天）}}，并请把自动确定的期间写进输出（若用户指定了期间则以用户指定为准）。请在已确定日的范围内选择。
- 请把ACoS的取得来源固定为一个（默认: analyze_ad_type_performance 的 campaign_types=["SP"]）。同一期间也会因取得来源不同而差几个百分点，请不要混用，并在输出中写明所使用的取得来源。
- 请在账户整体的ACoS不超过平时比{{上限（例: +5pt）}}（百分点）的范围内分配。请在输出中写明这个上限是相对上面固定的取得来源・平时期间的ACoS的加算。

执行前务必: 请给出变更内容的一览（区间・广告活动・分配额），在获得批准之前不向媒体反映。本提示词只到给出分配方案为止，不进行预算的写入。
执行后: 提案内容要在用户确认并批准之后反映，并使用「举措的效果测定」在各区间结束后取得ACoS与广告带来的销售额，若未达目标则Adjust下一区间的分配。

执行条件
- 各区间的天数可根据活动特性调整，调整后请写明该天数
- 若把 optimize_budget 作为分配依据，务必指定 target_acos（不指定会报错、不会生成提案）。该工具包含SB／SD／SBV，无法筛选为SP（根本不存在广告类型的参数），且消耗率会随期间长度成比例膨胀，因此不要直接引用消耗率，请归一化为「区间合计 ÷（日预算 × 已确定实际天数）」后再使用
  🔴 而且该工具会把名称以 old_ 开头的退役广告活动作为「建议增额」提出（实测2件）。请按上面的排除规则剔除。生成的 proposal 若未获批准，务必 cancel

可调整的条件 — 目标品牌名／活动日期／预热期・后续期的天数／ACoS 上限。

返回内容 — 区间（预热期 / 活动期 / 后续期）× 区分（品牌 KW / 通用 KW / ASIN 定向）的矩阵表。由于「搜索漏斗」是 Picaro 中不存在的字段，会写明使用这个区分作为代理指标。

设置变更 — 无变更（仅建议）。只生成分配方案，不修改预算。

下一步 — 执行分配请用调整预算，作为施策记录时请用记录施策与外部事件并验证效果。

按 ASIN 分析收益与成果

提示词 9: 按 ASIN 计算广告贡献额

将 SP 广告的销售额减去广告费，计算每笔订单的广告贡献额。

使用场景 — 想按 ASIN 查看广告的贡献度，决定发力商品和收缩商品时。

需要准备的信息 — 目标期间（已确定的日历月。例: 2026-07）。

目的: 可视化按ASIN的广告贡献度，用于投资分配的纠偏判断。

数据源（固定・不变更）
- 按ASIN的广告来源销售额・广告花费，以 `get_amc_ntb_by_asin`（AMC NTB by ASIN）为唯一来源。用 `max_rows=5000` 全量取得最新run，并把 `returned_row_count / selected_row_count` 作为覆盖率写进正文。
- 只以 `ad_product_type == "sponsored_products"` 的行为对象。该工具的DSP行与 sponsored_brands 行的 `ad_spend` 全行为0，直接计算贡献额会被误读为「零广告花费也卖出去了」，因此务必排除。
- `list_top_asins_by_metric` 是「广告命中的定向ASIN」维度，并不是自家商品的母集团（其他品牌的ASIN会混在前列）。不要用于本分析。
- 不要与 get_dashboard / analyze_ad_type_performance 等其他工具的销售额・广告花费混用。

目标期间: {{目标日历月（例: 2026-07）}}
- 这个数据源的最小粒度是日历月（`report_month`），切不出「过去30天」这类任意窗口。指定时务必使用已确定的日历月。
- 若响应的 `report_end_date` 早于目标月的月末，说明该月尚未确定，请不要作为对象，改用上一个已确定的日历月并写明该情况。

前处理
- `asin == "below_reporting_floor"` 的行是混在与实际ASIN相同的 `asin` 列中的聚合行，请排除，并写明排除掉的金额占目标月SP广告来源销售额的百分之多少。
- `ad_spend == 0` 的行不是「广告花费为零」，而应作为缺测处理，不要算出贡献额，并写明件数。

算出: 请按ASIN算出「广告来源销售额（attributed_revenue）－广告花费（ad_spend）＝广告贡献额」与「每笔订单的广告贡献额（广告贡献额 ÷ total_purchases）」（并写明这不是实际利润，而是广告贡献额）。

分析: 请把广告贡献额为负的ASIN，按广告花费从大到小最多抽取10件。同时给出负值ASIN的合计广告花费・合计贡献额，以及它们在目标月SP广告花费中所占的比例。

最后请输出以下3点。
1. 推荐行动 — 广告贡献额为负的ASIN作为下调出价或缩减预算的候选。但同一数据源・同一期间的广告来源销售额（attributed_revenue）前10%的ASIN要从缩减候选中排除（因为账户整体的总销售额排名无法按ASIN全量列举，护栏的母集团固定在本数据源之内）
2. 执行方式 — 提案要在用户确认并批准之后反映（本提示词不执行）
3. 测量 — 使用「举措的效果测定」，在下一个已确定日历月用相同步骤重新取得广告贡献额，改善则判断Keep，恶化则判断Revert（因为不存在ASIN维度的日次・周次数据源，所以不是7天后，而是按日历月周期来测量）

执行条件
- 「广告贡献额」不是毛利・利润。不要与含成本和亚马逊费用的实际利润混淆
- 本数据源的广告来源销售额是AMC的洁净室聚合，与广告活动粒度工具的广告销售额在母集团与归因上都不同。不要把两者的金额并列或谈论其差值

可调整的条件 — 目标日历月。

返回内容 — 广告贡献额为负的 ASIN 前 10 件 × 广告费 × 广告贡献额 × 每笔订单广告贡献额的表。数据源固定为 AMC 的 get_amc_ntb_by_asin（仅 Sponsored Products 行）。

设置变更 — 无变更（仅分析）。

下一步 — 对缩减候选的应对请用调整预算或调整竞价，贡献额偏低商品的详情页改进请用诊断商品目录并制定改进方案。

术语补充 — 「广告贡献额」不是毛利・利润。请不要与含成本和亚马逊费用的实际利润混淆。它是不计入成本率・毛利的、相对广告花费的销售贡献参考指标。

提示词 10: 获取主要 ASIN 的业绩汇总

针对主要 ASIN，以最近已确定的日历周为对象，按 ASIN 汇总取得广告销售额 / 广告费 / 广告销售件数 / ROAS（由于 Picaro 无法取得按 ASIN 的每日数据，这是期间合计的汇总）。

使用场景 — 想把关注的多个商品最近的成果汇总成一览查看时。

需要准备的信息 — 目标 ASIN 列表（例: B0XXXXXXXX, B0YYYYYYYY，可指定多个）、目标期间（最近已确定的日历周。例: 最近 1 周）。

目的: 为了把多个ASIN的广告业绩汇总成一览、及早发现异常ASIN，
请对{{目标ASIN列表（例: B0XXXXXXXX, B0YYYYYYYY）}}以{{目标期间（最近已确定的日历周。例: 最近1周）}}
按1个ASIN 1行汇总 广告销售额／广告花费／广告销售件数／ROAS。

【期间的确定方法 — 务必按这个顺序进行】
1. 用 get_data_ingestion_status 数出未确定日（fully_missed），确定已确定的最后一天。
   不看 rollup_status，而看各报告的 status（只要有1个广告类型未投放，整天就会掉成 no_data）。
2. 🔴 这个端点会把期间吸附到日历周。按天的指定是无效的。
   已实测确认: 把 from_date/to_date 错开1天调用2次，全部项目都返回了完全相同的值
   （同一个广告活动的 ads_sales / ads_units / clicks / impressions 连1日元・1件都没有差）。
   而且响应中没有表示实际生效期间的字段，因此无法从响应中察觉这种吸附。
   → 因此对象务必取「最近已确定的日历周」，前一期间取其前一个日历周。
   → 想要确认时的吸附检测方法: 对同一个ASIN把 from/to 错开1天调用2次，
     若数值完全一致，就可以判定「发生了吸附（按天的指定没有生效）」。
3. 用 call_picaro_api 调用 POST /bigquery/sales-ranking（body: {"amazon_account_id": <account_id>,
   "frequency": "weekly"}），在响应的 from_date / to_date 所显示的周范围内
   确认当期・前一期间的周边界。
4. 用于聚合的 from_date 务必是周日，to_date 务必是周六。
   传入未对齐周边界的期间，会被吸附到相近的周，或者无警告地把多个日历周合算。
   务必把实际使用的日期与天数写进输出。

【取得方法】
- 对每个ASIN用 call_picaro_api 调用 POST /product-analysis/product-detail/ad
  （body: {"amazon_account_id": <account_id>, "from_date": "<当期的周日>",
  "to_date": "<当期的周六>", "code": "<ASIN>", "type": "asin"}），
  从响应的 total 取 ads_sales / ads_spend / ads_units / roas。
- 前一期间用同样的调用，取前一周的周日〜周六。
- 没有批量取得的入口，请按ASIN逐个调用。
- 🔴 total 是「所返回页面内的合计」，并不是整体合计。
  已实测确认: 把 page_size 设为1调用时，total_count 仍是17，
  total 却只是开头1个广告活动的值（约为整体的四分之一）。
  → 不指定 page_size（默认20），或者设为 total_count 以上，用1页取完。
  → 在读 total 之前，务必确认 pagination.total_count 与 items 的件数一致，
     并把两者都写进输出。不一致时不要使用 total。
- 「销售额」为了与ROAS的分子对齐，使用广告销售额（ads_sales），不要与总销售额混淆。
- 🔴 在这个端点上 purchases 与 ads_units 在全部行都是同值（已实测确认全部广告活动）。
  也就是说这里取到的是销售件数而不是订单数，因此输出的列名要用「广告销售件数」，
  不要写成「广告订单数」。cvr 也是 ads_units ÷ clicks，同样是销售件数口径。
- 响应的数值全部以带格式的字符串（"¥1,691,946" / "733" / "112.8%"）返回。
  做四则运算前请去掉 ¥ ・逗号・%，不要以字符串状态排序。

【异常判定】
- 与上一周比较，请标记ROAS的相对变化率在{{ROAS恶化的阈值（相对变化率・例: -20%）}}
  以下的ASIN。
- 相对变化率 =（当期ROAS − 前期ROAS）÷ 前期ROAS，务必自己计算。
  工具返回的 change_percentage 是「百分点之差」却带着 "%" 显示，
  不得直接用于阈值判定。
- ROAS 栏是百分比表示（实测: "112.8%"）而不是倍率，请对齐分母・分子之后再比。
- 每次给出比率时，都要明示分子・分母・对象天数。

【缺失的处理】
- 不存在的ASIN，以及实际存在但没有广告投放的ASIN，两者都会以0件（全部项目 "--"）
  返回，既不报错也不警告。
- 请务必核对输入的ASIN件数与取得到值的行数，把未能取得的ASIN
  作为「无数据（无法判别是实绩0还是不在对象内）」另行列出。件数对不上时
  不要就此确定一览。
- ※ 若需要确认ASIN是否实际存在，可另行用SKU反查工具或商品一览（child-asin）
  确认有无登记。连这里也查不到的ASIN，请作为「未登记」分开写。

【输出】
- 1个ASIN 1行的表（广告销售额／广告花费／广告销售件数／ROAS当期／ROAS前期／相对变化率）
- 聚合所使用的当期・前期的实际日期与天数，以及两个期间的周长度相同
- 各ASIN的 pagination.total_count 与 items 件数（可以使用 total 的依据）
- 被标记的ASIN一览（0件则写明）
- 未能取得的ASIN一览

被标记的ASIN请作为「原因诊断」的详细分析对象。
下次在对象周确定之后重新聚合，确认被标记ASIN的ROAS是否改善。
即使是已确定期间，数值也可能因重新导入而变化，因此与上次不同并不能仅凭这一点断定为故障。

可调整的条件 — 目标 ASIN 列表／目标期间／视为 ROAS 恶化的阈值。

返回内容 — ASIN × 广告销售额 / 广告费 / 广告销售件数 / ROAS（当期・前期・相对变化率）的一览表，以及环比恶化的 ASIN 标记。由于目标期间会被吸附到日历周，无法按天任意指定。

设置变更 — 无变更（仅分析）。

下一步 — 想查看每日的整体 KPI 时，请用在仪表盘确认 KPI。

提示词 11: 识别点击率高但购买率低的 ASIN

识别 CTR（点击率）高但 CVR（购买率）低的 ASIN（广告吸引力强但在商品页流失的情况）。

使用场景 — 想找出广告能带来点击却不转化成销售的商品，从而决定商品页改进的优先级时。

需要准备的信息 — 目标期间（例: 过去 30 天）。

目的: 锁定广告点击获取能力强、却没有走到购买的ASIN，为商品目录的改进排定优先级。

数据源（固定为1个。不与其他数据源混用）
- 按ASIN的 impressions / clicks / ads_units / ads_spend / purchases / sessions / glance_views /
  stock_status / sellable_inventory / buy_box_percentage / org_cvr / ads_cvr
  从 call_picaro_api 的 POST /product-analysis/product-list/child-asin 取得。
  body: {amazon_account_id, product_line_id: 0（0 = 全部产品线。省略或传其他值只会返回部分产品线）,
         from_date, to_date, frequency: "daily", page, page_size: 40}
  ※ page_size 调大时响应会在80KB处被无警告截断。请用 page_size=40 取得到 total_pages 为止的全部页。
  ※ 响应的 pagination 中含 page / page_size / total_count / total_pages。请把 total_count 用作对象ASIN数的分母。
- 🔴 数值全部以带格式的字符串返回。 例: "¥59,959,000" / "25,000" / "35.9%" / "0.66%"。
  做四则运算前请去掉 ¥ ・逗号・%，"--" 作为 null（不是零）处理。
  例外是 sellable_inventory / sku_quantity 为原始数值。不要以字符串状态比较・排序。
- 账户平均使用同一响应中的 total 区块（不要自己重新计算平均）。
- 覆盖性的核算: 请确认全部页的 impressions / clicks / ads_spend 合计与 total 一致，并写明一致率。
  不一致时作为取得遗漏报告。

期间
- {{目标期间（例: 过去30天）}}。但不要把天数写死。
- 请先调用 get_data_ingestion_status，把 status 为 completed 的最后一天作为确定日。
  fully_missed / in_progress 的日期不纳入窗口（纳入的话窗口会被无警告地缩短、广告花费会偏少）。
  不要用 rollup_status 做确定性判定（只要有1个广告类型未投放，整天就会掉成 no_data）。请查看各报告的 status。
- 务必把实际聚合的开始日・结束日・天数写进输出。

指标的定义（不使用此定义以外的口径。全部用同一响应内的字段组成）
- CTR = clicks ÷ impressions（要核算与响应的 ctr 一致）
- 广告CVR（销售件数口径）= ads_units ÷ clicks（与响应的 ads_cvr 同义）
  ⚠ 这是「销售件数 ÷ 点击」而不是订单数口径。1笔订单卖出多件时，会比实际的订单口径CVR偏高。
  输出中务必写明「销售件数口径・广告归因」。
- 整体CVR（销售件数口径）= total_units_sold ÷ glance_views（与响应的 cvr 同义）
- 🔴 整体CVR（订单口径）= purchases ÷ glance_views — 这个是可以取得的。
  purchases 是订单数（自然＋广告的合计），total_units_sold 是销售件数。两者在同一行返回。
  分母为了与工具自身的 cvr 对齐而使用 glance_views，账户平均也用 total 区块的
  purchases ÷ glance_views 以相同算式算出（用 sessions 作分母会得到另一个值，不要混淆）。
  ※ 订单口径的「广告归因」CVR无法取得（没有与 ads_units 对应的 ads_purchases 之类的字段）。
    请划清界限: 「广告的转化」看销售件数口径，「商品・商品目录的转化」看订单口径。
- 请按指标在表的列名中写明用的是上述哪一个定义。不要把定义不同的CVR混进同一列。

母集团与最小样本
- impressions 为 "--"（null）的行不是「没有广告实绩」，而是「没有数据」。请与0区分，从母集团中排除并写明件数。
- impressions = 0 的行是未投放。CTR/CVR 不是0%，而应作为「无法算出」排除。
- 为了剔除统计上无意义的行，只把满足 impressions ≥ {{最小impressions（例: 10000）}} 且 clicks ≥ {{最小clicks（例: 200）}}
  的行作为判定对象。务必并记排除的行数，以及若不排除本会命中的行。

抽取条件（把{{阈值}}的含义唯一固定下来）
- CTR > 账户平均CTR，且
- 广告CVR（销售件数口径）≤ 账户平均广告CVR × {{阈值（例: 50%）}}
  ※ 不做「CVR后{{阈值}}」这种基于排名的解读。请把阈值的实际数值（账户平均CVR × 阈值）写进输出。
- 抽取之后，请对每一件并记订单口径的整体CVR，确认它是否与销售件数口径朝同一方向偏低。
  方向不同时，请写明可能是「每笔订单购买件数不同造成的表面差异」。

原因的切分（能取得的就不要当作假设）
- 库存: 把 stock_status / sellable_inventory 与 get_fba_inventory 核对。
  ⚠ get_fba_inventory 是当前时点的快照（coveragePeriod 为最近1周），
    无法证明目标期间内一直有库存。只写到「当前有库存」为止。
- 价格竞争力: 务必给出 buy_box_percentage。不足100%时，作为「价格/购物车获取的问题」基于事实指出
  （这不是假设）。但实测中大多数ASIN都贴在99%上下，请用与账户平均（total 区块）
  的差来评估，不要把几个百分点的差夸大为主因。
- 商品目录还是广告定向的切分: 请并记 org_cvr（自然CVR）。
  若 org_cvr 也大幅低于账户平均，则作为商品・商品目录一侧的问题；
  若 org_cvr 正常而只有广告CVR低，则作为广告定向一侧的问题来区分。
  ※ org_cvr = org_units ÷ org_click，这同样是销售件数口径。与广告CVR基准相同，可以直接比较。
- 图片/评论正文无法取得，因此请写明是「假设」，不要断定为事实。

输出
- 按广告花费投入额从大到小最多5件。符合的不足5件时就只给出那个件数，并写明「符合◯件」。0件就写0件（不要凑数）。
- 每一件要给出: ASIN / 商品名 / CTR / 账户平均CTR / 广告CVR（销售件数）/ 账户平均 /
  阈值实数 / 整体CVR（订单口径）/ impressions / clicks / ads_units / purchases / 广告花费 /
  库存 / buy_box_percentage / org_cvr。
- 每次给出比率时，都要并记分子・分母・聚合天数・母集团的覆盖率。

最后请输出以下3点。
1. 推荐行动 — 因缺货导致的立即处理，buy_box 下降作为价格・购物车因素提出纠正请求，
   其余作为向商品目录负责人的确认请求
2. 执行方式 — 广告侧的停止・出价变更要在用户确认并批准之后才反映，
   商品目录课题则作为向负责部门的确认请求
3. 测量 — 使用「举措的效果测定」，在处理7天后用相同数据源・相同定义重新取得CVR以确认改善

执行条件
- 图片/评论是假设，不要断定为事实
- CVR 每次都必须写明口径（销售件数 / 订单）与归因（仅广告 / 整体）两者
- 未能取得的行・排除的行务必以件数披露（不要把0件与未取得混为一谈）
- 即使是已确定期间，数值也可能因重新导入而变化。重新测量时数值不同，不能仅凭这一点断定为改善/恶化

可调整的条件 — 目标期间／CVR 判定的阈值。

返回内容 — ASIN × CTR × 广告 CVR（销售件数口径）× 与账户平均比 × 整体 CVR（订单口径）× 库存 × buy_box_percentage × org_cvr 的表（按广告费从大到小最多 5 件）。库存・价格竞争力用实际数据确认，图片・评论会写明是「假设」以与事实区分。

设置变更 — 无变更（仅分析）。

下一步 — 商品页改进的优先级排序可用诊断商品目录并制定改进方案，库存确认可用管理库存与销售机会。

提示词 12: 把恶化指标的原因切分为 6 个要因

在已知目标广告活动・广告组合与恶化指标的情况下，把原因切分为检索词 / 出价 / CPC / CVR / 预算 / 广告位这 6 个分类，并按贡献度从高到低排出应对优先级。提示词 4「从 CAC 与 LTV 视角分析亏损原因」用于尚未锁定问题所在、需要先找出对象本身的场景，而本提示词用于对象与恶化指标已经明确、需要切分为什么会恶化的场景。

使用场景 — 已知特定广告活动・广告组合的指标出现恶化，但想切分出检索词・出价・CPC・CVR・预算・广告位中哪个是主因时。

需要准备的信息 — 目标广告活动・广告组合。恶化的指标（例：ACoS 环比上周恶化 +5pt）。分析期间（例：过去 14 天）。

{{目标广告活动・广告组合（例：广告活动ID 12345678）}}出现了
{{恶化的指标（例：ACoS环比上周恶化+5pt）}}。请把原因分类为检索词／出价／CPC／CVR／预算／广告位中的
哪个要因，并排出应对优先级。

请比较最近{{分析期间（例：过去14天）}}与其之前相同长度的期间，针对以下6个分类分别确认
对恶化的贡献程度。

1. 检索词 — 使用 analyze_search_term_contribution。period_first 传入前一期间，period_second 传入
   最近期间（顺序颠倒会导致 change / contribution 的符号反转）。用 tab=acos 确认贡献度，
   用 tab=spend 确认广告费的增减。比较 total_items 与 returned_items，
   若返回 next_page_token，请持续获取到分析所需范围。若未获取全部数据，
   请明示获取件数与总件数，不要断定为整体结果。
   🔴 实际统计的期间请看 effective_period_first / effective_period_second。
   响应中也包含 be_request_ranges，但在 monthly / weekly 时它只是单个锚点日期
   （实测中明明是月度比较，from 与 to 却返回同一个月初日期）。若引用这个字段会误报为"仅比较了1天"。
   请一并注明 period_resolution_reason 与 period_mode。
   🔴 不要搞错单位。 change 是 bps 表示，change_value 是百分点，
   change_ratio 是相对变化率（实测：55.7%→62.0% 对应 change "+623 bps" / change_value 6.23 / change_ratio +11.18%）。
   请务必注明使用的是哪个单位。
   🔴 不会返回账户整体的"贡献度"。 total.contribution 为 -- ／ contribution_value 为 null
   （实测确认）。也不能把各行的 contribution 相加来代替（响应中的 surface_refs 明确禁止 sum(rows[])）。
   贡献度请直接引用排名靠前行的数值，整体变化用 total.change 来说明。
2. 出价 — 用 get_change_history 确认出价・预算・状态的变更历史。即使返回0件也
   不要断定为"没有调整出价"。无错误的0件无法区分"确实没有变更"与"无法获取历史"，
   请记录为"变更历史0件（可能未能获取）"。
   🔴 若传入超过90天前的开始日，工具会自动上调至90天前，
   并返回"注记：Amazon 的变更历史仅保留过去90天，已将获取开始日调整为 YYYY-MM-DD。"
   这样的注记（实测确认）。请直接引用调整后的日期，作为"已确认的范围"呈现。
   profile_id 需传入与 account_id 关联的值（必填参数）。
   作为辅助，可对贡献度靠前的检索词使用 get_search_term_impression_trend（frequency=weekly，
   指定 targets 列表中的 keyword_id）确认每周 keyword_bid 与搜索结果顶部展示份额的走势。
   该系列数据是检索词×单一定向单位，若 targets 未能返回全部，请注明返回件数与
   target_count，不要断定为广告活动整体的出价变化。
3. CPC — 使用 analyze_search_term_contribution 的 tab=cpc 的 total。不要自行用广告费÷点击数
   计算。若出价下降但 CPC 上升，请作为市场因素的"假设"提出，不要断定为因果关系。
4. CVR — 使用 tab=cvr 的 total。确认点击增加时订单是否没有相应减少。
   检查 CPC 变化率与 CVR 变化率的乘积是否与 ACoS 变化率大致吻合。
   ※ 此项核算须在全部 tab 中统一使用相同单位（相对变化率 = change_ratio）。混用 bps 与 百分点会对不上。
5. 预算 — 用 check_budget_status 确认月度预算上限的设置状况。若 status 为未设置，或
   cap / ad_spend / utilization_rate 为 null，请注明"因上限未设置无法评估上限比消耗率"，
   不要把 null 当作 0% 处理。
   🔴 unconfigured 时不仅 cap，连 ad_spend 也会返回 null（实测确认）。
   不要把该工具作为广告费的获取来源。
   在此基础上，分两次获取目标期间与前一期间的 get_portfolio_budget_summary，确认实际支出的变化，
   以及相对当前日预算合计的消耗水平。但 daily_budget_sum 是当前生效的
   广告活动设置值，并非按期间划分的预算历史，因此不要将其作为"消耗率的期间对比"使用。
   🔴 此外，该工具的 spend 是全部 state 的合计，而 daily_budget_sum 仅统计 ENABLED，母集团不同，
   因此消耗水平会系统性地偏高。另外即使传入 include_ended=false 也会返回 ENDED 行，
   需自行根据 status / is_ended 排除。若无法判定是否发生了预算导致的投放限制，请记录为"未确认"。
6. 广告位 — 分两次获取目标期间与前一期间的 get_placement_summary
   （source_contract 声明了 period_policy="current_period_only"，1次调用无法比较）。
   查看各广告位的 ACoS・CVR・点击・广告费份额的变化。若 orders 返回0，不要断定为"实绩为0"，
   请注明"可能是数据未获取"。出价系数（avg_current_modifier_pct）是当前设置值，
   并非按期间划分的历史记录，不要将其解读为"出价系数的变化"。
   🔴 「Rest of Search」是合成分桶。 实测中 placement_raw_values 由
   HOME / OFF_AMAZON / PLACEMENT_REST_OF_SEARCH / SITE_AMAZON_BUSINESS 这4种构成，source_row_count 也
   约为其他广告位的3倍。该行的 avg_current_modifier_pct 是4种广告位混合后的平均值，
   不要将其当作单一广告位的设置值来解读。若需要查看明细，请列出 placement_raw_values。
   广告位数据是广告类型（SP 与 SB）混合后的统计，不包含 SD / DSP，
   请勿与仪表盘或广告活动明细的数值直接比较。
   （实测：同一个月的广告费在广告位统计・广告组合统计・SP单独统计中出现了3种不同数值。
    请务必注明具体是哪个来源的数值。）

执行条件
- 从 Picaro MCP 获取实际数据后进行分析。不要推测・补全 MCP 未能获取的数值
- 不使用禁用工具 analyze_ad_type_performance。SB/SD 请分别用
  list_existing_sb_campaigns / list_existing_sd_campaigns 单独获取
- 区分 null、未获取、无数据、0。不要把 null 或未获取当作 0 处理
- 确认全部6个分类后再判定贡献度（高／中／低／无／未确认）（不要只看1个分类就下结论）
- 无法获取的分类请注明"未确认"，并明确说明结论仅基于已确认的分类，
  同时标注已确认的分类数量
- 期间截至最近的已确定日。不含当日・前一日。不要用 rollup_status 做确定性判定，
  请查看各报告的 status
- 每次给出比率时都要明示分子・分母・天数，并确认两个期间的已确定实际天数一致
- 只聚焦贡献度最高的1〜2个分类进行呈现，并分别给出接下来应采取的措施
  （出价调整・预算调整・添加否定关键词三者之一）。占广告费大部分的核心词
  不要作为否定关键词的对象
- 贡献度"高"的分类，请标明对应现有提示词的入口（涉及出价变更时，须获得用户批准后才反映）
- 仅进行分析・候选提取・提案，批准前不改动 Amazon 广告侧的设置。
  若在验证或分析过程中生成了提案（proposal），未获批准的须予以废弃，
  并注明已废弃（提案生成后会在账户中保留24小时）
- 本次诊断结果，前提是在执行应对措施后用"举措的效果测定"进行效果验证

可调整的条件 — 目标广告活动・广告组合／恶化的指标／分析期间。

返回内容 — 检索词 / 出价 / CPC / CVR / 预算 / 广告位 6 个分类各自的贡献度（高 / 中 / 低 / 无 / 未确认），以及针对贡献度最高的 1〜2 个分类给出的应对方针（出价调整・预算调整・添加否定关键词之一）。由于 Picaro 没有按期间划分的预算历史与广告位出价系数变化历史，预算・广告位这 2 个分类的判定仅限于基于当前设置值。

设置变更 — 无变更（仅进行分析・候选提取・提案）。若分析过程中生成了提案（proposal），未获批准的会被废弃，并在输出中注明。

下一步 — 根据判定为高贡献度的分类，分别前往调整竞价／调整预算／添加否定关键词的审批流程。执行应对措施后，使用记录举措与外部事件并验证效果进行效果验证。

制定广告策略

本页基本信息

使用场景

执行前需确认

快速参考

分析现状结构与成果

提示词 1: 确认现有广告活动结构

提示词 2: 按漏斗阶段分解业绩

提示词 3: 对比品牌词与通用词的成果

提示词 4: 从 CAC 与 LTV 视角分析亏损原因

模拟预算分配与品牌结构

提示词 5: 制定增加品牌新客的预算追加分配方案

提示词 6: 求解现有广告活动内预算追加的最优分配

提示词 7: 分析预算未消化的原因

提示词 8: 按搜索漏斗制定活动前后的预算分配方案

按 ASIN 分析收益与成果

提示词 9: 按 ASIN 计算广告贡献额

提示词 10: 获取主要 ASIN 的业绩汇总

提示词 11: 识别点击率高但购买率低的 ASIN

提示词 12: 把恶化指标的原因切分为 6 个要因

相关分类