Anomaly Detection: Catching Price Spikes, Inventory Shifts, and Catalog Changes

You cannot personally watch every product on every store you monitor. Even with alerts configured for specific thresholds, there are patterns that only become visible in aggregate: a competitor quietly removing thirty percent of their catalog, a sudden cluster of price increases across a product line, or a platform migration that changes how the store behaves.

Anomaly detection handles this layer. It learns what normal looks like for each store over time, then flags deviations that are statistically significant. You do not configure the thresholds. The system builds its own understanding of each store's rhythm and tells you when something breaks it.

What Anomaly Detection Watches For

Bonesaw tracks five types of anomalies, each surfacing a different kind of competitive signal:

Price spike. A product's price jumps well above its recent range. This could be a deliberate repricing, a data entry error, or a test price. Either way, a significant upward move on a product you are tracking is worth knowing about. The pricing signals guide covers how to distinguish meaningful price moves from noise.

Price crash. The opposite: a product's price drops well below its recent range. This might signal a clearance, a competitive response, or the beginning of a broader price war. A single price crash is a data point. Multiple crashes across the same store or category is a pattern.

Churn spike. More products removed from the catalog than usual. Stores routinely add and remove products, but a sudden spike in removals could indicate a supplier change, a product line sunset, or a strategic shift. If a competitor is pulling out of a category you both serve, that is tactical information.

New product surge. More products added to the catalog than usual. The mirror image of churn: a burst of new listings might signal a seasonal launch, a new supplier relationship, or expansion into a new category. The catalog change monitoring playbook covers how to evaluate these additions systematically.

Stack shift. A change in the store's detected technology or platform. Replatforming from Shopify to WooCommerce, adopting a new reviews tool, or switching payment providers. Stack changes often correlate with periods of operational disruption or strategic investment.

Beyond these five, Bonesaw also tracks crawl issues: repeated scan failures for a store that was previously scannable. Persistent crawl problems usually mean something changed about how the store handles traffic, and it might affect your monitoring coverage.

How It Decides Something Is Unusual

Anomaly detection is not based on fixed rules. It uses a rolling 30-day window to build a statistical baseline for each store and product. The baseline captures what typical behavior looks like: normal price variance, typical catalog churn rate, usual rate of new additions.

When a new data point arrives, the system compares it against this baseline. If the deviation is statistically significant, meaning it falls far enough outside the normal range, it is flagged as an anomaly. Small, routine fluctuations get ignored. Only changes that genuinely break the pattern trigger a flag.

This approach has two important implications. First, the system needs data before it works. A brand-new store with only a few days of history does not have a meaningful baseline yet. Anomaly detection starts becoming useful after roughly a week of monitoring, and it gets more accurate as more data accumulates. Second, the system adapts. If a store naturally has high price volatility, the baseline adjusts to reflect that, so you are not flooded with anomaly alerts for a store that just happens to move prices frequently.

For stores with thin data (fewer than a handful of scans), the system falls back to a simpler percentage-change check. This means you still get flagged for very large deviations even before a full statistical baseline is built, but the detection is less nuanced until more data accumulates.

Where Anomalies Appear

Anomalies surface in several places, so you will see them regardless of how you use Bonesaw:

Anomalies dashboard. The dedicated anomalies page at /app/anomalies shows all flagged anomalies across your watched stores. You can filter by time range and severity to focus on what matters most.

Store detail page. Each store's detail view includes an anomalies section showing recent flags for that specific store. This is useful when you are reviewing a particular competitor and want to know if anything unusual happened recently.

Weekly report. Your automated weekly report includes an anomaly summary section. This means you catch significant deviations even if you do not log into the dashboard between reports.

Digest emails. If you have digest delivery configured, anomalies are included in your daily or weekly digest alongside price changes and other alerts. The alert thresholds guide covers how to tune your digest delivery for the right signal-to-noise ratio.

Severity and Filtering

Not every anomaly is equally important. A small price spike on a low-priority product is less urgent than a massive catalog churn event on your main competitor. Bonesaw assigns severity based on the magnitude of the deviation and the type of anomaly.

The anomalies dashboard includes filters for both time range and severity. If you are doing a deep review, you might look at everything from the past thirty days. If you are doing a quick check, filtering to high-severity anomalies from the past week surfaces only the most significant events.

The dashboard shows anomalies only for stores you are actively monitoring. This is a "watched feed," meaning you will not see noise from stores you have not opted into tracking. Every anomaly you see is relevant to your monitoring scope.

When to Act vs When to Ignore

The hardest part of anomaly detection is not generating the flags. It is deciding which ones deserve your attention. Here is a practical framework:

Price spike on a single product. Check whether it is a real repricing or a data issue. Visit the product page to verify. If real, consider whether the price increase signals a supply constraint, a margin play, or a positioning change. If it is on a product that directly competes with yours, it might create an opportunity for you.

Catalog churn spike. A sudden wave of product removals warrants a closer look. Is the competitor exiting a category? Clearing discontinued inventory? Dealing with a supplier issue? Check which products were removed. If they overlap with your catalog, the competitive implications are different than if they are in an unrelated category.

New product surge. A burst of new listings is usually good news for competitive intelligence. Check whether the new products enter your category or adjacent ones. A competitor adding products in a category they were not previously in may be signaling expansion. The competitor launch tracking guide covers how to evaluate these signals systematically.

Stack shift. Technology changes are relatively rare, which makes them significant when they happen. A platform migration means the competitor is investing time and resources in their infrastructure. During the migration period, they are often less responsive to market changes. If you detect a stack shift, note it and watch for follow-on changes in the coming weeks.

Crawl issues. Persistent scan failures usually resolve on their own. If a store that was scanning fine suddenly starts failing, it might mean the store changed something about its configuration. If failures persist for more than a few days, it is worth checking whether the store is still accessible. The store health issue triage guide covers how to read and respond to these kinds of monitoring problems.

Anomalies and Alerts Working Together

Anomalies and alerts serve different purposes, and they work best as complements rather than replacements for each other.

Alerts are rule-based. You define what you care about: notify me when this product's price drops more than ten percent, or when a new product is added to this store. Alerts fire on specific, predictable events.

Anomalies are pattern-based. You do not define the rules. The system learns what is normal and flags deviations. Anomalies catch things you did not think to set a rule for.

Together, they cover both the expected and the unexpected. Alerts handle the events you anticipate. Anomalies catch the ones you did not. If you are only using one, you are leaving a gap. Setting up both gives you a comprehensive monitoring posture without requiring you to anticipate every possible scenario.

Frequently Asked Questions

How long before anomaly detection starts working on a new store?

The system needs baseline data, which builds over the first several days of monitoring. You may see some anomaly flags within the first week using the simpler percentage-change fallback, but the statistical baseline becomes meaningfully accurate after about two weeks of consistent scanning.

Can I adjust the sensitivity of anomaly detection?

Thresholds are automatic and adaptive. The system calibrates based on each store's observed behavior, so a store with naturally high price volatility will have a wider "normal" range than a stable store. You do not need to tune anything manually.

Do anomalies show up in my alert notifications?

Anomalies are included in digest emails if you have digest delivery configured. They also appear in your weekly report. However, individual anomaly events do not trigger the same real-time alert notifications as price drop or new product alerts. Anomalies are designed for strategic review rather than instant response.

What if I see an anomaly that looks like bad data?

Occasionally a scan might capture an unusual data point that does not reflect reality. If you see a price spike or crash that does not match what the store's product page actually shows, it is likely a transient data issue. These self-correct on the next scan, and the anomaly can be safely ignored.

---

Bonesaw is a product of MoonsLink. Monitoring capabilities described in this guide reflect publicly accessible product data collected through standard web protocols. Bonesaw does not access private or authenticated data. All data collection respects robots.txt directives and site access policies.