How a Deal Alert Knows the Price Changed

No retailer notifies a deal site when it changes a price. Something went and asked, on a repeating schedule, and the alert you received is simply the difference between two answers. Once you know that, the little clock next to “price just dropped” stops being information about the shop and starts being information about the watcher.

This matters because almost every urgency signal in online shopping is built on top of that difference. The countdown, the “hurry”, the red badge — none of them came from the retailer’s pricing system. They came from a program noticing that a number it had written down was no longer the number on the page.

There is no notification, only asking

Retail prices are not broadcast. A shop changes a number in its own system, the page renders differently, and the world finds out by looking. Everything that watches prices therefore does one of three things.

It loads the page and reads it. A crawler requests the product page at intervals and records whatever price it sees. This works on any retailer, for any product, and it is the only option for most of the catalogue.

It reads a feed the merchant publishes. Some retailers push structured product data to partners — usually through an affiliate programme — refreshed on the merchant’s own schedule. Cleaner and less fragile, but limited to participating shops and to the fields they choose to include.

It waits for a person to see it. Browser extensions and community posts report the price a real shopper actually saw. This catches regional and member-only prices that a crawler never sees, but only for items people happened to look at.

Most services blend all three, and which one produced any given alert is almost never shown to you.

Checking costs money, so checking is rationed

Here is the part that explains the behaviour you notice. Looking at a page is not free. At the scale of a catalogue it is a metered utility bought by the request: the retrieval vendors that sit behind this kind of tooling sell it that way explicitly, and Serply’s published credit pricing is a plain example of the model — one credit per successful uncached request, with cached responses costing nothing at all.

Everything follows from that structure. If a fresh look costs and a repeat look from cache doesn’t, then a watcher’s engineering effort goes into not looking: caching aggressively, batching requests, and spending its real checks where they pay off. Popular products get watched often. The long tail gets watched rarely, because nobody is going to buy an alert on it.

So the interval between checks is not a technical limit. It is a budget decision, and it is different for every product on the same service.

What that does to the claims you’re shown

The timestamp is when it was noticed. An alert that says a price dropped minutes ago means the check that spotted it ran minutes ago. The change itself could be hours old. On a slowly-watched item it could be days old, which is usually enough time for the thing to sell out.

“Lowest ever” means lowest observed. A price that existed only between two checks never happened as far as the tool is concerned, and its absence looks exactly like it never existed. This is the single most common reason two trackers disagree about the same product’s history — covered in more detail in how price trackers get their data.

The alert fired on one field of one offer. A threshold crossing is a comparison between two numbers. It says nothing about which seller was selling, which variant the page was showing, or what delivery costs to your address.

A missed drop and a nonexistent drop are indistinguishable. From the outside you cannot tell whether nothing happened or nothing was seen.

Why this reliably turns into urgency

A deal service’s product is freshness. The one thing it can genuinely claim over a shopper browsing manually is that it looked more recently than you did. So the interface is built to dramatise the moment of detection: an event, a timestamp, sometimes a timer.

But the underlying fact is thin. The service knows a field changed. It does not know whether the new price is good, whether it will last the afternoon, or whether it will be back next month as part of an ordinary markdown cycle. Presenting a field change as a deadline is a design choice, and it is the choice that converts.

The funding model reinforces it. Free price tools are generally paid on affiliate commission at the point of purchase, which means the service earns when you act quickly and earns nothing when you decide to wait. That doesn’t make the alert dishonest — the price really did change — but it does mean nobody in the chain is paid to tell you that this one is unremarkable.

Using alerts properly

1. Set the threshold from your own number. Decide what the item is worth to you before you set the watch. Then the alert is answering a question you asked, rather than proposing one.
2. Treat the alert as a prompt to go and look. The authoritative price is on the retailer’s page, now, with your address and account applied. Everything else is a recollection.
3. Check the seller and the variant on arrival. Marketplace pages change hands. The offer that triggered the alert may not be the offer you land on.
4. Add delivery before comparing anything. Item price is what gets watched; the total is what you pay.
5. Ignore the clock. If the price is right for the item you already decided you wanted, buy it. If it isn’t, a timer doesn’t change that — and if the drop is structural rather than promotional, waiting costs you nothing anyway.
6. Look at the history, not the event. One drop tells you almost nothing. A shape over a year tells you whether this price is normal.

The honest summary of any deal alert is: a program looked, and the number was different from last time it looked. That is genuinely useful. It is just much less than the notification implies.