🚨 Anomaly Alerts: Letting AI Flag Sudden Sales, Traffic, or Ad Spend Changes

Last updated:

📋 Overview

A sales drop is cheap to fix on day one and expensive to fix on day ten. Anomaly alerts are automated checks that compare today’s numbers against what your own history says is normal, then tell you when something falls outside that range — a sessions collapse, a conversion dip, an ad spend spike. This article covers which metrics are worth alerting on, how to build a baseline that respects day-of-week and seasonal patterns, how to read which metric moved first, and what to confirm in Seller Central before you change anything.


📊 What Actually Makes a Number an Anomaly

An alert is only as good as the definition of “normal” behind it. Four ideas do most of the work.

Baseline

The expected value for a metric on a given day, built from your own history. The simplest usable baseline is a rolling average of the same weekday over the previous several weeks — last four Tuesdays, not the last four days. A flat “last 7 days average” will fire every Saturday on a product that always sells slowly on weekends.

Deviation band

The range around the baseline you are willing to call normal. You can express it as a percentage (sales more than 35% below baseline) or statistically (more than two standard deviations from the mean). Percentages are easier to reason about; statistical bands adapt better to products with naturally choppy sales. Either is fine — pick one and write it down so you can tune it later.

Volume floor

A minimum amount of activity required before a metric is allowed to trigger an alert at all. A SKU with 11 sessions yesterday can swing from 18% conversion to 0% on a single order. Without a floor, your low-volume tail will generate most of your alerts and none of your useful ones.

Alert fatigue

What happens when the system cries wolf often enough that you stop opening the notifications. This is the main failure mode of anomaly alerting, and it is worse than having no alerts, because you will believe you are covered when you are not. Every tuning decision below exists to keep the alert count low enough that you still read them.


🛠️ Setting Up the Alert Set

1. Pick a short list of metrics worth waking up for

Start with five or six, not thirty. A practical set: Units Ordered, Sessions, Unit Session Percentage (Amazon’s conversion metric), Featured Offer %, daily ad spend, and daily ad-attributed sales. The first four come from Business Reports; the ad figures come from your advertising reports under Measurement & Reporting > Sponsored ads reports.

Set these at two levels: whole account, and your top SKUs by revenue. Account-level alerts catch marketplace-wide or account-wide problems. SKU-level alerts catch listing-specific ones. Mid-tail SKUs can be reviewed weekly instead.

2. Export enough history to build a baseline

You need enough weeks of daily data for the same-weekday comparison to mean something, and ideally a full year if your category has a seasonal shape. Pull daily Business Reports data by ASIN and daily ad spend by campaign, and keep them in one place — a spreadsheet, a database, or whatever your tool connects to. The baseline is computed from your own numbers, so a thin export produces a jumpy baseline and noisy alerts.

3. Set deviation bands wide, then tighten

Begin deliberately insensitive — something like a 40% deviation from the weekday baseline — and run it for a few weeks. Count how many alerts fired and how many turned out to be real. If almost everything was real, tighten. If you ignored half of them, loosen or raise the volume floor. These numbers are starting points for tuning, not a recommended setting, and the right band differs for a steady consumables SKU versus a seasonal one.

Add a volume floor per metric. Conversion rate alerts, in particular, should require a meaningful number of sessions before they can fire.

4. Define severity tiers and where each one goes

Not every anomaly deserves the same response. Three tiers are usually enough:

  • Critical — revenue is stopping right now: sales at or near zero on a top SKU, Featured Offer % collapsing, sessions dropping to a fraction of baseline. Push to phone or chat immediately.
  • Warning — a real move that is not an emergency: conversion down a third, ad spend up by half with flat sales. Collect into a once-daily digest.
  • Watch — a drift worth noticing over time: ad spend creeping up week over week. Review weekly, never as a push notification.

5. Keep a known-events calendar so expected swings stay quiet

Most false positives come from changes you made yourself. Maintain a simple dated log of promotions, coupons, price changes, bid or budget changes, new launches, restock gaps, and major Amazon shopping events, then feed it to whatever evaluates your alerts. An anomaly that coincides with a planned event should be suppressed or labeled, not escalated.

This is also what makes an AI layer worth adding. The detection math — compare today to baseline — does not need a language model. What a model adds is reading the anomaly against your event log and your other metrics and producing a ranked shortlist of possible causes with the check for each one.

6. Write the triage prompt to return hypotheses, not verdicts

If you route alerts through a general-purpose AI assistant, give it the same structure every time: the alerting metric and how far it moved, the other metrics for the same period, the last 30 days of the same metrics for context, your event log, and your definitions. Then ask for output in a fixed shape:

  • Three candidate causes, ranked by how well they fit the pattern
  • For each cause, the specific Seller Central or advertising report that would confirm or rule it out
  • Anything in the data the model could not explain

Instruct it explicitly not to recommend an action until a cause is confirmed. A model handed a sales drop will happily tell you to raise bids, and it has no way of knowing your listing was suppressed.

💡 Pro Tip: Log the resolved cause of every alert next to the alert itself. After a couple of months you will see that a few causes account for most of your real alerts — and that is what tells you which bands to tighten, which to retire, and which new check to add.


🔍 Reading Which Metric Moved First

The alert tells you something changed. The combination of metrics tells you roughly where to look. These pairings are diagnostic starting points, not conclusions — confirm each one in the report named before acting.

Sessions steady, conversion down

Traffic is still arriving but buying less. Shoppers are seeing something they do not like. Check your price against the competing offers, check Featured Offer % in Business Reports, check whether a new negative review landed, and check whether listing content or images changed. Also confirm in Manage Inventory that a popular variation has not gone out of stock, which pushes shoppers to a child ASIN they did not want.

Sessions down, conversion steady

Fewer people are reaching the page, but those who do still buy. Look upstream: a paused or budget-capped campaign, a bid change, a rank slip on a head keyword, a listing suppression, or a category-wide seasonal decline. Compare the drop against your other SKUs — if everything fell together on the same day, suspect a marketplace or seasonal cause rather than a listing problem, and check Account Health for anything account-level.

Ad spend up, ad sales flat

Either you are paying more for the same clicks or buying worse clicks. Pull the search term and placement data from your Sponsored ads reports and compare cost per click and click volume against the prior period. A spend jump with flat clicks points to rising competition on your existing terms; a spend jump with many new search terms points to an automatic campaign or a broad match picking up new queries.

Units flat, inventory moving oddly

Alerts on inventory movement that does not match sales catch receiving errors, misplaced units, and unexpected removals. The Inventory Ledger Report under Reports > Fulfillment > Inventory Ledger is where you reconcile what changed and why.


⚠️ Where Anomaly Alerting Breaks Down

Alerting on partial or restated data

Same-day figures are incomplete, and advertising data is adjusted after the fact as Amazon attributes conversions and removes invalid clicks. If you alert on today’s numbers at 10 a.m., you will fire every morning. Run anomaly checks on closed days, and if you want faster signal on advertising specifically, use an hourly data feed such as Amazon Marketing Stream rather than refreshing a daily report.

Treating every SKU as equally worth an alert

Turning on SKU-level alerts across a 400-SKU catalog produces dozens of notifications a day, nearly all from low-volume items where a two-unit swing looks like a 60% collapse. Alert on the SKUs that carry your revenue, apply volume floors, and review the long tail on a schedule instead.

Letting the alert trigger an automatic action

It is tempting to wire a spend anomaly straight to a campaign pause. The problem is that the alert does not know the cause. A spend spike during a legitimate demand surge is a reason to keep spending, and an automatic pause turns one good day into a week of lost rank. Keep actions behind a person until you have months of logged alerts showing the rule would have been right.

Never recalculating the baseline

A baseline built during a launch ramp or a peak season stays wrong for months afterward. Recompute on a rolling window, and reset the baseline deliberately after any permanent change — a price repositioning, a pack size change, a new main image — so the new normal becomes the comparison point.


❓ FAQs

Do I need a dedicated anomaly detection tool, or can a spreadsheet do this?

A spreadsheet with daily exports and a same-weekday rolling average will catch most large, slow problems and costs nothing to build. Dedicated tools earn their place when you need alerts within hours rather than the next morning, or when your SKU count makes manual exports impractical. Tool capabilities and integrations in this space change quickly, so confirm what a vendor currently supports on its own documentation rather than relying on a comparison you read somewhere.

How much history do I need before alerts are useful?

Enough weeks for a same-weekday baseline to stabilize — a handful of weeks will get you started, a full year lets you account for seasonality. For a brand-new ASIN, skip anomaly alerting entirely for the first several weeks; sales during a launch ramp have no stable normal to deviate from, and anything you compute will fire constantly.

Should I alert on profit instead of sales?

Only if the data feeding the alert actually contains your costs. Amazon’s reports include fees but not your landed cost of goods, so a “profit” alert built on Seller Central exports alone is really a revenue alert with a different label. If you maintain unit costs in a separate system, a margin alert is worth having — otherwise, alert on sales, spend, and conversion, and check margin on your own schedule.

What should I do first when a critical alert fires?

Confirm the listing is live and buyable before investigating anything else. Open the detail page as a shopper, check that the offer is present and you hold the Featured Offer, and check Manage Inventory for stock and listing status. A suppressed or out-of-stock listing explains the whole anomaly and makes every other analysis unnecessary.