Creating an alert system for rapidly changing data?

[Grayda]

I'm writing a PHP-based API around some data that is updated as frequently as once a minute, or as infrequently as once every 15 minutes. I'd like to have a cron job push alerts to end users when certain criteria is met (e.g. data goes above a certain threshold), but because my data changes so rapidly and is prone to wild fluctuations, I'm not entirely sure how to approach this. For reference, users can include, for example, people who have downloaded my Pebble smartwatch app, or my upcoming mobile phone app.

 

The data that I'm most interested in (which, if you're interested, is from the ACE spacecraft, and is used to help people view the northern or southern lights) changes every fifteen minutes, and the Kp index it provides is used as a (arguably) good indicator of how likely you are to see an aurora. Values under 5 are usually of no interest to most, anything above 5 (up to 9) are worth getting an alert about. These values can fluctuate, so if a Kp 5 storm is expected, it can hit 6, then dip to 4, then back to 5 and so forth. This is due to the particles ejected from the sun not being a nice, even "wave". I've personally witnessed nights where Kp goes up, then sits low for a while, so you head home, only to find that 10 minutes later it picked up again. Aaanyway, back to my story, I'd like to find a way to alert users about these values when they're of interest, but without bombarding them with notifications, or missing too many events.

 

Here's the various options I've considered:

 

• Send an alert every 15 minutes (too often, too annoying, not 'smart')
• Send an alert every 15 minutes, but only if the value has increased, then "reset" the check after a period of time (better, but what if it hits 7, then dips to 4 for 45 minutes, then hits 6.99? You'd miss out on an alert!)
• Find a way to check if the user has dismissed the notification and don't re-send it to them for an hour (not feasible, as Pebble's UX doesn't really allow for that, not to mention iOS doesn't have a way to notify your app when an alert has been dismissed)
• Some kind of data check, where if a value has remained high for longer than 30 minutes, it's alert-worthy and one gets sent out (but you'd miss out on stuff if the value is high for 29 minutes)
  • And riding on the back of that, if the value remains stable, prime the alert. If it increases after it's primed, send the message.

I'm more than happy to do some reading and learning. I just didn't exactly know what to search for, as I'm not dealing with something like storage space (where you can send an email if it hits < 20%, and it's unlikely that the storage will fluctuate between 20% and 21%, causing repeated messages) or rare events like CPU usage that you can alert if it stays high for longer than x many minutes

 

 

[requinix]

There are two root problems here that you can't really solve:

1. The Kp index is not completely accurate, in the sense that you cannot state "a rising value indicates a possible aurora" nor "a falling value indicates an aurora is ending" - the alternative meanings probably being due to random fluctuations and/or margins of error*.

2. Given two "high" Kp values, you don't know for sure whether they correspond to two different (chances of) auroras. For example, a change from 5->7 could indicate an increasing chance of the same aurora (such as 3->5->7) or the chance of a second aurora (as in 7->5->7).

 

Consider that the rising or falling Kp value is not an event itself but rather the symptom of an event. That is, after all, what it actually represents. What you want to do is notify users of the aurora event (or more precisely, a particular likelihood of an aurora in the near future), and do to so you use the Kp index to decide when one might start and when one might have ended. As such the question is not whether you should send a notification at a certain Kp value but whether the new measurement does/does not belong to a particular aurora event that has/has not had a notification sent. Follow that?

 

Honestly, I would pick a method, go for it, and see how it performs. Maybe you offer different options to the user so they can decide how they want their notifications?

 

My first attempt would be with your last option: define the beginning of aurora event as being a series of consecutive Kp values above some threshold for some period of time and the ending as consecutive Kp values below some threshold for some period of time. Here are two examples of that approach:

a) Auroras begin with Kp >= 5 for 10 minutes; auroras end with Kp

b) Auroras begin with Kp >= 6 for 20 minutes; auroras end with Kp

 

Also note that the second example has a buffer of uncertainty, where the Kp value can fall 6->5 for a while without being considered the end of an aurora.

 

* Speaking of margins of error, you may want to round the figures you receive. Like to the nearest tenth? Fifth? Because the hundredth between 6.99 and 7.00 shouldn't be treated as a significant difference.

[Grayda]

Thanks for the reply. Some super useful info in there, especially about Kp not being an event in itself, but a symptom of an event.

 

I might try Option B and see how it goes for a while. I'm running two separate "channels", a master API, and a beta API that I try out changes before migrating, so there's no harm in me adding in two options and spending a while evaluating both.

 

Cheers!

[CamaroMan]

to be more user friendly id stay away form using 100% thresholds.. maybe break it down - or let the user decide? maybe a 5 star rating with half stars would be less annoying.. all depends - and people vary..

 

maybe charge $5 for the live update - 

[requinix]

to be more user friendly id stay away form using 100% thresholds.. maybe break it down - or let the user decide? maybe a 5 star rating with half stars would be less annoying.. all depends - and people vary..

 

maybe charge $5 for the live update - 

None of that makes any sense. Are you in the right thread?

[Grayda]

None of that makes any sense. Are you in the right thread?

 

Actually, it made some sense to me in a way. Having various options for alerting is a good idea (e.g. user can pick to be alerted on Kp = 7, or if some value goes over a threshold. I'm still nutting out some other stuff, so I'll give proper thought to it when I get a moment.

 

And I did think of a "live" service where people would pay a subscription fee that would allow me, or a team of people, to hit a button when an aurora is detected on a webcam and / or "the gauges" look promising, but that's a bit out there, and probably something I'd look at if things took off..