Watch an app's chart position for a week and you will see it move almost every day — up two, down five, up one. Almost none of that is worth an email. An alerting system that reports every wiggle trains people to stop opening it within a month, which is a worse outcome than not alerting at all.
So the interesting design problem behind App Store rank alerts is not "detect a change." It is deciding which changes are news. Here is the logic we ship, and the backtest that shaped it.
A move has to clear a floor that scales with rank
A ten-place move means something different depending on where it happens. From rank 5 to rank 15 is a real event — you likely dropped out of a shelf people actually browse. From rank 85 to rank 95 is closer to daily noise; the difference in traffic between those two positions is small, and both are already deep in a chart that turns over constantly (see how much of the top 100 changes each day).
So the bar is not a flat number of places, it is a fraction of the better rank in the pair — 25%, with a floor of 5 so a move near the very top still has to clear a minimum. A fall from #5 to #30 is judged against #5 (floor 5, so it fires easily). A fall from #80 to #95 has to clear roughly 20 places to count. The move that matters most is always judged at the tighter scale.
One story per app, every few days, not one per wobble
An app oscillating between #48 and #52 all week is one story — "hovering around 50" — not five separate emails. A cooldown of three days caps how often a given app can trigger a plain move alert, regardless of how many times it crosses the floor in between.
Two categories of event skip the cooldown, deliberately: entering or exiting a chart entirely, and setting a genuine personal-best rank. Those are rare enough per app that gating them the same way would mean sitting on real news for days.
Milestones, and why they're the one exception with an exception
Breaking into the top 10, top 25 or top 100 for the first time is news at any delta — even a single-place move that crosses the line counts. But milestones still sit under the cooldown, and that took a specific failure case to notice: an app hovering at #52/#48 crosses "broke into the top 50" upward every other day. Without the cooldown, it gets told that four times in a week, which is both annoying and, by the third email, not really true anymore.
Rank 90 and below: exits don't count
We crawl the US top 100, which means an app sitting at rank 98 that "disappears" the next day might have fallen to rank 105 — one place outside what we can see — not actually dropped out of contention. Reporting that as an exit would be a false alarm dressed up as data. So an exit only counts as an exit above rank 90, which guarantees a real move of at least eleven places happened, not a visibility artifact.
The same problem shows up as flapping: an app parked right at the edge of visibility that appears and disappears repeatedly as it crosses rank 100. The first appearance is real news. A second crossing within the same week is not a new event, it's the same wobble being reported twice — so once an app has already flapped once in the trailing week, further crossings on that same chart go quiet until it settles.
What this cost us, measured
We don't ship these numbers on intuition. We backtested the detector against real crawl history — 54,941 chart-rows across eight consecutive crawl days, simulating one watcher per app with their own cooldown — and swept the thresholds against each other before picking one:
| Configuration | Emails / watcher / week |
|---|---|
| Entry and exit only, no move alerts | 0.53 |
| Flat 10-place floor, no cooldown | 1.70 |
| Scaled floor, no cooldown | 1.58 |
| Scaled floor, 3-day cooldown — shipped | 1.09 |
| Scaled floor, 7-day cooldown | 0.86 |
The cooldown did more work than the floor did. Tightening the floor alone bought a reduction of 0.30 emails a week; adding the three-day cooldown on top of it bought 0.49 on its own. That is why the shipped version leans on both — a floor that scales with rank, and a cooldown that stops repeat crossings from each becoming their own email — rather than trying to solve this with either one turned up further.
One caveat worth stating plainly: eight days is one week of data. It is provisional, tuned to catch obviously wrong behavior — an app disappearing because it fell one place past our crawl depth, a milestone re-firing daily — rather than a claim that 1.09 is precisely the right number forever. We plan to re-run it at 60 days once there is enough history to trust a longer window, and the thresholds live in one file specifically so that re-run is a config change, not a rewrite.
Where this shows up
None of this is abstract — it's the logic behind the watch button on every app page: confirm once, then at most one email a day, only on the days something in the list above actually happened, with one-click unsubscribe on every send. If you want to see what it looks like for a specific app, search for it and watch it from there.