Save rules to systematize proposal approval and monitoring

On this page you can save bid and exclusion rules against your account to skip specifying them every time, review and apply the proposals returned by the optimization prompts, set up budget-overspend alerts and recurring summary delivery, and put in place auto-proposals for targets that match your conditions. This page is for lightening operations where you keep making the same judgment, by turning it into a rule.

About this page

Item	Details
What you can do	Save decision rules, review and apply proposals, set up recurring monitoring and alerts, auto-propose targets that match your conditions
Applies to	Mainly Sponsored Products (SP)
Data & connection needed	A connected account. Alerts and delivery may require additional setup such as a Slack integration (see the note below)
Scope	Varies by prompt. Registering rules and conditions = records / approving a proposal = changes ad settings after approval / monitoring and delivery = sets up notifications / judging and proposing = analysis and proposal only. Each prompt states its own in “Changes”

When to use this

Writing the bid or exclusion criteria every time is tedious, and you want to save them as a rule
You want to apply all, or only some, of the proposals returned by an optimization prompt
You want to be notified when you overspend the budget, or to receive weekly results on a recurring basis
You want targets that match a condition (low performance, delivery stopped, etc.) to be found and proposed automatically

Before you run

Target account … if you handle multiple accounts, the account that created the proposal and the account you apply it on must match.
Judgment thresholds … target ACoS, the minimum clicks and orders to consider, and so on. If you have registered KPI targets, they are referenced automatically.
Alert and delivery integration … Prompts 5 and 6 require additional integration setup (see the note above).

Quick reference

Goal	What you get	Changes	Prompt
Save decision criteria against your account for reuse	The saved settings and their reference mapping	Registers a rule	Prompt 1
Review a proposal’s contents (current value, recommended value, reason)	A detailed list of proposal items	No change (read-only)	Prompt 3
Find seasonal campaigns that should be ended	The end recommendation and reasoning	No change (ending is manual)	Prompt 4
Get notified when you overspend the budget	The alert condition and recent overspend record	Sets up notifications	Prompt 5
Deliver a weekly results summary on a schedule	The delivery schedule and a preview	Sets up delivery	Prompt 6
Propose stronger bids for high-performing products in under-spending campaigns	A list of bid-increase proposals	No change (proposal only)	Prompt 7
Propose excluding targets that get many clicks but no sales	A list of exclusion candidates	No change (proposal only)	Prompt 8
Produce a restart plan for ads whose delivery has stopped	The cause and restart actions	No change (proposal only)	Prompt 9

Prompt 1: Save a decision rule

Save decision criteria such as bid, budget, and negative keyword thresholds against your account, so that later optimization prompts reference them automatically.

When to use — when you want to stop writing the same decision criteria every time and fix them as a rule.

What you need — the rule type and the thresholds used for the judgment (target ACoS, minimum clicks, and so on).

Register a {{rule type (e.g. bid optimization)}} decision rule:
- Target ACoS: 15%
- Minimum clicks to evaluate: 10 or more
- Minimum orders to evaluate: 1 or more
- Apply mode: do not apply until approved (return as a proposal)

What you can change — the rule type (“bid optimization”, “keyword bid”, “budget”, “placement multiplier”, “negative keyword”, “top-of-search impression share”, “combined”, etc.), the target ACoS, and the minimum-clicks / minimum-orders thresholds. You can omit the target ACoS if you have already registered KPI targets.

What you get back — a table of the saved settings and a note on which optimization prompts will reference it automatically.

Changes — registers the decision rule against your account (does not change ad settings). The apply mode is locked to “do not apply until approved”.

Term note — the minimum-clicks and minimum-orders thresholds are guidelines that keep low-data targets from being misjudged (the example uses 10 clicks and 1 order).

Next steps — the registered rule is referenced by Adjust bids, Adjust budgets, and Add negative keywords.

Prompt 2: Review proposal details

List the contents of each item (current value, recommended value, reason) from a proposal ID, to prepare for a partial apply.

When to use — when you want to look at each item and pick and choose before applying the whole proposal.

What you need — the proposal ID.

Goal: understand the proposal's contents accurately before approval, and prevent the wrong change from being applied.

Show the details of proposal ID {{proposal ID (e.g. campaign-1787102102700-xxxxx)}}.

[Always show]
- The item ID
- Current value / recommended value / reason for the recommendation
- The setting values in each item's metadata
- The proposal's type and account_id, and the expiry (expires_at)
- The number of items shown

[🔴 Where to look depends on the proposal's type. Always branch]
A. When it is a proposal to create a new campaign (type=campaign)
- items[] is only a summary. Always look at campaign_plan_raw.
  For SP proposals, campaign_plan_raw.steps[] contains the actual request bodies sent to the Amazon Ads API, for every level.
  Items confirmed by measurement:
  - campaign: name / targetingType / state / budget{budget,budgetType} / dynamicBidding / portfolioId
  - adGroup: name / state / defaultBid
  - productAd: sku / state
  - keyword: keywordText / matchType / state / bid
  - each step's nameSource / nameSourceLabel (which tells you whether the name came from the user or from a naming convention, e.g., "user-override" / "by user override")
- The item counts are in campaign_plan_raw.summary (the breakdown of campaigns / adGroups / productAds / keywords / negativeKeywords / targets).
  Use it to present the counts per level.
- 🔴 The state can differ between levels. In measurements, the campaign was PAUSED while the adGroup / productAd / keyword were ENABLED.
  Don't write "the state at creation" as a single combined value — enumerate it per level.
- * SB / SD campaign proposals have no campaign_plan_raw. Their metadata is only
  {name, budget, budgetType} (SB) / {name, budget, tactic} (SD), and the start date and
  portfolio you passed are not echoed back. In that case, enumerate them as "items that do not appear in the proposal's diff,"
  and have the user re-present the request contents from when the proposal was created so you can reconcile them.

B. When it is an adjustment proposal for bids, budgets, etc. (type=budget / bid family)
- items[]'s metadata contains the parent ID of the write target.
  For bid proposals, targetId / targetKind / campaignId / adGroupId were confirmed, along with the basis for the judgment: clicks / spend / sales / orders.
  So don't assert that "the parent ID isn't returned" — look at metadata first, then judge.
- A budget proposal's items may contain only id / label / current_value / recommended_value / reason.
  spend / sales / estimated_impact do not exist, so don't present the difference as an effect amount.

[Always state "not retrieved"]
Only for items you still could not retrieve after looking at A / B above, state "cannot be retrieved from the MCP" rather than filling them in by guesswork.
Examples (confirmed by measurement):
- The start date for a new SP campaign creation — the creation tool's config has no start-date field at all,
  so startDate is not in the campaign body either (it is determined by Amazon's default). Write "not specified (starts at creation)."
  * SB / SD are different: they do accept a start date as an argument, it simply doesn't appear in the diff. Don't conflate the two.
- The current reality of existing entities (for a creation proposal, currentValue is just "(new)";
  the proposal side does not determine whether a campaign with the same name already exists)

[Required checks before approval]
1. For a creation proposal, verify that campaign_plan_raw's portfolioId, sku, keywordText, and matchType actually exist
   (reconcile them against the portfolio list, SKU reverse lookup, and campaign list).
   🔴 A proposal is generated even with IDs that don't exist (their existence is not verified at creation time).
   Don't treat "the proposal could be generated" as evidence that the target exists.
2. For an adjustment proposal, reconcile metadata's campaignId / adGroupId against the list-retrieval tools.
3. If the target can be identified from neither metadata nor campaign_plan_raw, have the user re-present the
   {{target campaign ID}} / {{target ad group ID}} they specified when the proposal was created,
   reconcile with the list-retrieval tools that it exists and is the intended target, and only then answer whether to approve.
   If you cannot reconcile it, conclude "cannot approve (target unverified)."

[Expiry]
A proposal expires 24 hours after it is generated (always present expires_at).
There is no way to find a proposal ID in a list afterwards, so discard on the spot any proposal you decide not to approve,
and report that you discarded it (leaving it alone leaves a route by which another person could approve it later).

The next prompt that uses this result: {{destination (e.g., Approve and apply a proposal)}}

What you can change — (none; this only displays)

What you get back — a table of item ID × campaign × target × current value × recommended value × reason.

Changes — no change (read-only). Nothing is applied.

Next steps — the item IDs you confirm here can be passed straight to Prompt 2’s partial apply.

Prompt 3: Find seasonal campaigns that should be ended

From the per-product (SKU) ad profit over the past 14 days, decide which seasonal campaigns should be ended soon.

When to use — when you want to decide when to stop ads for sale or seasonal products.

What you need — (the period defaults to the past 14 days)

From the performance over the past {{target period (e.g., 14 days)}}, decide which seasonal campaigns should be ended.

0. [Finalized data boundary] First check the ingestion status and exclude unfinalized days (including today) from the aggregation period. State the finalized period you actually used. Don't include an unfinalized day as the final point of a trend.
1. [Identification] Before anything else, enumerate the list of seasonal/event words used as the criteria for "seasonal campaign" (spring/summer/autumn/winter/snow/autumn leaves/Christmas/Valentine's/White Day/lucky bags/Mother's Day/Father's Day/Halloween/year-end and New Year/new-life season/best cosmetics/limited edition/sale/Prime Day, etc.), then search across all of SP/SB/SD. State the rows retrieved / total count and whether you processed the paging to the end (don't treat a cutoff as the full set).
   - Always rule out false positives where a word happens to match part of a product line name, an ASIN string, or an internal code. Trace each candidate down through "ad group → product ad → ASIN → product name," confirm whether it is a seasonal product or a year-round product line, and only then adopt it. Enumerate the candidates you excluded and why.
   - Campaigns have no field indicating a season (no end date, schedule, or event linkage), so state that the identification is an inference based on names, and note as a limit on coverage that seasonal campaigns without a seasonal word in their name cannot be detected.
   - Limit the judgment to campaigns that are running (delivery state enabled AND ad spend > 0). If there are none, say so and stop.
2. [Trend] Compare the target campaigns' sales and ROAS at two points by splitting the finalized period into a first half and a second half. Confirm that the two halves sum to the aggregate for the whole period; if they don't, state "aggregate for a single period only" and don't use the words "trend" or "movement."
3. [Inventory] For the ASINs of ads currently delivering in the target campaigns, show inventory units, weekly shipments, and weeks of supply together. Don't include ASINs of paused ads.
4. [Basis for efficiency] If cost of goods is not connected, say so and note ROAS/ACoS as "a proxy metric for efficiency." Fetch the account-wide ROAS as the baseline for the judgment and show it alongside.
5. [Criteria for the end determination] Recommend ending only campaigns that satisfy all of the following (always state which conditions were met):
   (a) second-half sales are {{decay threshold (e.g., -30%)}} or worse versus the first half
   (b) second-half ROAS is below the account-wide ROAS
   (c) weeks of supply are not below {{weeks-of-supply floor (e.g., 4 weeks)}} (so you don't mistakenly stop a campaign being continued to clear inventory)
   Campaigns meeting only (a)(b) are "keep observing"; those meeting none are "leave as is."
[Constraints] Do not recommend action on campaigns whose existence is unverified. Make the table headings match the contents. When limiting to the top N, state the total count. State inference from names explicitly. Do not perform write operations (including pausing campaigns and creating, updating, or deleting automation rules).

Finally, output these 3 items.
1. Recommended action — present end-recommended / keep-observing / leave-as-is with priorities, and for end-recommended items show the expected ad spend saving (the actual ad spend over the finalized period, pro-rated to a monthly figure) with the basis for the calculation
2. How to execute it — for end-recommended campaigns, pause them only after the user reviews and approves the targets and the reason for stopping (this prompt does not execute)
3. Measurement — {{evaluation date (e.g., 14 days later)}} after the approved pause is executed, re-check the account-wide ROAS and the inventory situation. When re-checking, also cut the period at the finalized boundary with unfinalized days excluded

What you can change — the target period.

What you get back — a table of campaign × 14-day sales trend × ROAS × end recommendation × reason.

Changes — no change (analysis and proposal only). The actual campaign ending is done manually.

Next steps — to decide together with inventory status, also use Manage inventory and sales opportunities.

Prompt 4: Alert on budget overspend

Watch the budget pacing of all active SP campaigns and alert when daily spend exceeds the budget by 15%.

When to use — when you want to know each time you overspend the budget, rather than noticing later.

What you need — the overspend percentage to alert at (default is 15%). The alert integration setup (see the note above).

Watch the budget pacing of all active SP campaigns,
and notify me when daily spend exceeds the budget by 15%.

What you can change — the overspend percentage (15% in the example).

What you get back — a confirmation of the alert condition and the overspend record for the past week.

Changes — sets up notifications (does not change ad settings). Delivering the alert requires additional integration setup.

Next steps — revise the budget itself in Adjust budgets.

Prompt 5: Deliver a weekly summary on a schedule

Automatically build and deliver a weekly SP performance summary on the day and time you choose.

When to use — when you want to receive weekly results on a recurring basis without compiling them by hand.

What you need — the day and time to deliver (the example uses every Wednesday at 13:00). The delivery integration setup (see the note above).

Every Wednesday at 13:00, build an SP weekly performance summary,
and deliver it including a week-over-week (WoW) comparison.

What you can change — the day and time of delivery.

What you get back — a confirmation of the delivery schedule and a preview of the past week’s summary.

Changes — sets up delivery (does not change ad settings). Delivery requires additional integration setup.

Next steps — to customize the contents of the report, use Create reports.

Prompt 6: Propose stronger bids for high-performing products in under-spending campaigns

Within campaigns that are not spending their full budget, create proposals to raise bids on high-performing products (ASINs).

When to use — when you want to shift budget toward products that are growing, while you still have budget to spare.

What you need — the budget pacing threshold (default is under 70%).

Propose bid increases for the high-efficiency targets inside SP campaigns that have budget headroom.

[Premises]
- Set the analysis period to {{analysis period (e.g., the last 14 days, through the finalized date)}}, and don't include today because it is unfinalized.
- Always specify a target ACoS of {{target ACoS (e.g., 35%)}}. If you don't, the observed TACOS is used as the provisional basis, the run becomes down_or_maintain_only, and zero increase proposals come out.

[Procedure]
1. Fetch the ENABLED SP campaigns with start_existing_sp_campaigns_job, confirm that get_mcp_job_status is complete and truncated=false, and only then fetch get_mcp_job_result. Don't finalize the count while it is still running. State "rows retrieved / total count." This job returns campaign-level rows only — it does not include nested ad groups or product ads.
2. Calculate the utilization rate yourself with the following formula. Don't use the returned budgetUtilizationRate field as the utilization rate as is (it is actually "total spend over the period ÷ one day's worth of dailyBudget," so it is off by a factor equal to the number of days in the period).
   Utilization rate = total spend over the period ÷ (dailyBudget × the number of days in the analysis period)
   Show the numerator and denominator values on each row.
3. Enumerate every campaign whose utilization rate is under {{utilization threshold (e.g., 70%)}} and whose ROAS is at least {{ROAS threshold (e.g., 3x)}}, and make the count match the number of rows in the table. List rows with spend=0 in the period separately as "no delivery," and don't mix them into the increase candidates as 0% utilization headroom. Don't write counts you have not aggregated.
4. Call optimize_target_bids with the matching campaigns specified in campaign_ids and with the target ACoS. Read target_fetch_truncated / target_fetched_pages / target_total_pages_available, and state the target retrieval rate as "pages fetched / total pages." If those fields do not appear in the response, no cutoff occurred, so state "full set retrieved."
5. Fetch the detail with get_proposal and sort by ad spend descending using metadata's spend/sales/orders/clicks (optimize_target_bids' direct response contains no metadata, so always go through get_proposal). Present the current bid (currentValue), proposed bid (recommendedValue), the difference, and the basis for the calculation (reason) in monetary amounts.
   Amazon's suggested bid is not included in the bid proposal's items, but you can fetch the suggested bid (suggested_bid) separately from the target performance list and match it up by metadata's targetId to show alongside. Do not conclude that "the suggested bid cannot be retrieved" based solely on the bid proposal tool's output. For targets that return no suggested bid (e.g., paused ones), state "suggested bid unavailable" and do not treat it as 0.
   There is no surface that returns max CPC, so state "cannot be retrieved" (don't fill in a missing value by guesswork).
6. Separate branded from acquisition using the campaign name, and don't use a low ACoS as the justification for raising bids on branded. Prioritize non-branded for increase proposals.
7. State that the unit of the proposal is the "target (keyword / product target)." Make clear that a product target's ASIN is the ASIN being targeted, not your own advertised ASIN, and don't conflate campaign-level utilization rates with ASIN-level metrics.

[Constraints]
- No filling in by guesswork. Write "cannot be retrieved" for metrics the MCP does not return. That said, do not write "cannot be retrieved" for a value that is available from another tool.
- Stop at presenting the proposal; do not perform any write operations such as execute_proposal / execute_ads_adjustment_workflow / update_*.
- After presenting it, delete the generated proposal with cancel_proposal and confirm its disappearance with get_proposal.

Before executing, always: present the list of changes (target / current value / new value / Amazon's suggested bid / ad spend impact) and do not apply anything to the platform until approved.
After executing: apply the changes only after the user reviews and approves the proposal, then after {{evaluation period (e.g., 14 days)}} compare ROAS and ACoS with "measuring the effect of a change," judging Revert if they worsened and Keep if they improved.

What you can change — the budget pacing threshold (under 70% in the example).

What you get back — a table of campaign × product (ASIN) × current bid × proposed bid × expected spend rate.

Changes — no change (proposal only). Applying is done via Prompt 2’s approval flow.

Term note — “under 70%” is the guideline for judging that a campaign “has not yet used up its budget”.

Next steps — to apply the proposals, go to Prompt 2.

Prompt 7: Propose excluding high-click, no-sales targets

Find search terms and product targeting that get many clicks but no sales over the past 14 days, and create exclusion proposals.

When to use — when you want to clean up targets that keep costing money without turning into sales.

What you need — the clicks / CPC / ROAS thresholds (defaults below).

From the ad target performance over the past {{evaluation period (e.g., 14 days)}}, surface the wasteful targets that simultaneously satisfy 20 or more clicks, a CPC above ¥100, and a ROAS below 0.5 (= an ACoS above 200%), and create an exclusion candidate list and an exclusion proposal (Proposal). Do not apply anything to the platform at all until approved.

[Procedure]
1. Fix the period: check with get_data_ingestion_status the last day on which "Targeting SP" is completed, take that day as the end date, and set the start date by going back the length of the evaluation period. Today is easily fully_missed, and writing "the past N days" as is silently makes the effective window N-1 days, so always state the from_date / to_date you actually used in the output. Look at the per-report status, not rollup_status.

2. 🔴 Always pass min_clicks when fetching the candidates. Call list_target_performance with min_clicks=20 and target_types specified.
   min_clicks is filtered on the upstream server side, so the population starts out smaller.
   Confirm that server_filter_applied in the response is true and state it in the output.
   * The workaround for "the upstream is sorted by sales descending, so high-ACoS, low-sales rows get missed" is unnecessary.
     Specifying the filter changes the sort order to clicks descending, and high-ACoS, low-sales rows all enter the population (because they have clicks).
     Measured: with min_clicks=10 / target_types=KEYWORD / 14 days, fetched_row_count 295 against total_results 295, for 100% coverage.
     That set included rows like ACoS 1578% (sales ¥800 / ad spend ¥12,627) as well as rows with zero sales.
   * To narrow the low-sales tier further, combine it with max_sales (applied after fetching and reflected in filtered_row_count).
   * There is no filter argument for campaign_id, so aggregate the per-campaign breakdown yourself from the campaign_id on the returned rows.

3. Calculate it yourself: compute CPC = spend ÷ clicks and ROAS = sales ÷ spend for each row yourself, and keep only the rows satisfying all 3 conditions.
   The response's roas and acos fields are expressed as percentages, not multiples, so don't use them for the threshold judgment
   (measured: on a row with sales 2,540 / spend 5,160.09, the roas field is 49.22 — that is 49.22%, not 0.4922).

4. Preprocessing: (a) Check duplicate_rows_folded in the response and report it. If this value is returned, the tool has already folded the duplicates and you don't need to deduplicate yourself (only if it isn't returned, deduplicate by target_id + ad_group_id). (b) Check campaign_type and display SP / SB / SD separately (the tools that execute the exclusion belong to different families).

5. Fetching the zero-sales candidates: 🔴 pass zero_sales_only=true together with min_clicks and fetch them directly.
   This is an upstream server-side filter, so you can reach the zero-sales rows directly
   (measured: zero_sales_only=true + min_clicks=5 gave total_results 182 / fetched 175 = 96.2% coverage.
   The returned rows all had sales/units/purchases of 0, with spend between ¥5,357 and ¥12,331).
   The claim that "not a single zero-sales target can be retrieved, structurally" is wrong.
   * zero_sales_only also includes rows where sales were not retrieved (null), treating them as 0, so confirm row by row that sales, units, and purchases are all three 0 before adding it to the candidates.
   If you also use detect_negatives, use it as a supplement and transcribe search_term_fetched_pages / search_term_total_pages_available (the upstream can be cut off even when candidates_truncated is false).

6. Output: show the term/ASIN, kind (KEYWORD/TARGET), ad type (SP/SB/SD), campaign name, campaign_id, clicks, spend, sales, the calculated CPC, the calculated ROAS, and suggested_bid together so the numbers can be re-checked. Put the "zero-sales group" and the "low-ROAS group" in separate tables, each sorted by spend descending. Whenever you give a ratio, always state the numerator, denominator, and number of days.

7. Disclose the retrieval rate: transcribe total_results / fetched_row_count / filtered_row_count / returned_row_count as they are, and calculate coverage = fetched_row_count ÷ total_results.
   When a filter is passed, total_results is "the total number matching the conditions," not "the number of all targets in the period." Write this distinction.
   If coverage is 100% you may write "this is the full set under these conditions"; if it is under 100%, raise max_pages (limit 100 pages = 10,000 rows, default 20) and re-fetch. If it still falls short, state explicitly that "the matching count cannot be determined."

[Constraints]
- Do not perform any write operations such as registering exclusions or changing bids. Stop at generating the Proposal, and don't call execute_proposal.
  If you do not approve a generated Proposal, always discard it and report that you discarded it (a proposal stays in the account awaiting approval for 24 hours, and there is no way to find it in a list).
- Confirm the rollback path before approval: SP keyword exclusions can be reverted to state=PAUSED with update_sp_negative_keywords, but list_sp_negative_keywords, which you use to look up the target IDs, returns total_count=0 when ad_group_id is omitted, so you must record the campaign_id and ad_group_id of anything you exclude. Drop from the candidates any target for which you cannot take that record.
- Do not run this unattended as "automatic exclusion." manage_automation_rules' negative rules are propose_only / on_demand only in Phase 1 — scheduled automatic execution is not possible.
- The upstream aggregation is cached for about 4 hours, so state that recent bid changes and delivery results may not be reflected.

[Follow-up] If the exclusions are executed after approval, re-fetch the target campaigns' CTR and ROAS after {{evaluation period (e.g., 14 days)}} and confirm there is no adverse impact on CVR and sales. Measure at the ad group level rather than on the excluded target alone (an excluded target will always be -100%).

What you can change — the clicks / CPC / ROAS thresholds.

What you get back — a table of target (search terms and product targeting) × clicks × CPC × ROAS × recommended match type.

Changes — no change (proposal only). Applying is done via Prompt 2’s approval flow, or in Add negative keywords.

Term note — “20 or more clicks” narrows to targets that have enough data to judge; “CPC above ¥100 and ROAS below 0.5” are examples of targets “spending more than they return”. All of these can be changed to fit your operation.

Next steps — carry out the exclusion in Add negative keywords.

Prompt 8: Produce a restart plan for ads whose delivery has stopped

Produce a restart plan for active SP campaigns that have had zero delivery over the past 24 to 48 hours.

When to use — when an ad that should be running suddenly stops being delivered, and you want to know the cause and how to respond.

What you need — the target period (default is the past 48 hours).

Identify active SP campaigns with zero delivery (impressions = 0) over the past 48 hours, and present a restart plan that selects only the ones it is safe to restart. Do not perform any write operations.

[0. Fix the target period (always do this first)]
Check the finalized dates with get_data_ingestion_status, and take as the target period "the most recent 2 finalized days," excluding days whose rollup_status is fully_missed / in_progress. Always state the period you used and the dates you excluded.
* If you judge on a 1-day window that includes an unfinalized day, every campaign looks like "zero delivery." A combined window that includes a finalized day gives the same result even with an unfinalized day mixed in, but always state the target period.

[1. Fix the population]
Fetch every ENABLED campaign with start_existing_sp_campaigns_job (state=enabled, from_date/to_date = the finalized period above) → get_mcp_job_status → get_mcp_job_result. Don't use the sync version list_existing_sp_campaigns — it times out. Check truncated / row_count and state that you retrieved the full set.
Define "zero delivery" as impressions=0. Don't substitute spend=0 or clicks=0 (that pulls in healthy campaigns that are delivering but simply not getting clicks). Show the counts for impressions=0, spend=0, and clicks=0 side by side to make the difference between the definitions visible.

[2. Selection and ordering]
After stating the full matching count, select the top {{count (e.g., 10)}} by daily budget descending. State that the daily budget is only a proxy for the size of the opportunity, not the expected recovery amount. Arbitrarily taking the first few is prohibited. Also state what percentage of the population's total daily budget the selected top group accounts for.

[3. Isolating the cause for each campaign (always check all of the following, in this order)]
(a) Budget cap — a campaign with impressions=0 has spend=0, so the budget cap cannot be the cause. Consider it only when spend>0.
    * budgetUtilizationRate is "spend ÷ dailyBudget" and is not divided by the number of days in the period. Over a window of 2 days or more it inflates by a factor equal to the day count, so always normalize to "period spend ÷ (dailyBudget × the number of days)" before judging.
(b) The ad (product) side is stopped — get each ad group's product ad state with list_sp_product_ads. If there are 0 ENABLED ads, or most are PAUSED / ARCHIVED, delivery will not come back no matter how you touch bids or budgets. Check this first.
(c) Inventory — check the ASINs linked to ENABLED ads with get_fba_inventory. If daysOfSupply is below the evaluation period, or sellableInventory is minimal, judge it "do not restart (secure inventory first)." Don't recommend a restart without checking inventory.
(d) Over-narrowed targeting — actually fetch the targets with list_sp_keywords and state total_in_period. If it is 0, state "targets could not be retrieved" and don't write a bid value. If keyword_fetch_truncated is true, state the pages fetched and total pages together.
(e) Insufficient bid — give the gap rate between current_bid and suggested_bid. Some targets have a null suggested_bid, so always state the number for which the gap rate could be calculated versus the sample count, and don't assert anything for those it couldn't.
(f) If none of the above explains it, state "cause unknown." Don't fill it in by guesswork.
* IS% (impression share) cannot be retrieved at the target level, so don't use it as a basis.

[4. Handling deliberate stops (cannot be omitted)]
Campaigns have no end-date field, and manage_event has no campaign linkage, so things stopped deliberately — "the seasonal push ended," "the product was discontinued" — cannot be identified mechanically. Therefore state for every campaign that "whether the stop was deliberate cannot be determined," and require the operator's confirmation before any restart is executed. For campaigns where a deliberate stop is suspected from the campaign name or the PAUSED state of the ads, put them in a separate group as "needs review," with that basis.

[Guardrail]
Do not perform any write operations such as bid changes, state changes, or creating/updating automation rules. Execute only after approval.

Finally, output these 3 items.
1. Recommended action — based on the determinations in [3], sort them into the 3 categories "restart recommended," "needs review (suspected deliberate stop / cause unknown)," and "restart not recommended (insufficient inventory / ads stopped)," and for the restart-recommended ones only, assign priorities by daily budget size and show the cause-specific response (raise bids / re-enable the ads / broaden targeting). Write the expected effect for each one (the expected recovered impressions and the basis for the assumed sales), and where there is no supporting data, state "cannot be estimated"
2. How to execute it — apply it only after the user reviews and approves the proposal (this prompt does not execute)
3. Measurement — {{evaluation date (e.g., 7 days later)}} after the restart, re-fetch impressions and ACoS. Apply the same finalized-data boundary as [0] when re-fetching, and don't include unfinalized days. Keep if it recovered and ACoS is within the acceptable range; Revert if it worsened