These days, alerting isn’t all that complex. It’s trivial to integrate email and texting into an application – and supporting Webhooks isn’t much harder. This kind of integration used to be challenging but it just isn’t anymore. So, what is challenging with alerting? Performance. Realtime applications demand real-time performance and that can be a challenge at every step in the pipeline. In a people-measurement system based on LiDAR, the middle-ware system has to ingest the point-cloud and identify and locate objects. It must pass that data to our system. We have to position on the digital map, check for potential stitches, apply data cleaning rules, identify relevant behaviors (like entering an associate area), and then use all of that to…check for alerts. That’s a lot – it all must happen inside a few seconds – and so does what comes next.

The alerting has to be able to ingest the record, evaluate if it triggers any rules, evaluate if those rules have any restrictions on being triggered too often, and then do the easy part – fire off the alert. Oh, and it needs to create a record of the alert too so that people can figure out what got sent and if it got actioned.

For our DM1 alerting, we realized that we actually had two different sources of information that we needed to support. For queue and occupancy based alerts, we could use our existing MQTT feed that already has a rich backend to calculate queue and occupancy by area. It publishes messages that include current line length, current  occupancy, estimated wait time and registers open every time there is a change.

Ingesting that into the Alerting engine makes it easy. We don’t have to worry about processing individual journey metrics. We don’t have to do any calculation at all. And we get to take advantage of all the work that’s been done on that back-end – things like smoothing and registers open calculations. So alerting based on lines and occupancy turns out to be the easy stuff given work we’ve already done. That’s also true for clients who just want to consume those feeds – it’s not really a lot of work.

It turned out to be a lot harder to build alerting based on individual actions. The most common alert of that type is the dwell. People often want to trigger an alert when a customer has spent a certain amount of time in an area. Building that alert means checking every event to see if it’s in a defined area. If it is, tracking how long that person has been there. And if the dwell time exceeds the alert, triggering the message. There’s a fair amount of complexity here since you need to track continuous time in an area for every individual in the space. Making that sort of logic performant can be hard. And it just gets worse as the alerting requirements become more complex. Alerting on lack of interaction or dwell time without interaction not only requires interaction tracking, but requires tracking the time since those interactions by individual and by section.

It’s hard. Not necessarily hard to do, but hard to make happen fast enough to matter. Because that’s the real trick to effective alerting.

To find out more check out this overview of DM1 alerting: