Anomaly detection: when a number does not add up

Every multichannel seller knows the moment. You are reviewing the day’s numbers, adding up sales from Amazon, MercadoLibre and your Shopify store, and suddenly something does not fit. The stock for one SKU dropped faster than what you sold. A listing that billed steadily reported zero units for two days. The commission a marketplace charged you is different from what you expected. A number does not add up, and you cannot tell whether it is a data-entry mistake, a real problem, or just eleven-at-night fatigue playing tricks on you.

The issue is not that the numbers lie. The issue is that you live spread across three or four dashboards that do not talk to each other. You open Amazon Seller Central, then the MercadoLibre panel, then the 3PL report, copy everything into a spreadsheet, and by the time you finish building the table the data is already hours old. You decide with yesterday’s snapshot. And when something falls outside the norm, you find out late: a sale that stalled without you noticing, a duplicated charge nobody reviewed, a phantom inventory the system reported but that physically no longer existed.

Anomaly detection exists precisely for that moment. Not to tell you that you sold 40 units today, but to flag that selling 40 when you had been selling 12 a day for weeks is unusual, and worth a look before it becomes a problem. It is the difference between checking everything by hand hoping to catch the error, and having the system point you only to what broke the pattern.

what an anomaly actually is

An anomaly is not the same as a high number or a low number. It is a value that drifts away from what your own business considers normal, based on its own history. If SPORTIFY sells an average of 15 pairs of a sneaker model per day, selling 0 on a random Tuesday is an anomaly. Selling 90 in one hour is too, even if it sounds like good news: it could be a real spike from a promotion, or it could be a pricing error that put your listing at half of what it should be.

The key is context. The same number can be perfectly normal in high season and completely anomalous in February. That is why useful detection is not based on fixed thresholds like “alert me if I sell fewer than 10,” but on comparing against expected behavior: the recent average, the seasonality, the day of the week, the channel’s trend. A good system learns what is normal for each SKU on each marketplace, because what is normal on Amazon is almost never what is normal on MercadoLibre.

the numbers that drift the most for a multichannel seller

In daily operations there are a handful of figures that tend to deviate and that hurt when nobody is watching them:

• Sales velocity per SKU. A sharp drop can mean your listing lost the Buy Box, got deactivated by an account-health flag, or a competitor undercut you on price. A sharp rise can be a promo that worked or a pricing error.
• Stock dropping with no sale to explain it. When deducted units do not match orders, something is off: shrinkage, mishandled returns, or a mismatch between the 3PL’s inventory and the marketplace’s.
• Fees and commissions. A charge that jumps category, a storage fee that spiked, a commission different from what was agreed. Cents per unit that, multiplied by thousands of orders, eat your margin without showing up anywhere obvious.
• Conversion and traffic. Sessions holding steady while sales fall usually points to a listing problem: a broken image, a sold-out variant, a recent negative review.
• Shipping times and cancellations. A jump in cancellations almost always precedes an account problem or a desynchronized inventory.

Each of these figures lives in a different dashboard. The real anomaly, very often, only becomes visible when you cross them: stock dropping without a sale only makes sense next to returns; a sales drop only gets explained next to traffic.

Dictionary: a stockout is running out of units available to sell, and an anomaly in sales velocity often announces it before you ever hit zero.

why the late-night spreadsheet arrives too late

The classic method is honest but fragile. You download reports, paste them, build formulas, compare against last week. The problem is threefold. First, it is manual: it depends on someone doing it every single day without fail, and the busiest days are exactly the days worth reviewing the most. Second, it is slow: by the time the spreadsheet is built, the anomaly is already hours or days old. Third, it is blind to the cross-check: a spreadsheet does not warn you proactively; you have to go hunting for the problem, and you only find what you already suspected.

Automatic detection flips the burden. Instead of you searching through hundreds of rows, the system watches every figure at once and interrupts you only when something breaks the pattern. You move from “review everything just in case” to “handle what the system flagged.” That only works if the data is unified and fresh, and that is where a single real-time source changes the rules: if Amazon, MercadoLibre and your 3PL feed the same board, the comparison stops being a puzzle and becomes automatic.

from the alert to the diagnosis

Detecting the anomaly is half the work. The other half is understanding what caused it without losing half a morning investigating. An alert that only says “sales for SKU X dropped 70%” leaves you with more questions than answers. A useful alert comes with context: when the drop started, on which channel, whether stock is still available, whether the price changed, whether traffic held. With that, in thirty seconds you know whether it is a listing, pricing or inventory problem.

This is where anomaly detection connects with the rest of your operation. A sales drop that coincides with a competitor undercutting you on price is, at its core, the same phenomenon covered by cross-channel price-drop alerts: a number that moved, a cause that lives elsewhere on the board, and a decision you have to make fast. What changes is which figure starts the thread.

Dictionary: days of inventory tell you how long your stock lasts at the current pace; when an anomaly spikes sales velocity, that figure collapses and you should react.

tuning sensitivity without going crazy

The big risk of any alert system is noise. If it warns you about everything, you stop reading it, and an ignored alert is worse than no alert at all. That is why useful detection has to be tunable. The tolerance you want for your flagship product, where one odd day deserves your immediate attention, is not the same as for a long-tail SKU that sells two units a month and whose “pattern” is basically statistical noise.

A good practice is to scale by impact: anomalies on your highest-revenue SKUs reach you instantly, through the channel you actually read, while the minor ones pile up in a daily digest you review at your own pace. It also helps to separate anomalies that require action, like an imminent stockout or an unexpected charge, from those that are merely informational, like a sales spike that already passed. The goal is not to detect more, it is to detect what matters and to trust that if something serious happens, you will hear about it in time.

the cost of finding out late

It is worth putting numbers to the abstract. An undetected stockout on your best SKU does not just cost you the sales of the days you were out; on Amazon and MercadoLibre it punishes your ranking, and recovering position takes weeks. A pricing error that stayed live through an entire weekend can sell hundreds of units at a loss before someone notices on Monday. A misapplied commission nobody disputes turns into money given away month after month.

None of those losses show up in a single dashboard as a red light. They show up as a number that, glanced at sideways, looked normal. Anomaly detection is, at its core, the discipline of not letting what does not add up slip by, and of having a system that notices it for you while you are busy selling.

Dictionary: real-time sync keeps your figures from every channel current at the same instant, which is the condition for an anomaly to be detected when it happens and not hours later.

what it looks like in practice

The healthy way to work with this is not to live glued to the alerts, but the opposite: set them up once, with good judgment, and forget them until something truly warrants attention. You define which SKUs are critical, which figures matter, how sensitive you want to be and where you want the warning to land. From there, the system compares each figure against its own pattern, channel by channel, and stays quiet while everything is fine.

The day a number does not add up, the stock falling without a sale, the billing that stalled, the fee that climbed, you will not discover it building a spreadsheet at eleven at night. You will know it when it happened, with enough context to decide whether it is urgent or can wait. That is what changes when you stop chasing numbers by hand and let a single source of truth, fresh and unified, warn you when something steps outside the norm.