Log initiatives and external events and verify their impact

On this page you record the initiatives you ran yourself (the initiative log) and external events caused by others in Picaro, then verify the impact of the initiatives you recorded by comparing before/after (Before/After). Unless you record the initiatives you run, you can’t look back later on “what actually worked.” Recorded initiatives can also be used in Prompt 3 “Measure the Before/After impact of an initiative” in Check KPIs on the dashboard.

About this page

Item	Details
What you can do	Record initiatives and external events in Picaro, and compare KPIs before and after a change to verify impact
Applies to	Initiative logs (moves you made yourself — bid adjustments, budget changes, promotions, etc.) and external events (factors outside your control — TV broadcasts, sales, buzz, stockouts)
Data & connection needed	A connected account. Impact verification uses the connected account’s actual KPI data (no extra setup)
Scope	Varies by prompt. Registering initiatives and external events records to Picaro (a write occurs); comparing and reporting on change history is analysis only (read-only). Neither changes your Amazon ad settings themselves. Each prompt states its own in “Changes”

Terms used on this page

• Initiative log … a record of a move you made yourself (bid adjustment, budget change, promotion, etc.). You register it in Picaro so you can measure its impact later.
• External event … a record of an external factor that isn’t your own initiative (TV broadcast, sale, buzz, stockout, etc.). You reference it later as a reason KPIs moved.
• Initiative ID / Event ID … the number auto-assigned at registration. You specify it when verifying impact or updating.
• before/after (Before/After) … comparing KPIs across the periods before and after you ran an initiative. It’s the basic way to judge whether it had an effect.
• ACoS (Advertising Cost of Sales) / ROAS (Return on Ad Spend) … ad-efficiency metrics. Lower ACoS is better; higher ROAS is better.

Pair recording with impact verification

An initiative log delivers no value from recording alone. 7–14 days after you run it, pass the recorded initiative ID to the impact-verification prompt (Prompt 4) or the dashboard’s Before/After impact measurement, and the deltas in ACoS / ROAS / ad spend / sales are aggregated automatically.

Check these before you compare results

When judging the impact of an individual initiative (Prompts 4 and 6), check the following three points before you start comparing.

• Confirm the initiative ID exists before you use it. The comparison tools do not verify that the initiative ID you specified exists. Passing a non-existent ID still lets the comparison run, so confirm it exists first by fetching the individual initiative log.
• Check whether an external event overlaps the comparison period. If a sale, TV broadcast, or stockout overlaps the comparison period, the initiative’s impact and the external factor get conflated. The comparison tools do not exclude external events automatically.
• Always match the number of days before and after the initiative. The rate of change is a plain comparison of period totals; it does not normalize for a difference in day counts, and no warning is raised when they differ. Match the day counts, such as 14 days before and 14 days after.

When to use this

• You want to record initiatives you ran (bid adjustments, budget changes, promotions, etc.) in a form you can measure later
• You want to keep things others caused — TV broadcasts, sales, buzz, stockouts — as reasons for KPI movement
• You want to compare how KPIs changed before and after an initiative you ran, to verify its impact
• You want to reverse-trace the reason KPIs improved from your recorded initiatives

Before you run

• Target account … if you handle multiple accounts, check first that the account you’re recording or analyzing is the right one.
• Initiative execution date … when registering an initiative log, you can only specify past dates.
• Verification period … the period you compare before against after (Prompt 4 always takes the same number of days on each side; default 14 days). Today’s and yesterday’s data may not be finalized, so a recent, finalized period is safest.
• Target brand / ASIN (optional) … specify these to narrow to a particular brand or product. Without them, the whole account is covered.

Quick reference

Goal	What you get	Changes	Prompt
Record an initiative you ran in a form you can verify later	The auto-assigned initiative ID and what you registered	Records an initiative log	Prompt 1
List / update / add notes to recorded initiatives	A list of initiative logs, or the update result	List: no change / update & delete: modifies the initiative log	Prompt 2
Record external factors (TV / sale / buzz / stockout)	The auto-assigned event ID and what you registered	Records an external event	Prompt 3
Compare KPIs for the 2 weeks before and after a bid adjustment	A comparison table of KPI deltas across the 2 weeks before and after	No change (read-only)	Prompt 4
Identify the changes that contributed to KPI improvement	A this-period vs. prior-period comparison and the contributing initiatives	No change (read-only)	Prompt 5
Judge the impact of an initiative you ran and decide between keep / expand / adjust / pause / revert / investigate	A before/after metric comparison table and one of six verdicts, with reasons	No change (mostly read-only; registers an initiative log if none exists)	Prompt 6

Telling recording prompts from analysis prompts

Prompts 1–3 record initiatives and external events in Picaro (a data write occurs). Prompts 4–5 only read recorded change history or KPIs to analyze and compare — they write nothing. Prompt 6 is essentially read-only, but if the initiative log being compared has not been registered, it may register one after confirming with you. None of them change your Amazon ad settings themselves.

---

Record initiatives and external events

Prompt 1: Register an initiative log

Record an initiative you ran (bid adjustment, budget change, promotion, etc.) in Picaro, in a form you can compare before/after (Before/After) later.

When to use — when you want to keep a record of an initiative you ran so you can measure its impact later.

What you need — the initiative type, initiative name, and execution date (a past date).

Register an initiative log.
- Type: bid adjustment
- Name: {{INITIATIVE_NAME (e.g. Bid -22% on 18 high-ACoS keywords)}}
- Date executed: {{DATE_EXECUTED (e.g. 2026-05-18)}}
- Details: what the initiative was for (optional)
- Status: measuring

Note: this is a log for measuring the effect of an internal initiative (equivalent to `manage_measure`). To record external factors such as sales events, use the separate prompt (Record an external event).

Next prompt that uses this result: {{DESTINATION (e.g. Measure an initiative's impact, 2 weeks later)}}

What you can change — the initiative name, execution date (past dates only), and type (choose from “bid adjustment,” “budget change,” “placement adjustment,” “promotion,” “negative,” “other”). If you just executed a bid-adjustment proposal, you can also link that proposal.

What you get back — the auto-assigned initiative ID and a table of what you registered, with guidance to measure impact 7–14 days after the initiative.

Changes — records the initiative log in Picaro (a write occurs; it does not change your Amazon ad settings).

Next steps — verify the recorded initiative’s impact 7–14 days after you ran it, using Prompt 4 or the Before/After impact measurement in Check KPIs on the dashboard.

---

Prompt 2: List / update / add notes to initiative logs

Review the initiative logs you registered earlier in a list, and update progress notes or status.

When to use — when you want to check the status of recorded initiatives, or update progress notes or status.

What you need — the target initiative ID when updating or deleting.

Show me a list of the initiative logs that are still being measured (status=monitoring).

1. Filter to type "{{FILTER_TYPE (e.g. bid adjustment)}}". The pattern_id of an initiative log is only
   one of the six values cpc / budget / placement / promotion / negative / custom, so map the type given
   to one of those six before filtering
   (bid adjustment→cpc, budget change→budget, placement adjustment→placement, promotion→promotion,
   negative keyword→negative, other→custom).
   For a type that cannot be mapped, do not filter: return everything and state explicitly that
   "the specified type does not exist in pattern_id."
2. When the filtered result is 0 items, always report "0 initiatives match the conditions" and
   "there are 0 initiative logs at all" as distinct cases
   (retrieve the list again with the filter conditions removed to confirm).
3. For each initiative, give both the days elapsed since the initiative date (date) and the days elapsed
   since the registration date (createdAt).
   The registration date is not included in the list, so fetch each initiative individually to check it.
   When the two differ, treat the initiative-date basis as primary and note that there is a gap.
4. The "today" used to calculate days elapsed must be the last finalized day, determined after checking
   the ingestion status of the ad data (if today is not finalized, do not use today as the basis).
5. State explicitly that anything whose days elapsed on the initiative-date basis exceeds
   {{EVALUATION_GUIDE_DAYS (e.g. 14 days)}} has "reached its evaluation time," and sort by days elapsed
   descending.
6. Output as a table (initiative date / type / name / status / days elapsed since the initiative date /
   days elapsed since the registration date / evaluation time reached / ID).

Note: this is a list of internal initiative logs (manage_measure). External event logs (manage_event) are
out of scope.

The next prompt that uses this result: {{DESTINATION (e.g. measure an initiative's impact)}}
The values to hand over are the initiative ID, the initiative date, and the type. Always add that the
Before/After comparison windows have to be specified yourself around the initiative date, and that because
an initiative log does not hold the target campaign / ASIN, the comparison is account-wide.

What you can change — the list’s filter conditions (type, status, etc.). You can also specify a particular initiative ID (e.g. evt_2026_05_18_cpc) to update its contents, add a progress note, or delete it (ask like “Add the note ‘Day 3: results starting’ to evt_2026_05_18_cpc”).

What you get back — a list table of initiative ID / type / name / execution date / status / days elapsed (up to 20 by default, newest execution date first), or the result of an individual fetch or update.

Changes — listing and individual fetch make no change (read-only). Update, add-note, and delete modify the initiative log (a write occurs). Deletions always go through a confirmation step.

Next steps — once results are in, compare the before/after KPIs with Prompt 4.

---

Prompt 3: Record an external event

Record external factors that weren’t your own initiative — TV broadcasts, sales, buzz, stockouts — so you can reference them later as reasons for KPI movement.

When to use — when you want to keep the background behind a big KPI move (factors outside your control) so you can look back on it later.

What you need — the external-event type, start date, and event name.

Record an external event (sale, TV broadcast, buzz, stockout, etc.).
- Type: {{TYPE (one of tv / sale / buzz / stockout / other. Use other for anything with no match, such as a price increase or a competitor's move)}}
- Start date: {{START_DATE (YYYY-MM-DD. e.g. 2026-06-11)}}
- End date: {{END_DATE (YYYY-MM-DD, optional. Omit for a single day)}}
- Label: {{EVENT_NAME (e.g. Prime Day 2026 Spring). If you want to keep the scope or a supplementary note (e.g. all ASINs, 20% OFF coupon concurrent), include it inside this label, because the name field is the only place it can be stored}}

[Before registering]
Retrieve the list of existing events and confirm there is no duplicate before you register.
The list can be narrowed with filter_from / filter_to (date range) and filter_type (type), so narrow it to the period you are about to register and look for duplicates.
An event spans a period from date to end_date rather than a single day, so judge duplicates by overlapping periods (not by a matching start date alone).

[After registering]
Retrieve the list again, confirm that what was registered (type, start date, end date, label) is as intended, and report it.
Always include the returned id (a UUID) in your report. You need this id to correct or delete the event later,
and there is no way to obtain it other than finding it in the list.
The items the list returns are id / type / date / end_date / label / registered_by_email / registered_by_user_id /
updated_by_email / updated_by_user_id / created_at / updated_at.
* registered_by_* and updated_by_* can come back as null (in testing, every existing event was null).
  Distinguish "registrant unknown" from "no registrant," and do not fill null in by guesswork.

[Watch-outs for using this event later]
A registered event does not appear automatically in dashboard or report responses.
When you check KPI movement for this period, retrieve the event list narrowed to the target period, match the dates against
the analysis period, and only then treat it as a candidate driver (do not conflate event-driven movement with initiative impact).
* Prompts that compare before and after an initiative actually use this list as an input. The comparison tools do not
  exclude events automatically, so if registration is skipped here, downstream analysis will mistake a sale's influence for initiative impact.
* Large sales often run a "lead-in sale" and the "main event" back to back, so register them as separate events
  (so that downstream period analysis can detect that the lead-in window bleeds into the early sale).

[What cannot be stored]
There are no structured fields for scope of impact, discount rate, target ASINs, and the like. The only option is to include them in the label string.
Assume, therefore, that you cannot search or aggregate by event name, and use naming a person can tell apart by reading.

The next prompt that uses this result: {{DESTINATION (e.g. dashboard KPIs with prior-period comparison)}}

What you can change — the start date, end date (optional; omit for single-day events), event name, and type (choose from “TV broadcast,” “sale,” “buzz,” “stockout,” “other”).

What you get back — the auto-assigned event ID and a table of what you registered.

Changes — records the external event in Picaro (a write occurs; it does not change your Amazon ad settings).

Term note — a recorded external event is not displayed automatically in dashboard or report responses. When you run a before/after comparison of an initiative, retrieve the event list narrowed to the target period and match it up as a candidate driver of the KPI movement (the comparison tools do not exclude periods automatically).

Next steps — go to Check KPIs on the dashboard if you want to see how KPIs moved in light of the event you recorded.

---

Analyze and verify change history

Prompt 4: Compare KPIs for the 2 weeks before and after a bid adjustment

For a specified bid adjustment, compare KPI performance for the 2 weeks before and the 2 weeks after execution.

When to use — when you want to verify with numbers whether a recorded bid adjustment actually had an effect.

What you need — the execution date of the bid adjustment you ran. You can run the judgment off the execution date even if no initiative log has been registered (if one has, it is matched against the log from Prompt 1).

Judge the impact of the bid adjustment executed on {{EXECUTION_DATE (e.g. 2026-08-04)}} and decide whether to continue it.

Preconditions (do these first and state the results in the output)
1. Check with manage_measure(action=list) whether there is a record of this initiative. If there is, quote the initiative ID, pattern_id, and execution date.
   If there is no record, state "no initiative log recorded" explicitly and proceed on the basis of the execution date given.
   Even when you pass an initiative ID, the comparison tools do not verify that the ID exists, so always confirm its existence with manage_measure(action=get) before using it.
   (action=get returns "no matching log found" for an ID that does not exist, so this check actually works.)
2. Check with manage_event(action=list) whether an external event such as a sale, TV broadcast, or stockout overlaps the comparison period.
   If one does, shift the comparison period or state the influence in the output. The comparison tools do not exclude events automatically.
   An event spans a period from date to end_date, so look at the overlap of the whole period with before / after, not just the start date.

Conditions for the comparison (strict)
- Take the {{COMPARISON_DAYS (e.g. 14 days)}} immediately before the execution date as before and the {{COMPARISON_DAYS (e.g. 14 days)}} immediately after as after, and always match the number of days in before and after.
  The rate of change is a plain ratio of period totals with no normalization for the number of days, and no warning is raised when the day counts differ, so a comparison that is not matched is invalid.
- End the after period on the day sales figures are finalized. Sales-side data takes about 7 days and traffic-side data about 3 days to finalize.
  Confirm the last finalized day with get_data_ingestion_status, and do not include fully_missed / in_progress days in after.
  If the run raises a "before aggregation is final" warning, always lower the end of the period to the finalized day and rerun. Do not judge on unfinalized values.
- Fix the source of the ad-side metrics (ad spend, clicks, ad sales, orders, ACoS, ROAS, CTR, CPC, CVR) to compare_measure alone. Values differ from other tools, so do not mix them.
- compare_measure does not return total sales. For total sales alone, call get_dashboard once for the after period with include_previous=true
  (the prior period then automatically becomes "the immediately preceding period of the same length," which mechanically guarantees that before and after have the same number of days).
  Treat the total sales retrieved as a reference value from a different source, and distinguish it in the table by naming its source.
  Even for the same period and the same account, the ad sales from compare_measure and from get_dashboard may not match
  (in testing the after period matched while the before period alone was off by a few percent). If there is a divergence, state its size and do not overwrite one value with the other.
- CTR is displayed rounded to one decimal place, so put the value recalculated as clicks ÷ impressions in the delta table.
  Even when the rounded display looks identical for before and after, the recalculation can show a meaningful move.
- Do not use the judge the tool returns (improved/neutral/degraded) for your conclusion, because its criteria are undisclosed. Show it only as a reference.
  There is a measured case where judge returned neutral even though both ACoS and ROAS had worsened.

What to output
- A delta table with Before / After / rate of change for ACoS, ROAS, sales (ad sales), and CTR. Show ad spend, clicks, and orders alongside them.
- Also show the rate of change in total sales as a reference (state that the source is get_dashboard), and note when its sign differs from that of ad sales.
- compare_measure also returns the top campaigns by ad spend and ACoS, so name 1–3 campaigns that drove the overall change.
  However, campaigns whose before ad spend was 0 come out as "ACoS +100%," so write new delivery and worsening as distinct cases.

Criteria
- If ACoS meets {{IMPROVEMENT_CRITERION (e.g. improved by 10% or more in relative terms)}} and ad sales are within -5%, recommend Keep.
  If ROAS has also improved, consider Expand.
- If ACoS improved but ad sales worsened by more than -10%, consider Revert.
- If none of the above applies, or if uncertainty remains from preconditions 1 and 2, the verdict is Investigate.
- Always state whether the size of the improvement is a "relative rate of change (%)" or "percentage points (pt)."
  ACoS 61.1%→58.6% is -4.0% relative and -2.5pt absolute, and which reading you use changes the conclusion.

Guardrail: do not improve ACoS at the cost of a large drop in ad sales.
Guardrail: do not conclude "no effect" or "no need to continue" when the initiative cannot be identified or the period is not finalized. Always return Investigate and state what information is missing.
Guardrail: state that this is a before/after comparison only, with no control group. Seasonality, inventory, price, and review movement cannot be separated out.

Finally, output these three points.
1. Recommended action — state the verdict (Keep/Expand/Adjust/Revert/Investigate), the reason, the priority, the expected effect, the confidence, and the risks
2. How to execute — for Revert, a proposal to return bids to their pre-initiative level; for Expand, a proposal to widen the target. Apply either only after the user has reviewed and approved the proposal
3. Measurement — {{COMPARISON_DAYS (e.g. 14 days)}} after execution, retrieve the same metrics again and re-judge with "measure an initiative's impact"

What you can change — the execution date / the number of days in the comparison period (default 14 days; always the same number of days before and after) / the ACoS improvement criterion (default improved by 10% or more).

What you get back — a delta table of Before/After/rate of change for ACoS, ROAS, sales, and CTR (with ad spend, clicks, and orders shown alongside), plus a Keep/Expand/Adjust/Revert/Investigate verdict.

Changes — no change (read-only).

Term note — it’s similar to the Before/After impact measurement in Check KPIs on the dashboard, but this one is for bid-type initiatives and always matches the number of days compared before and after (default 14 days; strictly enforced, because the rate of change is not normalized for a difference in day counts and no warning is raised). Use Prompt 6 when you want to cover initiatives other than bid adjustments (budget changes, promotions, negatives, and so on), or when you want to specify different comparison periods before and after execution.

Next steps — go to Prompt 5 if you want to reverse-trace which change worked across the whole account. Go to Prompt 6 if you want to check impact with the six verdicts Keep/Expand/Adjust/Pause/Revert/Investigate, including initiatives other than bid adjustments.

---

Prompt 5: Identify the changes that drove KPI improvement

Report account-wide KPI performance for a period, compare it against the prior period, and identify the changes that contributed to the improvement.

When to use — when you want to reverse-trace the reason your numbers improved from your recorded initiatives.

What you need — the target period (defaults to the last 30 days).

Create a report that compares account-wide sales, ACoS, and ROAS for the last 30 days against the prior period, identifies the initiatives that contributed to the KPI improvement, and decides what to do about each (continue / expand / stop).
Goal: to identify the initiatives that worked and use that for the decision to roll them out more widely or stop them.

## Step 0. Fix the periods before you start (cannot be skipped)
1. Confirm the last finalized day with get_data_ingestion_status. Do not include fully_missed / in_progress days in the current period.
2. Take the current period as the {{COMPARISON_DAYS}} days back from the last finalized day and the prior period as the same {{COMPARISON_DAYS}} days immediately before it, and always match the number of days in both periods.
3. State the "last finalized day," "the start and end dates of the current period," "the start and end dates of the prior period," and "the number of days in each period" at the top of the report.
* A comparison whose day counts are not matched reports "a change" even when the change is zero. Including even a single unfinalized day moves the rate of change by several points, so do not skip this check. The tools do not warn about mismatched period lengths.
* Do not use rollup_status to judge finalization. A single ad type with no delivery drops the whole day to no_data even when every other report is completed. Look at the status of each report.

## Step 1. Fix the KPI source to one (cannot be skipped)
- Fix the primary KPI source for this report to {{KPI_SOURCE}} (either get_dashboard or analyze_ad_type_performance, not both) and state it at the top of the report.
- How to choose the source: get_dashboard does not return ROAS or clicks (it returns total sales, ad sales, ad spend, ACOS, TACoS, orders, and CVR). If ROAS is a primary KPI, either choose analyze_ad_type_performance or state that ROAS is "calculated by us (ad sales ÷ ad spend)." analyze_ad_type_performance, on the other hand, covers only the ad side (SP/SB/SD) and does not return total sales. Either choice leaves some metric missing, so write "not retrievable from this source" for whichever is missing.
- Do not mix figures from multiple sources within one table or one comparison. Even for the same period and the same account, ACoS, ROAS, and ad spend do not match across sources (the aggregation source, the tax treatment, and the attribution window differ). When you show a value from another source as a reference, always name the source and state the size of the divergence.
- Do not present a metric a tool does not return as if it had been returned. State values you calculated yourself as "calculated by us."
- Keep the units of a change in a ratio consistent. Standardize on either "absolute difference (points)" or "relative rate of change (%)" throughout the report and state which. Units returned differ by tool, so do not simply line up the values from the responses.
- Every time you present a ratio, show the numerator, the denominator, and the number of days alongside it. Make it possible for the reader to tell whether the change came from the denominator or the numerator.

## Step 2. Collect the records of initiatives (check all three routes)
Run all three of the following and record how many records each returned.
1. get_change_history … the change history on Amazon's side (lookback is limited to 90 days; pass the profile_id value tied to the account)
2. manage_measure (action=list, no filter) … Picaro's initiative log
3. query_audit_log … the record of operations via MCP

Important handling:
- Do not write "no initiatives were run" just because one of them returned 0 records. The correct statement is "the records of initiatives could not be retrieved, so whether any were run cannot be determined." The absence of a record does not mean the absence of an initiative.
- For each of the three routes, state separately "the number of records retrieved" and "the scope that route inherently cannot capture."
- query_audit_log is the record of the calling agent's own tool calls, not a record of changes to ads. Do not treat it as a substitute for the initiative log. Changes made by other people, other agents, or from Seller Central do not appear here.
- Do not treat the count from query_audit_log as the complete count. The response reports "records shown / records matched / records scanned" separately, and when the scan limit (10,000 records in testing) is reached it returns a next_cursor pointing at the unscanned remainder. In that case "N matched" is only a lower bound. Always write in the report whether the scan limit was reached.
- Do not use audit_level=mutation as a filter for "write operations." In testing, read-only listing tools were also labeled audit=mutation. Judge by tool name, not by the label. That said, write attempts via MCP are recorded whether they succeed or fail, so it is usable for your own route.
- If the records are 0 but ad spend and campaign allocation have actually moved, state that this is more likely a "gap in the recording routes" than a "true zero," and leave it as a confirmation action.
- Check external events (sales, TV, stockouts) separately from initiatives with manage_event (action=list). Events may be registered even when there are 0 initiative logs, and they can be the main driver of a KPI change. Always include events that overlap the period in the report.

## Step 3. Only when there is at least one initiative record, move on to deciding what to do
- For each initiative, compare Before/After with the number of days matched on either side of the execution date.
- Sort by size of impact (the size of the KPI improvement) and recommend one of "continue," "expand," or "stop."
- Do not use the tool's overall verdict (judge and the like) in place of your Guardrail judgment. Efficiency metrics can improve while sales and orders worsen, so always check sales and orders independently.

## Step 4. Isolating causation (cannot be skipped; do this whether or not Step 3 applied)
Before calling a KPI change the result of an initiative, check all of the following and state them in the report.
1. Change in exposure — did impressions, clicks, and ad spend fall at the same time? Consider the possibility that the improvement in efficiency metrics is "the result of inefficient delivery stopping."
2. Direction of scale versus efficiency — did efficiency (ACoS/ROAS) and scale (sales, orders) move in opposite directions? If so, do not simply call it an "improvement."
3. Absence of a control group — state that this is a before/after comparison only, with no control group. Write that seasonality, category movement, inventory, price, and review movement cannot be separated out.
4. Volatility of the figures — state that even finalized periods can change value on re-ingest.
If any of the above cannot be isolated, do not assert "X worked"; write "X happened at the same time as Y (causation undetermined)."

## Guardrail
- Do not recommend continuing or expanding an initiative that worsened sales or orders.
- Do not issue a continue / expand / stop recommendation while the evidence (the initiative record) is empty. When the initiative cannot be identified, replace the recommended action with "actions to put the records in order so that a judgment becomes possible" rather than a judgment on the initiative.
- Always state the scope retrieved and the scope missing separately. Write "cannot be determined" for anything you cannot assert.

## Output
Finally, output these three points. If the initiative could not be identified, write that fact and the alternative content under each item.
1. Recommended action — continue / expand / stop per initiative, with the reason, the priority (by size of KPI improvement), the expected effect, the confidence, and the risks. If the initiative cannot be identified, list actions for putting records in order and confirming causes in priority order, and state "why it is not sorted by size of KPI improvement"
2. How to execute — for expand and continue, propose widening the target or increasing the budget with {{EXECUTION_PROMPT}} and execute after approval. If there are 0 targets to hand over, write that and hand nothing over
3. Measurement — retrieve the same metrics again {{REMEASUREMENT_DAYS}} days after execution and compare. Apply Step 0 (finalization boundary, matched period lengths) and Step 1 (fixed KPI source) on the re-measurement too. Revert if it has worsened

What you can change — the target period (default 30 days; the prior period is compared at the same number of days) / the primary KPI source (fixed to either get_dashboard or analyze_ad_type_performance, not both).

What you get back — a KPI comparison of this period against the prior period, plus a list of initiatives gathered from all three routes (Amazon-side change history, Picaro initiative log, MCP operation records). Each initiative comes with a continue / expand / stop recommendation and its reason, priority, confidence, and risks. When no record of initiatives can be retrieved, you get actions for putting records in order, in priority order, instead of a judgment.

Changes — no change (read-only).

Next steps — use Prompt 4 to compare the same number of days before and after (14 by default) if you want to dig into a specific initiative individually. Go to Create reports to include it in a monthly report.

---

Prompt 6: Measure an initiative’s impact and decide whether to keep it or revert it

For an initiative you ran, compare the metrics before and after execution and reach a conclusion with one of six verdicts: Keep, Expand, Adjust, Pause, Revert, or Investigate.

When to use — when you want to judge whether an initiative you ran (not just bid adjustments, but also budget changes, promotions, negatives, and so on) is actually having an effect, and decide whether to continue it, widen it, or roll it back.

What you need — what the initiative was and the date you ran it. The comparison target (campaign, keyword, ASIN, etc.). The comparison periods before and after execution. The metrics you want to evaluate. The level at which you judge something has worsened (e.g. Orders within -10% week over week).

{{INITIATIVE_EXECUTED (e.g. lowering keyword bids)}} was applied on {{EXECUTION_DATE (e.g. 2026-08-10)}}. I want to judge
whether it is having an effect, and decide between keep, expand, adjust, pause, revert, or investigate.

For the target ({{TARGET_CAMPAIGN_KEYWORD_ASIN (e.g. campaign ID 12345678)}}), compare
{{EVALUATION_METRICS (e.g. ACoS, Orders, CPC)}} between the pre-execution period
({{PRE_PERIOD (e.g. the 14 days before the execution date)}}) and the post-execution period
({{POST_PERIOD (e.g. the 14 days from the execution date)}}), and present them in a table. Judge each one as
improved, worsened, or unchanged.

If a metric judged as worsened falls below {{LEVEL_TO_PROTECT (e.g. Orders within -10% week over week)}}, state
explicitly that it is a "Revert candidate." Based on the judgment, present exactly one of Keep, Expand,
Adjust, Pause, Revert, or Investigate, along with the reason.

Execution conditions
- Always retrieve before and after in two separate calls (do not have a single call return the prior period at the same time)
- For an account-wide comparison, pass before / after to compare_measure (it returns judge and the rate of change for the main KPIs).
  This tool has no parameter for narrowing the target, and what it returns is the account total plus the top 10 campaigns
  (by ad spend, cost and ACOS only). If the target is not among them, or if Orders or CPC is needed, switch to the
  per-granularity methods below
- For a campaign-level comparison, call list_existing_sp_campaigns (include_metrics=true) twice, once for the before period and once for after.
  Adding name_filter causes include_metrics and the period to be ignored, so when retrieving metrics call it with the period only,
  and confirm that truncated is false and that returned matches total_results before matching up the targets
- For a keyword / product-target-level comparison, call list_target_performance twice, before and after, and narrow the
  target with search_key. If target_fetch_truncated is true, raise max_pages to at least target_total_pages_available and
  retrieve again. If it still truncates, state that "full retrieval cannot be guaranteed" and treat the verdict as provisional. Upstream
  aggregation is cached for several hours, so also mention that recent changes may not be reflected. Calling multiple periods in
  parallel tends to time out, so run them one at a time
- Record and reference initiatives with manage_measure (action=list / add / get, specifying pattern_id and proposal_id).
  If there is no execution record, confirm the execution date, target, and change details with the user before registering. manage_event is for
  recording external events (sales, stockouts, TV, etc.) and is not an initiative log, so use it (action=list) to check whether an external
  event overlaps the comparison period, and if one does, note it in the interpretation
- Sales-side metrics (sales, orders, ACoS, ROAS, CVR) finalize in about 7 days, and traffic-side metrics (impressions, clicks, cost) in about 3 days.
  If the end of the comparison period includes unfinalized days, state so, and where possible re-cut the period to end on a finalized day
- Always state exactly one of the six verdicts (Keep/Expand/Adjust/Pause/Revert/Investigate)
- If the verdict is Revert, create a proposal to restore the pre-change values and advise that it be applied only after obtaining the user's approval
- If there is partial data or truncation, withhold the verdict and state that it is "provisional." Do not fill in metrics you could not retrieve by guessing

What you can change — the target (campaign, keyword, ASIN, etc.), the comparison periods before and after execution, the evaluation metrics, and the level at which something is judged to have worsened.

What you get back — a comparison table of metrics for the pre-execution and post-execution periods (with an improved / worsened / unchanged judgment), plus exactly one verdict from Keep / Expand / Adjust / Pause / Revert / Investigate with its reason. If there is partial data or truncation, the verdict is withheld and marked “provisional.”

Changes — no change (mostly read-only). However, if the initiative log being compared has not been registered, it may be recorded after confirming the execution date, target, and change details with you (a write occurs). It does not change your Amazon ad settings themselves.

Term note — Prompt 4 “Compare KPIs for the 2 weeks before and after a bid adjustment” is limited to bid adjustments and always compares the same number of days on each side (14 by default; you can change it). Prompt 6 is the general-purpose version: it works for any type of initiative, lets you specify the comparison period per initiative, and reaches a conclusion with one of six verdicts. This is the one other prompts point to when they say “re-evaluate the impact after execution.”

Next steps — if the verdict is Revert, create a proposal to restore the pre-change values and apply it only after obtaining the user’s approval.

---

Related categories

• Check KPIs on the dashboard — use recorded initiatives in Prompt 3 “Before/After impact measurement”
• Adjust bids / Adjust budgets — standard practice is to leave an initiative log alongside executing a proposal
• Set targets for sales, ad spend, and ACoS — pre-register a target ACoS / TACoS as the baseline for judging an initiative’s impact
• Create reports — bundle initiative logs and external events into the monthly report
• Save rules to systematize proposal approval and monitoring — record initiatives you approved and applied here