Skip to content
Picaro.AI Picaro.AI Prompt Library

Adjust bids

On this page you adjust bids — the biggest lever for moving ACoS toward your target. From lowering and raising bids at the keyword level, to surfacing keywords worth re-bidding, a cross-target review spanning keywords / ASIN targets / auto-targets, following the trend of Amazon’s suggested bid, improving top-of-search impression share, and tuning or directly setting placement bid multipliers, this page offers 10 patterns.

About this page

Section titled “About this page”
ItemDetails
What you can doCreate bid and placement-multiplier reduction / increase proposals from performance data, surface keywords worth re-bidding, make adjustments in line with Amazon’s suggested bid and top-of-search impression share, and directly set or roll back placement multipliers
Applies toMainly Sponsored Products (SP)
Data & connection neededPerformance data from a connected account (no extra setup). If you have registered KPI targets, the target ACoS is referenced automatically
ScopeVaries by prompt. Most are proposal only and are not applied to your ads until you approve. However, Prompt 3 does not change bids — it only carves out exclusion candidates (executed on another page) — and Prompt 7 applies a placement-multiplier preview via manual execution after approval. Each prompt states its own in “Changes”

When to use this

Section titled “When to use this”
  • You want to lower bids on keywords whose ACoS is above target
  • You want to surface, from keywords with click and purchase history, the ones whose bids should be reviewed
  • You want to carve out search terms and product targeting that get clicks but no sales as exclusion candidates
  • You want to adjust bids in line with how Amazon’s suggested bid is moving or with top-of-search impression share
  • You want to tune bid multipliers per placement (top of search, product pages, etc.)
  • You want to set a placement’s bid multiplier directly to any value, or undo a past adjustment
  • You want to bulk-lower bids on low-ROAS campaigns or high-ACoS keywords

Before you run

Section titled “Before you run”
  • Target account … if you handle multiple accounts, the account that creates the proposal and the account you apply it on must match.
  • Target period … such as “the last 30 days.” Today’s and yesterday’s data may not be finalized, so a recent, finalized period is safest (for Prompt 5, specify a finalized week).
  • Target ACoS / ROAS … if you register them in Set targets for sales, ad spend, and ACoS, the judgment criteria are referenced automatically and you can skip specifying them each time.

Quick reference

Section titled “Quick reference”
GoalWhat you getChangesPrompt
Lower bids on keywords above target ACoSA list of reduction candidates with suggested bidsApplied after approval (bid reduction)Prompt 1
Review keywords with proven clicks and purchasesA list of review candidates with suggested bidsApplied after approval (bid review)Prompt 2
Carve out zero-sales targets as exclusion candidatesA list of exclusion candidatesNo change (only carves out exclusion candidates; executed on another page)Prompt 3
Optimize bids by impression share and CVRRaise / lower adjustment proposalsApplied after approval (bid adjustment)Prompt 5
Identify low-ROAS campaigns and adjust bidsA list of target campaigns and recommended actionsApplied after approval (bid adjustment)Prompt 8
Bulk-lower bids on high-ACoS keywordsA list of reduced bids and expected ACoSApplied after approval (bulk bid reduction)Prompt 9
Review bids across keywords, ASIN targets, and auto-targetsA cross-target list of review candidates with direction and Amazon’s suggested bidApplied after approval (bid adjustment)Prompt 10

Prompt 1: Lower bids on keywords above target ACoS

Section titled “Prompt 1: Lower bids on keywords above target ACoS”

Safely lower bids, with justification, on keywords whose ACoS is above target.

When to use — when you want to lower bids, based on performance, on keywords exceeding your target ACoS.

What you need — target ACoS (auto-referenced if KPI targets are registered), target period (defaults to the last 30 days).

Against a target ACoS of {{TARGET_ACOS (e.g., 20%)}}, for keywords that were delivering (DELIVERING) over the last {{DATE_RANGE (e.g., 30 days)}} and that have {{MIN_CLICKS (e.g., 10)}} or more clicks and some sales, list the candidates whose bid should be lowered, alongside Amazon's suggested bid. The goal is to bring ACoS within target while maintaining ad-attributed sales.
Include in the output "target keyword / match type / campaign / clicks / orders / ad spend / sales / ACoS / current bid / new bid / Amazon's suggested bid / expected impact," and sort by the ACoS overage (ad spend − sales × target ACoS) in descending order.
Limit any single reduction to at most {{MAX_DECREASE_RATIO (e.g., 30%)}}. Also show how many candidates hit that reduction cap without reaching the target ACoS, and state explicitly when a single adjustment will not get them to target.
Present Amazon's suggested bid as "a reference value that leans toward maximizing exposure and does not account for the target ACoS," and do not assume that bids should be matched to it.
Data-fetch premises: always state the number of rows fetched, the upstream total, and whether paging ran to completion (whether a cutoff occurred). If a cutoff occurred, either split the scope and re-fetch, or state explicitly that rows may have been missed. Do not fill in figures you could not retrieve with guesses.
Guardrail: exclude from the proposal any keyword where {{metric to protect (e.g., Orders)}} has already fallen to {{GUARDRAIL_THRESHOLD (e.g., -10%)}} or worse versus the prior period over the last {{GUARDRAIL_PERIOD (e.g., 7 days)}}, since lowering its bid further would compound the damage. Do not exclude keywords for which prior-period comparison data cannot be retrieved — label them "Guardrail unverified" and state how many there are.
Before executing, always: present the list of changes (target keyword / current bid / new bid / expected impact) and do not apply anything to Amazon Ads until approved.
After executing: at {{evaluation date (e.g., 7 days later)}}, compare Before/After for ACoS and Orders, and present one of Keep/Expand/Adjust/Pause/Revert/Investigate.

What you can change — the target period (e.g., the last 30 days) / the minimum number of clicks to evaluate (e.g., 10 or more) / the condition of having sales. If you register a target ACoS in KPI targets, it is referenced automatically.

What you get back — a table of keyword × current bid × suggested bid × expected ACoS (5–20 items).

Changes — lowers bids after approval (nothing is applied until you approve).

Next steps — apply the proposal through the approval flow in Save rules to systematize proposal approval and monitoring.

Prompt 2: Surface keywords whose bids should be reviewed

Section titled “Prompt 2: Surface keywords whose bids should be reviewed”

Surface, in one pass, the keywords that have a meaningful number of clicks and purchases and are worth re-bidding.

When to use — when you want to list, for keywords with a track record, both raise and lower review candidates in one pass.

What you need — the target period (defaults to the last 30 days), and the minimum-clicks / minimum-purchases conditions.

Using the last 30 days (finalized data only; today is not yet ingested, so make the end date yesterday), list the keywords with 10 or more clicks and 1 or more purchases whose bid should be reviewed.


[Data fetch]
1. Consolidate the source of the figures into list_target_performance (target_types=["KEYWORD"], min_clicks=10). ACoS differs from optimize_target_bids even for the same keyword, so do not mix figures from the two. State the source you adopted at the top.


2. 🔴 min_clicks is filtered on the upstream server side, so always pass it.
   When passed, the sort order changes to clicks descending and the population gets smaller.
   Measured: with min_clicks=10 / target_types=KEYWORD / 14 days, fetched_row_count 295 against total_results 295 = 100% coverage, server_filter_applied: true.
   That set included rows like ACoS 1578% (sales ¥800 / ad spend ¥12,627) — low-sales, high-ACoS — as well as rows with zero sales.
   * The premise that "the low-sales, high-ACoS keywords worth re-bidding structurally fall outside the fetch range" applies only when min_clicks is not passed.
     This prompt's condition is "10 or more clicks," which converts directly into the server-side filter.
   * To narrow the low-sales tier further, combine it with max_sales (applied after fetching, reflected in filtered_row_count).


3. Always transcribe total_results / fetched_row_count / filtered_row_count / returned_row_count at the top,
   and calculate coverage = fetched_row_count ÷ total_results.
   When a filter is passed, total_results is "the total number of rows matching the conditions" (not the number of all keywords in the period).
   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, and only if it still falls short, state explicitly that "the matching count cannot be determined."


4. There is no filter argument for campaign_id, so filter afterwards by {{target campaign group (e.g., the top 20 campaigns by ad spend)}}, and show how many were excluded and the breakdown. Apply the purchase-count condition after fetching as well.
   * Check duplicate_rows_folded in the response and include the folded count in your report (if this value is returned, you don't need to deduplicate yourself).


[Output]
5. For each keyword, show current bid (bid) / Amazon's suggested bid (suggested_bid) / ACoS / clicks / purchases / ad spend / sales / top_of_search_impression_share together (they are all on the same row, so no separate tool is needed).
   For rows where suggested_bid looks pinned to a ceiling (e.g., several rows clustered at the overall maximum), note "possibly pinned to a ceiling" and don't use it as a target value (the existence of a ceiling is unverified, so don't assert it).
6. The acos / roas fields are expressed as percentages, not multiples (measured: on a row with sales 2,540 / ad spend 5,160.09, roas = 49.22). Align the units when using them for tier thresholds.
7. Split ACoS into 3 tiers: high (over 100%) / mid ({{mid-tier floor (e.g., 40%)}}–100%) / low (under {{mid-tier floor}}). State the adjustment rate per tier as {{high-tier adjustment (e.g., -40%)}} / {{mid-tier adjustment (e.g., -20%)}} / {{treatment of the low tier (e.g., hold)}} immediately before the table.
8. Name the column "proposed adjustment (current bid × N%)" and do not mix it with either Amazon's suggested bid or the recommended_value from optimize_target_bids. Do not substitute max_decrease_ratio from optimize_target_bids for it.
9. If the low tier includes branded keywords, list them separately and exclude them from the blanket adjustment. When judging by campaign name, note that the separators mix half-width | and full-width ｜.
10. If there is no data to estimate the change in clicks and CPC, do not state an expected ad-spend saving from the reduction — write "cannot be calculated."


[Guardrail]
- Do not execute any write tools (execute_proposal / update_sp_keywords / apply_task_operation, etc.) at all. Route the list to {{approval process (e.g., review by the owner)}} and do not apply it to the platform until approved.
- {{metric to protect (e.g., clicks within -20% week over week)}} is an after-the-fact metric that cannot be judged at proposal time. Do not use it as an exclusion condition at the proposal stage — state it as "a condition to monitor after execution," along with who checks it and when. If there is no automated monitoring in place, say so.
- For rollback purposes, always include target_id / keyword / match_type / campaign_name / ad_group_id / the bid before the change in the list (bid changes are not recorded in the change history API, so this list is the restoration record).


[After executing]
- At {{evaluation date (e.g., 7 days later)}}, re-fetch ACoS and clicks with the same tool, the same number of days, and the same conditions through the finalized date (the same min_clicks value), compare them, and present one of Keep/Expand/Adjust/Pause/Revert/Investigate with the criteria used.
- The upstream aggregation is cached for about 4 hours, so state that a re-fetch immediately after applying may not yet reflect the bid changes.
- If automatic cross-checking against the change history is not possible (e.g., get_change_history returns 0 records), state that the bids actually applied need to be reconciled on the approval-record side. If you pass get_change_history a start date more than 90 days back, it automatically rounds it up and returns the adjusted start date in a note — cite that date as "the range we could confirm."

What you can change — the target period (e.g., the last 30 days) / the minimum number of clicks (e.g., 10 or more) / the minimum number of purchases (e.g., 1 or more).

What you get back — a table of keyword × current bid × suggested bid × expected ACoS.

Changes — reviews bids after approval (nothing is applied until you approve).

Next steps — apply the proposal through the approval flow in Save rules to systematize proposal approval and monitoring.

Prompt 3: Carve out zero-sales keywords and product targeting as exclusion candidates

Section titled “Prompt 3: Carve out zero-sales keywords and product targeting as exclusion candidates”

List keywords and product targeting that are getting clicks but no sales as exclusion candidates — rather than lowering their bid. This prompt does not change bids; it only carves out exclusion candidates.

When to use — when you want to organize, as exclusion candidates, targets that only consume clicks without turning into sales.

What you need — the target period (defaults to the last 30 days), and the minimum-clicks condition.

Using the last {{DATE_RANGE (e.g., 30 days)}} of data, list targets that have {{MIN_CLICKS (e.g., 10)}} or more clicks but zero sales as exclusion candidates, in order to cut wasted ad spend.


Scope: {{filter conditions (e.g., target type = keyword / delivery status = delivering)}}


Fetch procedure (follow this order):
1. 🔴 Use the server-side filters. Call the target performance list passing both zero_sales_only=true and min_clicks={{MIN_CLICKS (e.g., 10)}}.
   Both are filtered on the upstream server side, so the population starts out smaller and you can reach zero-sales rows directly.
   Confirm that server_filter_applied in the response is true, and state this in the output.
   * The workaround for "results come back sorted by sales descending so you can't reach the zero-sales rows" is unnecessary.
     Specifying the filters changes the sort order to clicks descending, so the sales-descending problem does not arise.
     There is also no need to force the scope narrower.
   * The page-fetch limit is max_pages up to 100 (100 rows per page); when omitted it is 20.
     If the count is still large even with the filters, raise max_pages.
2. Report the count fields from the response as they are: total_results (the upstream total matching the conditions) /
   fetched_row_count / filtered_row_count / returned_row_count.
   Calculate coverage = fetched_row_count ÷ total_results, showing both the numerator and denominator.
   * When zero_sales_only and min_clicks are passed, total_results is not "the number of all targets in the period"
     but "the total number matching the conditions." Write this distinction in the output.
   If coverage is under 100%, state that these are "results within the fetched range" and do not assert that they cover the whole account.
3. Check duplicate_rows_folded in the response and include that value (the number of duplicate rows the tool folded) in the output.
   If this value is returned, the tool has already folded the duplicates and you don't need to deduplicate yourself.
   Only if it is not returned, deduplicate by target_id before totaling the counts and ad spend.
4. 🔴 Show the basis for "zero" row by row. zero_sales_only also includes rows where sales were not retrieved (null), treating them as 0.
   So don't trust the filter: confirm that sales, units, and purchases are all three 0 on each row
   before adding it to the candidates. Put any row with even one null in a separate group as "sales not retrieved (cannot be asserted as zero)."
5. For each candidate, include from the same row spend (the actual ad spend that could be cut), clicks, impressions, bid, suggested_bid,
   top_of_search_impression_share, campaign_name, ad_group_id, and target_id
   (they are all in the same response, so there is no need to call another tool).
   Always record and present target_id and ad_group_id so the change can be reverted later.


Handling of your own brand terms and defensive keywords:
- Present candidates matching {{BRAND_TERMS (e.g., a list of your brand names and abbreviations)}} in a separate group as "requires individual review before exclusion," apart from the normal candidates.
- Do not judge whether something is a brand term by your own guess. State the basis for the judgment (the brand term matched, the campaign naming convention), and present it on the premise that a human makes the final call.
- Campaign names mix the half-width | and full-width ｜ separators. If you judge by a naming convention, handle both.


Before executing, always: present the list of changes (target / campaign / clicks / ad spend / estimated saving) and do not apply anything to Amazon Ads until approved.
Present the estimated saving as "the total spend actually used within the period," not as a forecast of future savings.


Guardrail: {{metric to protect (e.g., Orders within -5% week over week)}}. After confirming that each candidate's order count was measured as zero within the period, also show the account-wide recent Orders and ad spend as a baseline. Since Orders cannot be forecast at the target level, state that the halo effect of an exclusion cannot be judged in advance and must be confirmed with measured results afterwards.
Guardrail: the upstream aggregation is cached for about 4 hours, so state that recent bid changes and delivery results may not be reflected.


After executing: at {{evaluation date (e.g., 14 days later)}}, compare Before/After for ad spend and Orders, and present one of Keep/Expand/Adjust/Pause/Revert/Investigate. At that point, also check whether an existing trend unrelated to the change is confounding the result. 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 target period (e.g., the last 30 days) / the minimum number of clicks (e.g., 10 or more).

What you get back — a table of candidate (search term / product targeting) × type × clicks × ad spend × sales.

Changes — no change (only carves out exclusion candidates). Bids do not change. The actual exclusion is done on the next page.

Next steps — after approval, register them for execution through the approval flow in Add negative keywords.

Prompt 4: Optimize bids by top-of-search impression share and CVR

Section titled “Prompt 4: Optimize bids by top-of-search impression share and CVR”

This combines the top-of-search slots you’re still missing (impression-share headroom) with the week-over-week change in CVR, and simultaneously surfaces the keywords whose exposure should grow and those that should be reined in.

When to use — when you want to decide, from both impression share and CVR, which keywords to raise and which to hold back at the same time.

What you need — the target period (specify a recent, finalized week).

Using the most recent finalized week, compare top-of-search impression share and CVR
against the previous week, then propose adjustments: raise bids on keywords that still
have impression-share headroom, and lower bids on keywords whose CVR is dropping.

What you can change — the target period (a finalized week) / the criteria for raising and lowering.

What you get back — a table of keyword × current bid × top-of-search impression share × CVR week-over-week × recommended action.

The idea — even if you keep raising bids to grow impression share, past a certain point CVR stops keeping up (and even starts to fall). This adjustment finds “the impression-share ceiling at which CVR holds,” grows the keywords that still have headroom, and reins in the keywords that have gone past the ceiling.

Changes — adjusts bids after approval (nothing is applied until you approve).

Next steps — apply the proposal through the approval flow in Save rules to systematize proposal approval and monitoring.

Prompt 5: Identify low-ROAS campaigns and adjust bids

Section titled “Prompt 5: Identify low-ROAS campaigns and adjust bids”

Identify SP campaigns whose ROAS is low (on the verge of running at a loss) over a recent period, and propose bid adjustments.

When to use — when you want to narrow down inefficient campaigns and build bid adjustment proposals.

What you need — the target period (defaults to the past 30 days), the ROAS threshold (default is under 2x), the minimum ad spend (over ¥50,000 in the example).

Identify SP campaigns whose ROAS is under {{ROAS threshold (e.g., 2.0)}}x over the last {{analysis period (e.g., 30 days)}} and whose ad spend is over ¥{{ad spend floor (e.g., 50000)}}, and propose bid adjustments.


[Data premises]
- Set the period to run through the day on which get_data_ingestion_status(daily) reports every report as completed, and do not include days that are fully_missed / in_progress. State the dates you excluded at the top.
- Standardize ROAS on the campaign-detail family (sales / spend from start_existing_sp_campaigns_job). Numerator = ad-attributed sales (for SP, a 7-day click attribution, tax included); denominator = ad spend (tax treatment undetermined). Do not mix it with the get_dashboard values (all ad types + DSP, a denominator with different tax treatment). State the source, attribution window, and number of days you used.


[Procedure]
1. Fetch all SP campaigns via start_existing_sp_campaigns_job → get_mcp_job_status → get_mcp_job_result, and state the rows fetched / total count / fetch rate plus truncated / total_pages / next_page_token at the top. (analyze_ad_type_performance does not lump things together if you restrict campaign_types, and its totals do cover the full set, but the detail rows it returns are limited to the top_n (max 100) by ROAS descending, so it cannot enumerate the low-ROAS side — don't use it for enumeration. You may use it to cross-check the totals.)
2. Enumerate every campaign matching the conditions, and make the count match the number of rows in the table. Sort by ad spend descending, and before outputting, self-check that the magnitude of the amounts matches the sort order. Also show the boundary values that straddle the thresholds (the lowest ad spend, the highest ROAS).
3. For the top {{number of campaigns to detail (e.g., 10)}} by ad spend, run optimize_target_bids with campaign_ids specified, and present "current bid → proposed bid → rate of change" per target in concrete amounts.
   - Pass {{target ACoS (e.g., 0.35)}} to target_acos. If you cannot, report target_acos_usable_as_target / target_acos_source / target_acos_safety_constraints as they are, and state explicitly whether the basis for judgment has been swapped from a target value to an observed value (TACoS, etc.).
   - Always give the number of proposals that increase / decrease / hold, and the proportion that are pinned to the decrease cap or the increase cap. If every row has the same rate of change, state explicitly that it is "pinning to a cap, not a difference driven by the data."
   - Always report target_fetch_truncated / target_fetched_pages / target_total_pages_available, and if a cutoff occurred, state explicitly that this is "not every target of the top N campaigns." If those fields do not appear in the response, no cutoff occurred, so state "full set retrieved."
   - Amazon's suggested bid is not included in the output of optimize_target_bids, but you can fetch the suggested bid (suggested_bid) separately from the target performance list and match it up via the targetId in get_proposal's metadata 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. Also show the count and representative examples where the ACoS-derived proposed bid and Amazon's suggested bid point in opposite directions.
4. Aggregate the count, ad spend, sales, and ROAS by the Generic/Competitor/Branded role, and differentiate the adjustment policy by role; for roles with zero matches, say so. Calculate priority as "ad spend × ROAS improvement headroom rate (= (ROAS threshold − actual ROAS) / ROAS threshold)," and state the formula and the scores of the top 5.
[Constraints] Do not write counts you have not aggregated. Do not fill in items the MCP does not return with guesses. That said, do not write "cannot be retrieved" for a value that is available from another tool. State explicitly that estimated figures "are not MCP return values."


Before executing, always: present the list of changes (target / current value / new value / Amazon's suggested bid / expected impact) and do not apply anything to the platform until approved. Do not run execute_proposal / execute_ads_adjustment_workflow / update_sp_targets before approval, and delete any proposal generated for verification with cancel_proposal, confirming its disappearance with get_proposal.
After executing: apply the changes only after the user has reviewed and approved them, then after {{evaluation period (e.g., 14 days)}} compare ROAS and Orders with "measuring the effect of a change," judging Keep if ROAS improved and Orders did not worsen by more than -10%, and Revert if it did. Align the comparison to the same attribution window and the same window length ({{evaluation period}}), and state the window length in the output.

What you can change — the target period (e.g., past 30 days → past 14 days) / the ROAS threshold (e.g., under 2x → under 3x) / the minimum ad spend (e.g., over ¥50,000). Reword the numbers to adjust.

What you get back — a table of campaign × ROAS × spend × ACoS × recommended action.

Changes — adjusts bids after approval (nothing is applied until you approve).

Next steps — apply the proposal through the approval flow in Save rules to systematize proposal approval and monitoring.

Prompt 6: Bulk-lower bids on high-ACoS keywords

Section titled “Prompt 6: Bulk-lower bids on high-ACoS keywords”

Identify keywords whose ACoS is high over a recent period, and build a proposal to lower their bids in bulk.

When to use — when you want to lower, all at the same rate, keywords that have exceeded your ACoS benchmark.

What you need — the target period (past 14 days in the example), the ACoS threshold (over 40% in the example), the reduction rate (12% in the example), the minimum clicks (10 or more in the example).

Using finalized data from the last {{analysis period (e.g., 14 days)}}, identify keywords whose ACoS exceeds {{ACoS threshold (e.g., 40%)}} and that have {{minimum clicks (e.g., 10)}} or more clicks, and build a proposal to lower their bids by {{reduction rate (e.g., 12%)}}. Do not apply anything to the platform.


[Procedure]
0. Fix the period: call get_data_ingestion_status first and exclude days that are fully_missed / in_progress. Today is often not finalized, and including it only reduces the day count while contributing nothing. State the confirmed effective period (start date–end date, actual number of days) at the top, and standardize on that period throughout.
   Look at the per-report status rather than rollup_status (a single ad type with no delivery can drop a whole day to no_data).


1. Fix the source of ACoS to one: fetch the per-keyword ACoS, current bid, and Amazon's suggested bid from list_target_performance, and judge against the threshold using that single source only. The ACoS returned by optimize_target_bids is aggregated on a different basis and differs even for the same keyword, so do not use it for the threshold judgment.


2. 🔴 Always pass min_clicks when fetching. Pass target_types=["KEYWORD"] and min_clicks={{minimum clicks (e.g., 10)}}.
   These are filtered on the upstream server side, and the sort order also changes to clicks descending. Confirm that server_filter_applied in the response is true and state it.
   * The premise that "the upstream is cut off in sales-descending order, so the keywords with small sales and high ACoS get dropped" applies only when min_clicks is not passed.
     This prompt's condition is "N or more clicks," which converts directly into the server-side filter.
     Measured: with min_clicks=10 / target_types=KEYWORD / 14 days, fetched_row_count 295 against total_results 295 = 100% coverage.
     That set included exactly the tier this prompt is looking for — ACoS 1578% (sales ¥800 / ad spend ¥12,627), ACoS 203% (¥2,540 / ¥5,160), and so on.
   * To lean further toward high ACoS and low sales, you can combine it with max_sales (applied after fetching, reflected in filtered_row_count).


3. Disclose the fetch range (required): state total_results / fetched_row_count / filtered_row_count / returned_row_count at the top,
   and calculate coverage = fetched_row_count ÷ total_results.
   Note that when a filter is passed, total_results is "the total number matching the conditions."
   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, and only if it still falls short, present the matching count as "a lower bound."


4. Narrowing to target campaigns: there is no filter argument for campaign_id, so do it afterwards using the campaign_id on the returned rows.
   To narrow to the top {{number of target campaigns (e.g., 20)}} by ad spend, fetch the campaigns via start_existing_sp_campaigns_job → get_mcp_job_status → get_mcp_job_result, and state what share of total ad spend those top N account for. Do not use the synchronous list tool — its response is too large.
   * The job response carries two families side by side: total_pages (on the result side) and fetched_pages / total_pages_available (on the upstream side). What you use to judge completeness is truncated plus agreement of the latter pair.
   * Job results can contain completely identical duplicate rows even when truncated=false, so deduplicate by keywordId and state the counts both before and after deduplication.


5. Proposed bid = current bid (bid) × (1 - reduction rate). Round to a whole number.
   If you also show the recommended value from optimize_target_bids, state explicitly that it comes from different logic (derived from a target ACoS, capped at -30%), that when no target ACoS is specified the observed TACoS is used as a provisional basis so only decreases or holds come out, and that the value adopted in this proposal is × (1 - reduction rate).
   * The acos / roas fields are expressed as percentages, not multiples (measured: on a row with sales 2,540 / ad spend 5,160.09, roas = 49.22). Align the units when comparing against the ACoS threshold.


6. Brakes (preventing over-reduction): keywords whose post-reduction bid would fall below {{minimum bid (e.g., ¥20)}}, and keywords whose current bid is already below {{floor ratio to the suggested bid (e.g., 50%)}} of suggested_bid, risk having delivery stop — separate them out of the main list as "not eligible for reduction (requires individual judgment)," and state the count and the reason.
   bid and suggested_bid sit side by side on the same row, so no separate tool is needed for this judgment (measured values: bid 108 / suggested 447, bid 182 / 323, bid 120 / 491, bid 79 / 621).


7. Rollback snapshot (required): always include target_id / keyword / match_type / campaign_name / ad_group_id / the bid before the change in the proposal list. Bid changes are not recorded in the change history API, and the proposal itself expires in 24 hours, so this list is the only restoration record.


8. Present the items prioritized by ACoS descending, and alongside them the total ad spend, sales, and clicks for the target set, plus a combined ACoS with its numerator, denominator, and number of days stated.


[Constraints]
- Do not perform any write operations (execute_proposal / update_sp_keywords / apply_task_operation, etc.) at all. Stop at generating and presenting the proposal.
- If you generated a proposal in the course of verification or analysis, always discard the ones you are not approving and state that you discarded them (a proposal stays in the account awaiting approval for 24 hours, and there is no way to find it in a list).
- Whenever you give a ratio, always attach the numerator, denominator, and number of days.
- The upstream aggregation is cached for about 4 hours, so state that recent bid changes may not be reflected.


Before executing, always: present the list of changes (target / current value / new value / number excluded / expected impact) and do not apply anything to the platform until approved.
After executing: apply the changes only after the user has reviewed and approved them, then after {{waiting period before measurement (e.g., 7 days)}} compare ACoS and clicks with "measuring the effect of a change," using the same period length, the same ACoS source, and the same min_clicks; judge Keep if ACoS improved and clicks did not worsen by more than -20%, and Revert if they did.

What you can change — the target period (e.g., past 14 days) / the ACoS threshold (e.g., over 40%) / the reduction rate (e.g., 12%) / the minimum clicks (e.g., 10 or more). Reword the numbers to adjust.

What you get back — a table of keyword × ACoS × current bid × reduced bid × expected ACoS.

Changes — bulk-lowers bids after approval (nothing is applied until you approve). The prompt specifies that a single reduction stays within -30%.

Next steps — apply the proposal through the approval flow in Save rules to systematize proposal approval and monitoring.

Prompt 7: Review bids across keywords, ASIN targets, and auto-targets

Section titled “Prompt 7: Review bids across keywords, ASIN targets, and auto-targets”

Cross keywords, ASIN targets, and auto-targets — all three target types — and consolidate the bid-review candidates into a single table. Prompts 1, 2, 8, and 9 each review a single target type or campaign scope individually; this prompt is different in that it crosses all three types into one table.

When to use — when you want a single table that consolidates the bid-review candidates across keywords, ASIN targets, and auto-targets at once.

What you need — the target campaign (or the campaigns under a portfolio; required), the target period, the minimum-clicks / minimum-orders conditions, and the target ACoS (auto-referenced if KPI targets are registered).

Using the last {{DATE_RANGE (e.g., 30 days)}} of data, for keywords, ASIN targets, and auto-targets
with {{MIN_CLICKS (e.g., 10)}} or more clicks and {{MIN_ORDERS (e.g., 1)}} or more orders, list the
candidates whose bid should be reviewed against a target ACoS of {{TARGET_ACOS (e.g., 20%)}}, including
the direction (increase/decrease) and Amazon's suggested bid.


[Scope] Run this specifying a target campaign (or the campaigns under a portfolio). If you target
the whole account without specifying a campaign, the upstream data fetch for bid proposals gets cut
off by the page limit and coverage drops to a few percent. Specifying a campaign avoids the cutoff,
so run this at the campaign level as a rule.


[Source for Amazon's suggested bid] Amazon's suggested bid is not included in the bid-proposal tool's
output, so fetch it separately from the target performance list and match it up by target ID. Don't
conclude that "the suggested bid can't be retrieved" based solely on the bid-proposal tool's output.
For targets that don't return a suggested bid (e.g., paused ones), state "suggested bid unavailable"
and don't treat it as 0.


Match-type weighting is fixed on the Picaro side and cannot be specified individually.


[Disclose the fetch coverage] If the data fetch was cut off by the upstream page limit, always state
the pages fetched, total pages, and coverage rate, and caveat that this isn't a complete list of every
target. If no cutoff occurred, state "full set retrieved."


[Direction conflicts] If the ACoS-derived bid change and Amazon's suggested bid point in opposite
directions (e.g., the ACoS basis calls for a decrease but Amazon's suggested bid is above the current
bid), always state the count and representative examples.


Before executing, always: present the list of changes (target / current bid / new bid / Amazon's
suggested bid / expected impact), and do not apply anything to Amazon Ads until approved.


Guardrail: there's no way to simulate the impact on {{metric to protect (e.g., Orders within -10% of
last week)}} before making the change, so approximate it upfront with a cap on the change size
{{maximum swing (e.g., ±30%)}} and a policy of holding steady (even if flagged for a decrease) any
target in the top group accounting for 50% of total Orders, and state that you could not pre-exclude
based on actual impact.


After executing: at {{evaluation date (e.g., 14 days later)}}, compare Before/After for ACoS and
{{metric to protect (e.g., Orders within -10% of last week)}}, and present one of
Keep/Expand/Adjust/Pause/Revert/Investigate.


If zero targets match, propose expanding the period.

What you can change — the target campaign (required) / the target period (e.g., last 30 days) / the minimum-clicks and minimum-orders conditions / the target ACoS / the cap on change size (e.g., ±30%) / the evaluation date.

What you get back — a list table crossing keywords, ASIN targets, and auto-targets, showing direction (increase/decrease) × Amazon’s suggested bid × expected impact. It also shows the count and representative examples where the ACoS-derived direction and Amazon’s suggested-bid direction disagree.

Changes — adjusts bids after approval (nothing is applied until you approve).

Next steps — apply the proposal through the approval flow in Save rules to systematize proposal approval and monitoring.

Section titled “Related categories”