---
name: what-changed-analysis-enhanced
description: Show what changed between the current and previous period for an Intentwise account — account totals, the campaigns that moved ad sales most, and the products that moved total sales most. Use for "what changed", period-over-period change reports, or /what-changed-analysis-enhanced.
---

# What Changed Analysis

Three tables, current period vs the previous period, shown in chat. No files, no deck.
Read-only — this skill never changes bids, budgets, or campaign states.

This is a change report, not a leaderboard. The ranked tables answer **which rows moved most**,
in either direction, sorted by the size of the move. A campaign that spends a lot and spent the
same last period changed nothing and does not belong in the tables.

| # | Table | Grain | Sorted by | Rows |
|---|---|---|---|---|
| 1 | Account | account totals | — | all metrics |
| 2 | Campaigns driving the change | campaign | absolute change in ad sales | 10 |
| 3 | Products driving the change | ASIN / product | absolute change in total sales | 15 |

Increases and decreases sit in one table together, biggest move first. Keep the ranked tables to
the columns listed in Step 5 — no rate columns, no contribution shares, no extra metrics.

## Step 1 — Resolve the account

Call `get_organization`, then `get_intentwise_accounts`. One account → use it. More than one →
ask which, and ask nothing else. Use anything the user already said earlier in the conversation
— account, channel, dates — instead of asking again.

**Channel is `amazon`, ads data source is `ads`.** Never ask which platform. Only switch if the
user explicitly names a different one.

Check `available_data_sources` for `vendor_central` or `seller_central` — that tells you which
total-sales column to read: `product_sales` for seller, `shipped_revenue` for vendor. The calls
are still `data_source='ads'`. If neither is connected, the skill still runs: drop the total-sales
and TACOS rows from the account table, sort products by absolute change in ad sales instead, and
say in one line that total sales isn't available for this account.

## Step 2 — Set the window

Default to the **last 7 days vs the prior 7 days**. If the user names a period, use it and
compare against the immediately preceding window of equal length. State what you used; don't ask.

Use the same two windows for all three tables so the numbers reconcile.

## Step 3 — Pull the data

Three `get_insights` calls, issued **in parallel** in a single turn — none depend on each other.
Same account, same windows, all `data_source='ads'`. Express both periods in one call; the
insights service returns current and previous together, so never make two calls per period.

| Call | entity | Ask for |
|---|---|---|
| A. Account | `account` | Ad spend, ad sales **and** total sales, current and previous period |
| B. Campaigns | `campaign` | Per-campaign ad sales and ad spend for both periods, sorted by the **absolute change in ad sales**, limit 10 |
| C. Products | `product` | Per-ASIN total sales and ad spend for both periods, sorted by the **absolute change in total sales**, limit 15 |

**Ask the service to sort by the change.** It handles biggest-movers ranking on both periods
in one query, so the rows come back already ordered and the tables render straight from the
response. Don't pull a wide candidate set to re-rank client-side, and don't ask for extra metrics
that won't appear in the output.

**Both the `account` and `product` entities carry advertising and total sales together.** That's
one call each, not two — ask for both sides in the same call and don't force a separate retail
source or join anything client-side.

Things that cost a retry if you skip them:

- If total sales comes back empty on A but the retail source is connected, re-run the `product`
  pull without a row limit and take its grand-total row as account total sales rather than
  summing the top rows — a top-N slice is a subset and won't tie out.
- **The first row of most results is a grand total** with null grouping columns. It's the sum
  across all groups, not an "unattributed" bucket. Use it for account totals if convenient,
  never show it as a ranked row.
- Products with total sales but no ad spend are real and worth keeping — unadvertised revenue is
  part of what changed. Don't filter them out.
- If a call returns nothing, don't retry with a different entity. Note the gap and present the rest.

## Step 4 — Finish the numbers (client-side)

Only what the response doesn't already give you:

- **Change** = current − previous, shown as both the absolute delta and the percent change.
- **ACOS and TACOS for the account table only**, derived from summed bases, never by averaging:
  ACOS = ad spend ÷ ad sales; TACOS = ad spend ÷ total sales.
- **Rate changes are percentage points.** ACOS moving 30% → 24% is **−6.0 pts**, not −20%.
- If a row has no previous-period value, show the change as `new` rather than a percentage.

No re-sorting, no contribution shares, no per-row rates. The ranked tables render in the order
the service returned them.

## Step 5 — Present the results

Open with one line naming the account, channel, and both date ranges. Then three markdown tables.

**1. Account**

`Metric · Current · Previous · Change · % Change`

One row each: Ad spend, Ad sales, Total sales, ACOS, TACOS.

**2. Campaigns driving the change**

`Campaign · Ad sales · Ad sales Δ · Spend · Spend Δ`

**3. Products driving the change**

`ASIN · Product · Total sales · Total sales Δ · Ad spend · Ad spend Δ`

Truncate long product titles to about 40 characters so the table stays readable.

**Colour the deltas.** Prefix every change value in tables 2 and 3 with 🟢 when positive and 🔴
when negative, so increases and decreases are separable at a glance in a single mixed table. The
sign stays on the number — the glyph is a second channel, not a replacement for it.

On the account table, colour by meaning rather than by sign: falling ACOS and TACOS are good and
get 🟢. Everywhere else, positive is 🟢.

Formatting: money as `$15,846`, ACOS and TACOS as `21.8%`, percent changes as `+12.4%`, rate
changes as `−6.0 pts`.

Close with two or three short bullets on what actually moved — which rows carry most of the
account change, whether the increases and decreases offset or compound, and whether total sales
moved with ads or independently of them. Tie it to outcomes, not to the mechanics of the pull,
and don't restate the tables.

## Rules

- Never invent a row. A missing section is a note, not a guess.
- Sort on the change, never on current-period size — and let the service do the sorting.
- Ranked tables carry only the columns in Step 5.
- One account per run.
- Same two date windows across all three tables.
- Read-only.