Skip to content
Picaro.AI Picaro.AI Prompt Library

Plan your ad strategy

On this page you can build the decision inputs one level above tactical ACoS and bid adjustments — the brand strategy, budget allocation, and CAC / LTV information the management layer wants to see. Beyond ad efficiency, it analyzes from the full-funnel, cross-product-line, and new-customer-acquisition angles, for monthly to quarterly strategic reviews.

About this page

Section titled “About this page”
ItemDetails
What you can doFrom Sponsored Ads performance, lay out strategy-level decision inputs: funnel decomposition, brand structure, budget allocation simulation, and per-ASIN profitability
Applies toSponsored Ads (SP / SB / SD). Each prompt focuses mainly on Sponsored Products (SP). Amazon DSP and AMC are separate pages (see the note below)
Data & connection neededThe Sponsored Ads performance data Picaro already holds (no extra setup needed for a connected account). Prompts 5 and 9, however, also use AMC (Amazon Marketing Cloud) data, so they cannot be run on accounts where AMC is not connected
ScopeRead-only (analysis only). Budget allocation plans are proposals only; ad settings are not changed. Actual budget, bid, and keyword changes happen through the approval flows on the related pages

When to use this

Section titled “When to use this”
  • Before a new build, you want to inventory the existing campaign structure to avoid naming collisions and duplicates
  • You want to pin down which funnel stage (impressions → clicks → orders) is the bottleneck
  • You want to compare which sells more efficiently — branded keywords or generic keywords
  • You want to explain unprofitability that ACoS alone can’t reveal, through the CAC / LTV and new-customer lens
  • You want to simulate which campaign is best to put additional budget into before allocating it
  • You want to judge, at the ASIN level, ad contribution (sales − ad spend) and which products get clicks but no sales

Before you run

Section titled “Before you run”
  • Target account … if you handle multiple accounts, confirm the right one first.
  • Target period … e.g. “last 30 days”. For strategic analysis that reads long-term trends, 30+ days is recommended. Today and yesterday may not be finalized, so a recently closed period is safer.
  • Target brand / ASIN / portfolio (optional) … specify to narrow to a particular scope. Leave blank to cover the whole connected account.
  • If you register a target ACoS / ROAS in Set targets for sales, ad spend, and ACoS, the “efficient / inefficient” judgment criteria are used automatically.

Quick reference

Section titled “Quick reference”
GoalWhat you getChangesPrompt
Inventory the existing SP campaign structure before a new buildA list of campaign names, statuses, and daily budgets, plus naming-collision cautionsNo changePrompt 1
Find bottlenecks by funnel stageA performance table by funnel × campaignNo changePrompt 2
Compare efficiency between branded and generic keywordsAn aggregate of the Brand vs Generic groups and an ASIN rankingNo changePrompt 3
Explain unprofitability and propose fixes from a customer lensA table of unprofitable target × CAC / estimated LTV × improvement suggestionNo changePrompt 4
Get an added-budget allocation plan to grow new customersA table of allocation target × allocation amount × measured NTB CACNo changePrompt 5
Find the optimal allocation of added budget within existing campaignsA table of campaign × recommended allocation × actual ROASNo changePrompt 6
Analyze why budget isn’t being spentA table of underspending target × likely cause × suggested actionNo changePrompt 7
Build a pre/post-event budget allocation plan by search funnel stageA table of funnel × lead-in / day-of / follow-up allocationNo changePrompt 8
Calculate ad contribution by ASINA table of ASIN × sales × ad spend × ad contributionNo changePrompt 9
Get a performance summary for key ASINs (period totals)A table of ASIN × ad sales / ad spend / ad units sold / ROASNo changePrompt 10
Identify ASINs with high CTR but low CVRA table of ASIN × CTR × CVR × ratio to average × hypothesized causeNo changePrompt 11
Break down the cause of a worsening metric by factorContribution by search term / bid / CPC / CVR / budget / placement, and the priority for actingNo changePrompt 12

Analyze current structure and performance

Section titled “Analyze current structure and performance”

Prompt 1: Check existing campaign structure

Section titled “Prompt 1: Check existing campaign structure”

As a preliminary step before a new build, fetch the list of SP campaigns tied to the referenced ad profile to avoid naming collisions and duplicate builds.

When to use — before creating new campaigns, when you want to inventory the existing structure to avoid naming collisions and duplicate builds.

What you need — the ad profile ID (a connected profile ID; if only one is connected, it is referenced automatically).

List the Sponsored Products campaigns tied to ad profile {{ad profile ID (e.g. 3528945248353716)}}.
This is used for a pre-build naming-collision check and a duplicate-build check.


Show status and daily budget (the creation date is out of scope because Picaro cannot retrieve it from the API. If it is needed, point to the CSV in the Amazon Ads console).


Confirm that the number retrieved matches the total count, and if it does not, re-retrieve with a period specification or similar. If any name is identical or similar to an existing campaign, call it out as a candidate.


Next prompt that uses this result: create new Sponsored Products (SP) campaigns

What you can change — the target ad profile ID.

What you get back — a table of campaign name, status, and daily budget, plus a note when similar names exist.

Changes — no change (read-only). Nothing is written to Amazon Ads.

Next steps — once you’ve checked the structure, use Create Sponsored Products (SP) campaigns to build new ones, and Classify ads with labels and naming rules to tidy up naming rules.

Prompt 2: Break down performance by funnel stage

Section titled “Prompt 2: Break down performance by funnel stage”

Reference the search-funnel KPIs (impressions → clicks → orders) and build a performance report that breaks the past period’s campaigns down by funnel stage.

When to use — when you want to pin down which stage — impressions, clicks, or orders — is leaking, i.e. the bottleneck.

What you need — the target period (e.g. last 30 days, 2026-04).

For SP campaigns over the past {{target period (e.g. last 30 days)}}, compute CTR and CVR per campaign from impressions, clicks, and orders, and identify which funnel stage is the bottleneck.
Goal: identify the bottleneck stage and set the priority for improvements.


Data retrieval (mandatory, single source)
- Impressions / clicks / orders must **always be retrieved together from the same source**.
  `start_existing_sp_campaigns_job` (with from_date / to_date) → confirm `get_mcp_job_status` shows
  `truncated=false` → retrieve every campaign row with `get_mcp_job_result`.
  If a synchronous call is enough, `campaign_rows` from `analyze_ad_type_performance` (campaign_types=["SP"]) is acceptable, but
  `top_n` is **fixed to descending ROAS**, so reconcile against `source_row_count` to confirm nothing was missed.
- **Both CTR and CVR have clicks in the numerator or denominator, so they must never be assembled across several tools.**
  `get_dashboard` does not return clicks. Another tool's CVR field is **based on units sold (sales quantity)**, which comes out
  higher than an order-based figure, so do not use it. **Always compute orders ÷ clicks yourself.**
- Whenever you specify a period, check every time that the period the response returned matches what you asked for.


Handling finalized data
- Before retrieving, run `get_data_ingestion_status` and **exclude from the period** any day that is `fully_missed` (usually today).
  Without that exclusion, the number of days you specified silently drops by one. Unfinalized days come back as zero-filled rows that cannot be
  distinguished from genuine zero performance, so do not use `rollup_status` to judge finalization. State the number of days you actually aggregated in the output.


Calculation and sanity checks
- CTR = clicks ÷ impressions, CVR = orders ÷ clicks. **Every time you produce a ratio, state the numerator, the denominator, and the number of days.**
- Compute the baseline (the average) from the **overall total of the same retrieval**, not from the average of the individual rows
  (overall CTR = overall clicks ÷ overall impressions, overall CVR = overall orders ÷ overall clicks).
- Run these sanity checks and state the results:
  (a) **whether any row has a CVR above 100%** (if so, you have grabbed a units-sold-based column — exclude it and switch to the order-based one)
  (b) whether the rows sum to the overall total (a mismatch suggests the retrieval was cut off)
  (c) whether orders are heavily missing for a particular period (if average order value is an order of magnitude off other periods, suspect missing data)
  A period with missing data must not be judged as "CVR is the bottleneck."
- **Set a statistical floor**: rows with fewer than {{minimum impressions (e.g. 50000)}} impressions,
  or fewer than {{minimum clicks (e.g. 200)}} clicks, are out of scope for the "markedly low" judgment and
  are listed separately as "insufficient sample" (CVR on a small number of clicks swings wildly).
- Confirm that the population at both stages is identical (the clicks in CTR and the clicks in CVR must be the same value).


Bottleneck judgment and ordering
- For each campaign, compute CTR shortfall = (overall CTR − that campaign's CTR) ÷ overall CTR and
  CVR shortfall = (overall CVR − that campaign's CVR) ÷ overall CVR, and take the larger one as the bottleneck stage.
- Impact = impressions × shortfall (the larger one). Order by **descending impact** and output the top {{number of rows (e.g. 10)}}.


Output
1. Premises — the aggregation period (actual days), the data source, overall CTR / overall CVR (with numerator and denominator), the number of campaigns in scope (those with performance / all), and the sanity-check results
2. Bottleneck list — campaign name / stage (CTR or CVR) / impressions / clicks / orders / CTR / CVR / shortfall / impact
3. Recommended action — for the CTR side, revisit creative, bids, and search terms; for the CVR side, revisit the product page, price, and inventory —
   with the target, the priority (by impact), the expected effect, the confidence, and the risk.
   **Compute the expected effect as "the incremental clicks and incremental orders if that campaign's CTR (or CVR) recovered to the overall average," and show the formula behind it** (do not write guessed numbers).
   **Assign confidence mechanically as high / medium / low from the number of clicks and the size of the shortfall** (state the criteria).
   The risk must always include, as a guardrail KPI, **the tolerated ceiling on ACoS deterioration, {{ACoS ceiling (e.g. +5 points vs. current)}}**.
4. How to execute — bid revisions are applied only after the user reviews and approves the proposal, and product-page issues are raised as a check request to the listing owner (this prompt does not execute changes)
5. Measurement — using "measure the effect of an action," re-retrieve CTR / CVR on {{evaluation date (e.g. 4 weeks after implementation)}} **from the same source and with the same formulas as this prompt** and confirm the improvement.
   Show the before and after values, and whether the guardrail KPI (ACoS) stayed within the ceiling.
   ⚠ The change-history API effectively returns nothing, so **you cannot assert that the re-retrieved change was caused by the action.**
   Whoever implements the action must record separately what was done and when.

What you can change — the target period.

What you get back — a table of funnel stage × campaign × impressions / clicks / orders / CVR / ACoS, plus the identified bottleneck stage.

Changes — no change (analysis only).

Next steps — if the click stage is weak, consider Diagnose the catalog and draft improvements; if the order stage is weak, consider Adjust bids.

Prompt 3: Compare performance between branded and generic keywords

Section titled “Prompt 3: Compare performance between branded and generic keywords”

Use campaign names to distinguish Brand (branded keywords) from Generic (generic keywords), and identify the best-performing ASIN groups.

When to use — when you want to compare whether branded search or generic search sells more efficiently, and decide where to focus.

What you need — none (use it as is).

Review all SP campaigns, compare those whose names contain Brand-type keywords
against those with Generic-type keywords, and identify the ASIN groups with the
best performance (ROAS / ACoS / sales).

What you can change — the comparison metric (ROAS / ACoS / sales).

What you get back — an aggregate table for the Brand group vs the Generic group, plus a per-ASIN performance ranking.

Changes — no change (analysis only).

Next steps — Brand / Generic detection accuracy depends on how you name campaigns. To improve it, tidy up your naming rules in Classify ads with labels and naming rules Prompt 6.

Term note — Brand keywords are keywords for branded (name) searches that include your brand name; Generic keywords are non-branded, generic keywords.

Prompt 4: Analyze unprofitability through the CAC and LTV lens

Section titled “Prompt 4: Analyze unprofitability through the CAC and LTV lens”

Decompose the unprofitability that ACoS alone cannot reveal through the CAC (customer acquisition cost) / LTV (lifetime value) lens, and return improvement suggestions.

When to use — when you want to separate, for a high-ACoS target, whether it’s simply worse efficiency or an investment in acquiring customers.

What you need — the target period (e.g. last 90 days; 30+ days recommended to read long-term trends).

Identify the unprofitable campaigns / unprofitable ASINs from the past {{target period (e.g. last 90 days)}},
and explain the causes through a CAC / LTV lens.
Give improvement suggestions from a customer perspective, not on an ACoS axis.

What you can change — the target period.

What you get back — a table of unprofitable campaign × CAC / estimated LTV / improvement suggestion.

Changes — no change (analysis and proposal only).

Next steps — to turn the suggestions into budget and bid changes, run them through the approval flow in Adjust budgets or Adjust bids.

Term note — LTV is an estimate from the sales history Picaro holds.

Simulate budget allocation and brand structure

Section titled “Simulate budget allocation and brand structure”

Prompt 5: Build an added-budget allocation plan to grow new-to-brand customers

Section titled “Prompt 5: Build an added-budget allocation plan to grow new-to-brand customers”

For the goal of growing new customers (NTB, New-to-Brand), present an allocation plan for the additional budget.

When to use — when you want to steer additional budget toward acquiring new customers rather than harvesting existing ones.

What you need — the additional budget amount (e.g. ¥500,000).

If the ad budget is increased by {{additional budget (e.g. ¥500,000)}}, build the allocation plan that maximizes the increase in NTB (new customers).
Goal: allocate the additional budget to the campaigns with the highest NTB acquisition efficiency, to maximize new-customer acquisition.
Scope: active campaigns of {{target ad types (e.g. SP only)}}.


[Step 0 | First determine whether budget is actually the constraint (mandatory, never skip)]
- Retrieve the dailyBudget and period spend of active campaigns via start_existing_sp_campaigns_job → get_mcp_job_status → get_mcp_job_result (the synchronous list_existing_sp_campaigns can fail because the response is too large).
  If a coarse portfolio-level judgment is enough, get_portfolio_budget_summary is acceptable, but then watch for the asymmetry of numerator and denominator described below (spend is the total across all states, daily_budget_sum is ENABLED only).
- Do not use the budgetUtilizationRate in the response as-is. It is "period spend ÷ one day's dailyBudget," so it inflates by the number of days in the period. Always compute true utilization = period spend ÷ (dailyBudget × days in period) yourself, and state the numerator, the denominator, and the number of days. Rows where dailyBudget=0 have the key missing, so do not read that as 0.
  🔴 Do not underestimate the scale of the inflation. In observation, over a 31-day window the tool returned values like "utilization 2694%," "1288%," and "1015%"; divided by the number of days these became 86.9% / 41.5% / 32.7% respectively. A pre-normalization value above 100% means nothing at all.
- If not a single campaign has true utilization at or above {{utilization considered a constraint (e.g. 80%)}}, budget is not the constraint. In that case do not build an allocation table: conclude that "adding budget will not increase NTB. The bottleneck is bids, targeting, or exposure," show the account-wide true utilization with numerator, denominator, and number of days, and stop.


[Step 1 | Measure NTB efficiency (only if Step 0 found a constraint)]
- Use get_amc_metric(metric_name="campaign_attribution"). It has ntb_purchases and total_spend by campaign_id, so you can compute measured NTB CAC = total_spend ÷ ntb_purchases.
- 🔴 Always pass max_rows_per_table. If you omit it, only a sample of the first few rows comes back and truncated: true. Listing NTB CAC for every campaign requires all rows. Pass a value at or above tables[].row_count and confirm truncated: false before aggregating. Do not build an ordering from a sample alone.
- 🔴 Use tables[].row_count for the count (the row count of the selected run). metadata.tables.*.list_row_count is the count across all runs, and in observation it was about 10× the former. Do not confuse the two.
- Do not use get_amc_new_customer (it is brand × month only, has no campaign axis, and cannot be used for allocation).
- Do not use get_amc_ntb_by_asin as a basis for allocation (a known defect makes ad_spend 0 on every row for some ad types; total_dsp_spend is also an unprorated constant).
- The window of campaign_attribution is a fixed long-term accumulation. Always state the returned report_start_date / report_end_date and do not confuse it with recent performance (in observation it was about two years of accumulation, in which a few weeks of change is completely buried).
- Among the active campaigns from Step 0, exclude any with no AMC row as "NTB CAC not computable" and state how many were excluded. Do the same for ad types with 0 ad spend (do not interpret 0 as "acquiring new customers with zero ad spend").
- 🔴 campaign_attribution includes DSP rows. If you narrow to {{target ad types}}, select rows by ad_product_type and state which ad types and how many rows you excluded. DSP's NTB CAC can be an order of magnitude away from SP's, so if you do list them together, show the ad type on every row.


[Step 2 | Allocation plan]
- Only campaigns whose true utilization has reached the constraint level are candidates for allocation.
- Show campaign × current daily budget × true utilization × allocation amount × measured NTB CAC × actual ACoS together in a table, ordered by ascending measured NTB CAC.
- Do not present a "projected NTB increase" as a definite value. The data needed to estimate the NTB increase per additional yen (marginal CAC, budget elasticity, budget-driven lost impression share) does not exist in MCP. Dividing the additional budget by past average NTB CAC overstates the increase by an order of magnitude. Only if a number is required, state it explicitly as "an upper bound assuming measured NTB CAC equals marginal CAC," and always add that it is an assumption and that it does not hold on branded surfaces.


[Guardrail]
- Do not cut an existing campaign's daily budget below {{lower bound (e.g. 80%)}} of its current daily budget amount (a ratio against the daily budget amount, not against utilization).
- ACoS must not exceed {{upper bound (e.g. +3pt)}} versus actuals for {{baseline period (e.g. the last 30 days)}}. ACoS diverges by source, so fix one source and state it.
- For accounts where check_budget_status is unconfigured, or whose portfolios are NO_CAP, state that cap-driven constraints are out of scope for the judgment.
  🔴 When unconfigured, check_budget_status returns null not only for cap but also for ad_spend (observed). Do not use this tool as a source for ad spend.


[Output and approval]
- Present the list of changes (campaign, current daily budget, new daily budget, difference, measured NTB CAC, ACoS) and do not apply anything to the platform until approval is obtained.
- Do not present the total of the budget differences as an effect amount. optimize_budget's items contain only id / label / current_value / recommended_value / reason — spend / sales / estimated_impact do not exist (confirmed by observation). A difference is not an effect.
- If you also use optimize_budget, pass target_acos explicitly (omitting it is a hard error and no proposal is generated). The response records the value you passed and its source in target_acos_goal_resolution, so quote that in the output. That tool has no NTB axis, however, and its increase/decrease judgment rests on the inflated utilization above, so do not use it as a basis for maximizing NTB.
  🔴 The same tool also cannot be narrowed to {{target ad types}} (in observation it returned SP / SB / SBV / SD mixed together), and it presents retired campaigns whose names start with old_ as "recommended increases" (2 of them in observation). Do not list its proposals as-is. Any proposal you generate must be cancelled unless it is approved.


[After execution]
- Apply the proposal only after the user reviews and approves it, and re-evaluate on {{evaluation date (e.g. 4 weeks later)}} with "measure the effect of an action."
- What can be used for the re-evaluation is campaign_attribution_monthly (NTB by campaign_id × month) and ACoS on the ads side. State in the evaluation design that a before/after comparison of NTB CAC is impossible because that table has no spend column (confirmed by observation: it returns only purchase_uv / ntb_uv / repeat_uv / total_purchases / ntb_purchases / repeat_purchases / product_sales), and that campaign_attribution, which does have spend, is a long-term cumulative window in which a few weeks of change is buried.
- 🔴 Joining the two tables on campaign_id is fine, but the ad-type column name and value notation differ. campaign_attribution uses ad_product_type (observed values: SPONSORED_PRODUCTS / DSP), while campaign_attribution_monthly uses ad_type (observed values: sponsored_products / DSP). Do not join on exact string equality (the casing does not line up).
- get_change_history sometimes returns no change history, so record what was implemented separately (registering it in the initiative log of manage_measure is the proper route).
- Pick the verdict from Keep / Expand / Adjust / Pause / Revert / Investigate.


[Data boundary]
- Today is not yet ingested (fully_missed), and the period you specify silently shortens by one day. Cut the period at yesterday and state the number of days you actually aggregated.
- Do not use rollup_status to judge finalization (a single ad type with no delivery drops the whole day to no_data).


[Execution conditions]
- On accounts where AMC's campaign_attribution cannot be retrieved, do not compute NTB CAC; state that "allocation by NTB efficiency cannot be estimated because AMC is not supported."

What you can change — the additional budget amount.

What you get back — a table of target campaign × allocation amount × measured NTB CAC (new-customer acquisition cost), ordered by ascending measured NTB CAC. A “projected NTB increase” is not given as a definite value, because Picaro has no data on marginal CAC or budget elasticity. Only when a number is required is it shown as an assumption-bound reference value: “an upper bound assuming measured NTB CAC equals marginal CAC.”

Changes — no change (proposal only). It only builds an allocation plan; it does not change budgets.

Next steps — to carry out the allocation, apply it through the approval flow in Adjust budgets.

Prompt 6: Find the optimal added-budget allocation within existing campaigns

Section titled “Prompt 6: Find the optimal added-budget allocation within existing campaigns”

Simulate where additional budget is best allocated within existing SP campaigns.

When to use — when you want to place additional budget where it works best inside existing campaigns, without adding new ones.

What you need — the target brand name (optional, for narrowing), and the additional budget amount (e.g. ¥1,000,000).

Goal: to allocate additional budget to the campaigns expected to contribute most to ad-attributed sales and thereby improve
account-wide ROAS, consider where to allocate {{additional budget (e.g. ¥1,000,000)}} added to
{{target brand name (e.g. Brand X)}}'s existing campaigns.
State {{unit of the additional budget (e.g. period total / daily amount)}} before you calculate (what Picaro handles is a
daily budget, so a change of unit changes the conclusion by an order of magnitude).


[Identifying the scope]
Resolve {{target brand name}} against the account names from list_accounts, and pass
account_id explicitly on every subsequent tool call. Campaigns have no brand attribute, and portfolios are
per product line, so if you cannot narrow by brand directly, state that "the whole account was taken as the scope."
Always exclude the following from the allocation targets, and state how many were excluded.
- 🔴 Campaigns under an ENDED portfolio
  * get_portfolio_budget_summary returns ENDED rows even when you pass include_ended=false.
    In observation, include_ended=false returned 8 ENDED portfolio rows, all with spend=0 yet with non-zero
    daily_budget_sum and active_campaign_count (together, a daily budget of just under ¥500,000 and about 50 active campaigns).
    Without excluding them, only the denominator of utilization inflates and the whole account looks unfairly like it "has budget headroom."
    Check each row's status / is_ended and exclude them yourself.
  * Conversely, campaigns with state=ENABLED do exist inside ENDED portfolios (confirmed by observation).
    The campaign's state alone is not enough, so always cross-check against the portfolio's status.
- Ad types other than {{target ad types (e.g. SP only / SP+SB+SD)}}
  * get_portfolio_budget_summary and optimize_budget do not accept an ad-type specification.
    The former declares source_contract.ad_type_scope="all_ad_types", and the latter returned SP / SB / SBV / SD
    mixed together in observation. If you want to narrow to SP, select with campaign-level tools.
- 🔴 Retired campaigns whose name contains old_ or "copy"
  * optimize_budget presents these as "recommended increases" (in observation, 2 old_ campaigns were in the recommended increases).
    Do not list the tool's proposals as-is.


[Period and finalized data]
Aggregate over {{target period (e.g. the last 30 days)}}. Before aggregating, check the finalization status with
get_data_ingestion_status, exclude any unfinalized days (fully_missed etc.), and state how many days of
real data there are. Even if you specify "30 days," it can effectively be 29.
Do not use rollup_status to judge finalization (a single ad type with no delivery drops the whole day to
no_data). Look at the status of each report.


[Confirming that a budget constraint actually exists — always do this first]
An "allocation target for additional budget" exists only where existing campaigns are hitting their daily-budget ceiling.
First produce the normalized daily-budget utilization for the whole account/portfolio and per campaign.


    Normalized daily-budget utilization = period ad spend ÷ (daily budget × days of real data)


- Always state the numerator, the denominator, and the number of days.
- The utilization the tools return (budgetUtilizationRate, or optimize_budget's "utilization") is
  not divided by the number of days when the window is 2 days or longer, so it inflates by the day count.
  Do not use it as-is. Always recompute it yourself with the formula above.
  🔴 Scale of the inflation: in observation, over a 31-day window the tool returned "utilization 2694%," "1288%," and "1015%";
     divided by the number of days these were 86.9% / 41.5% / 32.7%. In that same observation, of the
     35 campaigns the tool judged "budget constrained," zero reached 100% after normalization.
- 🔴 If you use get_portfolio_budget_summary, note that the numerator and denominator cover different populations.
  As source_contract declares, spend_scope="all_states" (actual spend totalled across all states) against
  control_scope="ENABLED_only" (daily_budget_sum and active_campaign_count cover ENABLED only).
  This asymmetry makes utilization come out systematically high. State which population you used,
  and if you use it to judge whether a constraint exists, read it as "this value, even though it runs high."
- If you use optimize_budget, pass target_acos explicitly
  (on accounts with no setting, omitting it is a hard error). The response records
  the value you passed and its source in target_acos_goal_resolution, so quote that in the output.
- If normalized utilization is sufficiently low across every campaign (e.g. broadly below
  {{utilization floor treated as a budget constraint (e.g. 70%)}}), conclude that "budget is not the constraint, so there is no
  allocation target for additional budget," and present as the next action where the constraint lies —
  bids, target coverage, or inventory.
  Do not force an allocation target into existence.
- Constraints from the CAP (monthly ceiling) are a separate system. If check_budget_status is unconfigured, or
  every portfolio is NO_CAP (cap_amount 0), state that CAP-driven constraints are out of scope for the
  judgment. When unconfigured, check_budget_status returns null not only for cap but also for ad_spend,
  so do not use this tool as a source for ad spend.


[Extracting allocation targets (only if a budget constraint actually existed)]
Extract campaigns on 3 conditions: high normalized utilization (capped by budget) × low ACoS × high actual ROAS.
Impression share cannot be retrieved at campaign level
(only target-level IS% exists, and since per-target impressions are not returned, a weighted aggregate is
impossible either). If you use IS as an input, state that it is a target-level value and that it has not been
aggregated.


[Presentation]
Present campaign × recommended allocation × recent actual ROAS (ad-attributed sales ÷ ad spend), ordered by Impact.
Observe the following strictly.
- Do not treat a budget increase or decrease as an effect amount, a sales uplift, or an amount freed up.
  If actual spend was already far below the daily budget, lowering the daily budget frees up ¥0.
  We have confirmed by observation that optimize_budget's items contain no spend / sales / estimated_impact.
- The expected effect amount and the marginal ROAS on additional budget cannot be retrieved from Picaro. State that actual ROAS is
  past performance and not the marginal ROAS on additional budget, and do not assert an estimate.
- Observe the rule: "Picaro holds no profit metric, so compute ROAS or ad contribution rather than ROI."


[Guardrail]
- First compute and state the current account-wide ACoS (with the name of the source tool alongside;
  it diverges by a few pt depending on the source).
- Keep account-wide ACoS from exceeding {{ACoS ceiling (e.g. 20%)}} after allocation.
- If current ACoS already exceeds the ceiling, however, do not reject the proposal outright:
  switch the effective gate to "do not make current ACoS worse," and state the gap to the ceiling alongside.
- Do not cut the budget of existing high-ROAS campaigns.


[Execution and measurement]
Apply the proposal only after approval (do not execute automatically). Budget changes are a separate system from
bid changes, so use the approval flow for applying budgets. If you generate a
proposal with optimize_budget for verification, always cancel it unless it is approved.
Re-retrieve ACoS and ROAS {{days until measurement (e.g. 7 days)}} after applying, and propose Keep if improved and
Revert if worse. On re-retrieval as well, state the numerator, denominator, and number of days for every ratio, and
exclude unfinalized days.

What you can change — the target brand name / additional budget amount.

What you get back — a table of campaign × recommended allocation × recent actual ROAS (ad-attributed sales ÷ ad spend). Picaro holds no profit metric, so it is not computed as ROI. The output states that differences must not be treated as effect amounts or sales uplift, and that actual ROAS is past performance rather than the marginal ROAS on additional budget.

Changes — no change (proposal only). It only builds an allocation plan; it does not change budgets.

Next steps — to carry out the allocation, apply it through the approval flow in Adjust budgets.

Prompt 7: Analyze why budget is not being spent

Section titled “Prompt 7: Analyze why budget is not being spent”

Explain why a portfolio or campaign is not spending its budget as planned.

When to use — when you want to isolate why a reserved budget isn’t being fully used.

What you need — the target brand name, and the target portfolio name (leave blank for the whole account).

Explain why {{target brand name (e.g. Brand X)}}'s {{target portfolio name (e.g. Portfolio X)}} is not
spending its budget as planned. Break out the causes (bid too low / not enough
impression share / match types too narrow, etc.).

What you can change — the target brand name / target portfolio name.

What you get back — a table of underspending campaign × likely cause (bid level / impression share / match type / competitive strength) × suggested action.

Changes — no change (analysis only).

Next steps — if bids are the cause, address it in Adjust bids; if the budget cap is the cause, in the approval flow of Adjust budgets.

Prompt 8: Build a pre/post-event budget allocation plan by search funnel stage

Section titled “Prompt 8: Build a pre/post-event budget allocation plan by search funnel stage”

Around sales and campaign events, build a budget allocation plan for the lead-in and follow-up windows, split by search funnel stage (research / comparison / immediate-purchase).

When to use — when you want to vary how you spend for a sale, from building awareness beforehand to harvesting on the day.

What you need — the target brand name, and the event date (e.g. 2026-07-15).

For {{target brand name (e.g. Brand X)}}'s sale / discount on {{event date (e.g. 2026-07-15)}}, build an SP budget allocation plan across 3 windows: lead-in, event, and follow-up.
Goal: optimize SP budget allocation to the demand swings around the event and prevent lost opportunity.
Scope: all SP campaigns of that brand. Limit to state=ENABLED only, exclude PAUSED / ARCHIVED and any campaign whose name contains "copy" or "old_", and state the number excluded in the output.
* 🔴 Even with state=ENABLED, that campaign's portfolio can be ENDED (confirmed by observation). Do not go by the campaign's state alone — cross-check against status / is_ended from get_portfolio_budget_summary and exclude accordingly.


■ How to set the windows
1. First call manage_event with action=list (read only; do not register or update) and identify the event that contains {{event date (e.g. 2026-07-15)}} or starts on that day. An event is a period with a date and an end_date, not a single day. If one is found, set "event window = date to end_date"; if not, set the event window to the single day {{event date (e.g. 2026-07-15)}} and state that you did so.
2. Lead-in window = {{number of days (e.g. 7 days)}} before the event start date through the day before it starts. Follow-up window = the day after the event end date through {{number of days (e.g. 3 days)}} later.
3. In the same manage_event listing, check whether the lead-in and follow-up windows overlap other registered events (an early-access sale, etc.). If they overlap, either exclude those days or state explicitly in the output that you are using them despite the overlap.
   🔴 Overlap is the rule, not the exception. Large sales normally have an "early sale" and the "main event" registered back to back (confirmed by observation), so taking the main event's start date as the event date almost always makes the lead-in window bite into the early sale. In that case, state that "N days of the lead-in window fall in the early-sale period and cannot be read as a normal lead-in," then choose whether to exclude them or split them into a separate window, and write your reason.
4. Always write each window's date range and actual day count in the output.


■ Handling finalized data
- Call get_data_ingestion_status over the target period and exclude from each window any day whose status is fully_missed. Unfinalized days come back as zero-filled rows with no warning, so including them makes it look like "delivery stopped after the event."
- Do not use rollup_status to judge finalization. A single ad type with no delivery drops the whole day to no_data. Look at the status of each report.
- State the number of days excluded, and the finalized actual day count of each window after exclusion.


■ Rules for comparing windows
- The windows are of unequal length, so normalize every amount and count to "per day" before comparing (window total ÷ that window's finalized actual days).
- Every time you produce a ratio, state the numerator, the denominator, and the number of days.
- Do not put comparisons of raw window totals in the output. Whether or not you normalize can flip the sign of an increase or decrease.


■ Proxy metrics
"Search funnel" is not a field that exists in Picaro, so use the brand KW / generic KW / ASIN target split as a proxy metric and vary the weighting in each window (e.g. raise the generic share in the lead-in window and strengthen brand KWs in the event window). Retrieve as follows.
- Call list_existing_sp_campaigns with name_filter per split, and check coverage_complete and be_total_results to guarantee you swept the whole population. The response returns matched_count / scanned_campaign_count / be_total_results / coverage_complete / pages_fetched.
  🔴 The name_filter results include PAUSED / ARCHIVED (in observation, 3 of 18 were PAUSED). Look at each row's state, exclude them yourself, and state the number excluded.
  🔴 Campaign names mix half-width | and full-width ｜ as separators (confirmed by observation). name_filter itself picks up both through NFKC normalization, but if you split campaign names yourself to determine the split, handle both separators. Splitting on only one leaves some campaigns falling into "unclassified."
- Pass the campaign_ids you obtained to analyze_ad_type_performance, specify campaign_types=["SP"] and each window's period_start / period_end, and aggregate per window.
- 🔴 Do not use analyze_label_kpi. The label axis (competitor / generic / branded) is the SaaS source of truth, but its frequency is weekly / monthly only, so it cannot carve out a 1-day or 3-day window.
  Observed behavior: called with a 4-day span (through 4/13), the response echoed back the requested 4 days in period while returning values equivalent to about 45% of that whole month's ad spend (several weeks' worth). There is no warning, and the echoed period matches the request, so there is no way to detect the snapping from the response. It must not be used for window analysis.
  Note that it has also been confirmed by observation that the label axis has no ASIN-target split. That is why campaign names are used as the proxy.
- List campaigns that do not follow the naming convention (Catch All, Category, AUTO, etc.) separately as "unclassified," and always state the unclassified share of ad spend in the output. The larger that share, the less reliable the proxy metric.
- State in the output that this is a proxy metric, and that its basis is campaign names (given by the operator) and not the SaaS label source of truth.


■ Output
- In a window × split matrix, show finalized actual days, ad spend per day, ad-attributed sales per day, ACoS, and ad-spend share.
- Alongside, give the projected budget allocation ratio for each window (by split, summing to 100%) and write the change in pt from the current ratio.
- Present the list of changes (window, campaign, current daily budget, proposed daily budget, difference). Do not, however, present the difference as an effect amount or an amount freed up (if actual spend is far below the daily budget, lowering the daily budget frees up ¥0).


■ Guardrail
- Set the normal-period baseline to the most recent run of {{number of days (e.g. 7 days)}} consecutive days that does not overlap a registered event in the manage_event listing by even one day, and state in the output the period you determined automatically (if the user specified a period, that takes precedence). Choose within the range of finalized days.
- Fix the source of ACoS to one (default: analyze_ad_type_performance with campaign_types=["SP"]). The same period differs by a few pt depending on the source, so do not mix sources, and state in the output which source you used.
- Allocate within a range that keeps account-wide ACoS from exceeding {{upper bound (e.g. +5pt)}} (percentage points) versus the normal period. Write in the output that this ceiling is an addition to the ACoS from the source and normal period you fixed above.


Always before executing: present the list of changes (window, campaign, allocation amount) and do not apply anything to the platform until approval is obtained. This prompt goes only as far as presenting the allocation plan and writes no budgets.
After executing: apply the proposal only after the user reviews and approves it, then use "measure the effect of an action" to retrieve ACoS and ad-attributed sales after each window ends, and Adjust the next window's allocation if the target was missed.


Execution conditions
- The number of days in each window may be adjusted to the nature of the event; if you change them, state the day counts
- If you use optimize_budget as a basis for the allocation, always specify target_acos (omitting it errors and no proposal is generated). That tool includes SB / SD / SBV and cannot be narrowed to SP (it has no ad-type argument at all), and its utilization inflates in proportion to the length of the period, so do not quote the utilization as-is — normalize it to "window total ÷ (daily budget × finalized actual days)" before use
  🔴 That tool also presents retired campaigns whose names start with old_ as "recommended increases" (2 in observation). Drop them per the exclusion rules above. Any proposal you generate must be cancelled unless it is approved

What you can change — the target brand name / event date / the number of days in the lead-in and follow-up windows / the ACoS ceiling.

What you get back — a matrix table of window (lead-in / event / follow-up) × split (brand KW / generic KW / ASIN target). Because “search funnel” is not a field that exists in Picaro, the output states that this split is used as a proxy metric.

Changes — no change (proposal only). It only builds an allocation plan; it does not change budgets.

Next steps — to carry out the allocation, use Adjust budgets; to log it as an initiative, use Log initiatives and external events and verify their impact.

Analyze profitability and performance by ASIN

Section titled “Analyze profitability and performance by ASIN”

Prompt 9: Calculate ad contribution by ASIN

Section titled “Prompt 9: Calculate ad contribution by ASIN”

Subtract ad spend from SP ad sales to compute the ad contribution per order.

When to use — when you want to see ad contribution at the ASIN level and decide which products to push and which to scale back.

What you need — the target period (a finalized calendar month, e.g. 2026-07).

Goal: to make ad contribution visible by ASIN and feed that into correcting how investment is allocated.


Data source (fixed; do not change it)
- Take ad-attributed sales and ad spend by ASIN from `get_amc_ntb_by_asin` (AMC NTB by ASIN) as the single source. Fetch the entire latest run with `max_rows=5000`, and state `returned_row_count / selected_row_count` in the body as the coverage rate.
- Cover only the rows where `ad_product_type == "sponsored_products"`. In the same tool, `ad_spend` is 0 on every DSP row and every sponsored_brands row, so computing contribution from them as-is would be misread as "selling with zero ad spend." Always exclude them.
- `list_top_asins_by_metric` is on the axis of "target ASINs the ads hit," not the population of your own products (other brands' ASINs are mixed into the top). Do not use it for this analysis.
- Do not mix in sales or ad spend from other tools such as get_dashboard or analyze_ad_type_performance.


Target period: {{target calendar month (e.g. 2026-07)}}
- The finest granularity of this source is the calendar month (`report_month`); an arbitrary window such as "the last 30 days" cannot be cut. Always specify a finalized calendar month.
- If the `report_end_date` in the response is before the last day of the target month, that month is not finalized: do not use it, switch to the immediately preceding finalized calendar month, and state that you did.


Pre-processing
- Rows where `asin == "below_reporting_floor"` are aggregate rows mixed into the same `asin` column as real ASINs, so exclude them and state what percentage of the month's SP ad-attributed sales the excluded amount represents.
- Treat rows where `ad_spend == 0` as missing, not as "zero ad spend": do not compute contribution for them, and state how many there are.


Calculation: by ASIN, compute "ad-attributed sales (attributed_revenue) − ad spend (ad_spend) = ad contribution" and "ad contribution per order (ad contribution ÷ total_purchases)" (state that this is ad contribution, not actual profit).


Analysis: extract up to 10 ASINs with negative ad contribution, in descending order of ad spend. Also give the total ad spend and total contribution of the negative ASINs, and the share they represent of the month's SP ad spend.


Finally, output these three things.
1. Recommended actions — treat ASINs with negative ad contribution as candidates for a bid cut or a budget reduction. However, exclude from the cut candidates the top 10% of ASINs by ad-attributed sales (attributed_revenue) from the same source and the same period (because an account-wide total-sales ranking cannot be enumerated in full at the ASIN level, fix the guardrail population inside this source)
2. How to execute — apply only after the user has reviewed and approved the proposal (this prompt does not execute anything)
3. Measurement — using "measuring the impact of an action," re-fetch ad contribution by the same procedure in the next finalized calendar month, and judge Keep if improved and Revert if worse (because no daily or weekly source exists on the ASIN axis, measure on a calendar-month cycle rather than after 7 days)


Execution conditions
- "Ad contribution" is not gross margin or profit. Do not confuse it with actual profit, which includes COGS and Amazon fees
- The ad-attributed sales in this source are AMC clean-room aggregates; both the population and the attribution differ from the ad sales in campaign-level tools. Do not line the two amounts up side by side or talk about the difference between them

What you can change — the target calendar month.

What you get back — a table of the top 10 ASINs with negative ad contribution × ad spend × ad contribution × ad contribution per order. The data source is fixed to AMC’s get_amc_ntb_by_asin (Sponsored Products rows only).

Changes — no change (analysis only).

Next steps — to act on the cut candidates, use Adjust budgets or Adjust bids; to improve the product pages of the low ones, use Diagnose the catalog and draft improvements.

Term note — “Ad contribution” is not gross margin or profit. Do not confuse it with actual profit, which includes COGS and Amazon fees. Use it as a rough gauge of the sales contribution against ad spend, with no allowance for cost ratio or gross margin.

Prompt 10: Get a performance summary for key ASINs

Section titled “Prompt 10: Get a performance summary for key ASINs”

For key ASINs, fetch ad sales / ad spend / ad units sold / ROAS at the ASIN level for the most recent finalized calendar week (Picaro cannot retrieve daily data by ASIN, so this is a period total).

When to use — when you want to check the recent performance of several products you’re watching, together in one list.

What you need — the target ASIN list (e.g. B0XXXXXXXX, B0YYYYYYYY; multiple allowed), and the target period (the most recent finalized calendar week, e.g. the last 1 week).

Goal: to lay out the ad performance of several ASINs in one list and catch anomalous ASINs early,
aggregate ad sales / ad spend / ad units sold / ROAS at one row per ASIN for
{{ASIN list (e.g. B0XXXXXXXX, B0YYYYYYYY)}} over {{target period (the most recent finalized calendar week, e.g. the last 1 week)}}.


[How to decide the period — always do it in this order]
1. Count the unfinalized days (fully_missed) with get_data_ingestion_status and identify the last finalized day.
   Look at the status of each report, not rollup_status (a single ad type with no delivery drops the whole day to no_data).
2. 🔴 This endpoint snaps the period to calendar weeks. A day-level specification has no effect.
   Confirmed by observation: calling it twice with from_date/to_date shifted by one day returned exactly the same values for every item
   (for the same campaign, ads_sales / ads_units / clicks / impressions did not differ by a single yen or a single unit).
   On top of that, the response has no field showing the effective period, so you cannot detect the snapping from the response.
   → Therefore always make the target "the most recent finalized calendar week," with the prior period being the calendar week before it.
   → How to detect the snapping, if you want to check: call it twice for the same ASIN with from/to shifted by one day, and
     if the values match exactly you can conclude "it is snapping (the day-level specification has no effect)."
3. Call POST /bigquery/sales-ranking with call_picaro_api (body: {"amazon_account_id": <account_id>,
   "frequency": "weekly"}) and confirm the week boundaries of the current and prior periods from the
   week range shown in the from_date / to_date of the response.
4. The from_date you aggregate with must always be a Sunday and the to_date always a Saturday.
   If you pass a period that is not aligned to week boundaries, it snaps to a nearby week or several calendar weeks are summed without warning.
   Always write the dates and the number of days you actually used into the output.


[How to fetch]
- For each ASIN, call POST /product-analysis/product-detail/ad with call_picaro_api
  (body: {"amazon_account_id": <account_id>, "from_date": "<the current period's Sunday>",
  "to_date": "<the current period's Saturday>", "code": "<ASIN>", "type": "asin"}), and
  take ads_sales / ads_spend / ads_units / roas from the total in the response.
- For the prior period, make the same call for the previous Sunday–Saturday.
- There is no bulk-fetch endpoint, so call it once per ASIN.
- 🔴 total is "the total within the page that was returned," not the overall total.
  Confirmed by observation: calling it with page_size set to 1, total_count stayed at 17 while
  total was the value of the first campaign only (about a quarter of the whole).
  → Either do not specify page_size (the default is 20) or set it at or above total_count so you get everything in one page.
  → Before reading total, always confirm that pagination.total_count matches the number of items, and
     record both in the output. Do not use total while they do not match.
- For "sales," use ad sales (ads_sales) to line up with the numerator of ROAS, and do not confuse it with total sales.
- 🔴 On this endpoint, purchases and ads_units are identical on every row (confirmed across all campaigns by observation).
  That is, what you can get here is units sold, not the number of orders, so label the output column "ad units sold" and
  do not write "ad orders." cvr is also ads_units ÷ clicks, so it too is on a units-sold basis.
- Every number in the response comes back as a formatted string ("¥1,691,946" / "733" / "112.8%").
  Strip ¥, commas, and % before doing arithmetic, and do not sort them while they are still strings.


[Anomaly detection]
- Flag ASINs whose relative rate of change in ROAS versus the previous week is at or below
  {{ROAS deterioration threshold (relative rate of change, e.g. -20%)}}.
- Always compute the relative rate of change yourself as (current ROAS − prior ROAS) ÷ prior ROAS.
  The change_percentage the tool returns is "a difference in percentage points" yet is displayed with a "%",
  so it must not be used for the threshold judgment as-is.
- The ROAS column is in percentage notation (observed: "112.8%"), not a multiple, so align numerator and denominator before comparing.
- Every time you produce a ratio, state the numerator, the denominator, and the number of days covered.


[Handling missing data]
- Both a non-existent ASIN and a real ASIN with no ad delivery come back as 0 rows (every item "--"),
  with no error and no warning.
- Always reconcile the number of ASINs you entered against the number of rows for which values were obtained, and
  list the ASINs you could not obtain separately as "no data (cannot tell whether performance was 0 or it is out of scope)."
  Do not finalize the list while the counts do not match.
- ※ If you need to confirm that an ASIN exists, you can check whether it is registered with the SKU reverse-lookup tool or the product list (child-asin).
  Write ASINs that do not appear there either separately, as "not registered."


[Output]
- A table with one row per ASIN (ad sales / ad spend / ad units sold / ROAS current / ROAS prior / relative rate of change)
- The actual dates and number of days used for the current and prior periods, and that both periods are the same week length
- pagination.total_count and the number of items per ASIN (the grounds for using total)
- The list of flagged ASINs (state so if there are none)
- The list of ASINs that could not be obtained


Pass the flagged ASINs on to "cause diagnosis" for detailed analysis.
Next time, once the target week is finalized, re-aggregate and check whether the ROAS of the flagged ASINs improved.
Even a finalized period can change value on re-ingestion, so do not conclude a defect from a difference against the previous value alone.

What you can change — the target ASIN list / the target period / the threshold treated as a ROAS deterioration.

What you get back — a table of ASIN × ad sales / ad spend / ad units sold / ROAS (current period, prior period, relative rate of change), plus flags on the ASINs that deteriorated versus the prior period. The target period is snapped to calendar weeks, so an arbitrary day-level specification is not possible.

Changes — no change (analysis only).

Next steps — to see overall daily KPIs, use Check KPIs on the dashboard.

Prompt 11: Identify ASINs with high CTR but low CVR

Section titled “Prompt 11: Identify ASINs with high CTR but low CVR”

Identify ASINs whose CTR (click-through rate) is high but whose CVR (conversion rate) is low (the ad pulls strongly, but people drop off on the product page).

When to use — when you want to find products that get ad clicks but don’t convert to sales, and set the priority for product-page improvements.

What you need — the target period (e.g. last 30 days).

Goal: to identify ASINs that are strong at winning ad clicks but are not reaching purchase, and to prioritize listing improvements.


Data source (fix it to one; do not mix it with other sources)
- Get impressions / clicks / ads_units / ads_spend / purchases / sessions / glance_views /
  stock_status / sellable_inventory / buy_box_percentage / org_cvr / ads_cvr at the ASIN level from
  POST /product-analysis/product-list/child-asin via call_picaro_api.
  body: {amazon_account_id, product_line_id: 0 (0 = all product lines; omitting it or using another value returns only some lines),
         from_date, to_date, frequency: "daily", page, page_size: 40}
  ※ Making page_size large truncates the response at 80KB without warning. Fetch every page up to total_pages with page_size=40.
  ※ The response's pagination contains page / page_size / total_count / total_pages. Use total_count as the denominator for the number of target ASINs.
- 🔴 Every number comes back as a formatted string. Examples: "¥59,959,000" / "25,000" / "35.9%" / "0.66%".
  Strip ¥, commas, and % before doing arithmetic, and treat "--" as null (not zero).
  The exceptions are sellable_inventory / sku_quantity, which are raw numbers. Do not compare or sort them as strings.
- Use the total block in the same response for the account average (do not recompute the average yourself).
- Completeness cross-check: confirm that the sums of impressions / clicks / ads_spend across all pages match total, and state the match rate.
  If they do not match, report it as a fetch gap.


Period
- {{target period (e.g. last 30 days)}}. But do not hard-code the number of days.
- Call get_data_ingestion_status first and take the last day whose status is completed as the finalized day.
  Do not include fully_missed / in_progress days in the window (including them silently shortens the window and understates ad spend).
  Do not use rollup_status to judge finalization (a single ad type with no delivery drops the whole day to no_data). Look at the status of each report.
- Always write the start date, end date, and number of days you actually aggregated into the output.


Metric definitions (use no definition other than these; build them all from fields in the same response)
- CTR = clicks ÷ impressions (cross-check that it matches the ctr in the response)
- Ad CVR (units-sold basis) = ads_units ÷ clicks (the same as ads_cvr in the response)
  ⚠ This is "units sold ÷ clicks," not an order basis. When one order sells several units, it comes out higher than the real order-based CVR.
  Always label it "units-sold basis, ad-attributed" in the output.
- Overall CVR (units-sold basis) = total_units_sold ÷ glance_views (the same as cvr in the response)
- 🔴 Overall CVR (order basis) = purchases ÷ glance_views — this one you can get.
  purchases is the number of orders (organic + ads combined) and total_units_sold is units sold. Both come back on the same row.
  Use glance_views as the denominator to line up with the tool's own cvr, and compute the account average with the same formula,
  purchases ÷ glance_views from the total block (using sessions as the denominator gives a different value, so do not confuse the two).
  ※ An order-based "ad-attributed" CVR cannot be obtained (there is no field equivalent to ads_purchases corresponding to ads_units).
    Accept that "ad conversion" is on a units-sold basis and "product / listing conversion" is on an order basis.
- Write which of these definitions you used into the column name of the table, per metric. Do not mix CVRs with different definitions into the same column.


Population and minimum sample
- A row whose impressions is "--" (null) is "no data," not "no ad performance." Distinguish it from 0, exclude it from the population, and state how many there were.
- A row with impressions = 0 has not been delivered. Exclude it as "cannot be calculated" rather than CTR/CVR of 0%.
- To remove statistically meaningless rows, judge only rows that satisfy impressions ≥ {{minimum impressions (e.g. 10000)}} and clicks ≥ {{minimum clicks (e.g. 200)}}.
  Always state the number of rows excluded alongside the rows that would have qualified had they not been excluded.


Extraction conditions (fix the meaning of {{threshold}} to exactly one thing)
- CTR > the account average CTR, and
- Ad CVR (units-sold basis) ≤ the account average ad CVR × {{threshold (e.g. 50%)}}
  ※ Do not interpret this as a rank-based "bottom {{threshold}} by CVR." State the actual value of the threshold (account average CVR × threshold) in the output.
- After extraction, also show the order-based overall CVR for each row and check whether it is low in the same direction as the units-sold basis.
  If the directions differ, note the possibility of "an apparent gap caused by a difference in units purchased per order."


Isolating the cause (do not present as a hypothesis what you can actually retrieve)
- Inventory: reconcile stock_status / sellable_inventory with get_fba_inventory.
  ⚠ get_fba_inventory is a snapshot as of now (coveragePeriod is the most recent week) and cannot prove that stock was available throughout the target period.
    Write no more than "in stock as of now."
- Price competitiveness: always show buy_box_percentage. If it is below 100%, point it out on a factual basis as "a price / Buy Box problem"
  (this is not a hypothesis). In observation, however, most ASINs sit in the 99% range, so evaluate it by the gap against the account average (the total block)
  and do not exaggerate a few points of difference as the main cause.
- Separating a listing problem from an ad-targeting problem: show org_cvr (organic CVR) alongside.
  If org_cvr is also far below the account average, treat it as a problem on the product / listing side;
  if org_cvr is normal and only the ad CVR is low, treat it as a problem on the ad-targeting side.
  ※ org_cvr = org_units ÷ org_click, which is also on a units-sold basis. It is on the same basis as ad CVR, so the two can be compared directly.
- Images and review text cannot be retrieved, so label them "hypothesis" and do not assert them as fact.


Output
- Up to 5 rows, in descending order of ad spend. If fewer than 5 qualify, output only that many and state "N qualified." If none qualify, write 0 (do not pad).
- For each row: ASIN / product name / CTR / account average CTR / ad CVR (units sold) / account average /
  the threshold's actual value / overall CVR (order basis) / impressions / clicks / ads_units / purchases / ad spend /
  inventory / buy_box_percentage / org_cvr.
- Every time you produce a ratio, state the numerator, the denominator, the number of days aggregated, and the coverage rate of the population.


Finally, output these three things.
1. Recommended actions — handle out-of-stock cases immediately; treat a drop in buy_box as a price / Buy Box factor and raise a correction request;
   treat everything else as a confirmation request to the listing owner
2. How to execute — pauses and bid changes on the ad side are applied only after the user has reviewed and approved them,
   and listing issues are raised as confirmation requests to the responsible team
3. Measurement — using "measuring the impact of an action," re-fetch CVR from the same source with the same definitions 7 days after the fix and confirm the improvement


Execution conditions
- Images and reviews are hypotheses; do not assert them as fact
- For CVR, always state both the basis (units sold / orders) and the attribution (ads only / overall), every time
- Always disclose, as counts, the rows you could not fetch and the rows you excluded (do not conflate 0 with not-fetched)
- Values can change on re-ingestion even for finalized periods. On re-measurement, do not conclude improvement or deterioration from a difference alone

What you can change — the target period / the threshold for the CVR judgment.

What you get back — a table of ASIN × CTR × ad CVR (units-sold basis) × ratio to the account average × overall CVR (order basis) × inventory × buy_box_percentage × org_cvr (up to 5 rows, in descending order of ad spend). Inventory and price competitiveness are confirmed against real data; images and reviews are labelled “hypothesis” and kept separate from fact.

Changes — no change (analysis only).

Next steps — for prioritizing product-page improvements, use Diagnose the catalog and draft improvements; to check inventory, use Manage inventory and sales opportunities.

Prompt 12: Break down the cause of a worsening metric into 6 factors

Section titled “Prompt 12: Break down the cause of a worsening metric into 6 factors”

When you already know the target campaign or portfolio and which metric has worsened, break the cause down into 6 categories — search term / bid / CPC / CVR / budget / placement — and set the priority for acting, starting with the factors that contributed most. Where Prompt 4 “Analyze unprofitability through the CAC and LTV lens” hunts for the target itself when you have not yet narrowed down what the problem is, this prompt is for breaking down why something worsened when you already know the target and the worsening metric.

When to use — when you know a metric has worsened on a specific campaign or portfolio, but want to work out which of search term, bid, CPC, CVR, budget, or placement is the main driver.

What you need — the target campaign or portfolio. The metric that worsened (e.g. ACoS worsened by +5pt week over week). The analysis period (e.g. the last 14 days).

{{target campaign or portfolio (e.g. campaign ID 12345678)}} is showing
{{worsened metric (e.g. ACoS worsened by +5pt week over week)}}. Classify the cause into one of the factors —
search term / bid / CPC / CVR / budget / placement — and set the priority for acting.


Compare the last {{analysis period (e.g. last 14 days)}} against the immediately preceding period of the same
length, and check the contribution to the worsening for each of the following 6 categories.


1. Search term — use analyze_search_term_contribution. Pass the prior period to period_first and the most
   recent period to period_second (reversing the order flips the sign of change / contribution). Use
   tab=acos for contribution and tab=spend for the change in ad spend. Compare total_items with returned_items,
   and if next_page_token comes back, keep retrieving as far as the analysis requires. If you have not
   retrieved everything, state the number retrieved and the total, and do not assert the result as account-wide.
   🔴 For the period actually aggregated, look at effective_period_first / effective_period_second.
   The response also contains be_request_ranges, but for monthly / weekly this is only the single anchor day
   (observed: a monthly comparison returned the same first-of-month date for from and to). Quoting it would
   misreport the analysis as "a one-day comparison." Also state period_resolution_reason and period_mode.
   🔴 Do not mix up units. change is in bps, change_value is in percentage points, and change_ratio is the
   relative rate of change (observed: for 55.7%→62.0%, change "+623 bps" / change_value 6.23 / change_ratio +11.18%).
   Always state which unit you are speaking in.
   🔴 Account-wide "contribution" is not returned. total.contribution is -- and contribution_value is null
   (confirmed by observation). Do not substitute the sum of the rows' contribution either (the response's
   surface_refs explicitly prohibits sum(rows[])). Quote contribution from the top rows as is, and describe
   the overall change with total.change.
2. Bid — use get_change_history to check the change history for bids, budgets, and states. Even if 0 records
   come back, do not conclude "no bid changes." An error-free 0 cannot distinguish "there were no changes"
   from "the history could not be retrieved," so write "0 change-history records (may not have been retrieved)."
   🔴 If you pass a start date more than 90 days back, the tool automatically rounds it up to 90 days ago and
   returns the note "Note: Amazon's change history goes back only 90 days, so the retrieval start date was
   adjusted to YYYY-MM-DD." (confirmed by observation). Quote this adjusted date as the range you were able to check.
   Pass the profile_id value tied to account_id (a required argument).
   As a supplement, for the top-contributing search terms, use get_search_term_impression_trend (frequency=weekly,
   specifying keyword_id from the targets list) to check the weekly trend of keyword_bid and top-of-search
   impression share. This series is per search term × single target, so if targets does not come back in full,
   state the number returned and target_count, and do not assert it as a campaign-wide bid change.
3. CPC — use total from analyze_search_term_contribution with tab=cpc. Do not compute ad spend ÷ clicks yourself.
   If CPC is rising while bids are falling, present market factors as a "hypothesis" and do not assert causation.
4. CVR — use total from tab=cvr. Check whether orders are falling even as clicks rise. Verify that the product of
   the rate of change in CPC and the rate of change in CVR is broadly consistent with the rate of change in ACoS.
   * Do this reconciliation with the same unit across all tabs (the relative rate of change = change_ratio).
   Mixing bps and pt will not add up.
5. Budget — use check_budget_status to check whether a monthly budget cap is configured. If status is unconfigured,
   or if cap / ad_spend / utilization_rate are null, state that "utilization against the cap cannot be evaluated
   because no cap is set," and do not treat null as 0%.
   🔴 When unconfigured, not only cap but also ad_spend comes back as null (confirmed by observation).
   Do not use this tool as a source for ad spend.
   Then retrieve get_portfolio_budget_summary twice, once for the target period and once for the prior period, and
   check the change in actual spend and the spend level against the current daily budget total. However,
   daily_budget_sum is the current effective campaign setting, not a per-period budget history, so do not treat it
   as a "period-over-period comparison of utilization."
   🔴 Further, this tool's spend is the total across all states while daily_budget_sum covers ENABLED only, so the
   populations differ and the spend level comes out systematically high. Also, ENDED rows come back even when you
   pass include_ended=false, so exclude them yourself using status / is_ended. If you cannot determine whether
   delivery was constrained by budget, write "not confirmed."
6. Placement — retrieve get_placement_summary twice, once for the target period and once for the prior period
   (source_contract declares period_policy="current_period_only", so one call cannot compare).
   Look at the change in ACoS, CVR, clicks, and ad-spend share by placement. If orders comes back as 0, do not
   conclude "zero performance"; state that "the data may not have been retrieved." The bid multiplier
   (avg_current_modifier_pct) is the current setting, not a per-period history, so do not read it as a
   "change in bid multiplier."
   🔴 "Rest of Search" is a synthetic bucket. In observation, placement_raw_values held 4 kinds —
   HOME / OFF_AMAZON / PLACEMENT_REST_OF_SEARCH / SITE_AMAZON_BUSINESS — and source_row_count was about 3× that of
   the other placements. This row's avg_current_modifier_pct is an average mixing 4 kinds of placement, so do not
   read it as the setting for a single placement. If you need the breakdown, enumerate placement_raw_values.
   Placement data is an aggregate mixing ad types (SP and SB) and does not include SD / DSP, so do not compare it
   directly against dashboard or campaign-detail figures.
   (Observed: ad spend for the same month came out three different ways across the placement aggregate, the
    portfolio aggregate, and the SP-only aggregate. Always state which source a value came from.)


Execution conditions
- Retrieve real data from Picaro MCP and analyze it. Do not guess or fill in numbers you did not retrieve via MCP
- Prohibited tool: do not use analyze_ad_type_performance. Retrieve SB/SD individually with
  list_existing_sb_campaigns / list_existing_sd_campaigns
- Distinguish null, not retrieved, no data, and 0. Do not treat null or not-retrieved as 0
- Check all 6 categories before judging contribution (high / medium / low / none / not confirmed). Do not conclude
  from a single category
- State "not confirmed" for any category you could not retrieve, and make it explicit that you concluded from the
  confirmed categories only, along with how many categories you were able to confirm
- Run the period up to the most recent finalized day. Do not include today or yesterday. Do not use rollup_status
  to judge finalization; look at the status of each report
- Every time you present a ratio, state the numerator, denominator, and number of days, and confirm that the
  finalized actual day counts match across both periods
- Narrow to the 1–2 highest-contributing categories and, for each, guide the next move to take (bid adjustment,
  budget adjustment, or adding negative keywords). Do not make core terms that account for most of the ad spend
  into negative-keyword targets
- For categories with "high" contribution, point to the corresponding existing prompt (where a bid change is
  involved, apply it only after obtaining the user's approval)
- Go as far as analysis, candidate extraction, and proposals; do not change Amazon Ads settings before approval.
  If a proposal is generated during verification or analysis, discard any you do not approve and state that you
  discarded it (a proposal stays on the account for 24 hours after generation)
- The results of this diagnosis assume that, after acting, you will verify the effect with "measuring an
  initiative's impact"

What you can change — the target campaign or portfolio / the worsened metric / the analysis period.

What you get back — the contribution (high / medium / low / none / not confirmed) for each of the 6 categories — search term / bid / CPC / CVR / budget / placement — and how to act on the 1–2 highest-contributing categories (bid adjustment, budget adjustment, or adding negative keywords). Because Picaro holds no per-period budget history and no change history for placement bid multipliers, the output states that the budget and placement categories are judged only from the current settings.

Changes — no change (analysis, candidate extraction, and proposals only). If a proposal is generated during the analysis, any you do not approve is discarded and the output says so.

Next steps — depending on which category is judged to contribute most, move on to the approval flow in Adjust bids / Adjust budgets / Add negative keywords. After acting, verify the effect with Log initiatives and external events and verify their impact.

Section titled “Related”