State-change dedup, explained
The single most common reason people turn off stock alerts is that they fire too much. RSI drops below 30 once, and now you're getting pinged every five minutes for the next two hours while it bounces around the threshold. Here's how Tickerbot solves that.
The naive implementation
The simplest possible alert system works like this:
- User defines a condition. ("RSI under 30 on AAPL.")
- Every five minutes, the system evaluates the condition.
- If the condition is true, fire a notification.
Looks fine on paper. In practice, here's what happens: AAPL's RSI dips to 29.8 at 10:00 AM. You get a notification. The condition is still true at 10:05, so you get another one. And another. RSI bounces to 30.1 at 10:30 (no alert), but drops back to 29.4 at 10:35 — another notification. By the end of the day you've gotten 14 alerts about a single oversold event.
You'd turn the alert off. Most people do. That's why most alert systems are considered useless after a week.
The fix: state-change dedup
The core insight is that you don't actually want to be told when the condition is true. You want to be told when the condition becomes true after being false. There's a difference.
One notification per event, not one per evaluation.
In Tickerbot, every alert remembers its previous result set. Each evaluation compares the current matches to the previous matches and fires only on new additions.
It generalizes to any condition
The same logic applies to multi-condition queries. "Stocks where RSI is under 30 AND price is below VWAP AND volume is above 2×" returns a set of tickers every evaluation. State-change dedup compares this set to the previous set and fires only on new entrants.
That's also what makes the system feel quiet during noisy markets. If a condition stays true for hours, you don't get hourly nags. You got the alert once when the state changed; the rest is up to you.
The edge cases
A few things we had to figure out the hard way:
- What about a ticker that drops out and re-enters within minutes? We use a configurable cooldown per alert — default 30 minutes — so a ticker that flickers on and off the threshold doesn't double-fire.
- What about overnight gaps? The previous-result-set is reset at the start of each market day, so a ticker that was matching at 4pm and is still matching at 9:30am the next day fires fresh.
- What about scheduled events (earnings calendar, ex-div dates)? Calendar-based alerts fire once per scheduled event, not per evaluation. A different code path.
Why this matters more than the AI part
Most of what makes Tickerbot feel different isn't the natural-language input — it's that the alerts you set up actually stay set up. You're not constantly turning them off because they spam you. The state-change dedup is the unsexy plumbing that makes the whole product viable.
See it in practice
Set up an alert that would normally spam you 14 times a day. Watch it fire once.