记录举措与外部事件并验证效果

本页可以帮助你把自己打出的举措（举措日志）和自己以外发生的外部事件记录到 Picaro，并对已记录的举措在变更前后（Before/After）验证效果。打出的举措如果不记录下来，事后就无法回顾「究竟是什么起了作用」。已记录的举措还可以在 在仪表盘确认 KPI 的提示词 3「举措前后效果测定」中使用。

本页基本信息

项目	内容
本页能做的事	把举措·外部事件记录到 Picaro，对比变更前后的 KPI 来验证效果
对象	举措日志（出价调整·预算变更·提升等自己采取的举措）和外部事件（电视播出·促销·爆款·缺货等自己以外的因素）
所需数据·连接	已连接账户。效果验证需要已连接账户的 KPI 实绩数据（无需额外设置）
操作范围	因提示词而异。举措·外部事件的登记＝记录到 Picaro（会发生写入）／变更历史的汇总·对比·报告＝仅分析（只读）。两者都不会改动 Amazon 广告设置本身。各提示词会在「设置变更」中单独说明

本页用到的术语

• 举措日志 … 自己采取的举措（出价调整·预算变更·提升等）的记录。为了日后测量效果而登记到 Picaro。
• 外部事件 … 并非自己举措的外部因素（电视播出·促销·爆款·缺货等）的记录。作为 KPI 变动的理由供日后参照。
• 举措 ID / 事件 ID … 登记时自动编号的编号。在验证效果或更新时指定。
• 变更前后（Before/After） … 在举措实施前后的期间对比 KPI。这是判断是否有效果的基本方法。
• ACoS（广告花费销售占比）／ROAS（广告投入产出比）… 广告效率指标。ACoS 越低越好，ROAS 越高越好。

记录与效果验证要成套使用

举措日志只记录是产生不了价值的。在实施后 7〜14 天，把已记录的举措 ID 传给效果验证提示词（提示词 4）或仪表盘的举措前后效果测定，即可自动汇总 ACoS / ROAS / 广告费 / 销售额的差值。

对比效果之前需确认的事项

在单个举措的效果判定（提示词 4・6）中，开始对比之前请确认下列 3 点。

• 举措 ID 要先确认实际存在再使用。 对比工具不会验证指定的举措 ID 是否存在。即使传入不存在的 ID，对比本身也会继续进行，因此请先用举措日志的单条获取确认其实际存在。
• 确认对比期间是否与外部事件重叠。 促销・电视播出・缺货等若与对比期间重叠，举措的效果就会与外部因素混同。对比工具不会自动排除外部事件。
• 举措前后的对比天数务必一致。 变化率是期间合计值之间的简单对比，不会对天数偏差做归一化，即使有偏差也不会发出警告。请像举措前 14 天・举措后 14 天那样让天数一致。

什么时候用

• 想把打出的举措（出价调整·预算变更·提升等），以日后可测量效果的形式记录下来
• 想把电视播出·促销·爆款·缺货等自己以外发生的事，作为 KPI 变动的理由留存下来
• 想对比已实施举措前后 KPI 的变化，验证效果
• 想从已记录的举措反查 KPI 变好的原因

执行前需确认

• 连接的账户 … 处理多个账户时，请先确认记录·分析的目标账户是否正确。
• 举措的实施日 … 登记举措日志时只能指定过去的日期。
• 效果验证的目标期间 … 对比变更前后的期间（提示词 4 务必在前后指定相同天数・默认 14 天）。当日·前日的数据可能尚未确定，因此选择已确定的最近期间更稳妥。
• 目标品牌·ASIN（可选） … 想聚焦特定品牌或商品时指定。不指定则以整个账户为对象。

提示词速查表

想做的事	能得到什么·会生成什么	设置变更	提示词
把打出的举措以日后可验证效果的形式记录	自动编号的举措 ID 与登记内容	记录举措日志（写入 Picaro）	提示词 1
列出·更新·添加备注已记录的举措	举措日志列表，或更新结果	列出为只读／更新·删除会变更举措日志	提示词 2
记录外部因素（TV / 促销 / 爆款 / 缺货）	自动编号的事件 ID 与登记内容	记录外部事件（写入 Picaro）	提示词 3
对比出价调整前后 2 周的 KPI	前后 2 周的 KPI 差值对比表	无变更（只读）	提示词 4
识别对 KPI 改善有贡献的变更	本期·上期的对比与有贡献的举措	无变更（只读）	提示词 5
测定举措效果并判断继续还是差还原	执行前后的指标对比表与 6 项判定·理由	无变更（以读取为主。举措日志未登记时会登记）	提示词 6

如何区分记录类和分析类

提示词 1〜3 会把举措·外部事件记录到 Picaro（会发生数据写入）。提示词 4〜5 只是读取已记录的变更历史或 KPI 进行分析·对比，不写入任何东西。提示词 6 基本为只读，但若比较对象的举措日志尚未登记，可能会在向用户确认后进行登记。均不会改动 Amazon 广告设置本身。

---

记录举措与外部事件

提示词 1: 登记举措日志

将实施的举措（出价调整·预算变更·提升等），以可用于变更前后（Before/After）对比的形式记录到 Picaro。

使用场景 — 想把打出的举措记录下来，以便日后测定效果时。

需要准备的信息 — 举措的种类、举措名称、实施日（过去的日期）。

登记举措日志。
- 种类: 出价调整
- 名称: {{举措名称（例: 高 ACoS 关键词 18 个的出价 -22%）}}
- 实施日: {{实施日期（例: 2026-05-18）}}
- 详情: 为何打出此举措（可选）
- 状态: 效果测定中

注: 这是用于内部举措效果测定的日志（相当于 `manage_measure`）。促销等外部因素的记录请使用另一个提示词（记录外部事件）。

使用此结果的下一个提示词: {{接续对象（例: 举措的效果测定・2 周后）}}

可调整的条件 — 举措名称、实施日（仅过去的日期）、种类（从「出价调整」「预算变更」「广告位调整」「提升」「排除」「其他」中选择）。若刚执行完出价调整的提案，也可以把该提案关联进来。

返回内容 — 自动编号的举措 ID 与登记内容的表格。并附带在实施后 7〜14 天测定效果的提示。

设置变更 — 把举措日志记录到 Picaro（会发生写入。不改动 Amazon 广告设置）。

下一步 — 已记录的举措效果，请在实施后 7〜14 天用提示词 4 或 在仪表盘确认 KPI 的举措前后效果测定来验证。

---

提示词 2: 列出 / 更新 / 添加备注举措日志

列表确认过去登记的举措日志，进行进度备注或状态的更新。

使用场景 — 想确认已记录举措的状况时，或想更新进度备注·状态时。

需要准备的信息 — 更新·删除时需要目标举措 ID。

列出效果测定中（status=monitoring）的举措日志。

1. 种类为「{{筛选种类（例：出价调整）}}」。举措日志的 pattern_id 只有
   cpc / budget / placement / promotion / negative / custom 这 6 种，
   因此请先把指定的种类对应到这 6 种之一再筛选
   （出价调整→cpc，预算变更→budget，广告位调整→placement，促销→promotion，
   否定关键词→negative，其他→custom）。
   无法对应的种类不做筛选而列出全部，并明示「指定的种类在 pattern_id 中不存在」。
2. 筛选结果为 0 件时，务必区分报告「符合条件的举措为 0 件」与「举措日志本身为 0 件」
   （去掉筛选条件再取一次列表来确认）。
3. 对每个举措，同时给出以举措日（date）为起点的经过天数，与以登记日（createdAt）为起点的经过天数。
   登记日不包含在列表中，因此请逐条单独获取各举措来确认。
   两者有偏差时以举措日起点为主，并注明存在差异。
4. 计算经过天数所用的「今天」，要在确认广告数据的入库状况之后，取已确定的最后一天
   （当天若未确定，就不要把当天用作起点）。
5. 以举措日为起点的经过天数超过 {{评估参考天数（例：14 天）}} 的，明示为「已到评估时期」，
   并按经过天数从长到短排列。
6. 输出为表格形式（举措日 / 种类 / 名称 / 状态 / 举措日起点的经过天数 / 登记日起点的经过天数 / 已到评估时期 / ID）。

注：这是内部举措日志的列表（manage_measure）。外部事件日志（manage_event）不在对象范围内。

使用此结果的下一个提示词：{{衔接目标（例：举措的效果测定）}}
要传递的值是 举措ID・举措日・种类。Before/After 的对比窗口需要自己以举措日为界指定，
且举措日志不保存对象广告活动/ASIN，因此务必附上「对比是在整个账户范围进行」这一点。

可调整的条件 — 列表的筛选条件（种类·状态等）。也可以指定特定的举措 ID（例: evt_2026_05_18_cpc）来更新内容、添加进度备注或删除（如依赖「给 evt_2026_05_18_cpc 添加备注『第 3 天: 开始有效果』」）。

返回内容 — 举措 ID / 种类 / 名称 / 实施日 / 状态 / 经过天数的列表（默认 20 条·按实施日从新到旧），或单条获取·更新的结果。

设置变更 — 列出·单条获取为只读。更新·添加备注·删除会变更举措日志（会发生写入）。删除时必定插入确认。

下一步 — 效果已显现的举措，用提示词 4 对比前后 KPI。

---

提示词 3: 记录外部事件

记录电视播出·促销·爆款·缺货等并非自家打出举措的外部因素，以便日后作为 KPI 变动的理由参照。

使用场景 — 想把 KPI 大幅变动的背景（自己以外的因素）留存下来以便日后回顾时。

需要准备的信息 — 外部事件的种类、开始日、事件名称。

请记录外部事件（促销・电视播出・爆款・缺货等）。
- 种类: {{种类（tv / sale / buzz / stockout / other 之一。涨价・竞品举措等没有对应项的用 other）}}
- 开始日: {{开始日期（YYYY-MM-DD。例：2026-06-11）}}
- 结束日: {{结束日期（YYYY-MM-DD・可选。单日则省略）}}
- 标签: {{事件名称（例：Prime Day 2026 春）。若想留下对象范围或补充说明（例：全 ASIN 对象・同时发放 20% OFF 优惠券），由于保存处只有名称栏，请写进这个标签里}}

【登记前】
请先获取既有事件的列表，确认没有重复后再登记。
列表可用 filter_from / filter_to（日期范围）与 filter_type（种类）筛选，请按准备登记的期间筛选后查看是否重复。
事件不是单日，而是持有 date〜end_date 的期间，因此重复判定请看期间的重叠（不要只看开始日是否一致）。

【登记后】
请再次获取列表，确认登记内容（种类・开始日・结束日・标签）是否符合意图并报告。
务必把返回的 id（UUID）包含在报告中。 日后订正・删除需要这个 id，
而除了从列表中查找之外没有别的获取方法。
列表返回的项目为 id / type / date / end_date / label / registered_by_email / registered_by_user_id /
updated_by_email / updated_by_user_id / created_at / updated_at。
※ registered_by_* ・updated_by_* 可能以 null 返回（实测中既有事件全部为 null）。
  请区分「登记者不明」与「无登记者」，不要凭推测填补 null。

【日后使用该事件时的注意】
已登记的事件，不会自动出现在仪表盘或报告的响应中。
确认该期间的 KPI 变动时，请按对象期间筛选获取事件列表，与分析期间的日期核对之后
再作为要因候选处理（不要把事件引起的变动与举措效果混同）。
※ 做举措前后对比的提示词会把这个列表实际用作输入。对比工具不会自动排除事件，
  因此这里若漏登记，下游的分析就会把促销的影响误认为举措效果。
※ 大型促销常常是「预热促销」与「正式促销」接连进行，请作为不同事件分开登记
  （以便下游的区间分析能够检测出前置期已经吃进了预热促销）。

【无法保存的内容】
不存在影响范围・折扣率・对象 ASIN 等结构化字段。只能包含在标签的字符串里。
因此请在「无法按事件名称检索・汇总」的前提下，取一个人读了就能分辨的名称。

使用此结果的下一个提示词：{{衔接目标（例：仪表盘 KPI（含上期对比））}}

可调整的条件 — 开始日、结束日（可选·单日事件则省略）、事件名称、种类（从「电视播出」「促销」「爆款」「缺货」「其他」中选择）。

返回内容 — 自动编号的事件 ID 与登记内容的表格。

设置变更 — 把外部事件记录到 Picaro（会发生写入。不改动 Amazon 广告设置）。

术语补充 — 已记录的外部事件，不会自动显示在仪表盘或报告的响应中。做举措前后对比时，请按对象期间筛选获取事件列表，作为 KPI 变动的要因候选来核对（对比工具不会自动排除期间）。

下一步 — 想确认记录的事件是否影响了 KPI 走势时，请前往 在仪表盘确认 KPI。

---

分析·验证变更历史

提示词 4: 对比出价调整前后 2 周的 KPI

针对指定的出价调整，对比实施前 2 周与实施后 2 周的 KPI 表现。

使用场景 — 想用数字验证已记录的出价调整是否真的有效果时。

需要准备的信息 — 已实施的出价调整的实施日。举措日志未登记时，也可以以实施日为基准判定（已登记则与提示词 1 的日志核对）。

请判定 {{举措实施日（例：2026-08-04）}} 实施的出价调整的效果，并决定是否需要继续。

前提确认（先做，并把结果写进输出）
1. 用 manage_measure(action=list) 确认是否有该举措的记录。有记录则引用举措ID・pattern_id・实施日。
   没有记录时写明「举措日志未记录」，并以指定的举措实施日为基准继续。
   即使传入举措ID，对比工具也不会验证 ID 是否实际存在，因此务必先用 manage_measure(action=get) 确认存在后再使用。
   （action=get 对不存在的 ID 会返回「找不到对应日志」，所以这个确认实际有效。）
2. 用 manage_event(action=list) 确认对比期间是否与促销・电视・缺货等外部事件重叠。
   重叠时请错开对比期间，或把影响写进输出。对比工具不会自动排除事件。
   事件持有 date〜end_date 的期间，因此不要只看开始日，要看整个期间与 before / after 的重叠。

对比的条件（务必遵守）
- 以举措实施日之前紧邻的 {{对比期间的天数（例：14 天）}} 为 before、之后紧邻的 {{对比期间的天数（例：14 天）}} 为 after，before 与 after 的天数务必一致。
  变化率是期间合计的简单比值，不做天数归一化，天数有偏差也不会发出警告，因此天数不一致的对比视为无效。
- after 的期末取到销售额已确定的日期为止。销售类约需 7 天、流量类约需 3 天才确定。
  用 get_data_ingestion_status 确认已确定的最后一天，不要把 fully_missed / in_progress 的日期包含进 after。
  执行结果若出现「汇总确定前」的警告，务必把期末下调到已确定日并重新执行。不要用未确定值做判定。
- 广告侧指标（广告费・点击・广告销售额・订单数・ACoS・ROAS・CTR・CPC・CVR）的出处统一到 compare_measure。 与其他工具的值会不一致，不要混用。
- 总销售额 compare_measure 不返回。 只有总销售额用 get_dashboard 以 after 期间・include_previous=true 调用 1 次来获取
  （上期会自动变成「相同天数的紧邻前一期间」，因此 before 与 after 的天数一致在机制上得到保证）。
  取得的总销售额作为另一出处的参考值处理，在表中附上出处名称加以区分。
  即使是相同期间・相同账户，compare_measure 的广告销售额与 get_dashboard 的广告销售额也可能不一致
  （实测中 after 期间一致，唯独 before 期间差了几个百分点）。若有偏离请写明偏离幅度，不要用一方的值覆盖另一方。
- CTR 的显示会四舍五入到小数点后 1 位，因此差分表中请放入用 clicks ÷ impressions 重新计算的值。
  四舍五入后的显示在 before / after 看起来相同时，重新计算后也可能有显著变动。
- 工具返回的 judge（improved/neutral/degraded）判定基准未公开，不要用于结论。只作为参考并列写出。
  实测中存在 ACoS 与 ROAS 双双恶化，judge 却返回 neutral 的情况。

要输出的内容
- 包含 ACoS・ROAS・销售额（广告销售额）・CTR 的 Before / After / 变化率的差分表。广告费・点击数・订单数也一并写出。
- 作为参考也一并写出总销售额的变化率（出处写明为 get_dashboard），与广告销售额符号不同时请写明这一点。
- compare_measure 也会返回按广告活动的广告费・ACoS 上位，因此请举出 1〜3 个牵引整体变化的广告活动。
  但 before 广告费为 0 的广告活动会显示成「ACoS +100%」这样，请区分书写新增投放与恶化。

判定基准
- ACoS 满足 {{改善基准（例：相对改善 10% 以上）}}，且广告销售额在 -5% 以内时推荐 Keep。
  若 ROAS 也有改善，可检讨 Expand。
- 即使 ACoS 有改善，广告销售额恶化超过 -10% 时检讨 Revert。
- 不符合上述任何一项，或前提确认 1・2 仍残留不确定性时，判定为 Investigate。
- 改善幅度务必写明是「相对变化率（%）」还是「百分点（pt）」。
  ACoS 61.1%→58.6% 相对为 -4.0% / 绝对为 -2.5pt，按哪个读结论会不同。

Guardrail：不要以大幅牺牲广告销售额为代价去改善 ACoS。
Guardrail：在无法确定举措・期间尚未确定的情况下，不要断定「无效果」「无需继续」。务必判定为 Investigate，并写明缺少的信息。
Guardrail：写明这只是前后对比、没有对照组。季节性・库存・价格・评论变动无法分离。

最后请输出以下 3 点。
1. 推荐行动 — 写明判定结果（Keep/Expand/Adjust/Revert/Investigate）・理由・优先级・预期效果・确信度・风险
2. 执行方法 — Revert 生成把出价恢复到举措前水平的建议，Expand 生成扩大对象的方案，两者都由用户确认・批准后再反映
3. 测定 — 执行后 {{对比期间的天数（例：14 天）}} 重新获取同一指标，用「举措的效果测定」重新判定

可调整的条件 — 举措实施日／对比期间的天数（默认 14 天。举措前后务必为相同天数）／ACoS 的改善基准（默认改善 10% 以上）。

返回内容 — ACoS・ROAS・销售额・CTR 的 Before/After/变化率的差分表（一并写出广告费・点击数・订单数），以及 Keep/Expand/Adjust/Revert/Investigate 的判定。

设置变更 — 无变更（只读）。

术语补充 — 与 在仪表盘确认 KPI 的举措前后效果测定相似，但此处针对出价类举措，务必让举措前后的对比天数一致后再对比（默认 14 天。天数有偏差时变化率不会被归一化，也不会发出警告，因此务必遵守）。想以出价调整以外的举措（预算变更・提升・排除等）为对象，或想在执行前后指定不同的对比期间时，请使用提示词 6。

下一步 — 想在整个账户范围反查哪些变更起了作用时，前往提示词 5。想把出价调整以外的举措也纳入，用 Keep/Expand/Adjust/Pause/Revert/Investigate 这 6 项判定来确认效果时，前往提示词 6。

---

提示词 5: 识别对 KPI 改善有贡献的变更

报告期间内整个账户的 KPI 表现，与上一期间比较，识别对改善有贡献的变更。

使用场景 — 想从已记录的举措反查数字变好的原因时。

需要准备的信息 — 目标期间（默认为最近 30 天）。

请创建一份报告：把最近 30 天整个账户的销售额・ACoS・ROAS 与上一期间对比，识别对 KPI 改善有贡献的举措，并判断如何应对（继续/扩大/停止）。
目的：识别出有效果的举措，用于横向推广或停止的判断。

## Step 0. 先确定期间再开始（不可省略）
1. 用 get_data_ingestion_status 确认已确定的最后一天。fully_missed / in_progress 的日期不计入本期。
2. 本期＝从已确定的最后一天往前回溯 {{对比天数}} 天，上期＝紧邻其前的相同 {{对比天数}} 天，两个期间的天数务必一致。
3. 在报告开头写明「已确定的最后一天」「本期的开始日与结束日」「上期的开始日与结束日」「各期间的天数」。
※ 天数不一致的对比，即使变化为零也会显示成「发生了变化」。仅包含 1 天未确定日就会让变化率动几个百分点，因此不要跳过这个确认。工具不会对期间长度的不一致发出警告。
※ 不要用 rollup_status 做确定判定。只要有 1 个未投放的广告类型，即使其他报表全部 completed，整天也会落为 no_data。请看各报表各自的 status。

## Step 1. 把 KPI 的出处固定为 1 个（不可省略）
- 把本报告的主 KPI 出处固定为 {{KPI出处}}（get_dashboard 或 analyze_ad_type_performance 其中之一），并在报告开头写明。
- 出处的选法：get_dashboard 不返回 ROAS 与 clicks（返回的是 总销售额・广告销售额・广告费・ACOS・TACoS・订单数・CVR）。若要把 ROAS 纳入主 KPI，请选择 analyze_ad_type_performance，或把 ROAS 写明为「本方计算（广告销售额÷广告费）」。另一方面 analyze_ad_type_performance 只有 SP/SB/SD 的广告侧，不返回总销售额。无论选哪个都会缺指标，缺的一侧请写「该出处无法取得」。
- 不要在 1 张表・1 次对比中混用多个出处的数值。 即使是相同期间・相同账户，出处不同 ACoS・ROAS・广告费也不会一致（汇总来源・税别・归因窗口不同）。作为参考并列写出其他出处的值时，务必附上出处名称，并写出偏离幅度。
- 不要把工具没有返回的指标写得像返回过一样。 自己计算的值请写明为「本方计算」。
- 比率的变化要统一单位。 是「绝对差（百分点）」还是「相对变化率（%）」，请在报告内统一并写明是哪一种。不同工具返回的单位不同，不要把响应的值原样并列。
- 每次给出比率时，都要一并写出分子・分母・对象天数。要做到让读者能分辨变化来自分母还是分子。

## Step 2. 收集举措的记录（3 条路径全部确认）
请把下列 3 项全部执行，并记录各自的取得件数。
1. get_change_history … Amazon 侧的变更历史（可回溯上限为 90 天。profile_id 请传与 account 关联的值）
2. manage_measure（action=list，无筛选） … Picaro 的举措日志
3. query_audit_log … 经由 MCP 的操作记录

重要的处理方式：
- 其中任何一项为 0 件，都不要写「未实施任何举措」。 正确的表述是「无法取得举措的记录，无法判定是否实施」。记录的缺失并不意味着举措的缺失。
- 对 3 条路径分别写明「取得到的件数」与「该路径在原理上无法捕捉的范围」。
- query_audit_log 是调用方 Agent 自身的工具调用记录，并不是对广告的变更记录。不要当作举措日志的替代。其他人・其他 Agent・Seller Central 发起的变更不会出现在这里。
- 不要把 query_audit_log 的件数当作全数。 响应中会分别给出「显示件数 / 符合件数 / 扫描件数」，到达扫描上限（实测为 10,000 件）时会返回指向未扫描部分的 next_cursor。此时「符合 N 件」只是下限值。是否到达扫描上限务必写进报告。
- 不要把 audit_level=mutation 当作「写入操作的筛选」使用。实测中连列表获取类的只读工具也被标记为 audit=mutation。请按工具名而非标签来判定。另外经由 MCP 的写入尝试无论成功失败都会被记录，因此限于自己这条路径是可用的。
- 记录为 0 件、但广告费・广告活动分配实际在变动时，请写明很可能不是「真正的零」而是「记录路径的缺失」，并作为确认行动留下来。
- 外部事件（促销・电视・缺货）与举措分开，用 manage_event（action=list）确认。即使举措日志为 0 件，事件也可能已登记，并且可能成为 KPI 变化的主因。与期间重叠的事件务必写进报告。

## Step 3. 仅当举措记录有 1 件以上时，才进入应对判断
- 对每个举措，以举措实施日为界让前后天数一致来对比 Before/After。
- 按影响度（KPI 改善幅度）从大到小排列，推荐「继续」「扩大」「停止」之一。
- 不要用工具返回的综合判定（judge 等）代替 Guardrail 判定。 即使效率指标改善，销售额・订单数也可能恶化，因此销售额与订单数务必各自独立确认。

## Step 4. 因果的拆分（不可省略・无论 Step 3 有无都要执行）
在把 KPI 的变化称为举措的成果之前，请确认下列全部并写进报告。
1. 曝光量的增减 — 曝光量・点击・广告费是否同时减少。请考虑效率指标的改善可能是「低效率投放停止后的结果」。
2. 规模与效率的方向 — 效率（ACoS/ROAS）与规模（销售额・订单数）是否朝相反方向变动。若相反，就不要简单地称为「改善」。
3. 对照组的缺失 — 写明这只是前后对比、没有对照组。写明季节性・品类变动・库存・价格・评论变动无法分离。
4. 数值的可变性 — 写明即使是已确定的期间，也可能因重新入库而改变数值。
上述任何一项无法拆分时，不要断定「〜起了作用」，而要写成「与〜同期发生了〜（因果未确定）」。

## Guardrail
- 让销售额或订单数恶化的举措，不要推荐继续・扩大。
- 在依据（举措记录）为空的状态下不要给出继续/扩大/停止的推荐。 无法确定举措时，请把推荐行动从「举措判断」替换为「为使举措判断成为可能的整备行动」。
- 务必分开写明取得到的范围与缺失的范围。无法断定的事情请写「无法判定」。

## 输出
最后请输出以下 3 点。未能确定举措时，请在各项中写明这一点与替代内容。
1. 推荐行动 — 各举措的继续/扩大/停止・理由・优先级（按 KPI 改善幅度）・预期效果・确信度・风险。无法确定举措时，请按优先级给出记录整备・原因确认的行动，并写明「未按 KPI 改善幅度排列的理由」
2. 执行方法 — 扩大・继续用 {{执行用提示词}} 提出对象扩大・预算增额，批准后再执行。要传递的对象为 0 件时请写明这一点，并且不传递
3. 测定 — 执行 {{再测定天数}} 天后重新获取同一指标并对比。再测定时也务必应用 Step 0（确定边界・期间长度一致）与 Step 1（KPI 出处的固定）。若恶化则 Revert

可调整的条件 — 目标期间（默认 30 天。上期也用相同天数对比）／KPI 的主出处（固定为 get_dashboard 或 analyze_ad_type_performance 其中之一）。

返回内容 — 本期·上期的 KPI 对比，以及从 3 条路径（Amazon 侧变更历史・Picaro 举措日志・MCP 操作记录）收集到的举措一览。每个举措附有继续／扩大／停止的推荐，以及理由・优先级・确信度・风险。无法取得举措记录时，会以按优先级排列的记录整备行动来代替判断。

设置变更 — 无变更（只读）。

下一步 — 想单独深挖已识别举措的效果时，用提示词 4 以前后相同天数（默认 14 天）对比。想纳入月度报告时，前往 生成报告。

---

提示词 6: 测定举措效果并判断继续还是差还原

针对已执行的举措，比较执行前后的指标，并以 Keep（继续）／Expand（扩大）／Adjust（微调）／Pause（停止）／Revert（差还原）／Investigate（需调查）这 6 种判定给出结论。

使用场景 — 想判定已执行的举措（不限于出价调整，也包括预算变更・提升・排除等）是否真的产生了效果，并决定是继续・扩大还是还原时。

需要准备的信息 — 已执行举措的内容与执行日。比较对象（广告活动・关键词・ASIN 等）。执行前后的比较期间。想比较的评估指标。判定为恶化的水准（例：Orders 环比 -10% 以内）。

已将{{已执行的举措（例：下调关键词出价）}}于 {{执行日（例：2026-08-10）}} 反映生效。想判定是否产生效果，
并判断继续／扩大／调整／停止／差还原／需调查中的哪一项。

针对对象（{{目标广告活动・关键词・ASIN等（例：广告活动ID 12345678）}}），请比较执行前期间
（{{执行前的比较期间（例：执行日前14天）}}）与执行后期间（{{执行后的比较期间（例：执行日起14天）}}）的
{{评估指标（例：ACoS, Orders, CPC）}}，并以表格呈现。请分别判定改善／恶化／无变化。

若被判定为恶化的指标低于{{需守护的水准（例：Orders 环比 -10% 以内）}}，请注明为"Revert候选"。
基于判定结果，请给出 Keep（继续）／Expand（扩大）／Adjust（微调）／Pause（停止）／Revert（差还原）／
Investigate（需调查）中的一项，并附理由。

执行条件
- 执行前后必须分2次获取（不要让1次调用同时返回前后两期）
- 账户整体的比较，向 compare_measure 传入 before / after（会返回 judge 与主要KPI的变化率）。
  该工具没有缩小对象范围的参数，返回的是账户合计与按广告活动的Top10（按广告费排序・仅费用和ACOS）。
  若对象不在其中，或需要 Orders・CPC，请切换到下述按粒度划分的方式
- 广告活动单位的比较，用 before / after 两个期间各调用一次 list_existing_sp_campaigns（include_metrics=true）。
  附加 name_filter 会导致 include_metrics 与期间被忽略，因此获取指标时仅按期间调用，
  确认 truncated 为 false 且 returned 与 total_results 一致后再核对对象
- 关键词／商品定向单位的比较，用 before / after 两个期间各调用一次 list_target_performance，用 search_key
  缩小对象范围。target_fetch_truncated 为 true 时，把 max_pages 调高到 target_total_pages_available 以上
  重新获取。若仍被截断，请注明"无法保证全量获取"，并将判定标记为暂定。上游汇总会缓存数小时，
  也请提及最近的变更可能尚未反映。并行调用多个期间容易超时，请逐个执行
- 举措的记录・引用用 manage_measure（action=list / add / get，指定 pattern_id 与 proposal_id）进行。
  若没有执行记录，请先向用户确认执行日・对象・变更内容后再登记。manage_event 用于记录外部事件
  （促销・缺货・电视等），并非举措日志，因此用于确认比较期间内是否有外部事件重叠（action=list），
  若有重叠请在解读中注明
- 销售额相关指标（销售额・订单・ACoS・ROAS・CVR）约需7天、流量相关指标（展示・点击・费用）约需3天
  才能确定。若比较期间的末端包含未确定日期，请注明，并尽可能把期间收窄到已确定日期为止
- 判定必须从6项（Keep/Expand/Adjust/Pause/Revert/Investigate）中明确选出1项
- 若判定为 Revert，请生成恢复到变更前数值的提案，并说明需获得用户批准后才反映
- 若存在部分数据・截断，请将判定保留并注明"暂定"。无法获取的指标不要用推测补全

可调整的条件 — 对象（广告活动・关键词・ASIN 等）、执行前后的比较期间、评估指标、判定为恶化的水准。

返回内容 — 执行前期间与执行后期间的指标对比表（附改善／恶化／无变化的判定），以及 Keep／Expand／Adjust／Pause／Revert／Investigate 中的一项判定与理由。若存在部分数据・截断，判定会被保留并注明”暂定”。

设置变更 — 无变更（以读取为主）。但若比较对象的举措日志尚未登记，可能会在向用户确认执行日・对象・变更内容后进行记录（会发生写入）。不会改动 Amazon 的广告设置本身。

术语补充 — 提示词 4「对比出价调整前后 2 周的 KPI」仅限出价调整，且前后务必指定相同天数进行对比（默认 14 天，可更改）。提示词 6 不限举措种类，比较期间也可按举措单独指定，是给出 6 项判定结论的通用版本。其他提示词中作为”执行后重新评估效果”而被引用的正是本提示词。

下一步 — 若判定为 Revert（差还原），请生成恢复到变更前数值的提案，并在获得用户批准后反映。

---

相关分类

• 在仪表盘确认 KPI — 在提示词 3「举措前后效果测定」中使用已记录的举措
• 调整竞价 / 调整预算 — 与提案执行组合、留下举措日志是惯例
• 设定销售额·广告费·ACoS 目标 — 作为举措效果判定基准，事先登记目标 ACoS / TACoS
• 生成报告 — 在月度报告中附上举措日志 + 外部事件
• 保存判定规则，将提案的批准与监控流程化 — 把批准并应用的举措记录到这里