The Use-Case Divide that Drives Sensor Decisions

In our flow-analytics sensor technology decision-tree, the fundamental split in the flow is based on what turns out to be THE fundamental divide in people measurement use cases. Do you just need to count people, or do you need to track individuals? This may be (and often is) a relatively straightforward question. If you want to track shoppers in a retail store and know what drives conversion, you need to track individuals. If you want to count how many fans are in a grandstand, you need to count people.

Simple right?

But not every use case is quite that clear-cut. Consider, for instance, queue management? Is it a counting people application or a tracking individuals’ application? It depends. It depends on exactly what you want to measure inside the queue and how you want to do your queue analytics. If you just need a count of how many people are in line right now, then it’s a counting application. But if you need to know how long someone spent in a line, then you need to track individuals.

In this post, I’m going to take the most common applications of flow analytics (beginning with queue management) and work through how to think about defining your requirements for each. It’s a surprisingly interesting and revealing exercise.

?

Queue Management

If you just need to know how many people are in line, you need people counting – something that can often be done with a basic CCTV camera (that may already be installed) and appropriate ML inferencing. This is the cheapest and easiest people-measurement approach. On the other hand, if you need to track things like time at processing station, individual wait times, wait times by line, time by process step (e.g. an airport queue where you want to measure time in initial line, time at security station, time loading luggage, time screening, and time in pickup), or # of stations open – you usually will need individual tracking. In one fairly specific case, you can use a blend of counting and tracking technologies. If your main interest is in getting accurate wait times and throughput numbers, you can put individual tracking over the processing stations and use counting for the line waiting areas. Individual tracking lets you measure throughput and also supports much more accurate stations open counting. If you then use a count of people in line to calculate a wait time based on stations open, you can derive predicted wait times with considerable accuracy. Why do it this way? In public spaces, the queue waiting areas can be VERY large. Covering those areas with sensors capable of individual tracking may be quite expensive. By confining the individual tracking area to the much smaller processing area, you can dramatically reduce costs on very large queues and still get very good measurement.

?

Door Counting (Flow at a Chokepoint)

Though it has counting in the description, door-counting turns out to be more akin to individual tracking. You can’t snapshot a scene once a minute (or even every second) and then count the people in it. Door counting requires constant real-time tracking and, to get it right, you have to be able to measure how many people cross from one side of an arbitrary line to the other. To do that takes individual tracking. That’s why the sensor we use most often for counting people flow at a chokepoint (a Xovis Camera) can also be used for full-journey tracking.

?

Occupancy & Utilization

This has got to be counting people, right? Umm…maybe? Here’s the deal with occupancy – there are two basic methods of measuring occupancy. Unsurprisingly, the best and almost always the most accurate method is to count how many people are in the space. So, yes, counting people. However, not every space lends itself to that approach. Suppose you have an office space or a health-care facility with lots of individual rooms. Or, at the other end of the spectrum, suppose you have a football arena with an event complex approximately the size of a small town. Even a retail store with a lot of high shelving/display can be almost impossible to snapshot.

When you don’t have easy lines of sight across a location, generating a count is impossible with lidar or camera. Nor is electronic data much help since public electronic data collection never gets more than an unrepresentative sample of the people in a space. That doesn’t mean measuring occupancy is impossible – it means you have to count ins/outs at chokepoints and calculate the current occupancy.

For most spaces, calculating occupancy means door-counting, making occupancy an application that sometimes requires individual tracking. Note that while door-counting is one of the most accurate people-measurement applications, using door-counting to calculate occupancy is VERY demanding. Suppose you have an arena event with 50K people. If your door-counting is 99% accurate, your occupancy count may be off by 500 people at the end of the day. In traditional door-counting, that type of error is trivial. But when you change the name of the metric from count to occupancy, people suddenly think about it differently. And when your application says there are 500 people in an empty stadium, the user is likely to complain! Telling them your 99% accurate isn't going to cut much water even though it happens to be true.

Like queue management, occupancy calculation also has a hybrid solution. For live events, you can use ticket scans for ingress and count exits to get occupancy. Why do it this way? Ticket scans are the most accurate source for ingress, and if you want to track intra-day occupancy to sell additional event tickets, counting outs is much easier and more accurate than counting ins (or counting outs at the end of an event). I’ll cover this specific use-case and why it takes maximum advantage of the technologies involved in my next post.

?

Crowd Density

This isn’t a use-case, pre-PMY, that I needed to worry about. But for live events, crowd-crush is a significant problem. As someone with a touch of enochlophobia, I totally get this. Yet irrational fears aside, there have been some truly terrible incidents at live-events where crowd density got too high, and people died. Measuring crowd density isn’t quite as simple as counting because density isn’t uniform across the space. From a practical perspective, though, crowd density measurement is very similar to counting (and will mostly drive you along the same technology decision path) but it requires a little more sophistication out of the ML inferencing engine. Instead of just counting for an area, the ML needs to be able to generate coordinates for each individual or calculate maximum density. On the whole, I still classify this as a counting exercise, but it’s important to realize that just because you can take a camera feed and produce a count doesn’t mean you can take a camera feed and produce measures of density. Yes – it’s always possible – it’s just not the same thing.

?

Everything Else

There are always people measurement use cases turning up, many of which I have never contemplated or seen before even after years of working in this space. However, as a rule of thumb EVERYTHING else is likely to require individual tracking. Most use-cases do require individual tracking and – as discussed – even every day and apparently simple use-cases like door-counting require individual tracking under the hood. If you want to measure anything about a journey, any form of dwell metrics or conversion metrics, anything with demographics or segmentation, you’ll need individual tracking. That being said, there may be a significant number of use-cases that would reward hybrid approaches of the sort I described for queue management. Sometimes, the ability to combine counting of a large area and detailed measurement of a smaller area can get the job done with maximum efficiency.

And, of course, it's our job to help you figure that out before you buy a bunch of sensors.