Competitor Price Alerts: Build a System That Cuts Noise

A monitor that scrapes every SKU every hour is not yet an alert system. It is a data feed with no opinion. The team has the data, opens the dashboard, sees that competitor #2 dropped its basket median by 6% overnight, and closes the tab. Tomorrow it happens again. By Friday the dashboard is muted. The problem was never the scraping cadence — it was the missing layer between "the price moved" and "someone needs to know about this specific move right now."

What a competitor price alert actually is

A competitor price alert is a narrow, opinionated event: a threshold was crossed on a defined surface, the move was deduplicated against recent history, and a channel fired with a recommendation attached. Three components, in order:

1. A defined surface. Not "the competitor's catalog" — a specific SKU or basket, against a specific competitor list, against a specific reference price (your list, your cart, your last week's median). Alerts without a defined surface are noise.
2. A threshold rule. Percentage or absolute, sign-aware or not, with a configured cooldown so the same move doesn't fire three alerts in an hour. The rule is opinionated on purpose: a 2% drop on a $9 SKU is not the same event as a 2% drop on a $900 SKU, and a generic "alert on every change" pipeline will treat them identically.
3. An attached recommendation. Every alert ships with a next action: hold, raise, drop, or unavailable. Alerts without a recommendation are status updates. The team reads them, does nothing, and learns to mute them.

An alert without a recommendation is a notification. A notification is a thing you mute. An alert that arrives with a hold/raise/drop verdict is a thing you ship against.

Designing thresholds that fire on signal, not noise

Threshold design is the most underrated part of the pipeline. The defaults that ship in most tools — "alert on any change" or "alert on 5%" — are wrong for almost every real catalog. Two design decisions matter:

Percentage vs absolute thresholds

Percentage thresholds are tunable across the catalog but mislead on long-tail SKUs where the absolute move is small in dollars. Absolute thresholds are accurate per-SKU but become a configuration burden at scale. The honest answer is both: a percentage guard catches the burst (a competitor's flash promo drops 18%), and an absolute guard catches the slow drift on long-tail SKUs where the percentage change is small but the dollar move compounds.

Sign-aware rules

A 3% drop and a 3% raise are not the same event. A drop below your price is a defensive move that often warrants same-day action; a raise above your price is an opportunity that usually waits for the weekly digest. Configure them separately — the drop gets a tighter cooldown and a faster channel, the raise gets a batched digest — and the alert volume collapses by an order of magnitude on a calm week.

Deduping, quiet windows, and batching

A monitor that fires one alert per scrape is a noise machine. The same competitor can produce six "moves" in an hour as their site rebalances, and a naive pipeline ships six notifications. Three habits keep the channel usable:

• Dedupe window. A 60–120 minute window per (SKU, competitor) pair suppresses repeat alerts on the same surface. The first fire wins; the rest coalesce into the batched summary at the end of the window.
• Quiet hours. Most teams don't want a price alert at 03:00 local. The exceptions are floor_unreachable events and stock-driven moves that genuinely need same-day action — those bypass the quiet window; everything else queues until morning.
• Batched digests for the long tail. Same-direction moves on the same category batch into a single weekly digest. One email, eight SKUs, one recommendation per SKU. The digest is where the recommendation engine earns its keep.

Without these three, the team mutes the channel within a fortnight. With them, the channel stays open because the events that arrive are the events that matter.

Choosing the right channel for each kind of move

Channel choice is a function of urgency, not preference. The same alert sent via the wrong channel is either ignored (email for a same-day decision) or interruptive (Slack for a weekly review). The routing is the design:

1. Same-day defensive moves (your price is now above a competitor's; floor unreachable) → in-app bell + email. The team needs to see it before the next order lands.
2. Opportunistic raises (a competitor has moved up; you can raise too) → weekly digest. The decision can wait; batching it with other opportunities is the value.
3. Floor_unreachable flags (the polite undercut is no longer reachable) → Slack or in-app with explicit escalation. This is a workflow problem, not a pricing problem, and it needs the operator to widen the band, the floor, or the SKU.
4. MAP drift detected → email with the vendor-reset memo attached. This is a contractual event, not a pricing decision, and the right channel is the one that reaches the merchant's compliance lane.

Default to the cheapest channel that still meets the urgency. Most teams over-route to Slack and end up training themselves to mute the channel entirely.

Operating the alert pipeline without burning out the team

An alert system that produces 80 notifications a day is not an asset — it's a queue. Four operating rules keep it productive:

• Track the mute rate. If the team is dismissing alerts without acting on them, the thresholds are wrong. Tune the rules before tuning the channel.
• Review realized vs recommended monthly. A persistent gap between the alert's recommendation and the price that actually shipped is a workflow problem (CMS override, buyer's memo, manual promo), not a model problem. Find the override.
• Per-SKU overrides expire on a date. "Alert me on any change for SKU X until Friday" beats "alert me on any change for SKU X forever." Stale overrides are how the alert channel becomes a graveyard.
• Kill the false-positive categories. If a competitor's site rebalances every 30 minutes and produces four phantom drops per day, blacklist them from the alert surface until their cadence is sane.

Frequently asked questions

How often should competitor prices be scraped to support alerting?

It depends on category churn, not on a universal rule. Top-decile SKUs in fast-moving categories (consumer electronics, fashion) are scraped hourly; mid-tail twice daily; long-tail weekly. The scrape cadence has to outpace the category's repricing cycle or the alert is already late when it fires.

Should every alert be real-time, or are digests enough?

Neither, alone. The healthy mix is same-day real-time for defensive moves (you're now above a competitor; a polite undercut is unreachable) and a weekly digest for everything else. Digests-only hides urgent moves; real-time-only drowns the team. The routing rule is the design.

What threshold should a brand-new alert pipeline start at?

Start generous and tighten over the first month. A reasonable starting rule is a 5% percentage drop with a 90-minute dedupe window and a 24-hour quiet hours setting. After two weeks of data, drop the percentage to 3% for top-decile SKUs and raise the dedupe window to 120 minutes for the long tail. Tune from observed mute rates, not from theory.

Alerts are the layer that turns a monitor into a tool. The other posts in this sequence cover the upstream inputs (what to scrape, how often) and the downstream behavior (what to do with the alert once it fires).

For the inputs to the alert pipeline — sources, cadence, and dedupe boundaries — see our competitor monitoring guide. For the diagnostic queries that catch alert-quality drift — collapsed bands, stale thresholds, forgotten quiet hours — see competitive pricing bands. To see alerts firing against real competitor data, try the pricing report tool, or compare the tier with scheduled monitoring on the pricing page.