Price Tracker — Who Tracks Everything Outside Amazon?

CamelCamelCamel has tracked Amazon prices since 2008. Keepa does the same with deeper historical charts and a browser extension baked into product pages. Between them, they've built the most mature price-tracking ecosystem that exists anywhere online — and it's built entirely around a single marketplace. Ask the obvious follow-up question — who tracks price history and drop alerts on everything else? — and the honest answer is: almost nobody, at any real scale.

The Amazon-only ceiling on the entire category

CamelCamelCamel's own growth is proof the demand for price tracking isn't niche or fading — the tool has kept gaining traffic month over month for years, which only makes sense if people keep discovering they want this kind of alert. Capital One Shopping, similarly, has built out coverage across roughly 100,000 retailers for coupon and cashback matching — a sign that "watch prices/deals across many stores" is a large enough job to justify serious engineering investment when someone decides to build for it broadly.

But price history and threshold alerts, specifically, stayed locked to Amazon. Neither CamelCamelCamel nor Keepa tracks Target, Etsy, Walmart, eBay, or the dozens of regional and specialty marketplaces where plenty of shopping actually happens. Smaller trackers exist for individual stores — an Etsy price-tracking browser extension here, a Target price-tracking site there — but they're single-purpose, small-team projects, not a unified system that watches a product wherever you happen to shop for it.

That leaves a structural gap: the tooling infrastructure for "tell me when this specific product's price drops" is excellent for one marketplace and nearly absent everywhere else, even though the underlying shopper behavior — "I want this, but not yet, tell me when it's cheaper" — has nothing to do with which storefront the product happens to live on.

What a real price-watch alert actually looks like

Strip away the marketing language most price trackers use and the actual mechanic is simple: you tell the system which product to watch and at what threshold, and it checks periodically, comparing the current price against your baseline. When the price crosses your threshold, you get notified with the two numbers that matter — the baseline you set and the current price — plus the percentage difference between them.

That's the entire job. It doesn't require guessing a "typical" price from scattered historical data, and it doesn't require dressing the alert up as a specific dollar amount "saved," because a coupon wasn't applied and no purchase happened yet — just an accurate before/after comparison at the moment the threshold was crossed. The value is in the timing (you find out the moment it matters, instead of checking manually every few days) and the specificity (a percentage or absolute threshold you chose, not a vague "deal alert" based on someone else's idea of a good price).

Tier structures for this kind of feature typically scale on two axes: how many products you can watch simultaneously, and how often the system checks each one. A free tier might watch a couple of products once a day; a paid tier scales up both the number of watched items and the check frequency, sometimes adding the ability to set a custom threshold percentage instead of a fixed default. None of that requires per-alert billing or complicated pricing — it's a slot-and-cadence model, the same shape used by nearly every tracking tool in this category regardless of which marketplace it targets.

What's live today, and what's on the waitlist

Cross-store, cross-region price tracking — watch a product on whatever store you actually shop at, not just the handful Amazon-focused tools cover — is not available everywhere yet. That expansion is tracked by waitlist: join the ReviewBot waitlist to register real demand for price-watch reaching more marketplaces and regions.

What's honestly true today, stated without naming any specific store: threshold-based price-watch — watch a product, get pinged when it drops below the threshold you set — is a real, shipped, production feature already running for two of the largest marketplaces in one region. Free, mid, and higher tiers each get a different number of watch slots and a different check frequency, with higher tiers unlocking a custom threshold instead of a fixed default. Alerts report the factual price change; there's no "you saved $X" framing, no guarantee language, and no manufactured urgency — just the baseline, the current price, and the percentage move between them.

The waitlist for this page isn't a bet on an unproven idea. The mechanism — periodic price checks, threshold comparison, factual drop notification — is already live and has been running long enough to have real tier limits, real cost ceilings per user, and real delivery infrastructure behind it. The open question is which additional stores and regions get that same mechanism pointed at them next, and waitlist signups are the actual input into that decision, not a symbolic gesture.

Why this gap persists instead of getting solved generically

It's worth asking why, given how mechanically simple a price-watch alert is, nobody has built a store-agnostic version that just works everywhere. The honest answer is that "simple mechanic" and "simple to build broadly" are different things: each marketplace has its own product-page structure, its own rate limits, its own terms around automated access, and in some cases its own official API with a legal-review gate before you can use it for a consumer feature at all. CamelCamelCamel and Keepa didn't stay Amazon-only because tracking other marketplaces is conceptually hard — they stayed Amazon-only because building and maintaining a reliable adapter for each additional marketplace is real, ongoing engineering and legal work, multiplied by however many stores you want to cover.

That's the same reason price-watch expansion here is sequenced by adapter and by demand rather than promised broadly on day one: an official, low-friction API path (the kind eBay's public Browse API offers, for example) is a much faster and lower-risk build than a marketplace with no public API and an access-terms question that needs legal sign-off first, the way Amazon's Product Advertising API does. Waitlist volume per marketplace is what determines which adapter gets built next, rather than committing engineering time speculatively and hoping demand shows up afterward.

How price-watch fits alongside review-trust checks

Price and trust are two different questions about the same purchase decision, and treating them as separate tools is part of why shoppers end up juggling several browser extensions and apps just to buy one thing carefully. "Is this price actually good, or just a marked-up 'discount'?" is a price-history question — the one CamelCamelCamel and Keepa answer for Amazon. "Are these reviews telling me the truth about the product?" is a trust question — the one covered on the review hub and broken down signal-by-signal on Fake Review Checker. A genuinely good purchase decision usually needs both answers, not just one.

That's why price-watch lives in the same engine as the Trust Score analysis rather than as a standalone app: a product worth tracking for a price drop is also worth checking for review manipulation before you commit to buying it once the price does drop. The two capabilities share infrastructure — the same wallet, the same Telegram bot, the same tiered access model — because they're answering adjacent parts of one decision, not because bundling unrelated features together is inherently more efficient.

What a tiered price-watch system typically looks like in practice

Most price-watch tools that scale beyond a free hobby project settle on a similar shape, and it's worth naming explicitly what "tiered" means here in concrete terms rather than abstractly. A free tier usually caps you at a small number of watched products — enough to try the feature meaningfully, not enough to track an entire wishlist — with a single daily check and a fixed default threshold (a preset percentage drop, rather than letting you dial in an exact number). A mid tier typically expands both the slot count and adds the ability to set your own custom threshold, useful if you're specifically waiting for a 20%-off moment rather than any drop at all. A top tier usually raises the check frequency from once a day to several times a day, which matters most for fast-moving flash-sale-driven categories where a good price can appear and disappear within hours.

The economics behind that tiering aren't arbitrary either: each price check against a live marketplace page costs something, even if it's a fraction of a cent, and checking fifteen products four times a day costs meaningfully more in aggregate than checking two products once a day. Slot-and-cadence tiering is how a price-watch feature stays sustainable while still being genuinely useful at every tier, rather than crippling the free tier to the point of uselessness or making the paid tier unlimited and unsustainable.

Frequently asked

The FAQ accordion above covers eligibility, threshold mechanics, and the specific honesty split between what's live and what's waitlisted. This section is the longer-form reference: the Amazon-only ceiling that CamelCamelCamel and Keepa represent even at their most mature, the mechanical anatomy of a real threshold alert (baseline, current price, factual percentage — no inflated "savings" framing), and why marketplace-by-marketplace expansion is gated by adapter effort and, in some cases, a legal review rather than being a simple feature flag to flip. If you're deciding whether to wait for coverage on your specific store, the honest next step is the waitlist link above — it's the actual signal that decides sequencing, not a mailing-list formality.