Catching Amazon Ad Performance Anomalies Before They Cost You

The gap between the break and the finding is pure margin

Every operator has sat through some version of this meeting. Someone senior asks why ACoS jumped in the third week of the month, and the honest answer is that a bid overshot, or a competitor moved onto a term, or a budget cap started cutting off the best hours, and it happened on a Tuesday nobody was looking. The break took a day. Finding it took three weeks. Explaining it is somehow the worst part.

Those three weeks are the cost. A campaign that breaks quietly and gets caught in the monthly review has spent weeks of budget against an assumption that stopped being true on day one, and margins are thin enough now that a quarter does not absorb many of those. The breaks themselves are unglamorous: a bid change that overshoots, a competitor entering a term you have owned for a year, a budget cap truncating your best hours, a listing that goes unavailable while campaigns keep bidding into it. They show up in the data within a day or two, and almost none of them announce themselves.

Anomaly detection is the practice of shrinking that gap: comparing each campaign and target against its own recent history every morning, and flagging what that history does not explain. Done well, the stakeholder conversation becomes "we caught this Tuesday and here is what we did" rather than an autopsy. Done badly, it produces eighty alerts a morning, gets muted inside a fortnight, and leaves the account with the feeling of coverage instead of the coverage.

What follows is what to watch and at what grain, how the standard method works and the four places it will mislead you, how to set a threshold you will still be reading in a month, and the filtering step almost nobody builds.

Quick answer

• What it is. Comparing an entity's current numbers, usually a campaign-and-target combination, against that same entity's own recent history, and flagging the moves its normal variation does not explain.
• What it buys you. The expensive quiet break caught the day it happens instead of weeks later in a review, and caught across the long tail no manual review ever reaches.
• Monitor the inputs, meaning spend, clicks, CPC, conversion rate and impression share, rather than only composite ratios like ACoS. A ratio move does not tell you which side of it moved.
• Compare at campaign-and-target grain, with a minimum click volume floor. Account level absorbs almost every break worth catching.
• Set the threshold to the number of alerts a person will read each morning, then backtest to find it. There is no statistically correct number, only an attention budget.
• Filter every candidate against causes you already know about before it becomes an alert. This is the step that separates a scan people use from a scan people mute.
• Know the blind spot. A rolling-average comparison cannot see slow decline, by construction rather than by misconfiguration. Keep the scheduled review for that.

What Amazon PPC anomaly detection should watch, and at what grain

ACoS is a ratio, so a ratio spike tells you half of what you need

An ACoS that moved from 28% to 41% overnight tells you a ratio changed, not whether spend rose, sales fell, or both moved a little in opposite directions. Those are three problems with three different responses. Any monitor built on a ratio, including TACOS and ROAS, inherits the ambiguity of its numerator and denominator. So monitor the inputs alongside the composite: spend, clicks, impressions, CPC, conversion rate, and units, with ACoS as confirmation rather than trigger. When the input series carry the alert, the alert arrives with a direction attached.

Impressions break first, ACoS confirms last

Impressions and impression share respond the moment competitive pressure or eligibility changes, CPC and clicks follow within a day, spend follows clicks. Conversion rate runs on its own clock and is contaminated by attribution timing, since conversions attribute back to the click date inside a window, so a recent day is incomplete and restates upward for several days. Orders and ACoS settle last. Two consequences: alert only on ACoS and you are watching the slowest metric to stabilize, and never scan the current day, because a partially attributed day against a fully attributed baseline manufactures a conversion-rate collapse every morning. Impression share and rank data from the Search Query Performance report is where competitive shifts surface earliest.

The useful grain is campaign-and-target with a volume floor

At account level almost nothing is visible. A target that quadrupled its spend is a rounding error against the account total, which is why account dashboards look calm through most of the failures worth catching. At campaign level movement is real but frequently meaningless, particularly in auto campaigns where the target mix churns daily. The grain that carries signal is usually campaign-and-target, with placement and match type as extra cuts when you need to localize the cause.

Push lower and you hit the opposite problem, which is where most homegrown alerting fails. Below a certain click volume, nothing is a signal. A target with six clicks and zero orders looks alarming until you do the arithmetic: at a 10% baseline conversion rate, zero orders on six clicks happens 53% of the time (0.9 to the sixth power). The volume floor is therefore load-bearing, and it should differ by metric, since CPC stabilizes on relatively few clicks while conversion rate needs an order of magnitude more. Everything below the floor gets monitored one level up instead.

Z-score anomaly detection, explained plainly, and the four places it misleads you

This is the most technical stretch of the post, and it is worth ten minutes of your attention for one reason: the Z-score is the method behind most homegrown alerting and a fair amount of purchased alerting, and understanding it is the difference between trusting your alerts and being quietly misled by them. You do not need a statistics background for what follows.

The idea is simpler than the name. A Z-score answers one question: how unusual is today, compared to this entity's own recent past? Take the last 28 closed days, work out the average and how much the metric normally bounces around day to day (the standard deviation), then measure how far today sits from that average, counted in units of normal bounce. Operators call those units sigma. A day within one sigma is ordinary. A day three sigma out is a move the entity's own history does not explain. In a spreadsheet that is one AVERAGE, one STDEV, and one subtraction per row, which is why a first version takes an afternoon.

Built that way, it will also mislead you in four specific places.

Ad metrics are not normally distributed. Spend, clicks, and orders are counts bounded at zero and skewed right. A 2-sigma threshold quietly promises that only about 5% of ordinary days will trip it, and that promise comes from textbook assumptions, not from your data. Treat sigma as a dial you tune, not a probability you can trust.

Day-of-week seasonality is stronger than most of the anomalies you are hunting. A Sunday scored against a window of weekdays looks anomalous every week. Either compare like days, building the window from the last eight Tuesdays, or deseasonalize: compute a day-of-week index from a longer history, divide each day by its index, and score the adjusted series. The second scales better for a daily scan.

The trailing window absorbs a slow drift. A gradual decline never trips a rolling Z-score because the baseline walks down with it. A target losing 2% of its conversion rate per day is down roughly 25% after two weeks (0.98 to the fourteenth power) without producing one flag, because each day sat within a standard deviation of a mean that was quietly falling. Slow decay is invisible here by construction, not by misconfiguration.

One outlier hides the next one. A spike day enters the baseline, pulls the mean toward itself, and inflates the standard deviation, so the next genuine spike scores lower against a wider band. A problem persisting for a week gets flagged on day one and goes quiet through day seven. Excluding previously flagged days from the baseline is the cheap fix.

The fixes are within reach, and they are worth knowing by name because they separate a scan you trust from a scan you mute. Swap the average for the median (the middle value) and the standard deviation for the median absolute deviation (the typical distance from that middle), and one wild day stops distorting the baseline, because neither number moves much when a single observation goes strange. For counts like clicks and orders, the sharper question is the plain one: how surprising is 12 orders on a day when the recent rate implies 4? Statisticians answer it with Poisson or negative binomial models, and the names matter less than the question, which any analyst or vendor you evaluate should be able to answer for you.

Setting the threshold: how many alerts will you really read each morning?

There is no correct threshold, and no textbook will hand you one. There is only the number of alerts a person will read carefully before they start skimming, and that number is small. So invert the problem: decide how many alerts per morning the operator will work through across the accounts they own, backtest candidate thresholds against 90 days of your own history, pick the one that would have produced that volume, then tighten as trust builds. A threshold set this way is an operating decision about attention rather than a discovery about your data, and it lands on a different number for a 200-target account than for a 13,000-target one.

That framing prevents the failure mode that kills most alerting projects. A scan firing 80 times a morning gets muted inside two weeks, and a muted scan is worse than no scan, because the account now has the feeling of coverage without the coverage.

Scan enough targets and noise alone trips alarms: three floors that fix it

Scan 10,000 targets a day at 2 sigma and roughly 460 of them will breach by pure chance, flags that mean nothing. Tighten to 3 sigma and noise still produces about 27 a day. Accounts at this scale are ordinary: we have looked at one where roughly 44% of 60 days of ad spend produced zero sales across 13,000 targets. Raising sigma is the least effective response, because it throws away small real breaks along with the noise. Three floors work better:

• A volume floor. Below a minimum click count per metric, no conclusion gets drawn, and the entity is monitored one level up instead.
• A materiality floor. A flag has to clear a dollar impact worth a person's minute. A 3-sigma move on a target spending $1.40 a day is statistically real and operationally nothing.
• Grouping. One cause produces many flags, so flags sharing a campaign, an ASIN, or a day collapse into a single alert with the pieces underneath it.

The known-cause layer: an anomaly is only worth an alert if it is unexplained

This is the step that separates a scan people use from a scan people mute, and almost nobody builds it. A statistical flag is a candidate. It becomes an alert only after it survives a check against what you already know about:

• Changes you made on purpose. A bid or budget you moved yesterday, a campaign you paused, a rule that fired exactly as written.
• Inventory events. A SKU out of stock or heading there while campaigns keep bidding into it.
• Price and Buy Box events. A price change, a lost Buy Box, a competitor's promotion.
• Calendar effects. Prime Day, a holiday, your own deal or coupon window.

Ad metrics moving because the product went out of stock is an inventory event, and routing it to the ads inbox wastes the one thing the scan exists to protect. The uncomfortable part is that this layer is semantic rather than numeric. Deciding whether Monday's spend drop is explained by the budget you changed on Sunday is a judgment about your own account, and no threshold expresses it. In practice it means a suppression list with expiry dates and a logged explanation every time you dismiss a flag.

What anomaly detection cannot do

It finds changes, not causes, so every flag arrives as a question and the diagnostic work behind it is unchanged. It is blind to slow decay, which needs a different comparison: this period against the same period last year, or against a fixed reference window rather than a moving one.

And it cannot tell you whether the change is bad. A CPC spike on a target that also converted better is a target worth more money. A spend drop is a problem if you lost impression share and a success if you capped a wasteful campaign on purpose. Direction and desirability are separate questions, and only the first is statistical.

Four ways to detect ad performance changes, compared

Reactive detection versus the scheduled review: run both, for different jobs

There is a live argument among operators that a good anomaly scan makes the rigid weekly review obsolete, and it is half right. A scheduled review catches slow decay, the class of problem a scan cannot see, and it is where structural questions get asked: whether the branded-term allocation still makes sense, whether a match type has outlived its purpose, whether a set of campaign rules is still doing what it was written to do. Those need a hypothesis, and a scan does not form hypotheses.

An anomaly scan catches the sudden break a weekly review finds five days late, five days of spend later, and it covers the long tail no review reaches. One operator with five years in the channel described his review as evaluating 7, 14, 30, 60, and 90 day windows against different placement and audience cuts, and said instinct does not scale. Picking a side is a worse answer than running both with clear boundaries: the scan owns sudden breaks and the long tail, the review owns trends and structure.

Where a spreadsheet-and-pivot-table pass breaks down

Building this once in a spreadsheet is a legitimate move, and you will understand your own thresholds afterward in a way no purchased alert teaches you. If you have never built one, the path looks like this: download a bulk report from the ads console, arrange it so each row is one campaign-and-target and each column is a day, then add three columns per metric: its recent average, its typical day-to-day bounce, and how far today sits from that average. Sort by the last column and the strangest movers rise to the top.

Where it breaks down is repetition and judgment. Every morning across a roster means a data pull, a baseline recompute that excludes previously flagged days, a day-of-week adjustment, floors per metric and per account, alert grouping, a suppression list, and then the known-cause pass. That last step is the hard one, because deciding whether Tuesday's collapse was an ad problem or an inventory problem is a semantic judgment about a specific account on a specific day, and a numeric rule does not make it. Somebody also has to notice on the morning the scan silently fails to run.

Where Qore fits

That gap is what Qore is for. You describe the scan to Qore once, the way you would brief a new analyst: what to watch, at what grain, what counts as normal, what is too small to matter, and which causes explain a flag away. Qore turns that into logic you can read and correct, then runs it every morning across the roster. The same inputs return the same output, so this week's flags compare cleanly to last week's instead of being a fresh opinion each time. The part that earns its place is the known-cause pass, because that step is contextual judgment rather than a numeric rule, and it is the step spreadsheet scans skip.

Any resulting action starts gated on your approval, and that gate is a setting you tune rather than a permanent state. A scan is a good place to see why. Most of what it proposes is routine, a pause on a target that has cleared your volume and dollar floors and matches a pattern you have approved thirty times, and once you have watched it make that call correctly for a month you can tighten the rules until those apply on their own and only the ambiguous flags reach a person. The alerts you actually want to read in the morning are the ones the skill could not resolve itself.

The honest limit: it codifies your standard, it does not invent one. If you have not decided what counts as material in dollars, or which causes should suppress an alert, a scheduled scan will produce your undecided judgment faster and every morning. Qore reads, analyzes, and can make an approved change on any account, whatever runs the bids. If a third-party automation later overwrites that change, the limitation is that tool's. Continuous, always-on execution is Qinetix's job, and it is a separate product.

Start with three metrics and a threshold you will actually read

Amazon PPC anomaly detection is less about statistics than about attention. The math is a rolling baseline, a robust dispersion measure, and a threshold. What decides whether it works has no formula: the grain you scan at, the volume floor below which you refuse to draw conclusions, the false-positive budget you set against how many alerts a person will read, and the known-cause list that keeps inventory problems out of the ads queue.

Start with three metrics at campaign-and-target grain, a volume floor, and a threshold tuned to ten alerts a morning, then add known-cause checks as you find yourself dismissing the same flag twice. Keep the weekly review, because the slow decline a scan cannot see is still the thing most likely to cost you the quarter.

The bottom line for ecommerce teams

• Scan at campaign-and-target grain. Account dashboards look calm through most of the failures worth catching, because aggregation is averaging.
• Set a volume floor per metric. Zero orders on six clicks happens 53% of the time at a 10% conversion rate. Below the floor, draw no conclusion and monitor a level up.
• Add a dollar floor as well. A 3-sigma move on a target spending $1.40 a day is statistically real and operationally nothing.
• Pick the threshold from your attention budget. Decide how many alerts get read each morning, then backtest 90 days to find the sigma that would have produced that number.
• Never scan the current day. Partial attribution against a settled baseline manufactures a conversion-rate collapse every morning.
• Build the known-cause filter. An inventory problem routed to the ads queue costs you the attention the scan exists to protect.
• Keep the weekly review. Slow decay is invisible to a rolling baseline, and it is the thing most likely to cost you the quarter.

If you are re-deriving what a material ACoS move even is for a given SKU, our ACoS calculator sets that floor faster than a fresh spreadsheet.